| TOC |
|
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 May 22, 2008.
An EAP extension, called "EAP Re-authentication Protocol (ERP)", has been specified that supports an EAP method-independent protocol for efficient re-authentication between the peer and the server through an authenticator. This document specifies Diameter support for ERP. The Diameter EAP application is re-used for encapsulating the newly defined EAP Initiate and EAP Finish messages specified in the ERP specification. AVPs for request and delivery of Domain Specific Root Keys from the AAA/EAP server to the ER server are also specified. Additionally, this document also specifies Diameter processing rules relevant to ERP.
1.
Introduction
2.
Terminology
3.
Assumptions
4.
Diameter Support for ERP
4.1.
Protocol Overview
4.2.
DSRK Request and Delivery
5.
Command Codes
5.1.
Diameter-EAP-Request (DER)
5.2.
Diameter-EAP-Answer (DEA)
6.
Attribute Value Pair Definitions
6.1.
EAP-DSRK-Request AVP
6.2.
EAP-DSRK AVP
6.3.
EAP-DSRK-Name AVP
6.4.
EAP-DSRK-Lifetime AVP
7.
AVP Occurrence Table
8.
AVP Flag Rules
9.
Security Considerations
10.
IANA Considerations
11.
Acknowledgments
12.
References
12.1.
Normative References
12.2.
Informative References
§
Authors' Addresses
§
Intellectual Property and Copyright Statements
| TOC |
RFC 4072 [1] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.) specifies a Diameter application that carries EAP packets between a Diameter client and the Diameter Server/EAP server. [2] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” March 2008.) 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, an Extended Master Session Key (EMSK) based re-authentication key hierarchy has been defined [5] (Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” June 2008.). 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. To accomplish the 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.
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. This document also specifies how the DSRK is transported to the local ER server using Diameter.
| TOC |
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 [3] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
This document uses terminology defined in [6] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.), [5] (Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” June 2008.), [2] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” March 2008.), and [1] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.).
| TOC |
This document defines additional optional AVPs for usage with the Diameter EAP application. Routing of these messages is therefore provided via the Diameter Application Identifier (among other elements), as specified by the Diameter Base protocol [4] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.). Based on the deployment of ERP, a local Diameter server (the same entity serves as a Diameter proxy during the full EAP authentication) may play the role of the ER server for future re-authentication attempts. As such, the local Diameter server requesting the DSRK needs to be in the path of the current EAP exchange between the peer and the EAP server and also along in the future. The Diameter client is furthermore assumed to be able to route the re-authentication messages to the ER server.
| TOC |
| TOC |
Diameter 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 Diameter from RFC 4072 [1] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.) apply to the new EAP messages defined for ERP as well. The EAP Initiate Reauth message is encapsulated in an EAP-Payload AVP of a Diameter EAP-Request message by the NAS and sent to the Diameter server. 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 a User-Name AVP of the Diameter EAP-Request.
The ER server processes the EAP Initiate Reauth message in accordance with [2] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” March 2008.), and if that is successful, it responds with an EAP Finish Reauth message indicating a success ('R' flag set to 0). The Diameter server MUST encapsulate the EAP Finish Reauth message with the R flag set to zero in an EAP-Payload AVP attribute of a Diameter EAP-Answer message. An EAP-Master-Session-Key AVP included in the Diameter EAP-Answer contains the Re-authentication Master Session Key (rMSK). The Diameter Result Code, if any, SHOULD be a success Result Code.
If the processing of the EAP Initiate Reauth message resulted in a failure, the Diameter server MUST encapsulate an EAP Finish Reauth message indicating failure ('R' flag set to 1) in an EAP-Payload AVP of a Diameter EAP-Answer message. The Diameter Result Code, if any, SHOULD be a failure Result Code. Whether an EAP Finish Reauth message is sent at all is specified in [2] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” March 2008.).
| TOC |
A local ER server, collocated with a Diameter proxy in the peer's visited domain, may request a DSRK from the EAP server, either in the initial EAP exchange (implicit bootstrapping) or in an ERP bootstrapping exchange (explicit bootstrapping). It does this by including the EAP-DSRK-Request AVP in the Diameter EAP-Response message. The EAP-DSRK-Request AVP contains the domain or server identity required to derive the DSRK.
An EAP server MAY send the DSRK when it receives a valid Diameter EAP-Request message containing an EAP-DSRK-Request AVP. An ER server MUST send the DSRK (or send a failure result) when it receives a valid Diameter EAP-Request message containing an EAP-DSRK-Request AVP along with a valid EAP Initiate Re-auth packet with the bootstrapping flag turned on. If an EAP-DSRK-Request AVP is included in any other Diameter EAP-Request message, the Diameter server MUST reply with a failure result. An EAP-DSRK AVP MUST be used to send a DSRK; 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.
| TOC |
This document re-uses the EAP application commands [1] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.):
Command-Name Abbrev. Code Reference Application Diameter-EAP-Request DER 268 RFC 4072 EAP Diameter-EAP-Answer DEA 268 RFC 4072 EAP
| Figure 1: ERP Command Codes |
Re-Auth-Request (RAR) may trigger ERP.
Session-Termination-Request (STR), Session-Termination-Answer (STA), Abort-Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request (ACR), and Accounting-Answer (ACA) commands are used together with Diameter ERP, they follow the rules in the Diameter EAP application [1] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.) and the Diameter Base specification [4] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.). The accounting commands use the Application Identifier value of 3 (Diameter Base Accounting); the others use 0 (Diameter Common Messages).
| TOC |
The Diameter-EAP-Request (DER) message [1] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.), indicated by the Command- Code field set to 268 and the 'R' bit set in the Command Flags field, is sent by the NAS to the Diameter server to initiate a network access authentication and authorization procedure.
The DEA message format is the same as defined in [1] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.) with an addition of optional EAP Re-authentication Protocol (ERP) AVPs. The addition of the EAP-DSRK-Request AVP to the Diameter-EAP-Request message indicates that an ERP server is present and willing to participate in the ERP protocol for this session. Furthermore, the EAP-DSRK-Request AVP provides identity information about the domain of the ERP server.
<Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ EAP-DSRK-Request ]
[ User-Name ]
[ Destination-Host ]
...
* [ AVP ]
| TOC |
The Diameter-EAP-Answer (DEA) message defined in [1] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.), indicated by the Command-Code field set to 268 and 'R' bit cleared in the Command Flags field, is sent in response to the Diameter-EAP-Request message (DER).
The DEA message format is the same as defined in [1] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.) with an addition of optional EAP Re-authentication Protocol (ERP) AVPs. The addition of the EAP-DSRK, EAP-DSRK-Name and the EAP-DSRK-Lifetime AVP to the Diameter-EAP-Answer message indicates that an Diameter / ER server is able to provide ERP support for this session and delivers keying material, lifetime and a key name.
<Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
[ EAP-DSRK ]
[ EAP-DSRK-Name ]
[ EAP-DSRK-Lifetime ]
[ User-Name ]
...
* [ AVP ]
| TOC |
| TOC |
The EAP-DSRK AVP (AVP Code TBD) is of type DiameterIdentity. This AVP fulfills two purposes: First, it indicates that a ER server is located in the local domain that is willing to play the role of an ER server for a particular session. Second, it conveys information about the domain and ER server identity to the Diameter/EAP server.
| TOC |
The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. The Domain Specific Root Key (DSRK) is carried in this payload.
| TOC |
The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString. This AVP contains the name of the DSRK key that is later used during the re-authentication exchange to select the correct DSRK.
| TOC |
The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type Unsigned64 and contains the DSRK lifetime in seconds.
| TOC |
The following table lists the AVPs that may optionally be present in the DER and DEA commands [1] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.).
+---------------+
| 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 2: 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.
| TOC |
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 [4] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) 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 3: AVP Flag Rules Table |
| TOC |
The security considerations specified in RFC 4072 [1] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.), and RFC 3588 [4] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) are applicable to this document.
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.
| TOC |
This document requires IANA registration of the following new AVPs to the AVP registry established by RFC 3588 [4] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.):
| TOC |
Vidya Narayanan reviewed a rough draft version and found some errors. Many thanks for her input.
| TOC |
| TOC |
| [1] | Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” RFC 4072, August 2005 (TXT). |
| [2] | Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” draft-ietf-hokey-erx-14 (work in progress), March 2008 (TXT). |
| [3] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [4] | Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” RFC 3588, September 2003 (TXT). |
| TOC |
| [5] | 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-07 (work in progress), June 2008 (TXT). |
| [6] | Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” RFC 3748, June 2004 (TXT). |
| TOC |
| Lakshminath Dondeti | |
| QUALCOMM, Inc. | |
| 5775 Morehouse Dr | |
| San Diego, CA | |
| USA | |
| Phone: | +1 858-845-1267 |
| Email: | ldondeti@qualcomm.com |
| Hannes Tschofenig | |
| Nokia Siemens Networks | |
| Otto-Hahn-Ring 6 | |
| Munich, Bavaria 81739 | |
| Germany | |
| Email: | Hannes.Tschofenig@nsn.com |
| URI: | http://www.tschofenig.com |
| TOC |
Copyright © The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 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.
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.