draft-ietf-dime-erp-15.txt   draft-ietf-dime-erp-16.txt 
Network Working Group J. Bournelle Network Working Group J. Bournelle
Internet-Draft L. Morand Internet-Draft L. Morand
Intended status: Standards Track Orange Labs Intended status: Standards Track Orange Labs
Expires: June 13, 2013 S. Decugis Expires: June 14, 2013 S. Decugis
INSIDE Secure INSIDE Secure
Q. Wu Q. Wu
Huawei Huawei
G. Zorn G. Zorn
Network Zen Network Zen
December 10, 2012 December 11, 2012
Diameter Support for the EAP Re-authentication Protocol (ERP) Diameter Support for the EAP Re-authentication Protocol (ERP)
draft-ietf-dime-erp-15.txt draft-ietf-dime-erp-16.txt
Abstract Abstract
The EAP Re-authentication Protocol (ERP) defines extensions to the The EAP Re-authentication Protocol (ERP) defines extensions to the
Extensible Authentication Protocol (EAP) to support efficient re- Extensible Authentication Protocol (EAP) to support efficient re-
authentication between the peer and an EAP Re-authentication (ER) authentication between the peer and an EAP Re-authentication (ER)
server through a compatible authenticator. This document specifies server through a compatible authenticator. This document specifies
Diameter support for ERP. It defines a new Diameter ERP application Diameter support for ERP. It defines a new Diameter ERP application
to transport ERP messages between an ER authenticator and the ER to transport ERP messages between an ER authenticator and the ER
server, and a set of new AVPs that can be used to transport the server, and a set of new AVPs that can be used to transport the
skipping to change at page 1, line 43 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 13, 2013. This Internet-Draft will expire on June 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 2, line 37
8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 12 8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 12
8.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 12 8.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Key AVP . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.3. Key AVP . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.3.1. Key-Type AVP . . . . . . . . . . . . . . . . . . . . . 12 8.3.1. Key-Type AVP . . . . . . . . . . . . . . . . . . . . . 12
8.3.2. Keying-Material AVP . . . . . . . . . . . . . . . . . 12 8.3.2. Keying-Material AVP . . . . . . . . . . . . . . . . . 12
8.3.3. Key-Name AVP . . . . . . . . . . . . . . . . . . . . . 13 8.3.3. Key-Name AVP . . . . . . . . . . . . . . . . . . . . . 13
8.3.4. Key-Lifetime AVP . . . . . . . . . . . . . . . . . . . 13 8.3.4. Key-Lifetime AVP . . . . . . . . . . . . . . . . . . . 13
9. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 13 9. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 13
9.1. Permanent Failures . . . . . . . . . . . . . . . . . . . . 13 9.1. Permanent Failures . . . . . . . . . . . . . . . . . . . . 13
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Diameter Application Identifier . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Diameter Application Identifier . . . . . . . . . . . . . 14 10.3. New Permanent Failures Result-Code AVP Values . . . . . . 14
12.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12.3. New Permanent Failures Result-Code AVP Values . . . . . . 14 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . . 15 14.1. Normative References . . . . . . . . . . . . . . . . . . . 15
14.2. Informative References . . . . . . . . . . . . . . . . . . 15 14.2. Informative References . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Cao, et al. [RFC6696] defines the EAP Re-authentication Protocol Cao, et al. [RFC6696] defines the EAP Re-authentication Protocol
(ERP). It consists of the following steps: (ERP). It consists of the following steps:
Bootstrapping Bootstrapping
skipping to change at page 3, line 38 skipping to change at page 3, line 38
This document also discusses the distribution of the root key during This document also discusses the distribution of the root key during
bootstrapping, in conjunction with either the initial EAP bootstrapping, in conjunction with either the initial EAP
authentication (implicit bootstrapping) or the first ERP exchange authentication (implicit bootstrapping) or the first ERP exchange
(explicit bootstrapping). Security considerations for this key (explicit bootstrapping). Security considerations for this key
distribution are detailed in Salowey, et al. [RFC5295]. distribution are detailed in Salowey, et al. [RFC5295].
2. Terminology 2. Terminology
This document uses terminology defined in Aboba, et al. [RFC3748], This document uses terminology defined in Aboba, et al. [RFC3748],
Salowey, et al. [RFC5295], Cao, et al. [RFC6696], and Eronen, Hiller Salowey, et al. [RFC5295], Cao, et al. [RFC6696], and Eronen, et
& Zorn [RFC4072]. al. [RFC4072].
The re-athentication Domain-Specific Root Key (rDSRK) is a re- The re-athentication Domain-Specific Root Key (rDSRK) is a re-
authentication Root Key (rRK, [RFC6696]) derived from the DSRK authentication Root Key (rRK, [RFC6696]) derived from the DSRK
instead of the EMSK. instead of the EMSK.
"Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK "Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK
derived from an EMSK, depending on the location of the ER server in derived from an EMSK, depending on the location of the ER server in
home or foreign domain. home or foreign domain.
We use the notation "ERP/DER" and "ERP/DEA" in this document to refer We use the notation "ERP/DER" and "ERP/DEA" in this document to refer
to Diameter-EAP-Request and Diameter-EAP-Answer commands with the to Diameter-EAP-Request and Diameter-EAP-Answer commands with the
Application Id set to <Diameter ERP Application> Section 12.1; the Application Id set to <Diameter ERP Application> Section 10.1; the
same commands are denoted "EAP/DER" and "EAP/DEA" when the same commands are denoted "EAP/DER" and "EAP/DEA" when the
Application Id in the message is set to <Diameter EAP Application> Application Id in the message is set to <Diameter EAP Application>
[RFC4072]. [RFC4072].
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 5, line 4 skipping to change at page 5, line 4
Figure 1: Diameter ERP Overview. Figure 1: Diameter ERP Overview.
The ER server is located either in the home domain (same as EAP The ER server is located either in the home domain (same as EAP
server) or in the visited domain (same as authenticator, when it server) or in the visited domain (same as authenticator, when it
differs from the home domain). differs from the home domain).
When the peer initiates an ERP exchange, the authenticator creates a When the peer initiates an ERP exchange, the authenticator creates a
Diameter-EAP-Request (DER) message [RFC4072]. The Application Id of Diameter-EAP-Request (DER) message [RFC4072]. The Application Id of
the message is set to that of the Diameter ERP application the message is set to that of the Diameter ERP application
Section 12.1 in the message. The generation of the ERP/DER message Section 10.1 in the message. The generation of the ERP/DER message
is detailed in Section 6. is detailed in Section 6.
If there is an ER server in the same domain as the authenticator If there is an ER server in the same domain as the authenticator
(i.e., the local domain), Diameter routing MUST be configured so that (i.e., the local domain), Diameter routing MUST be configured so that
this ERP/DER message reaches that server, even if the Destination- this ERP/DER message reaches that server, even if the Destination-
Realm is not the same as local domain. Realm is not the same as local domain.
If there is no local ER server, the message is routed according to If there is no local ER server, the message is routed according to
its Destination-Realm AVP content, extracted from the realm component its Destination-Realm AVP content, extracted from the realm component
of the keyName-NAI attribute. As specified in RFC 6696, this realm of the keyName-NAI attribute. As specified in RFC 6696, this realm
skipping to change at page 9, line 18 skipping to change at page 9, line 18
the Domain- Name TLV attribute with the content from the ERP-Realm the Domain- Name TLV attribute with the content from the ERP-Realm
AVP. The server creates the EAP/DEA reply message [RFC4072] AVP. The server creates the EAP/DEA reply message [RFC4072]
including an instance of the Key AVP (Section 8.3) with Key-Type AVP including an instance of the Key AVP (Section 8.3) with Key-Type AVP
set to rRK and an instance of the Domain-Name TLV attribute with the set to rRK and an instance of the Domain-Name TLV attribute with the
content from the ERP-Realm AVP. content from the ERP-Realm AVP.
The ER server receives this EAP/DEA and proxies it as follows, in The ER server receives this EAP/DEA and proxies it as follows, in
addition to standard proxy operations: addition to standard proxy operations:
Set the Application Id back to Diameter ERP Application Id Set the Application Id back to Diameter ERP Application Id
(Section 12.1) (Section 10.1)
Extract and cache the content of the Key AVP with Key-Type set to Extract and cache the content of the Key AVP with Key-Type set to
rRK, as described in Section 5.1). rRK, as described in Section 5.1).
The ERP/DEA message is then forwarded to the authenticator, that can The ERP/DEA message is then forwarded to the authenticator, that can
use the rMSK as described in RFC 6696. use the rMSK as described in RFC 6696.
The figure below captures this proxy behavior: The figure below captures this proxy behavior:
Authenticator ER server Home Diameter server Authenticator ER server Home Diameter server
skipping to change at page 11, line 19 skipping to change at page 11, line 19
the content of the User-Name and Destination-Realm AVPs. the content of the User-Name and Destination-Realm AVPs.
The Auth-Request-Type AVP content is set to the appropriate value. The Auth-Request-Type AVP content is set to the appropriate value.
The EAP-Payload AVP contains the EAP-Initiate/Re-Auth message. The EAP-Payload AVP contains the EAP-Initiate/Re-Auth message.
Then this ERP/DER message is sent as described in Section 4. Then this ERP/DER message is sent as described in Section 4.
The ER server receives and processes this request as described in The ER server receives and processes this request as described in
Section 4. It then creates an ERP/DEA message following the general Section 4. It then creates an ERP/DEA message following the general
process described in RFC4072 [RFC4072], with the following process described in Eronen, et al. [RFC4072], with the following
differences: differences:
The Application Id in the header is set to <Diameter ERP> (code The Application Id in the header is set to <Diameter ERP> (code
TBD1). TBD1).
The value of the Auth-Application-Id AVP is also set to <Diameter The value of the Auth-Application-Id AVP is also set to <Diameter
ERP>. ERP>.
The EAP-Payload AVP contains the EAP-Finish/Re-auth message. The EAP-Payload AVP contains the EAP-Finish/Re-auth message.
skipping to change at page 13, line 34 skipping to change at page 13, line 34
Errors that fall within the Permanent Failures category are used to Errors that fall within the Permanent Failures category are used to
inform the peer that the request failed and SHOULD NOT be attempted inform the peer that the request failed and SHOULD NOT be attempted
again. again.
DIAMETER_ERROR_ EAP_CODE_UNKNOWN (TBD4) DIAMETER_ERROR_ EAP_CODE_UNKNOWN (TBD4)
This error code is used by the Diameter server to inform the This error code is used by the Diameter server to inform the
peer that the received EAP-PAYLOAD AVP contains an EAP packet peer that the received EAP-PAYLOAD AVP contains an EAP packet
with an unknown EAP code. with an unknown EAP code.
10. Contributors 10. IANA Considerations
Hannes Tschofenig wrote the initial draft of this document.
Lakshminath Dondeti contributed to the early versions of the
document.
11. Acknowledgements
Hannes Tschofenig, Zhen Cao, Benoit Claise, Elwyn Davies, Menachem
Dodge, Vincent Roca and Jouni Korhonen provided useful reviews.
Vidya Narayanan reviewed a rough draft version of the document and
found some errors.
Many thanks to these people!
12. IANA Considerations
This document requires IANA registration of the following new This document requires IANA registration of the following new
elements in the Authentication, Authorization, and Accounting (AAA) elements in the Authentication, Authorization, and Accounting (AAA)
Parameters registries [AAAPARAMS]. Parameters registries [AAAPARAMS].
12.1. Diameter Application Identifier 10.1. Diameter Application Identifier
This specification requires IANA to allocate a new value "Diameter This specification requires IANA to allocate a new value "Diameter
ERP" (code: TBD1) in the "Application IDs" registry using the policy ERP" (code: TBD1) in the "Application IDs" registry using the
specified in Section 11.3 of RFC 3588 [RFC3588]. "Specification Required" policy [RFC5226]; see Section 11.3 of RFC
3588 [RFC3588] for further details.
12.2. New AVPs 10.2. New AVPs
This specification requires IANA to allocate new values from the "AVP This specification requires IANA to allocate new values from the "AVP
Codes" registry according to the policy specified in Section 11.1 of Codes" registry according to the policy specified in Section 11.1 of
Fajardo, et al. [RFC6733] for the following AVPs: Fajardo, et al. [RFC6733] for the following AVPs:
ERP-RK-Request (code: TBD2) ERP-RK-Request (code: TBD2)
ERP-Realm (code: TBD3) ERP-Realm (code: TBD3)
These AVPs are defined in Section 8. These AVPs are defined in Section 8.
12.3. New Permanent Failures Result-Code AVP Values 10.3. New Permanent Failures Result-Code AVP Values
This specification requires IANA to allocate a new value from the This specification requires IANA to allocate a new value from the
"Result-Code AVP Values (code 268) - Permanent Failure" registry "Result-Code AVP Values (code 268) - Permanent Failure" registry
according to the policy specified in Section 11.3.2 of Fajardo, et according to the policy specified in Section 11.3.2 of Fajardo, et
al. [RFC6733] for the following Result-Code: al. [RFC6733] for the following Result-Code:
DIAMETER_ERROR_EAP_CODE_UNKNOWN (code: TBD4) DIAMETER_ERROR_EAP_CODE_UNKNOWN (code: TBD4)
This result-code value is defined in Section 9. This result-code value is defined in Section 9.
13. Security Considerations 11. Security Considerations
The security considerations from the following documents apply here: The security considerations from the following documents apply here:
o Fajardo, et al. [RFC6733] o Eronen, et al. [RFC4072]
o RFC 4072 [RFC4072] o Cao, et al. [RFC6696]
o RFC 6696 [RFC6696] o Fajardo, et al. [RFC6733]
o Zorn, Wu and Cakulev [RFC6734] o Zorn, et al. [RFC6734]
14. References 12. Contributors
Hannes Tschofenig wrote the initial draft of this document.
Lakshminath Dondeti contributed to the early versions of the
document.
13. Acknowledgements
Hannes Tschofenig, Zhen Cao, Benoit Claise, Elwyn Davies, Menachem
Dodge, Vincent Roca and Jouni Korhonen provided useful reviews.
Vidya Narayanan reviewed a rough draft version of the document and
found some errors.
Many thanks to these people!
14. References
14.1. Normative References 14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "Extensible Authentication Protocol H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004. (EAP)", RFC 3748, June 2004.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter
Extensible Authentication Protocol (EAP) Application", Extensible Authentication Protocol (EAP) Application",
RFC 4072, August 2005. RFC 4072, August 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M.
Nakhjiri, "Specification for the Derivation of Root Keys Nakhjiri, "Specification for the Derivation of Root Keys
from an Extended Master Session Key (EMSK)", RFC 5295, from an Extended Master Session Key (EMSK)", RFC 5295,
August 2008. August 2008.
[RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., and G. Zorn, "EAP [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., and G. Zorn, "EAP
Extensions for the EAP Re-authentication Protocol Extensions for the EAP Re-authentication Protocol
(ERP)", RFC 6696, July 2012. (ERP)", RFC 6696, July 2012.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
skipping to change at page 16, line 5 skipping to change at page 15, line 43
[RFC6734] Zorn, G., Wu, Q., and V. Cakulev, "Diameter Attribute- [RFC6734] Zorn, G., Wu, Q., and V. Cakulev, "Diameter Attribute-
Value Pairs for Cryptographic Key Transport", RFC 6734, Value Pairs for Cryptographic Key Transport", RFC 6734,
October 2012. October 2012.
14.2. Informative References 14.2. Informative References
[AAAPARAMS] Internet Assigned Numbers Authority, "Authentication, [AAAPARAMS] Internet Assigned Numbers Authority, "Authentication,
Authorization, and Accounting (AAA) Parameters", Authorization, and Accounting (AAA) Parameters",
http://www.iana.org/assignments/aaa-parameters/. http://www.iana.org/assignments/aaa-parameters/.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588,
September 2003.
Authors' Addresses Authors' Addresses
Julien Bournelle Julien Bournelle
Orange Labs Orange Labs
38-40 rue du general Leclerc 38-40 rue du general Leclerc
Issy-Les-Moulineaux 92794 Issy-Les-Moulineaux 92794
France France
EMail: julien.bournelle@orange-ftgroup.com EMail: julien.bournelle@orange-ftgroup.com
 End of changes. 27 change blocks. 
52 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/