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]
