Diameter Maintenance and L. Dondeti
Extensions (DIME) QUALCOMM, Inc.
Internet-Draft H. Tschofenig
Intended status: Standards Track Nokia Siemens Networks
Expires: May 22, 2008 November 19, 2007
Diameter Support for EAP Re-authentication Protocol
draft-dondeti-dime-erp-diameter-01.txt
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 May 22, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
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
Dondeti & Tschofenig Expires May 22, 2008 [Page 1]
Internet-Draft Diameter Support for ERP November 2007
Keys from the AAA/EAP server to the ER server are also specified.
Additionally, this document also specifies Diameter processing rules
relevant to ERP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Diameter Support for ERP . . . . . . . . . . . . . . . . . . . 4
4.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . 4
4.2. DSRK Request and Delivery . . . . . . . . . . . . . . . . 4
5. Command Codes . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Diameter-EAP-Request (DER) . . . . . . . . . . . . . . . . 5
5.2. Diameter-EAP-Answer (DEA) . . . . . . . . . . . . . . . . 6
6. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 7
6.1. EAP-DSRK-Request AVP . . . . . . . . . . . . . . . . . . . 7
6.2. EAP-DSRK AVP . . . . . . . . . . . . . . . . . . . . . . . 7
6.3. EAP-DSRK-Name AVP . . . . . . . . . . . . . . . . . . . . 7
6.4. EAP-DSRK-Lifetime AVP . . . . . . . . . . . . . . . . . . 7
7. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 7
8. AVP Flag Rules . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Dondeti & Tschofenig Expires May 22, 2008 [Page 2]
Internet-Draft Diameter Support for ERP November 2007
1. Introduction
RFC 4072 [1] specifies a Diameter application that carries EAP
packets between a Diameter client and the Diameter Server/EAP server.
[2] 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]. 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.
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 [3].
This document uses terminology defined in [6], [5], [2], and [1].
3. Assumptions
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]. 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
Dondeti & Tschofenig Expires May 22, 2008 [Page 3]
Internet-Draft Diameter Support for ERP November 2007
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.
4. Diameter Support for ERP
4.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 RFC 4072 [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 [2], 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].
4.2. DSRK Request and Delivery
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
Dondeti & Tschofenig Expires May 22, 2008 [Page 4]
Internet-Draft Diameter Support for ERP November 2007
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.
5. Command Codes
This document re-uses the EAP application commands [1]:
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] and the Diameter Base specification [4]. The
accounting commands use the Application Identifier value of 3
(Diameter Base Accounting); the others use 0 (Diameter Common
Messages).
5.1. Diameter-EAP-Request (DER)
The Diameter-EAP-Request (DER) message [1], 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.
Dondeti & Tschofenig Expires May 22, 2008 [Page 5]
Internet-Draft Diameter Support for ERP November 2007
The DEA message format is the same as defined in [1] 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 ]
5.2. Diameter-EAP-Answer (DEA)
The Diameter-EAP-Answer (DEA) message defined in [1], 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] 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.
Dondeti & Tschofenig Expires May 22, 2008 [Page 6]
Internet-Draft Diameter Support for ERP November 2007
<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 ]
6. Attribute Value Pair Definitions
6.1. EAP-DSRK-Request AVP
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.
6.2. EAP-DSRK AVP
The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. The Domain
Specific Root Key (DSRK) is carried in this payload.
6.3. EAP-DSRK-Name AVP
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.
6.4. EAP-DSRK-Lifetime AVP
The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type Unsigned64 and
contains the DSRK lifetime in seconds.
7. AVP Occurrence Table
The following table lists the AVPs that may optionally be present in
the DER and DEA commands [1].
Dondeti & Tschofenig Expires May 22, 2008 [Page 7]
Internet-Draft Diameter Support for ERP November 2007
+---------------+
| 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 4: 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.
8. 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 [4] 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 5: AVP Flag Rules Table
9. Security Considerations
The security considerations specified in RFC 4072 [1], and RFC 3588
[4] are applicable to this document.
Dondeti & Tschofenig Expires May 22, 2008 [Page 8]
Internet-Draft Diameter Support for ERP November 2007
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.
10. IANA Considerations
This document requires IANA registration of the following new AVPs to
the AVP registry established by RFC 3588 [4]:
o EAP-DSRK-Request
o EAP-DSRK
o EAP-DSRK-Name
o EAP-DSRK-Lifetime
11. Acknowledgments
Vidya Narayanan reviewed a rough draft version and found some errors.
Many thanks for her input.
12. References
12.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)", draft-ietf-hokey-erx-08 (work in
progress), November 2007.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588, September 2003.
Dondeti & Tschofenig Expires May 22, 2008 [Page 9]
Internet-Draft Diameter Support for ERP November 2007
12.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)", draft-ietf-hokey-emsk-hierarchy-02
(work in progress), November 2007.
[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
Hannes Tschofenig
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Dondeti & Tschofenig Expires May 22, 2008 [Page 10]
Internet-Draft Diameter Support for ERP November 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 & Tschofenig Expires May 22, 2008 [Page 11]