Diameter Maintenance and L. Dondeti Extensions (DIME) QUALCOMM, Inc. Internet-Draft J. Bournelle (Editor) Intended status: Standards Track L. Morand Expires: July 18, 2009 Orange Labs S. Decugis NICT January 14, 2009 Diameter Support for EAP Re-authentication Protocol draft-ietf-dime-erp-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 July 18, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Dondeti, et al. Expires July 18, 2009 [Page 1] Internet-Draft Diameter Support for ERP January 2009 Abstract EAP Re-authentication Protocol (ERP) defines extensions to the Extensible Authentication Protocol (EAP) to support efficient re- authentication between the EAP peer and an EAP re-authentication server through any EAP/ERP authenticator. This document specifies Diameter support for ERP. The Diameter EAP application is re-used for encapsulating the newly defined EAP codes specified in the ERP specification. Additionally, this document also defines specific Diameter processing rules relevant to ERP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Diameter Support for ERP . . . . . . . . . . . . . . . . . . . 3 3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 3 3.2. DSRK Request and Delivery . . . . . . . . . . . . . . . . . 4 4. Command Codes . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 5 5.1. EAP-DSRK-Request AVP . . . . . . . . . . . . . . . . . . . 5 5.2. EAP-DSRK AVP . . . . . . . . . . . . . . . . . . . . . . . 5 5.3. EAP-DSRK-Name AVP . . . . . . . . . . . . . . . . . . . . . 5 5.4. EAP-DSRK-Lifetime AVP . . . . . . . . . . . . . . . . . . . 5 6. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 5 7. AVP Flag Rules . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 11.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Dondeti, et al. Expires July 18, 2009 [Page 2] Internet-Draft Diameter Support for ERP January 2009 1. Introduction RFC 4072 [1] specifies a Diameter application that carries EAP packets between a Diameter client and the Diameter Server/EAP server. RFC 5296 [2] defines the EAP Re-authentication Protocol to allow faster re-authentication of a previously authenticated peer. In ERP, a peer is authenticated by the network thanks to keying material obtained during a previous EAP exchange. This keying material is derived from the Extended Master Session Key (EMSK) as defined in the RFC 5295 [5]. To accomplish the EAP reauthentication functionality, ERP defines two new EAP codes - EAP-Initiate and EAP Finish. This document specifies the reuse of Diameter EAP Application to carry these new EAP messages. ERP is executed between the peer and a server located either in the peer's home domain or in the local domain visited by the peer. In the latter case, a Domain Specific Root Key (DSRK) is derived from the EMSK, as defined in the RFC 5295 [5], and is provided by the Home EAP server to the local domain server. For that purpose, this document specifies the transport of the DSRK using the Diameter EAP Application. 2. Assumptions This document defines only additional optional AVPs for usage with the Diameter EAP application. This document does not define a new Diameter application and therefore a new Application ID is not required, as described in the Diameter Base protocol [3]. In this document, when EAP re-authentication is performed in the domain visited by the peer, it is assumed that the local ER server is co-located with a Diameter agent in the visited domain present in the path of the full EAP exchange. (Editor's Note: it is not clear at the time of writing wether this document must require this local AAA server to be on the path.) 3. Diameter Support for ERP 3.1. Protocol Overview The Diameter EAP Application is used to transport ERP messages between the NAS (authenticator) and an authentication server (ER server). In ERP, the peer sends an EAP-Initiate/Re-auth message to the ER Dondeti, et al. Expires July 18, 2009 [Page 3] Internet-Draft Diameter Support for ERP January 2009 server via the authenticator. Alternatively, the NAS may send an EAP-Initiate/Re-auth-Start message to the peer to trigger the start of ERP. In this case, the peer responds with an EAP-Initiate/Re-auth message to the NAS. The general guidelines for encapsulating EAP messages in Diameter from RFC 4072 [1] apply to the new EAP codes defined for ERP as well. The EAP-Initiate/Re-auth message is encapsulated in an EAP-Payload AVP of a Diameter EAP Request (DER) message by the NAS and sent to the Diameter server. The NAS MUST copy the contents of the value field of the 'KeyName-NAI' TLV or the 'peer-id' TLV (when the former is not present) of the EAP Initiate/Re-auth message into a User-Name AVP of the Diameter EAP-Request. The ER server processes the EAP-Initiate/Re-auth message in accordance with [2] and responds with an EAP-Finish/Re-auth message. The Diameter server MUST encapsulate the EAP-Finish/Re-auth message within an EAP-Payload AVP of a Diameter EAP Answer message. In an EAP re-authentication successful case, an EAP-Master-Session-Key AVP is included in the Diameter EAP Answer (DEA) message that contains the Re-authentication Master Session Key (rMSK). The Diameter Result-Code SHOULD be a success Result-Code. In an EAP re- authentication failure case, the Diameter Result-Code AVP of the a Diameter EAP Answer (DEA) message SHOULD be a failure Result-Code and no EAP-Master-Session-Key AVP is present. (Editor's Note: it is FFS if a SHOULD is sufficient) (2nd Editor's Note: add a figure ?) 3.2. DSRK Request and Delivery A local ER server, collocated with a Diameter proxy in the domain visited by the peer, may request a DSRK from the home EAP/ERP server, either in the initial EAP exchange (implicit bootstrapping) or in an ERP bootstrapping exchange (explicit bootstrapping). This is done by including the EAP-DSRK-Request AVP in the Diameter EAP Request (DER) message. The EAP-DSRK-Request AVP contains the domain or server identity required to derive the DSRK. In successful case, the DSRK is carried by the EAP-DSRK AVP in the Diameter EAP Answer (DEA) message. Along with the EAP-DSRK AVP, an EAP-DSRK-Name AVP MUST be used to send the DSRK's keyname and an EAP- DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime. (Editor's Note: add a figure ?). 4. Command Codes This document re-uses the EAP application commands [1] and does not define new command codes. Dondeti, et al. Expires July 18, 2009 [Page 4] Internet-Draft Diameter Support for ERP January 2009 5. Attribute Value Pair Definitions This section defines new AVPs for the ERP support within Diameter EAP Application. 5.1. EAP-DSRK-Request AVP The EAP-DSRK Request AVP (AVP Code TBD) is of type DiameterIdentity. This AVP fulfills two purposes: first, it indicates that a ERP server is located in the local domain that is willing to play the role of an ERP server for a particular session. Second, it conveys information about the domain name to the Diameter/EAP/ERP server. (Editor's Note: it is FFS if DiameterIdentity is the correct type). 5.2. EAP-DSRK AVP The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. This AVP contains keying material to be used by the visited domain (i.e. the DSRK). Exactly how this keying material is derived is beyond the scope of this document. 5.3. EAP-DSRK-Name AVP The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString. This AVP contains the EMSKname which identifies the keying material. How this name is derived is beyond the scope of this document and defined in [5]. 5.4. EAP-DSRK-Lifetime AVP The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type Unsigned64 and contains the DSRK lifetime in seconds. (Editor's Note: it is FFS if Unsigned32 is not sufficient). (Editor's Note: it is FFS default value) 6. AVP Occurrence Table The following table lists the AVPs that may optionally be present in the DER and DEA commands [1]. Dondeti, et al. Expires July 18, 2009 [Page 5] Internet-Draft Diameter Support for ERP January 2009 +---------------+ | Command-Code | +-+-----+-----+-+ Attribute Name | DER | DEA | -------------------------------|-----+-----+ EAP-DSRK-Request | 0-1 | 0 | EAP-DSRK | 0 | 0-1 | EAP-DSRK-Name | 0 | 0-1 | EAP-DSRK-Lifetime | 0 | 0-1 | +-----+-----+ Figure 1: DER and DEA Commands AVP Table When the EAP-DSRK AVP is present in the DEA then the EAP-DSRK-Name and the EAP-DSRK-Lifetime MUST also be present. 7. AVP Flag Rules The following table describes the Diameter AVPs, their AVP Code values, types, possible flag values, and whether the AVP MAY be encrypted. The Diameter base [3] specifies the AVP Flag rules for AVPs in Section 4.5. +---------------------+ | AVP Flag Rules | +----+-----+----+-----+----+ AVP Section | | |SHLD|MUST | | Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr| ------------------------------------------+----+-----+----+-----+----+ EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | V,M | Y | EAP-DSRK TBD 4.7.2 OctetString| | P | | V,M | Y | EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | V,M | Y | EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | V,M | Y | ------------------------------------------+----+-----+----+-----+----+ Due to space constraints, the short form DiamIdent is used to represent DiameterIdentity. Figure 2: AVP Flag Rules Table 8. Security Considerations The security considerations specified in RFC 4072 [1], and RFC 3588 [3] are applicable to this document. Dondeti, et al. Expires July 18, 2009 [Page 6] Internet-Draft Diameter Support for ERP January 2009 EAP channel bindings may be necessary to ensure that the Diameter client and the server are in sync regarding the key Requesting Entity's Identity. Specifically, the Requesting Entity advertises its identity through the EAP lower layer, and the user or the EAP peer communicates that identity to the EAP server (and the EAP server communicates that identity to the Diameter server) via the EAP method for user/peer to server verification of the Requesting Entity's Identity. 9. IANA Considerations This document requires IANA registration of the following new AVPs to the AVP registry established by RFC 3588 [3]: o EAP-DSRK-Request o EAP-DSRK o EAP-DSRK-Name o EAP-DSRK-Lifetime 10. Acknowledgments Vidya Narayanan reviewed a rough draft version and found some errors. Many thanks for her input. 11. References 11.1. Normative References [1] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005. [2] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- authentication Protocol (ERP)", RFC 5296, August 2008. [3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Dondeti, et al. Expires July 18, 2009 [Page 7] Internet-Draft Diameter Support for ERP January 2009 11.2. Informative References [5] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, "Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK)", RFC 5295, August 2008. [6] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Authors' Addresses Lakshminath Dondeti QUALCOMM, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Julien Bournelle Orange Labs 38-40 rue du general Leclerc Issy-Les-Moulineaux 92794 France Email: julien.bournelle@orange-ftgroup.com Lionel Morand Orange Labs 38-40 rue du general Leclerc Issy-Les-Moulineaux 92794 France Email: lionel.morand@orange-ftgroup.com Dondeti, et al. Expires July 18, 2009 [Page 8] Internet-Draft Diameter Support for ERP January 2009 Sebastien Decugis NICT 4-2-1 Nukui-Kitamachi Tokyo 184-8795 Koganei, Japan Email: sdecugis@nict.go.jp Dondeti, et al. Expires July 18, 2009 [Page 9]