Diameter Support for EAP Re-authentication Protocol
draft-dondeti-dime-erp-diameter-00

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 March 27, 2008.

Abstract

[5] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” March 2008.) specifies the EAP Re-authentication Protocol (ERP). This document specifies Diameter support for ERP. The EAP payload AVP defined in the Diameter EAP application specification [1] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.) is used for encapsulating the EAP Initiate and Finish messages specified in [5] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” March 2008.). This document 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 Diameter message processing rules relevant to ERP.

Table of Contents

1.  Introduction
2.  Terminology
3.  Diameter Support for ERP
    3.1.  Protocol Overview
    3.2.  DSRK Request and Delivery
4.  Security Considerations
5.  IANA Considerations
6.  Acknowledgments
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

RFC4072[1] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.) specifies EAP message encapsulation in Diameter messages. [5] (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, ERP defines two new EAP codes - EAP Initiate and EAP Finish. This document specifies the encapsulation of these messages in Diameter. In addition, a Domain Specific Root Key (DSRK) may be transported from the Diameter 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 [5] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” March 2008.). This document defines how the DSRK is transported to the ER server using Diameter.

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] (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.), [7] (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.), [5] (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.).

3.  Diameter Support for ERP

The EAP Re-authentication Protocol, defined in [5] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” March 2008.), 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 [7] (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.

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.

3.1.  Protocol Overview

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 RFC4072 [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 [5] (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 [5] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” March 2008.).

3.2.  DSRK Request and Delivery

A local ER server, collocated with a Diameter 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. A Diameter server acting as an ER server may include a EAP-DSRK-Request AVP in the Diameter EAP-Request message containing an EAP Response or an EAP Initiate Reauth packet in the EAP-Payload AVP. The Data field of the EAP-DSRK-Request AVP SHOULD be set to the domain or server identity required to derive the DSRK. The format of the Data field is OctetString. If the EAP-Payload AVP contains EAP Response, the 'M' bit in the AVP flags MUST NOT be set; if the EAP-Payload AVP contains an EAP Initiate Reauth message with the bootstrapping flag turned on, the 'M' bit MUST be set. The Diameter 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.

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.

EAP-DSRK AVP SHALL contain Data in OctetString format; EAP-DSRK-Name AVP SHALL contain Data in OctetString format; and finally EAP-DSRK-Lifetime AVP SHALL contain Data in Unsigned64 format encoding DSRK lifetime in seconds.

4.  Security Considerations

The security considerations specified in RFC 4072 [1] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.), RFC 4005 [3] (Calhoun, P., Zorn, G., Spence, D., and D. Mitton, “Diameter Network Access Server 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 user and the server are in synchronization 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.

5.  IANA Considerations

This document requires IANA registration of several new Diameter AVPs:

EAP-DSRK-Request

EAP-DSRK

EAP-DSRK-Name

EAP-DSRK-Lifetime

6.  Acknowledgments

Vidya Narayanan reviewed a rough draft version and found some errors. Many thanks for her input. Any remaining errors and omissions are my responsibility however.

7.  References

7.1. Normative References

7.2. Informative References

Author's Address

Full Copyright Statement

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.

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.