shared secret.
When IPsec ESP is used with RADIUS, per-packet authentication,
integrity and replay protection MUST be used. 3DES-CBC MUST be
supported as an encryption transform and AES-CBC SHOULD be supported.
AES-CBC SHOULD be offered as a preferred encryption transform if
supported. HMAC-SHA1-96 MUST be supported as an authentication
transform. DES-CBC SHOULD NOT be used as the encryption transform.
A typical IPsec policy for an IPsec-capable RADIUS client is
"Initiate IPsec, from me to any destination port UDP 1812". This
IPsec policy causes an IPsec SA to be set up by the RADIUS client
prior to sending RADIUS traffic. If some RADIUS servers contacted by
the client do not support IPsec, then a more granular policy will be
required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server,
destination port UDP 1812."
For a client implementing this specification, the policy would be
"Accept IPsec, from any to me, destination port UDP 3799". This
causes the RADIUS client to accept (but not require) use of IPsec.
It may not be appropriate to require IPsec for all RADIUS servers
connecting to an IPsec-enabled RADIUS client, since some RADIUS
servers may not support IPsec.
For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept
IPsec, from any to me, destination port 1812". This causes the
RADIUS server to accept (but not require) use of IPsec. It may not
be appropriate to require IPsec for all RADIUS clients connecting to
an IPsec-enabled RADIUS server, since some RADIUS clients may not
support IPsec.
For servers implementing this specification, the policy would be
"Initiate IPsec, from me to any, destination port UDP 3799". This
causes the RADIUS server to initiate IPsec when sending RADIUS
extension traffic to any RADIUS client. If some RADIUS clients
contacted by the server do not support IPsec, then a more granular
policy will be required, such as "Initiate IPsec, from me to IPsec-
capable-RADIUS-client, destination port UDP 3799".
Where IPsec is used for security, and no RADIUS shared secret is
configured, it is important that the RADIUS client and server perform
an authorization check. Before enabling a host to act as a RADIUS
client, the RADIUS server SHOULD check whether the host is authorized
to provide network access. Similarly, before enabling a host to act
as a RADIUS server, the RADIUS client SHOULD check whether the host
is authorized for that role.
RADIUS servers can be configured with the IP addresses (for IKE
Aggressive Mode with pre-shared keys) or FQDNs (for certificate
authentication) of RADIUS clients. Alternatively, if a separate
Certification Authority (CA) exists for RADIUS clients, then the
RADIUS server can configure this CA as a trust anchor [RFC3280] for
use with IPsec.
Similarly, RADIUS clients can be configured with the IP addresses
(for IKE Aggressive Mode with pre-shared keys) or FQDNs (for
certificate authentication) of RADIUS servers. Alternatively, if a
separate CA exists for RADIUS servers, then the RADIUS client can
configure this CA as a trust anchor for use with IPsec.
Since unlike SSL/TLS, IKE does not permit certificate policies to be
set on a per-port basis, certificate policies need to apply to all
uses of IPsec on RADIUS clients and servers. In IPsec deployment
supporting only certificate authentication, a management station
initiating an IPsec-protected telnet session to the RADIUS server
would need to obtain a certificate chaining to the RADIUS client CA.
Issuing such a certificate might not be appropriate if the management
station was not authorized as a RADIUS client.
Where RADIUS clients may obtain their IP address dynamically (such as
an Access Point supporting DHCP), Main Mode with pre-shared keys
[RFC2409] SHOULD NOT be used, since this requires use of a group
pre-shared key; instead, Aggressive Mode SHOULD be used. Where
RADIUS client addresses are statically assigned, either Aggressive
Mode or Main Mode MAY be used. With certificate authentication, Main
Mode SHOULD be used.
Care needs to be taken with IKE Phase 1 Identity Payload selection in
order to enable mapping of identities to pre-shared keys, even with
Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity
Payloads are used and addresses are dynamically assigned, mapping of
identities to keys is not possible, so that group pre-shared keys are
still a practical necessity. As a result, the ID_FQDN identity
payload SHOULD be employed in situations where Aggressive mode is
utilized along with pre-shared keys and IP addresses are dynamically
assigned. This approach also has other advantages, since it allows
the RADIUS server and client to configure themselves based on the
fully qualified domain name of their peers.
Note that with IPsec, security services are negotiated at the
granularity of an IPsec SA, so that RADIUS exchanges requiring a set
of security services different from those negotiated with existing
IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs
are also advisable where quality of service considerations dictate
different handling RADIUS conversations. Attempting to apply
different quality of service to connections handled by the same IPsec
SA can result in reordering, and falling outside the replay window.
For a discussion of the issues, see [RFC2983].
5.4. Replay Protection
Where IPsec replay protection is not used, the Event-Timestamp (55)
Attribute [RFC2869] SHOULD be included within all messages. When
this attribute is present, both the NAS and the RADIUS server MUST
check that the Event-Timestamp Attribute is current within an
acceptable time window. If the Event-Timestamp Attribute is not
current, then the message MUST be silently discarded. This implies
the need for time synchronization within the network, which can be
achieved by a variety of means, including secure NTP, as described in
[NTPAUTH].
Both the NAS and the RADIUS server SHOULD be configurable to silently
discard messages lacking an Event-Timestamp Attribute. A default
time window of 300 seconds is recommended.
6. Example Traces
Disconnect Request with User-Name:
0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....#
16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^..
32: 6d63 6869 6261
Disconnect Request with Acct-Session-ID:
0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(.....
16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,.
32: 3930 3233 3435 3637 90234567
Disconnect Request with Framed-IP-Address:
0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(.....
16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ...
32: 0a00 0203
7. References
7.1. Normative References
[RFC1305] Mills, D., "Network Time Protocol (version 3)
Specification, Implementation and Analysis", RFC1305,
March 1992.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
1321, April 1992.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC2401, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC2406, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC2409, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access
Identifier", RFC2486, January 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC2866, June 2000.
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
Extensions", RFC2869, June 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6",
RFC3162, August 2001.
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC3280,
April 2002.
[RADIANA] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC3575, July
2003.
7.2. Informative References
[RFC2882] Mitton, D., "Network Access Server Requirements:
Extended RADIUS Practices", RFC2882, July 2000.
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC
2983, October 2000.
[AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization
and Accounting (AAA) Transport Profile", RFC3539,
June 2003.
[Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in
Progress.
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent
Attack", CryptoBytes Vol.2 No.2, Summer 1996.
[NASREQ] Calhoun, P., et al., "Diameter Network Access Server
Application", Work in Progress.
[NTPAUTH] Mills, D., "Public Key Cryptography for the Network
Time Protocol", Work in Progress.
8. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards- related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
9. Acknowledgments
This protocol was first developed and distributed by Ascend
Communications. Example code was distributed in their free server
kit.
The authors would like to acknowledge the valuable suggestions and
feedback from the following people:
Avi Lior <avi@bridgewatersystems.com>,
Randy Bush <randy@psg.net>,
Steve Bellovin <smb@research.att.com>
Glen Zorn <gwz@cisco.com>,
Mark Jones <mjones@bridgewatersystems.com>,
Claudio Lapidus <clapidus@hotmail.com>,
Anurag Batta <Anurag_Batta@3com.com>,
Kuntal Chowdhury <chowdury@nortelnetworks.com>, and
Tim Moore <timmoore@microsoft.com>.
Russ Housley <housley@vigilsec.com>
10. Authors' Addresses
Murtaza Chiba
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose CA, 95134
EMail: mchiba@cisco.com
Phone: +1 408 525 7198
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
EMail: gdommety@cisco.com
Phone: +1 408 525 1404
Mark Eklund
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
EMail: meklund@cisco.com
Phone: +1 865 671 6255
David Mitton
Circular Logic UnLtd.
733 Turnpike Street #154
North Andover, MA 01845
EMail: david@mitton.com
Phone: +1 978 683 1814
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
11. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.