--- 1/draft-ietf-radext-rfc3576bis-11.txt 2007-10-18 22:12:08.000000000 +0200 +++ 2/draft-ietf-radext-rfc3576bis-12.txt 2007-10-18 22:12:08.000000000 +0200 @@ -1,24 +1,24 @@ Network Working Group Murtaza S. Chiba INTERNET-DRAFT Gopal Dommety Obsoletes: 3576 Mark Eklund Category: Informational Cisco Systems, Inc. Expires: April 25, 2008 David Mitton RSA Security, Inc. Bernard Aboba Microsoft Corporation - 17 October 2007 + 18 October 2007 Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) - draft-ietf-radext-rfc3576bis-11.txt + draft-ietf-radext-rfc3576bis-12.txt By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -62,32 +62,31 @@ 3.1 Proxy State ..................................... 13 3.2 Authorize Only .................................. 13 3.3 State ........................................... 14 3.4 Message-Authenticator ........................... 15 3.5 Error-Cause ..................................... 16 3.6 Table of Attributes ............................. 19 4. Diameter Considerations ............................... 22 5. IANA Considerations ................................... 25 6. Security Considerations ............................... 25 6.1 Authorization Issues ............................ 25 - 6.2 Impersonation ................................... 26 - 6.3 IPsec Usage Guidelines .......................... 27 - 6.4 Replay Protection ............................... 30 -7. Example Traces ........................................ 30 -8. References ............................................ 31 - 8.1 Normative References ............................ 31 - 8.2 Informative References .......................... 32 -ACKNOWLEDGMENTS .............................................. 33 -AUTHORS' ADDRESSES ........................................... 34 -Appendix A - Changes from RFC 3576 ........................... 35 -Full Copyright Statement ..................................... 37 -Intellectual Property ........................................ 37 + 6.2 IPsec Usage Guidelines .......................... 26 + 6.3 Replay Protection ............................... 27 +7. Example Traces ........................................ 27 +8. References ............................................ 28 + 8.1 Normative References ............................ 28 + 8.2 Informative References .......................... 29 +ACKNOWLEDGMENTS .............................................. 29 +AUTHORS' ADDRESSES ........................................... 30 +Appendix A - Changes from RFC 3576 ........................... 31 +Full Copyright Statement ..................................... 33 +Intellectual Property ........................................ 33 1. Introduction The RADIUS protocol, defined in [RFC2865], does not support unsolicited messages sent from the RADIUS server to the Network Access Server (NAS). However, there are many instances in which it is desirable for changes to be made to session characteristics, without requiring the NAS to initiate the exchange. For example, it may be desirable for @@ -117,27 +116,27 @@ Existing implementations of this protocol do not support authorization checks, so that an ISP sharing a NAS with another ISP could disconnect or change authorizations for another ISP's users. In order to remedy this problem, a "Reverse Path Forwarding" check is described; see Section 6.1. for details. Existing implementations utilize per-packet authentication and integrity protection algorithms with known weaknesses [MD5Attack]. To provide stronger per-packet authentication and integrity - protection, the use of IPsec is recommended. See Section 6.3 for + protection, the use of IPsec is recommended. See Section 6.2 for details. Existing implementations lack replay protection. In order to support replay detection, it is recommended that an Event-Timestamp Attribute be added to all packets in situations where IPsec replay protection - is not employed. See Section 6.4 for details. + is not employed. See Section 6.3 for details. The approach taken with CoA commands in existing implementations results in a semantic ambiguity. Existing implementations of the CoA-Request identify the affected session, as well as supply the authorization changes. Since RADIUS Attributes included within existing implementations of the CoA-Request can be used for session identification or authorization change, it may not be clear which function a given attribute is serving. The problem does not exist within the Diameter protocol [RFC3588], in @@ -512,24 +511,26 @@ Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not present in a CoA-Request or Disconnect-Request, it is possible that the the User-Name or Chargeable-User-Identity attributes will not be sufficient to uniquely identify a single session (e.g. if the same user has multiple sessions on the NAS, or if the privacy NAI is used). In this case if it is desired to identify a single session, session identification MAY be performed by using one or more of the Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called- Station-Id, Calling-Station-Id, NAS-Port and NAS-Port-Id attributes. - To address security concerns described in Section 6.2, one or more of - the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present - in CoA-Request and Disconnect-Request packets; the NAS-Identifier - Attribute MAY be present. + To assist RADIUS proxies in routing Request packets to their + destination, one or more of the NAS-IP-Address or NAS-IPv6-Address + Attributes SHOULD be present in CoA-Request and Disconnect-Request + packets; the NAS-Identifier Attribute MAY be present. Impersonation + issues with NAS Identification attributes are discussed in [RFC3579] + Section 4.3.7. A Disconnect-Request MUST contain only NAS and session identification attributes. If other attributes are included in a Disconnect- Request, implementations MUST send a Disconnect-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included. The DAC may require access to data from RADIUS authentication or accounting packets. It uses this data to compose compliant CoA- Request or Disconnect-Request packets. For example, as described in Section 3.3, a CoA-Request packet containing a Service-Type Attribute @@ -1194,198 +1195,55 @@ NAS if it maintains its own a realm routing table. If the NAS does not maintain a realm routing table (e.g. it selects forwarding proxies based on primary/secondary configuration and/or liveness checks), then an RPF check cannot be performed. Since authorization to send a Disconnect-Request or CoA-Request is determined based on the source address and the corresponding shared secret, the Dynamic Authorization Server SHOULD configure a different shared secret for each Dynamic Authorization Client. -6.2. Impersonation - - [RFC2865] Section 3 states: - - A RADIUS server MUST use the source IP address of the RADIUS - UDP packet to decide which shared secret to use, so that - RADIUS requests can be proxied. - - When RADIUS Access-Requests are forwarded by a proxy, the NAS-IP- - Address or NAS-IPv6-Address Attributes will typically not match the - source address observed by the RADIUS server. Since the NAS- - Identifier Attribute need not contain an FQDN, this Attribute may not - be resolvable to the source address observed by the RADIUS server, - even when no proxy is present. - - As a result, the authenticity check performed by a RADIUS server or - proxy does not verify the correctness of NAS identification - attributes. This makes it possible for a rogue NAS to forge NAS-IP- - Address, NAS-IPv6-Address or NAS-Identifier Attributes within a - RADIUS Access-Request in order to impersonate another NAS. It is - also possible for a rogue NAS to forge attributes such as the Called- - Station-Id, Calling-Station-Id, or Originating-Line-Info [RFC4005]. - This could fool the Dynamic Authorization Client into sending CoA- - Request or Disconnect-Request packets containing forged session - identification attributes to a NAS targeted by an attacker. - - To address these vulnerabilities RADIUS proxies one hop from the NAS - SHOULD check whether NAS identification attributes (see Section 3) - match the packet source address. Where one or more attributes do not - match, Access-Request packets SHOULD be silently discarded. - - Such a check may not always be possible. Since the NAS-Identifier - Attribute need not correspond to an FQDN, it may not be resolvable to - an IP address to be matched against the source address. Also, where - a NAT exists between the RADIUS client and proxy, checking the NAS- - IP-Address or NAS-IPv6-Address Attributes may not be feasible. - -6.3. IPsec Usage Guidelines +6.2. IPsec Usage Guidelines In addition to security vulnerabilities unique to Disconnect or CoA packets, the protocol exchanges described in this document are susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is - RECOMMENDED that IPsec be employed to afford better security. - - Implementations of this specification SHOULD support IPsec [RFC4301] - along with IKEv1 [RFC2409] for key management. IPsec ESP [RFC4303] - with non-null transform SHOULD be supported, and IPsec ESP with a - non-null encryption transform and authentication support SHOULD be - used to provide per-packet confidentiality, authentication, integrity - and replay protection. IKE SHOULD be used for key management. - - Within RADIUS [RFC2865], a shared secret is used for hiding of - Attributes such as User-Password, as well as in computation of the - Response Authenticator. In RADIUS accounting [RFC2866], the shared - secret is used in computation of both the Request Authenticator and - the Response Authenticator. - - Since in RADIUS a shared secret is used to provide confidentiality as - well as integrity protection and authentication, only use of IPsec - ESP with a non-null transform can provide security services - sufficient to substitute for RADIUS application-layer security. - Therefore, where IPsec AH or ESP null is used, it will typically - still be necessary to configure a RADIUS shared secret. - - Where RADIUS is run over IPsec ESP with a non-null transform, the - secret shared between the Dynamic Authorization Server and the - Dynamic Authorization Client may not be configured. In this case, a - shared secret of zero length MUST be assumed. However, a Dynamic - Authorization Client that cannot know whether incoming traffic is - IPsec-protected MUST be configured with a non-null RADIUS 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 a RADIUS Access-Request to a RADIUS server. If some - RADIUS servers contacted by the RADIUS 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 Dynamic Authorization Server implementing this specification - the policy would be "Accept IPsec, from any to me, destination port - UDP 3799". This causes the Dynamic Authorization Server to accept - (but not require) use of IPsec. It may not be appropriate to require - IPsec for all Dynamic Authorization Clients connecting to an IPsec- - enabled Dynamic Authorization Server, since some Dynamic - Authorization Clients may not support IPsec. + RECOMMENDED that IPsec be employed to afford better security, + utilizing the profile described in [RFC3579] Section 4.2. - 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 Dynamic Authorization Servers implementing this specification the + IPsec policy would be "Require IPsec, from any to me, destination + port UDP 3799". This causes the Dynamic Authorization Server to + require use of IPsec. If some Dynamic Authorization Clients do not + support IPsec, then a more granular policy will be required: "Require + IPsec, from IPsec-Capable-DAC to me." For Dynamic Authorization Clients implementing this specification, - the policy would be "Initiate IPsec, from me to any, destination port - UDP 3799". This causes the Dynamic Authorization Client to initiate - IPsec when sending Dynamic Authorization traffic to any Dynamic - Authorization Server. If some Dynamic Authorization Servers - contacted by the Dynamic Authorization Client do not support IPsec, - then a more granular policy will be required, such as "Initiate - IPsec, from me to IPsec-capable-Dynamic-Authorization-Server, - destination port UDP 3799". + the IPsec policy would be "Initiate IPsec, from me to any, + destination port UDP 3799". This causes the Dynamic Authorization + Client to initiate IPsec when sending Dynamic Authorization traffic + to any Dynamic Authorization Server. If some Dynamic Authorization + Servers contacted by the Dynamic Authorization Client do not support + IPsec, then a more granular policy will be required, such as + "Initiate IPsec, from me to IPsec-Capable-DAS, destination port UDP + 3799". Where IPsec is used for security, and no RADIUS shared secret is - configured, it is important that the Dynamic Authorization Server and - Dynamic Authorization Client perform an authorization check. Before - enabling a host to act as a Dynamic Authorization Server, the Dynamic - Authorization Client SHOULD check whether the host is authorized to - act in that role. Similarly, before enabling a host to act as a - Dynamic Authorization Client, the Dynamic Authorization Server SHOULD - check whether the host is authorized for that role. - - Dynamic Authorization Clients can be configured with the IP addresses - (for IKEv1 Aggressive Mode with pre-shared keys) or FQDNs (for - certificate authentication) of Dynamic Authorization Servers. - Alternatively, if a separate Certification Authority (CA) exists for - Dynamic Authorization Servers, then the Dynamic Authorization Client - can configure this CA as a trust anchor [RFC3280] for use with IKEv1. - - Similarly, Dynamic Authorization Servers can be configured with the - IP addresses (for IKEv1 Aggressive Mode with pre-shared keys) or - FQDNs (for certificate authentication) of Dynamic Authorization - Clients. Alternatively, if a separate CA exists for Dynamic - Authorization Clients, then the Dynamic Authorization Server can - configure this CA as a trust anchor for use with IKEv1. - - Since unlike SSL/TLS, IKEv1 does not permit certificate policies to - be set on a per-port basis, certificate policies need to apply to all - uses of IKEv1 on Dynamic Authorization Servers and Dynamic - Authorization Clients. In a deployment supporting only certificate - authentication, a management station initiating an IPsec-protected - telnet session to the Dynamic Authorization Client would need to - obtain a certificate chaining to the Dynamic Authorization Server CA. - Issuing such a certificate might not be appropriate if the management - station was not authorized as a Dynamic Authorization Server. - - Where Dynamic Authorization Servers obtain their IP address - dynamically (such as an Access Point supporting DHCP), IKEv1 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 Dynamic Authorization Server addresses are - statically assigned either IKEv1 Aggressive Mode or Main Mode MAY be - used. With certificate authentication, IKEv1 Main Mode SHOULD be - used. - - Care needs to be taken with IKEv1 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 Dynamic Authorization Client and Dynamic Authorization Server to - configure themselves based on the fully qualified domain name of - their peers. + configured, it is important that the DAC and DAS perform an + authorization check. Before enabling a host to act as a DAS, the DAC + SHOULD check whether the host is authorized to act in that role. - Note that with IPsec, security services are negotiated at the - granularity of an IPsec SA, so that 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]. + Similarly, before enabling a host to act as a DAC, the DAS SHOULD + check whether the host is authorized for that role, utilizing the + mechanisms described in [RFC3579] Section 4.2. -6.4. Replay Protection +6.3. Replay Protection Where IPsec replay protection is not used, an Event-Timestamp (55) [RFC2869] Attribute SHOULD be included within CoA-Request and Disconnect-Request packets, and MAY be included within CoA-ACK, CoA- NAK, Disconnect-ACK and Disconnect-NAK packets. When the Event-Timestamp attribute is present, both the Dynamic Authorization Server and the Dynamic Authorization Client MUST check that the Event-Timestamp Attribute is current within an acceptable time window. If the Event-Timestamp Attribute is not current, then @@ -1437,80 +1295,61 @@ 8. References 8.1. Normative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. -[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", - RFC 2409, November 1998. - [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2869] Rigney, C., Willats W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, 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", RFC 3280, April 2002. - [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July 2003. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. -[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet - Protocol", RFC 4301, December 2005. - -[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, - December 2005. - 8.2. Informative References [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. -[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, - October 2000. - [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting Transport Profile", RFC 3539, June 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. -[RFC4005] Calhoun, P., Zorn, G., Spence, D. and D. Mitton, "Diameter - Network Access Server Application", RFC 4005, August 2005. - [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006. [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006. [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006. [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix @@ -1631,26 +1470,30 @@ o Use of Vendor-Specific Attributes (VSAs) for session identification and authorization change has been clarified (Section 3.6). o Added Note 6 on the use of the CoA-Request for renumbering, and Note 7 on the use of Vendor-Specific attributes (Section 3.6). o Added Diameter Considerations (Section 4). o Event-Timestamp Attribute should not be recalculated on retransmission. The implications for replay and duplicate detection - are discussed (Section 6.4). + are discussed (Section 6.3). o Operation of the Reverse Path Forwarding (RPF) check has been clarified. Use of the RPF check is optional rather than recommended by default (Section 6.1). + o Text on impersonation (included in [RFC3579] Section 4.3.7) and + IPsec operation (included in [RFC3579] Section 4.2) has been removed, + and is now referenced. + Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS