Network Working Group K. Gaonkar Internet-Draft Georgia Tech University Intended status: Standards Track L. Dondeti Expires: August 28, 2008 V. Narayanan QUALCOMM, Inc. G. Zorn February 25, 2008 RADIUS Support for EAP Re-authentication Protocol draft-gaonkar-radext-erp-attrs-03 Status of this Memo 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. 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 August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract RFCxxxx (draft-ietf-hokey-erx after publication) [6] specifies the EAP Re-authentication Protocol (ERP). This document specifies RADIUS support for ERP. The procedures in RFC3579 [1] are used for encapsulating the EAP Initiate and Finish messages specified in RFCxxxx (draft-ietf-hokey-erx after publication) [6]. This document Gaonkar, et al. Expires August 28, 2008 [Page 1] Internet-Draft RADIUS for ERP February 2008 specifies attributes for the request and delivery of Domain Specific Root Keys from the AAA/EAP server to the ER Server. Additionally, this document also specifies RADIUS message processing rules relevant to ERP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. RADIUS Support for ERP . . . . . . . . . . . . . . . . . . . . 3 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4 3.2. DSRK Request and Delivery . . . . . . . . . . . . . . . . . 5 3.3. Conflicting Messages . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Gaonkar, et al. Expires August 28, 2008 [Page 2] Internet-Draft RADIUS for ERP February 2008 1. Introduction RFC3579 [1] specifies EAP message encapsulation in RADIUS messages. [6] defines the EAP Re-authentication Protocol to allow faster re- authentication of a previously authenticated peer. In ERP, a peer authenticates to the network by proving possession of key material derived during a previous EAP exchange. For this purpose, ERP defines two new EAP codes - EAP Initiate and EAP Finish. This document specifies the encapsulation of these messages in RADIUS. In addition, a Domain Specific Root Key (DSRK) may be transported from the RADIUS or EAP Server to an EAP Re-authentication (ER) server in the local domain for the purpose of re-authenticating the peer within that domain (see Figure 2 of [6]. This document defines how the DSRK is transported to the ER server using RADIUS. 2. Terminology 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 RFC 2119 [2]. This document uses terminology defined in [7], [8], [6], and [1]. 3. RADIUS Support for ERP The EAP Re-authentication Protocol, defined in [6], provides a mechanism for efficient re-authentication of EAP peers that have unexpired keying material from a previous EAP exchange. For this purpose, an Extended Master Session Key (EMSK) based re- authentication key hierarchy has been defined [8]. ERP may be executed between the ER peer and an ER server in the peer's home domain or the local domain visited by the peer. In the latter case, a Domain Specific Root Key (DSRK), derived from the EMSK, is provided to the local domain ER server. The peer and the local server subsequently use the re-authentication key hierarchy from the DSRK to authenticate and derive authenticator specific keys within that domain. The DSRK can be obtained as part of the regular EAP exchange or as part of an ERP bootstrapping exchange. The local ER server requesting the DSRK needs to be in the path of the EAP or ERP bootstrapping exchange in order to request and obtain the DSRK. Gaonkar, et al. Expires August 28, 2008 [Page 3] Internet-Draft RADIUS for ERP February 2008 3.1. Protocol Overview RADIUS may be used to transport ERP messages between the NAS (authenticator) and an authentication server (ER server). In ERP, the peer sends an EAP Initiate Reauth message to the ER server via the authenticator. Alternatively, the NAS may send an EAP Initiate Reauth-Start message to the peer to trigger the start of ERP; the peer then responds with an EAP Initiate Reauth message to the NAS. The general guidelines for encapsulating EAP messages in RADIUS from RFC3579 [1] apply to the new EAP messages defined for ERP as well. The EAP Initiate Reauth message is encapsulated in an EAP-Message attribute of a RADIUS Access-Request message by the NAS and sent to the RADIUS server. In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, the NAS MUST copy the contents of the value field of the 'rIKName as NAI' TLV or the peer-id TLV (when the former is not present) of the EAP Initiate Reauth message into the User-Name attribute of the Access-Request. The ER server processes the EAP Initiate Reauth message in accordance with [6], and if that is successful, it responds with an EAP Finish Reauth message indicating a success ('R' flag set to 0). The RADIUS server MUST encapsulate the EAP Finish Reauth message with the R flag set to zero in an EAP-Message attribute of a RADIUS Access-Accept message. The Re-authentication Master Session Key (rMSK) is transported along with this message to the NAS. The rMSK transport follows the same procedures of MSK transport along with EAP Success messages in a regular EAP exchange. The MS-MPPE-Recv-Key and MS- MPPE-Send-Key attributes defined in RFC2548 [3] are used to transport the rMSK from the server to the NAS as follows: MS-MPPE-Recv-Key = rMSK (0, n/2-1) MS-MPPE-Send-Key = rMSK (n/2, n-1) where, 'n' is the total length of the rMSK in octets and the (x, y) notation indicates the starting and ending octets of the key material. If the processing of the EAP Initiate Reauth message resulted in a failure, the RADIUS server MUST encapsulate an EAP Finish Reauth message indicating failure ('R' flag set to 1) in an EAP-Message attribute of a RADIUS Access-Reject message. Whether the RADIUS server sends an EAP Finish Reauth message is specified in [6]. Gaonkar, et al. Expires August 28, 2008 [Page 4] Internet-Draft RADIUS for ERP February 2008 3.2. DSRK Request and Delivery A local ER server, collocated with a RADIUS server in the peer's visited domain, may request a DSRK from the EAP server, either in the initial EAP exchange or in an ERP bootstrapping exchange. The key request and delivery mechanism specified in [9] is used. A RADIUS server acting as an ER server may include the Keying-Material attribute defined in [9] in the RADIUS Access-Request message containing an EAP Response packet or an EAP Initiate Reauth packet in the EAP-Message attribute. The App ID field of the Keying-Material attribute MUST be set to "EAP DSRK" and the Optional Data field SHOULD be set to the domain or server identity required to derive the DSRK. The RADIUS server requesting the DSRK needs to be in the path of the corresponding EAP or ERP exchange between the peer and the EAP or ER server. The RADIUS server, acting as the EAP server, if it wishes to include a DSRK in response to a request for it, SHOULD include the Keying- Material attribute defined in [9] in the RADIUS Access-Accept message (containing either an EAP Success or EAP Finish Reauth with the 'R' flag set to 0). The App ID of the Keying-Material attribute MUST be set to "EAP DSRK" and the Optional Data field SHOULD be set to the domain or server identity used by the EAP server to derive the DSRK. The encrypted DSRK itself must be included in the Data field of the Keying-Material attribute in accordance with [9]. 3.3. Conflicting Messages In addition to the rules specified in Section 2.6.3. of RFC3579 [1], the following combinations SHOULD NOT be sent by a RADIUS Server: Access-Accept/EAP-Message/EAP Finish Reauth with 'R' flag set to 1 Access-Reject/EAP-Message/EAP Finish Reauth with 'R' flag set to 0 Access-Reject/Keying-Material Access-Challenge/EAP-Message/EAP Initiate Reauth Access-Challenge/EAP-Message/EAP Finish Reauth 4. Security Considerations The security considerations specified in RFC 3579 [1], RFC 2548 [3], and [9] are applicable to this document. Gaonkar, et al. Expires August 28, 2008 [Page 5] Internet-Draft RADIUS for ERP February 2008 5. IANA Considerations This document requires IANA registration of the following value of the App ID field for the RADIUS Keying-Material attribute: 2 ... EAP DSRK 6. Acknowledgments 7. References 7.1. Normative References [1] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [4] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", draft-narten-iana-considerations-rfc2434bis-08 (work in progress), October 2007. 7.2. Informative References [6] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- authentication Protocol (ERP)", draft-ietf-hokey-erx-12 (work in progress), February 2008. [7] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [8] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", draft-ietf-hokey-emsk-hierarchy-04 (work in progress), February 2008. Gaonkar, et al. Expires August 28, 2008 [Page 6] Internet-Draft RADIUS for ERP February 2008 [9] Zorn, G., "RADIUS Attributes for the Delivery of Keying Material", draft-zorn-radius-keywrap-13 (work in progress), April 2007. Authors' Addresses Kedar Gaonkar Georgia Tech University Email: kgaonkar3@gatech.edu Lakshminath Dondeti QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Vidya Narayanan QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Glen Zorn Email: glenzorn@comcast.net Gaonkar, et al. Expires August 28, 2008 [Page 7] Internet-Draft RADIUS for ERP February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Gaonkar, et al. Expires August 28, 2008 [Page 8]