Network Working Group L. Dondeti
Internet-Draft QUALCOMM, Inc.
Intended status: Standards Track September 24, 2007
Expires: March 27, 2008
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.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
[5] 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] is used for
encapsulating the EAP Initiate and Finish messages specified in [5].
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.
Dondeti Expires March 27, 2008 [Page 1]
Internet-Draft Diameter Support for ERP September 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Diameter Support for ERP . . . . . . . . . . . . . . . . . . . 3
3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4
3.2. DSRK Request and Delivery . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . . . 8
Dondeti Expires March 27, 2008 [Page 2]
Internet-Draft Diameter Support for ERP September 2007
1. Introduction
RFC4072[1] specifies EAP message encapsulation in Diameter messages.
[5] 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]. 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].
This document uses terminology defined in [6], [7], [5], and [1].
3. Diameter Support for ERP
The EAP Re-authentication Protocol, defined in [5], 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]. 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.
Dondeti Expires March 27, 2008 [Page 3]
Internet-Draft Diameter Support for ERP September 2007
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] 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], 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].
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'
Dondeti Expires March 27, 2008 [Page 4]
Internet-Draft Diameter Support for ERP September 2007
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], RFC 4005 [3],
and RFC 3588 [4] 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
Dondeti Expires March 27, 2008 [Page 5]
Internet-Draft Diameter Support for ERP September 2007
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
[1] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
Network Access Server Application", RFC 4005, August 2005.
[4] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
7.2. Informative References
[5] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP
Reauthentication Protocol (ERP)", draft-ietf-hokey-erx-04 (work
in progress), August 2007.
[6] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
[7] Salowey, J., "Specification for the Derivation of Root Keys from
an Extended Master Session Key (EMSK)",
draft-ietf-hokey-emsk-hierarchy-01 (work in progress),
June 2007.
[8] Zorn, G., "RADIUS Attributes for the Delivery of Keying
Material", draft-zorn-radius-keywrap-13 (work in progress),
April 2007.
Dondeti Expires March 27, 2008 [Page 6]
Internet-Draft Diameter Support for ERP September 2007
Author's Address
Lakshminath Dondeti
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Dondeti Expires March 27, 2008 [Page 7]
Internet-Draft Diameter Support for ERP September 2007
Full Copyright Statement
Copyright (C) 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Dondeti Expires March 27, 2008 [Page 8]