Network Working Group Paul Congdon INTERNET-DRAFT Chuck Black Category: Informational Hewlett-Packard Company Bernard Aboba 11 July 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 January 2, 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 11 July 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-VID ...................................... 5 2.2 Ingress-Filter-Enable ........................... 6 2.3 User-Priority-Table ............................. 7 2.4 Allowed-SSID .................................... 8 2.5 Allowed-Called-Station-Id ....................... 8 2.6 NAS-Filter-Rule ................................. 9 2.7 QoS-Filter-Rule ................................. 10 2.8 EAP-Master-Session-Key .......................... 10 2.9 EAP-Key-Name .................................... 11 2.10 Redirect-Host ................................... 12 2.11 Origin-Realm .................................... 12 3. RADIUS Accounting ..................................... 13 3.1 Accounting-EAP-Auth-Method ...................... 13 4. Table of Attributes ................................... 14 5. Diameter Considerations ............................... 14 6. IANA Considerations ................................... 15 7. Security Considerations ............................... 15 7.1 Packet modification or forgery .................. 15 7.2 Dictionary Attacks .............................. 16 7.3 Known Plaintext Attacks ......................... 16 7.4 Key Management Issues ........................... 17 8. References ............................................ 17 8.1 Normative References .................................. 17 8.2 Informative References ................................ 19 Appendix A - Extended Attribute Formats ...................... 21 ACKNOWLEDGMENTS .............................................. 25 AUTHORS' ADDRESSES ........................................... 25 Intellectual Property Statement .............................. 25 Disclaimer of Validity ....................................... 26 Full Copyright Statement ..................................... 26 Congdon, et al. Informational [Page 2] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 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 11 July 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. In addition, problems were encountered in negotiating support for security-critical attributes. 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 provisioned. 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 Congdon, et al. Informational [Page 4] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 the network on receipt of unknown attributes, rather than ignoring them. 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 thesmelves 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 accomodate both a Mandatory bit and the Diameter AVP Code space, so as to enable automated Diameter/RADIUS translation. Another alternative is to utilize an extended IETF standard 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 the extended attribute format first described in [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 the "short form" encoding described in Appendix A is assumed. 2. RADIUS Authentication 2.1. Egress-VID This attribute represents an allowed IEEE 802 Egress VID for this port. The Egress-VID contains two parts: the first part is the VID, the second part indicates if this VID is allowed for tagged or untagged packets. Multiple Egress-VID attributes can be delivered in an authentication response; each attribute adds the specified VLAN to the list of allowed egress VLANs for the port. Code TBD Congdon, et al. Informational [Page 5] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 Length 8 (Short Form) M 1 - Mandatory Data-Type Integer32 Integer32 The values include: 1 = Tagged 2 = Untagged 2.2. Ingress-Filter-Enable This attribute describes whether ingress filtering is enabled. Code TBD Length 8 (Short Form) M 1 - Mandatory Data-Type Integer32 Integer32 This attribute has the following values: 1 - Enabled 2 - Disabled Congdon, et al. Informational [Page 6] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 2.3. User-Priority-Table 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. Code TBD Length >=5 (Short Form) M 1 - Mandatory Data-Type String String The table, expressed as a string, 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 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 this 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. This table and its configuration are outside the scope of this document. Congdon, et al. Informational [Page 7] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 2.4. Allowed-SSID 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. Allowed- SSID is an Extended attribute (see Appendix A) defined to allow the RADIUS server to specify which SSIDs the user is allowed to access. It is defined as follows: Code TBD Length >=5 (Short Form) M 1 - Mandatory Data-Type String String 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.5. Allowed-Called-Station-Id 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. Allowed-Called-Station-Id is an Extended attribute (see Appendix A) defined to allow the RADIUS server to specify which Called-Station-Ids the user is allowed to access. It is defined as follows: Code TBD Congdon, et al. Informational [Page 8] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 Length >=5 (Short Form) 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.6. NAS-Filter-Rule NAS-Filter-Rule is an Extended attribute designed to enable the provisioning of Internet Protocol filters on the NAS by the RADIUS server. The semantics of this attribute are identical to that of the NAS-Filter-Rule AVP defined in [NASREQ], Section 6.6. If more than one of these attributes is present, they are concatenated together and treated as a single entity. The NAS-Filter-Rule attribute is defined as follows: Code 400 [NASREQ] Length >=5 (Short Form) M 1 - Mandatory Data-Type Text Text Congdon, et al. Informational [Page 9] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 The Text field contains an IP filter in ASCII format, utilizing the syntax defined in [RFC3588], Section 4.3. 2.7. QoS-Filter-Rule QoS-Filter-Rule is an Extended attribute designed to enable the provisioning of QoS filters on the NAS by the RADIUS server. The semantics of this attribute are identical to that of the QoS-Filter- Rule AVP defined in [NASREQ], Section ?. If more than one of these attributes are included, they are concatenated together and interpretted as a single entity. The QoS-Filter-Rule attribute is defined as follows: Code TBD Length >=5 (Short Form) M 1 - Mandatory Data-Type Text Text The Text field contains a QoS filter in ASCII format, utilizing the syntax defined in [NASREQ], Section ?. 2.8. EAP-Master-Session-Key EAP-Master-Session-Key is an Extended attribute designed to enable a RADIUS server to provide an EAP Master Session Key to the RADIUS client, as defined in [KEYFRAME]. The semantics of this attribute are identical to that of the EAP-Master-Session-Key AVP defined in [DiamEAP], Section 4.1.3. The EAP-Master-Session-Key attribute is defined as follows: Code TBD [DiamEAP] Length Congdon, et al. Informational [Page 10] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 >=5 (Short Form) M 1 - Mandatory Data-Type String String The String field is one 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 [RFC3579], Section 4.2. As a result, there is no need for alternative confidentiality mechanisms. 2.9. EAP-Key-Name EAP-Key-Name is an Extended attribute designed to enable a RADIUS server to provide a key name to the RADIUS client. The semantics of this attribute are identical to that of the EAP-Key-Name AVP defined in [DiamEAP], Section 4.1.4. 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. 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 Congdon, et al. Informational [Page 11] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 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]. UTF-8 encoded 10646 characters are recommended, but a robust implementation SHOULD support the field as undistinguished octets. 2.10. Redirect-Host The Redirect-Host attribute provides support for Redirect functionality, as described in [RFC3588], Section 6.12. Code ? - Defined in RFC 3588 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.11. Origin-Realm The Origin-Realm attribute contains the realm of the originator of a message, as described in [RFC3588], Section 6.4. Code 296 Congdon, et al. Informational [Page 12] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 Length >=5 (Short Form) M 1 - Mandatory Data Type String String The String field contains the fully qualified domain name (FQDN) representing the realm. 3. RADIUS Accounting 3.1. Accounting-EAP-Auth-Method Accounting-EAP-Auth-Method is an Extended attribute designed to enable 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. The Accounting-EAP-Auth-Method attribute is defined as follows: Code TBD [DiamEAP] Length 12 (Short Form) M 1 - Mandatory Data-Type Unsigned Integer 64 UInt64 The UInt64 field is eight (8) octets. The Accounting-EAP-Auth- Method attribute is of type Unsigned64. In case of expanded types Congdon, et al. Informational [Page 13] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 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. 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 Egress-VID [a] 0 0-1 0 0 0-1 TBD Ingress-Filter-Enable [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+ TBD 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. Issues ------ [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 noted in Appendix A, this specification utilizes an attribute format that enables simultaneous definition of attributes for both RADIUS and Diameter. The goal of this common attribute format is to enable automated translation between RADIUS and Diameter, without Congdon, et al. Informational [Page 14] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 requiring the complex gateway rules defined in [NASREQ]. The attributes specified in this document utilize Code values as well as Data Types in the manner defined in [RFC3588]. 6. IANA Considerations This specification does not create any new registries. This specification requires assignment of attribute types for the following new RADIUS attribute: Attribute Type ========= ==== Extended TBD In addition, this specification requires assignment of Code values for the following new Diameter AVPs: AVP Code ========= ==== Egress-VID TBD Ingress-Filter-Enable TBD User-Priority-Table TBD Allowed-SSID TBD Allowed-Called-Station-Id TBD QoS-Filter-Rule 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 Congdon, et al. Informational [Page 15] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 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. 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 Congdon, et al. Informational [Page 16] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 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. 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 accomodated 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. Congdon, et al. Informational [Page 17] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 [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. [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", Congdon, et al. Informational [Page 18] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 June 2004. [Arkko] Arkko, J., "Extended RADIUS Attribute Format", draft-arkko- radext-extended-attrs-00.txt, Internet draft (work in progress), July 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 Congdon, et al. Informational [Page 19] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 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 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-02.txt, June 2004. Congdon, et al. Informational [Page 20] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 Appendix A - Extended Attribute Formats The use of a Diameter-compatible Extended attribute format within RADIUS was first proposed in [Arkko]. This Appendix includes a modification of the original proposal, providing support for sub- attributes, as well as support for a more efficient "short form" encoding. Attributes utilizing the Extended format are enclosed within a RADIUS attribute of type TBD. While it is conceivable that the Vendor- Specific Attribute type 26 could be used along with a Vendor-Id of zero (0), discussion on the RADEXT WG mailing list has tended to favor allocation of a distinct attribute type. If multiple attributes of type TBD 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. 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 - Short Form Congdon, et al. Informational [Page 21] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 1 - Full Diameter AVP format Code Where the S bit is set, the Code field is 15 bits, encoding the 15 most significant bits of the Diameter AVP format defined in [RFC3588]. Where the S bit is cleared, the Short Form attribute format is used, as defined below. 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: +-+-+-+-+-+-+-+-+ |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 Congdon, et al. Informational [Page 22] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 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 atribute. 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 - Negotiation of the Extended Format A RADIUS client supporting the Extended attribute format MUST send an Extended attribute with a Length of 2 to the RADIUS server within each Access-Request. A RADIUS server receiving such an "empty" Extended attribute MAY respond by including Extended attributes within an Access-Challenge, Access-Accept, or Access- Request. A RADIUS server not receiving an "empty" Extended attribute within an Access-Request MUST NOT respond by including Extended attributes within an Access-Challenge, Access-Accept or Access- Reject. A.3 - 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: [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 Congdon, et al. Informational [Page 23] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 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 0 - 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 atribute. 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. Congdon, et al. Informational [Page 24] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 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 can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to Congdon, et al. Informational [Page 25] INTERNET-DRAFT RADIUS Extensions for IEEE 802 11 July 2004 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 26]