Network Working Group Paul Congdon INTERNET-DRAFT Chuck Black Category: Informational Hewlett-Packard Company <draft-congdon-radext-ieee802-02.txt> Bernard Aboba 2 November 2004 Microsoft RADIUS Extensions for IEEE 802 By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 28, 2005. Copyright Notice Copyright (C) The Internet Society 2004. All rights reserved. Abstract IEEE 802.1X-2004 enables authenticated access to IEEE 802 media, including Ethernet, Token Ring, and 802.11 wireless LANs. Although AAA support is optional within IEEE 802.1X, it is expected that many IEEE 802.1X Authenticators will function as RADIUS or Diameter clients (or both). This document proposes additional attributes for usage by IEEE 802.1X authenticators. These attributes are usable within either RADIUS or Diameter. Congdon, et al. Informational [Page 1]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 Table of Contents 1. Introduction .......................................... 3 1.1 Terminology ..................................... 3 1.2 Requirements Language ........................... 4 1.3 Attribute format ................................ 4 2. RADIUS Authentication ................................. 5 2.1 Egress-VLANID ................................... 5 2.2 Ingress-Filters ................................ 6 2.3 VLAN-Name ....................................... 6 2.4 User-Priority-Table ............................. 7 2.5 Allowed-SSID .................................... 8 2.6 Allowed-Called-Station-Id ....................... 9 2.7 NAS-Filter-Rule ................................. 9 2.8 QoS-Filter-Rule ................................. 10 2.9 EAP-Master-Session-Key .......................... 11 2.10 EAP-Key-Name .................................... 12 2.11 Redirect-Host ................................... 12 2.12 Origin-Realm .................................... 13 3. RADIUS Accounting ..................................... 14 3.1 Accounting-EAP-Auth-Method ...................... 14 4. Table of Attributes ................................... 14 5. Diameter Considerations ............................... 15 6. IANA Considerations ................................... 17 7. Security Considerations ............................... 17 7.1 Packet modification or forgery .................. 17 7.2 Dictionary Attacks .............................. 18 7.3 Known Plaintext Attacks ......................... 18 7.4 Key Management Issues ........................... 19 8. References ............................................ 19 8.1 Normative References .................................. 19 8.2 Informative References ................................ 21 Appendix A - Extended Attribute Formats ...................... 23 ACKNOWLEDGMENTS .............................................. 27 AUTHORS' ADDRESSES ........................................... 27 Intellectual Property Statement .............................. 27 Disclaimer of Validity ....................................... 28 Full Copyright Statement ..................................... 28 Congdon, et al. Informational [Page 2]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 1. Introduction IEEE 802.1X [IEEE8021X] provides "network port authentication" for IEEE 802 [IEEE802] media, including Ethernet [IEEE8023], Token Ring and 802.11 [IEEE80211i] wireless LANS. IEEE 802.1X does not require use of a backend authentication server, and thus can be deployed with stand-alone bridges or Access Points, as well as in centrally managed scenarios. As a result, support for the RADIUS [RFC2865] or Diameter [RFC3588] protocols is optional for IEEE 802.1X authenticators. In situations where it is desirable to centrally manage authentication, authorization and accounting (AAA) for IEEE 802 networks, deployment of a backend authentication and accounting server is desirable. In such situations, it is expected that IEEE 802.1X authenticators will function as AAA clients. This document defines additional attributes suitable for usage by IEEE 802.1X authenticators acting as AAA clients. 1.1. Terminology This document uses the following terms: Access Point (AP) A Station that provides access to the distribution services via the wireless medium for associated Stations. Association The service used to establish Access Point/Station mapping and enable Station invocation of the distribution system services. authenticator An authenticator is an entity that require authentication from the supplicant. The authenticator may be connected to the supplicant at the other end of a point-to-point LAN segment or 802.11 wireless link. Authentication server An authentication server is an entity that provides an authentication service to an authenticator. This service verifies from the credentials provided by the supplicant, the claim of identity made by the supplicant. Port Access Entity (PAE) The protocol entity associated with a physical or virtual (802.11) Port. A given PAE may support the protocol functionality associated with the Authenticator, Supplicant or Congdon, et al. Informational [Page 3]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 both. Station (STA) Any device that contains an IEEE 802.11 conformant medium access control (MAC) and physical layer (PHY) interface to the wireless medium (WM). Supplicant A supplicant is an entity that is being authenticated by an authenticator. The supplicant may be connected to the authenticator at one end of a point-to-point LAN segment or 802.11 wireless link. 1.2. Requirements Language In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.3. Attribute format In defining the attributes included in this document, a number of problems were encountered, including issues with RADIUS/Diameter translation and negotiation of support for security-critical attributes. Since support for RADIUS or Diameter protocols is optional for IEEE 802.1X authenticators, it is desirable for attributes defined for use with [IEEE8021X] to be usable within both RADIUS and Diameter, ideally without the need to define elaborate gateway translation rules as in [NASREQ]. This issue was not encountered in [RFC3580] since that document did not define any new attributes, while this specification does. Several of the attributes proposed in this document have security implications. If sent by a RADIUS server to a RADIUS client, these attributes may not be safely ignored, or the required security will not be provided. As noted in [RFC2865] Section 5: A RADIUS server MAY ignore Attributes with an unknown Type. A RADIUS client MAY ignore Attributes with an unknown Type. Unfortunately, in the case of security-critical attributes, the behavior that is desired is for the RADIUS client to deny access to the network on receipt of unknown attributes, rather than ignoring them. Congdon, et al. Informational [Page 4]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 In order to enable the RADIUS client to distinguish unknown attributes that may be safely ignored from attributes that must be understood in order to safely provide service, security-critical attributes need to be encoded using an attribute format which includes support for a Mandatory bit. The use of the Mandatory bit needs to be negotiated so that it will only be assumed to be usable by the RADIUS server if the RADIUS client indicates support for it. Several possible mechanisms suggest themselves for dealing with RADIUS/Diameter translation problems and the need for a Mandatory bit. For example, it is possible for IEEE 802 to define a Vendor- Specific Attribute (VSA) format that can accommodate a Mandatory bit. Another alternative is to utilize an Extended RADIUS attribute format, as proposed by [Arkko]. Other solutions are possible as well. However, for the purpose of this document, it is not necessary to take a position on the preferred approach, only to point out that we believe that these problems need to be solved. For the purposes of illustrating some potential alternatives, Appendix A describes a potential Extended attribute format based on [Arkko], and suggests how usage might be negotiated between the RADIUS client and server. Potential modifications to enable support for sub-attributes and a more efficient "short form" encoding are also described. For the purposes of calculating the attribute Length field of extended attributes, the "short form" encoding described in Appendix A is assumed. 2. RADIUS Authentication 2.1. Egress-VLANID Description The Egress-VLANID attribute represents an allowed IEEE 802 Egress VLANID for this port. The Egress-VLANID contains two parts: the first part is the VLANID, the second part indicates if this VLANID is allowed for tagged or untagged packets. Multiple Egress-VLANID attributes can be delivered in an authentication response; each attribute adds the specified VLAN to the list of allowed egress VLANs for the port. This is an Extended RADIUS attribute. Code TBD Length Congdon, et al. Informational [Page 5]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 8 M 1 - Mandatory Data-Type Integer32 Integer32 The values include: 1 = Tagged 2 = Untagged 2.2. Ingress-Filters Description 802.1Q clause 8.4.5 describes the Ingress Filter variable per port. The Ingress-Filters attribute corresponds to Ingress Filter per-port variable defined in IEEE 802.1Q clause 8.4.5. When the attribute has the value "Enabled", the set of VLANs that are allowed to ingress a port must match the set of VLANs that are allowed to egress a port. By default, where the Ingress-Filter attribute is not set, the value "Disabled" should be assumed. Only a single Ingress-Filters attribute MAY be sent within an Access- Accept or CoA-Request; this attribute MUST NOT be sent within an Access-Request, Access-Challenge, Access-Reject, or Disconnect- Request. This attribute is defined as an Extended RADIUS attribute. Code TBD Length 8 M 1 - Mandatory Data-Type Congdon, et al. Informational [Page 6]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 UInt32 UInt32 1 - Enabled 2 - Disabled 2.3. VLAN-Name Description 802.1Q-2003 clause 12.10.2.1.3 (a) describes the administratively assigned VLAN Name associated with a VLAN ID defined within an 802.1Q bridge. The VLAN-Name attribute represents an allowed VLAN for this port. It works similar to the Egress-VLANID attribute except that the VLAN-ID itself is not specified or known, rather the VLAN name is used to identify the VLAN within the system. The VLAN-Name attribute contains two parts; the first part is the VLAN name, the second part indicates if frames on the VLAN for this port are to be represented in tagged or untagged format. Multiple VLAN-Name attributes can be delivered in an authentication response; each attribute adds the named VLAN to the list of allowed egress VLANs for the port. This attribute is defined as an Extended RADIUS attribute. Code TBD Length >=9 M 1 - Mandatory Data-Type TBD - to be assigned by IANA - VLAN-Name String The String field contains the VLAN Name as defined in 802.1Q-2003 clause 12.10.2.1.3 (a). UTF-8 encoded 10646 characters are recommended, Congdon, et al. Informational [Page 7]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 but a robust implementation SHOULD support the field as undistinguished octects. Integer32 1 = Tagged 2 = Untagged 2.4. User-Priority-Table Description IEEE 802.1D clause 7.5.1 discusses how to regenerate (or re-map) user priority on frames received at a port. This per-port configuration enables a bridge to cause the priority or received traffic at a port to be mapped to a particular priority. The management variables are described in clause 14.6.2.2. This attribute represents the IEEE 802 prioritization that will be applied to packets arriving at this port. There are eight possible user priorities, according to the IEEE 802 standard. This attribute is defined as an Extended RADIUS attribute. Code TBD Length 12 M 1 - Mandatory Data-Type UInt64 UInt64 The table, expressed as a unsigned 64-bit integer, maps the incoming priority (if one exists - the default is 0) into one of seven regenerated priorities. The format of this attribute is an eight byte octet string, where the first octet maps to incoming priority 0, the second octet to incoming priority 1, etc. The values in each octet represent the regenerated priority of the Congdon, et al. Informational [Page 8]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 packet. It is thus possible to either remap incoming priorities to more appropriate values; or to honor the incoming priorities; or to override any incoming priorities, forcing them to all map to a single chosen priority. The IEEE 802.1D specification, Annex G, provides a useful description of traffic type - traffic class mappings. For mapping of the priority to quality of service at the IP layer, it is assumed that the LAN Edge Device has been provided a table with device-wide mappings of this user priority to the appropriate DiffServ code points. That table and its configuration are outside the scope of this document. 2.5. Allowed-SSID Description As described in [KEYFRAME] Section 2.5, it may be desirable for the RADIUS server to be able to restrict the scope of the EAP Key provided to the RADIUS client. In particular, it may be desirable to restrict the use of the key to a set of authorized SSIDs. The Allowed-SSID attribute allows the RADIUS server to specify which SSIDs the user is allowed to access. More than one Allowed- SSID attribute may be included in an Access-Accept packet. This attribute is defined as an Extended RADIUS attribute. The Allowed-SSID attribute is defined as follows: Code TBD Length >=5 M 1 - Mandatory Data-Type String String Congdon, et al. Informational [Page 9]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 The String field contains one or more octets, encoding a single SSID, as defined in [IEEE80211]. UTF-8 encoded 10646 characters are recommended, but a robust implementation SHOULD support the field as undistinguished octets. 2.6. Allowed-Called-Station-Id Description As described in [KEYFRAME] Section 2.5, it may be desirable for the RADIUS server to be able to restrict the scope of the AAA-Key provided to the RADIUS client. In particular, it may be desirable to restrict the use of the key to a set of authorized Called- Station-Ids. The Allowed-Called-Station-Id attribute allows the RADIUS server to specify which Called-Station-Ids the user is allowed to access. More than one Allowed-Called-Station-Id attribute may be included in an Access-Accept packet. This attribute is defined as an Extended RADIUS attribute. The Allowed-Called-Station-Id attribute is defined as follows: Code TBD Length >=5 M 1 - Mandatory Data-Type String String The String field is one or more octets, containing the layer 2 endpoint that the user's call terminated on. For details of the encoding, see [RFC3580]. UTF-8 encoded 10646 characters are recommended, but a robust implementation SHOULD support the field as undistinguished octets. 2.7. NAS-Filter-Rule Description Congdon, et al. Informational [Page 10]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 The NAS-Filter-Rule attribute enables the provisioning of Internet Protocol filters on the NAS by the RADIUS server. This attribute is defined as an Extended RADIUS attribute. The NAS-Filter-Rule attribute is defined as follows: Code 400 [NASREQ] Length >=5 M 1 - Mandatory Data-Type IPFilterRule IPFilterRule The IPFilterRule field contains an IP filter, utilizing the syntax defined for the IPFilterRule derived data type defined in [RFC3588], Section 4.3. Since the NAS-Filter-Rule AVP defined in [NASREQ] Section 6.6 also obeys the same syntax, these attributes are analogous. 2.8. QoS-Filter-Rule Description The QoS-Filter-Rule attribute enables the provisioning of QoS filters on the NAS by the RADIUS server. This attribute is defined as an Extended RADIUS attribute. The QoS-Filter-Rule attribute is defined as follows: Code 407 Length >=5 M Congdon, et al. Informational [Page 11]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 1 - Mandatory Data-Type QoSFilterRule QoSFilterRule The QoSFilterRule field contains a QoS filter, utilizing the syntax defined for the QoSFilterRule derived data type defined in [RFC3588], Section 4.3. Note that this definition contained an error, so that the complete syntax is described in the definition of the QoS-Filter-Rule AVP, defined in [NASREQ] Section ?. 2.9. EAP-Master-Session-Key Description The EAP-Master-Session-Key attribute enables a RADIUS server to provide an EAP Master Session Key to the RADIUS client, as defined in [KEYFRAME]. This attribute MUST NOT be included in an Access- Request or Access-Challenge, but MAY be included within an Access- Accept. This attribute is defined as an Extended RADIUS attribute. The EAP-Master-Session-Key attribute is defined as follows: Code TBD [DiamEAP] Length >=12 M 1 - Mandatory Data-Type String String The String field is eight or more octets, containing the EAP Master Session Key provided to the RADIUS client. In order to address the RADIUS security threats detailed in [RFC3579] Section 4.3, IPsec ESP with non-null transform MUST be used to protect RADIUS packets containing this attribute, as described in Congdon, et al. Informational [Page 12]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 [RFC3579], Section 4.2. As a result, there is no need for alternative confidentiality mechanisms. 2.10. EAP-Key-Name Description The EAP-Key-Name attribute enables a RADIUS server to provide a key name to the RADIUS client. It should be noted that not all link layers use this attribute, and currently most EAP methods do not generate it. If sent within an Access-Request, the EAP-Key- Name attribute MUST be empty (Length = 4), and a RADIUS server SHOULD include this attribute in an Access-Accept only if an empty EAP-Key-Name attribute was present in the Access-Request. This attribute MUST NOT be included within an Access-Challenge. This attribute is defined as an Extended RADIUS attribute. The EAP- Key-Name attribute is defined as follows: Code TBD [DiamEAP] Length = 4 (REQUIRED in an Access-Request) >=5 (REQUIRED in an Access-Accept) M 1 - Mandatory Data Type String String The String field is one or more octets, containing the name of the key provided to the RADIUS client. For details of the encoding, see [KEYFRAME], and [DiamEAP], Section 4.1.4. UTF-8 encoded 10646 characters are recommended, but a robust implementation SHOULD support the field as undistinguished octets. 2.11. Redirect-Host Description The Redirect-Host attribute provides support for Redirect Congdon, et al. Informational [Page 13]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 functionality, as described in [RFC3588], Section 6.12. This attribute is defined as an Extended RADIUS attribute. Code ? - Defined in [RFC3588] Length =4 (REQUIRED in an Access-Request) >=5 (REQUIRED in an Access-Accept) M 1 - Mandatory Data Type String String The String field is one or more octets, containing the full qualified domain name of the server to which the NAS should be redirected. This attribute MUST only be sent in an Access-Accept if a null Redirect-Host attribute (Length = 4) is included in an Access-Request. 2.12. Origin-Realm Description The Origin-Realm attribute contains the realm of the originator of a message, as described in [RFC3588], Section 6.4. Code 296 Length >=5 (Short Form) M 1 - Mandatory Data Type Congdon, et al. Informational [Page 14]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 String String The String field contains the fully qualified domain name (FQDN) representing the realm. 3. RADIUS Accounting 3.1. Accounting-EAP-Auth-Method Description Accounting-EAP-Auth-Method enables a RADIUS client to include the EAP method utilized within an accounting packet. The semantics of this attribute are identical to that of the Accounting-EAP-Auth- Method AVP defined in [DiamEAP], Section 4.1.5. This is a standard RADIUS attribute. The Accounting-EAP-Auth-Method attribute is shown below. The fields are transmitted from left to right: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 10 Value The Value field is eight octets. In case of expanded types defined in [RFC3748] Section 5.7, the least significant 32 bits contain the Vendor-Type field, and the next 24 bits contain the Vendor-Id field. Congdon, et al. Informational [Page 15]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 4. Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Access- Access- Access- Access- CoA- Request Accept Reject Challenge Req # Attribute 0+ 0+ 0+ 0+ 0+ TBD Extended 0 0+ 0 0 0+ TBD Egress-VLANID [a] 0 0-1 0 0 0-1 TBD Ingress-Filters [a] 0 0-1 0 0 0-1 TBD User-Priority-Table [a] 0 0+ 0 0 0 TBD Allowed-SSID 0 0+ 0 0 0 TBD Allowed-Called-Station-Id 0 0+ 0 0 0+ 400 NAS-Filter-Rule [a] 0 0+ 0 0 0+ 407 QoS-Filter-Rule [a] 0-1 0-1 0 0 0 TBD EAP-Master-Session-Key 0-1 0-1 0 0 0 TBD EAP-Key-Name 0-1 0 0 0+ 0 ? Redirect-Host 0-1 0 0 0 0 296 Origin-Realm Actng- Actng- Request Response # Attribute 0-1 0 TBD Accounting-EAP-Auth-Method The following table defines the meaning of the above table entries. 0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in the packet. 0-1 Zero or one instance of this attribute MAY be present in the packet. Notes ------ [a] This attribute MAY only be included in a CoA-Request if the NAS indicates in the Access-Request that it supports Extended attributes. Otherwise, this attribute MUST NOT be sent in a CoA-Request. 5. Diameter Considerations As described in Appendix A, the Extended attributes described in this specification are defined in both RADIUS and Diameter, and utilize the Data Types defined in [RFC3588]. Attributes already defined within Diameter, and defined as Extended RADIUS attributes within this specification include: NAS-Filter-Rule [NASREQ], QoS-Filter-Rule [NASREQ], EAP-Master-Session-Key [DiamEAP], EAP-Key-Name [DiamEAP], Redirect-Host [RFC3588] and Origin-Realm [RFC3588]. Congdon, et al. Informational [Page 16]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 Extended attributes defined within both RADIUS and Diameter include Egress-VLANID, Ingress-Filters, User-Priority-Table, Allowed-SSID, and Allowed-Called-Station-Id. Attributes solely defined within RADIUS include the Extended attribute (used to encapsulate Diameter-compatible RADIUS attributes), as well as the Accounting-EAP-Auth-Method attribute, defined within [DiamEAP]. In order to translate RADIUS Extended attributes to Diameter AVPs, a RADIUS/Diameter gateway must first concatenate all RADIUS attributes of type Extended, and then parse the included sub-attributes. The sub-attributes are then encapsulated within the Diameter AVP format as folows: a. The Code, Length, and Mandatory fields as well as the attribute data are copied directly from the Extended RADIUS attribute to the Diameter AVP. b. If the RADIUS "short form" Extended format is used, then the 'V' bit always set to zero in the Diameter AVP. c. If the RADIUS "long form" Extended format is used, then the 'V' bit and Vendor-Id is copies from the Extended RADIUS attribute to the Diameter AVP. In translating from Diameter to RADIUS, the gateway encapsulates Diameter AVPs within Extended RADIUS attributes as follows: a. If the 'V' bit is set to one (1), or the Diameter AVP Code is larger than 16384, then the "Long Form" Extended RADIUS attribute format MUST be used. Otherwise, the "Short Form" attribute format SHOULD be used. b. The Code, Length, and Mandatory fields as well as the attribute data are copied directly from the Diameter AVP to the Extended RADIUS attribute. c. If the 'V' bit is set to one (1), then the 'V' bit as well as the Vendor-Id fields are copies from the Diameter AVP to the Extended RADIUS attribute. d. Once the Extended RADIUS attributes have been encoded, they are encapsulated within RADIUS attributes of type Extended. Note that automated translation may not be on an initial Access- Request, since this packet must contain an empty Extended attribute Congdon, et al. Informational [Page 17]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 in order to negotiate use of the Extended attribute format. 6. IANA Considerations This specification does not create any new registries. This specification requires assignment of a RADIUS attribute type for the Extended attribute. In addition, this specification requires assignment of the following Diameter Code values: AVP Code ========= ==== Egress-VLANID TBD Ingress-Filter-Enable TBD User-Priority-Table TBD Allowed-SSID TBD Allowed-Called-Station-Id TBD 7. Security Considerations Since this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in IEEE 802.1X-enabled networks, it is vulnerable to all of the threats that are present in other RADIUS applications. For a discussion of these threats, see [RFC2607], [RFC2865], [RFC3162], [RFC3576], [RFC3579], and [RFC3580]. Vulnerabilities include: Packet modification or forgery Dictionary attacks Known plaintext attacks Key management issues 7.1. Packet Modification or Forgery As noted in [RFC3580], when used with IEEE 802.1X, all RADIUS packets MUST be authenticated and integrity protected. In addition, as described in [RFC3579], Section 4.2: To address the security vulnerabilities of RADIUS/EAP, implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] 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. Congdon, et al. Informational [Page 18]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 7.2. Dictionary Attacks As discussed in [RFC3579] Section 4.3.3, the RADIUS shared secret is vulnerable to offline dictionary attack, based on capture of the Response Authenticator or Message-Authenticator attribute. In order to decrease the level of vulnerability, [RFC2865], Section 3 recommends: The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well- chosen password. It is preferred that the secret be at least 16 octets. In addition, the risk of an offline dictionary attack can be further mitigated by employing IPsec ESP with non-null transform in order to encrypt the RADIUS conversation, as described in [RFC3579], Section 4.2. 7.3. Known Plaintext Attacks Since IEEE 802.1X is based on EAP, which does not support PAP, the RADIUS User-Password attribute is not used to carry hidden user passwords. The hiding mechanism utilizes MD5, defined in [RFC1321], in order to generate a key stream based on the RADIUS shared secret and the Request Authenticator. Where PAP is in use, it is possible to collect key streams corresponding to a given Request Authenticator value, by capturing RADIUS conversations corresponding to a PAP authentication attempt using a known password. Since the User- Password is known, the key stream corresponding to a given Request Authenticator can be determined and stored. The vulnerability is described in detail in [RFC3579], Section 4.3.4. Even though IEEE 802.1X Authenticators do not support PAP authentication, a security vulnerability can still exist where the same RADIUS shared secret is used for hiding User-Password as well as other attributes. This can occur, for example, if the same RADIUS proxy handles authentication requests for both IEEE 802.1X (which may hide the Tunnel-Password, MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes) and GPRS (which may hide the User-Password attribute). The threat can be mitigated by protecting RADIUS with IPsec ESP with non-null transform, as described in [RFC3579], Section 4.2. In addition, the same RADIUS shared secret MUST NOT used for both IEEE 802.1X authentication and PAP authentication. Congdon, et al. Informational [Page 19]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 7.4. Key Management Issues As detailed in [Housley56], AAA protocols transporting keys are required to protect them against disclosure to third parties. After much debate, the AAA WG has settled on the Diameter re-direct mechanism to enable transport of keys directly between the NAS and the home AAA server. The redirect key protection mechanism relies on scalable mechanisms for establishment of security associations between the NAS and home AAA server, such as provisioning of certificates. This can be accommodated by use of RADIUS over IPsec, as specified in [RFC3579]. As described in Section 2.10, support for the redirect key protection mechanism also requires addition of a Redirect attribute to RADIUS. As in [DiamEAP], the NAS can either attempt to use a re-direct to directly communicate with the home server from the beginning, or it can request authentication-only while communicating through proxies, and then can send an authorize-only message directly to the home- server to obtain the key. Note that this usage may not work well with existing RADIUS implementations that interpret key attributes as authentication, rather than authorization-related. 8. References 8.1. Normative references [RFC1321] Rivest, R. and S. Dusse, "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. [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. [RFC2867] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. Congdon, et al. Informational [Page 20]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 [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. [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. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., Arkko, J., "Diameter Base Protocol", RFC 3588, September 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE Std 802.1X-2004, August 2004. [IEEE802.11i] Institute of Electrical and Electronics Engineers, "Supplement to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security", June 2004. [Arkko] Arkko, J., "Object Identifier and Type Spaces in a Rationalized RADIUS Data Model", post to the RADEXT WG mailing list, June 9, 2004, http://ops.ietf.org/lists/radiusext/2004/msg00441.html Congdon, et al. Informational [Page 21]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 8.2. Informative references [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack." CryptoBytes Vol.2 No.2, Summer 1996. [Housley56] Housley, R., "Key Management in AAA", Presentation to the AAA WG at IETF 56, http://www.ietf.org/proceedings/03mar/slides/aaa-5/index.html, March 2003. [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture, ANSI/IEEE Std 802, 1990. [IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q, January 1998. [IEEE8023] ISO/IEC 8802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 1996), 1996. [IEEE80211] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Congdon, et al. Informational [Page 22]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 802.11-1999, 1999. [KEYFRAME] Aboba, B., Simon, D., Arkko, J., Eronen, P. and H. Levkowetz, "EAP Key Management Framework", draft-ietf-eap-keying-03.txt, July 2004. Congdon, et al. Informational [Page 23]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 Appendix A - Extended Attribute Formats The use of a Diameter-compatible Extended attribute format within RADIUS was first proposed in [Arkko]. This Appendix describes a potential definition of the Extended attribute, based on a modified version of that proposal. The proposed definition provides support for Diameter-compatibility as well as sub-attributes, and support for a more efficient "short form" encoding. The Extended attribute, RADIUS attribute type TBD, enables the encoding of Extended RADIUS attributes. If multiple Extended attributes are present in a packet their values should be concatenated; this allows attributes longer than 253 octets to be transported by the Extended attribute format. Multiple sub- attributes MAY be encoded within a single Extended attribute, although they do not have to be. Note: for the purposes of this appendix, allocation of a new RADIUS Type value is assumed. However, on the RADEXT WG mailing list, there has also been discussion of utilizing type 26 (Vendor-Specific) along with a Vendor-Id of zero(0). For the purposes of this specification either format would be work equally well. Extended attributes MUST only be used when both the RADIUS client and server support them. A RADIUS client supporting the Extended attribute format MUST include an Extended attribute with a Length value of two (2) within the initial Access-Request of a session. A RADIUS server receiving an empty Extended attribute within an Access- Request MAY utilize Extended attributes within messages sent to the client, including Access-Reject, Access-Challenge, Access-Accept, CoA-Request and Disconnect-Request messages. A RADIUS server not receiving an empty Extended attribute within an initial Access-Request MUST NOT include Extended attributes in any RADIUS message sent to the client, including Access-Reject, Access- Challenge, Access-Accept, CoA-Request or Disconnect-Request messages. Congdon, et al. Informational [Page 24]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 A.1 - Full Diameter AVP Format The full Extended attribute format is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |S| Code +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code (opt) | Length2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Vendor-Id (opt) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id(opt)| Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD - Allocated by IANA from within the RADIUS attribute space. Length The length of the attribute in octets, including the Type, Length, S, Code, Length2, Flags, Vendor-Id and Data fields. S 0 - Full Diameter AVP format 1 - Short Form Code Where the S bit is clear, the "full Diameter AVP" format is used, and the Code field is 31 bits, encoding the 31 least significant bits of the Diameter AVP format defined in [RFC3588]. Where the S bit is set, the "Short Form" Extended format is used, and the Code field is 14 bits, encoding the 14 least significant bits of the Diameter AVP format, defined in [RFC3588]. Length2 The Length of the sub-attribute in octets, including the S, M, Code, Length2 and Data fields. Flags The Flags field is a single octet, defined as follows: Congdon, et al. Informational [Page 25]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 +-+-+-+-+-+-+-+-+ |V|M|r|r|r|r|r|r| +-+-+-+-+-+-+-+-+ V 0 = IETF standard 1 = Vendor Specific M The 'M' Bit, known as the Mandatory bit, indicates whether support of the attribute is required. If an attribute with the 'M' bit set is received and either the attribute or its value is unrecognized, the message MUST be silently discarded. Attributes with the 'M' bit cleared are informational only and a receiver that receives a message with such an attribute that is not supported, or whose value is not supported, MAY simply ignore the attribute. r The 'r' (reserved) bits are unused and SHOULD be set to 0. Note that subsequent specifications MAY define additional bits within the header, and an unrecognized bit SHOULD be considered an error. Vendor-Id The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order. Data The Data field is zero or more octets and contains information specific to the attribute. The format and length of the Data field is determined by the Code and Length2 fields. The format of the Data field MUST be one of the data types defined in [RFC3588] or a data type derived from the base data types. A.2 - Short Form In order to enable Extended attributes to be encoded more economically, a "Short Form" of the Extended attribute format is proposed. The Short Form can be used to encode any Diameter AVP that meets the following constraints: Congdon, et al. Informational [Page 26]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 [a] An IETF standard attribute (not Vendor-Specific) [b] Diameter Code between 0 and 16384 (all existing attributes) [c] No flag bits other than the Mandatory bit. The short form Extended attribute format is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |S|M| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length2 | Data.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD - Allocated by IANA from the RADIUS attribute space. Length The length of the attribute in octets, including the Type, Length, S, M, Code, Length2 and Data fields. S 1 - Short Form M 0 - Optional 1 - Mandatory Code The 14 least significant bits of the Diameter AVP Code field, as defined in [RFC3588]. Length2 The Length of the sub-attribute in octets, including the S, M, Code, Length2 and Data fields. Data The Data field is zero or more octets and contains information specific to the attribute. The format and length of the Data field is determined by the Code and Length2 fields. The format of the Data field MUST be one of the data types defined in Congdon, et al. Informational [Page 27]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 [RFC3588] or a data type derived from the base data types. Acknowledgments The authors would like to acknowledge Dorothy Stanley of Agere, and Ashwin Palekar of Microsoft. Authors' Addresses Paul Congdon Hewlett Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747 EMail: paul.congdon@hp.com Phone: +1 916 785 5753 Fax: +1 916 785 8478 Chuck Black Hewlett Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747 EMail: chuck.black@hp.com Phone: +1 916 785 9713 Fax: +1 916 785 1199 Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329 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 Congdon, et al. Informational [Page 28]
INTERNET-DRAFT RADIUS Extensions for IEEE 802 2 November 2004 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 implementors 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. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Congdon, et al. Informational [Page 29]