draft-ietf-hokey-rfc5296bis-06.txt   draft-ietf-hokey-rfc5296bis-07.txt 
Network Working Group Q. Wu, Ed. Network Working Group Z. Cao
Internet-Draft Huawei Internet-Draft China Mobile
Obsoletes: 5296 (if approved) Z. Cao Obsoletes: 5296 (if approved) B. He
Intended status: Standards Track China Mobile Intended status: Standards Track CATR
Expires: May 18, 2012 G. Zorn, Ed. Expires: November 18, 2012 Y. Shi
Q. Wu, Ed.
Huawei
G. Zorn, Ed.
Network Zen Network Zen
Y. Shi May 17, 2012
H3C
B. He
CATR
November 15, 2011
EAP Extensions for EAP Re-authentication Protocol (ERP) EAP Extensions for EAP Re-authentication Protocol (ERP)
draft-ietf-hokey-rfc5296bis-06 draft-ietf-hokey-rfc5296bis-07
Abstract Abstract
The Extensible Authentication Protocol (EAP) is a generic framework The Extensible Authentication Protocol (EAP) is a generic framework
supporting multiple types of authentication methods. In systems supporting multiple types of authentication methods. In systems
where EAP is used for authentication, it is desirable to avoid where EAP is used for authentication, it is desirable to avoid
repeating the entire EAP exchange with another authenticator. This repeating the entire EAP exchange with another authenticator. This
document specifies extensions to EAP and the EAP keying hierarchy to document specifies extensions to EAP and the EAP keying hierarchy to
support an EAP method-independent protocol for efficient re- support an EAP method-independent protocol for efficient re-
authentication between the peer and an EAP re-authentication server authentication between the peer and an EAP re-authentication server
skipping to change at page 1, line 48 skipping to change at page 1, line 47
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 May 18, 2012. This Internet-Draft will expire on November 18, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Changes from RFC 5296 . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 6 3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 9 3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 10
3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 10 3.2. ERP With a Local ER Server . . . . . . . . . . . . . . . . 11
4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 12 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 14
4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 14 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 15
4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 14 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 15
4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 15 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 16
4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 16
4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 17
4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 17
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 18
5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 22 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 23
5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 23 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 24
5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 24 5.3. EAP Codes . . . . . . . . . . . . . . . . . . . . . . . . 25
5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 25 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 26
5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 26 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 27
5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 26 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 27
5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 26 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 27
5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 28 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 29
5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 32
5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 33
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 33
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 34
7. AAA Transport of ERP Messages . . . . . . . . . . . . . . . . 34 7. AAA Transport of ERP Messages . . . . . . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 36
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.1. Normative References . . . . . . . . . . . . . . . . . . . 39 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41
10.2. Informative References . . . . . . . . . . . . . . . . . . 40 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 41 12.1. Normative References . . . . . . . . . . . . . . . . . . . 41
A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 41 12.2. Informative References . . . . . . . . . . . . . . . . . . 42
A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 41 Appendix A. RFC 5296 Acknowledgments . . . . . . . . . . . . . . 43
Appendix B. Sample ERP Exchange . . . . . . . . . . . . . . . . . 41 Appendix B. Sample ERP Exchange . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP) is a an authentication The Extensible Authentication Protocol (EAP) is a an authentication
framework that supports multiple authentication methods. The primary framework that supports multiple authentication methods. The primary
purpose is network access authentication, and a key-generating method purpose is network access authentication, and a key-generating method
is used when the lower layer wants to enforce access control. The is used when the lower layer wants to enforce access control. The
EAP keying hierarchy defines two keys to be derived by all key- EAP keying hierarchy defines two keys to be derived by all key-
generating EAP methods: the Master Session Key (MSK) and the Extended generating EAP methods: the Master Session Key (MSK) and the Extended
MSK (EMSK). In the most common deployment scenario, an EAP peer and MSK (EMSK). In the most common deployment scenario, an EAP peer and
skipping to change at page 4, line 39 skipping to change at page 4, line 39
computational overhead (e.g., EAP-AKA [RFC4187]), but method-specific computational overhead (e.g., EAP-AKA [RFC4187]), but method-specific
re-authentication takes at least 2 round trips with the original EAP re-authentication takes at least 2 round trips with the original EAP
server in most cases. It is also important to note that several server in most cases. It is also important to note that several
methods do not offer support for re-authentication. methods do not offer support for re-authentication.
Key sharing across authenticators is sometimes used as a practical Key sharing across authenticators is sometimes used as a practical
solution to lower handover times. In that case, however, the solution to lower handover times. In that case, however, the
compromise of one authenticator results in the compromise of keying compromise of one authenticator results in the compromise of keying
material established via other authenticators. Other solutions for material established via other authenticators. Other solutions for
fast re-authentication exist in the literature: for example, see fast re-authentication exist in the literature: for example, see
Lopez, et al. [MSKHierarchy]; Clancy, et al. have described the EAP Lopez, et al. [MSKHierarchy]; Clancy, et al. have described the EAP
re-authentication problem statement in detail [RFC5169]. re-authentication problem statement in detail [RFC5169].
In conclusion, to achieve low latency handovers, there is a need for In conclusion, to achieve low latency handovers, there is a need for
a method-independent re-authentication protocol that completes in a method-independent re-authentication protocol that completes in
less than 2 round trips, preferably with a local server. less than 2 round trips, preferably with a local server.
This document specifies EAP Re-authentication Extensions (ERXs) for This document specifies EAP Re-authentication Extensions (ERXs) for
efficient re-authentication using EAP. The protocol that uses these efficient re-authentication using EAP. The protocol that uses these
extensions is itself referred to as the EAP Re-authentication extensions is itself referred to as the EAP Re-authentication
Protocol (ERP). It supports EAP method-independent re-authentication Protocol (ERP). It supports EAP method-independent re-authentication
skipping to change at page 5, line 12 skipping to change at page 5, line 12
performed EAP authentication. The protocol and the key hierarchy performed EAP authentication. The protocol and the key hierarchy
required for EAP re-authentication are described in this document. required for EAP re-authentication are described in this document.
Note that to support ERP, lower-layer specifications may need to be Note that to support ERP, lower-layer specifications may need to be
revised to allow carrying EAP messages that have a code value higher revised to allow carrying EAP messages that have a code value higher
than 4 and to accommodate the peer-initiated nature of ERP. than 4 and to accommodate the peer-initiated nature of ERP.
Specifically, the Internet Key Exchange (IKE) protocol [RFC5996] must Specifically, the Internet Key Exchange (IKE) protocol [RFC5996] must
be updated to carry ERP messages; work is in progress on this project be updated to carry ERP messages; work is in progress on this project
[I-D.nir-ipsecme-erx]. [I-D.nir-ipsecme-erx].
1.1. Changes from RFC 5296
This document obsoletes RFC 5296 but is fully backward compatible
with that document. The changes introduced in this document focus on
fixing issues that have surfaced since the publication of the
original ERP specification [RFC5296]. An overview of some the major
changes is given below.
o Co-location of the home ER and EAP servers is no longer required
(see the "ER Server entry in Section 2).
o The behavior of the authenticator and local ER server during the
bootstrapping process has been clarified (Section 5.1); in
particular, the authenticator and/or local ER server is now
required to check for current possesion of the root keys.
o The authenticator is now recommended, rather than just allowed, to
initiate the ERP conversation by means of the EAP-Initiate/
Re-auth-Start message (Section 5.3.1.1).
In addition, many editorial changes have been made to improve the
clarity of the document and to eliminate perceived abmbiguities. A
comprehensive list of changes is not given here for practical
reasons.
2. Terminology 2. Terminology
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the basic EAP terminology [RFC3748] and EMSK This document uses the basic EAP terminology [RFC3748] and EMSK
keying hierarchy terminology [RFC5295]. In addition, this document keying hierarchy terminology [RFC5295]. In addition, this document
uses the following terms: uses the following terms:
skipping to change at page 7, line 43 skipping to change at page 8, line 25
[Bootstrap] [Bootstrap]) [Bootstrap] [Bootstrap])
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
Re-auth/ Re-auth/ Re-auth/ Re-auth/
[Bootstrap] [Bootstrap]) [Bootstrap] [Bootstrap])
Note: [] brackets indicate optionality. Note: [] brackets indicate optionality.
Figure 2: ERP Exchange Figure 2: ERP Exchange
Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this Two EAP codes, EAP-Initiate and EAP-Finish, are specified in this
document for the purpose of EAP re-authentication. When the peer document for the purpose of EAP re-authentication. When the peer
identifies a target authenticator that supports EAP re- identifies a target authenticator that supports EAP re-
authentication, it performs an ERP exchange, as shown in Figure 2; authentication, it performs an ERP exchange, as shown in Figure 2;
the exchange itself may happen when the peer attaches to a new the exchange itself may happen when the peer attaches to a new
authenticator supporting EAP re-authentication, or prior to authenticator supporting EAP re-authentication, or prior to
attachment. The peer initiates ERP by itself; it may also do so in attachment. The peer initiates ERP by itself; it may also do so in
response to an EAP-Initiate/Re-auth-Start message from the new response to an EAP-Initiate/Re-auth-Start message from the new
authenticator. The EAP-Initiate/Re-auth-Start message allows the authenticator. The EAP-Initiate/Re-auth-Start message allows the
authenticator to trigger the ERP exchange. The EAP-Finish message authenticator to trigger the ERP exchange. The EAP-Finish message
also can be used by the authenticator to announce the local domain also can be used by the authenticator to announce the local domain
skipping to change at page 9, line 19 skipping to change at page 9, line 46
possession of the rIK, and freshness of the message, derives a re- possession of the rIK, and freshness of the message, derives a re-
authentication MSK (rMSK) from the rRK using the sequence number as authentication MSK (rMSK) from the rRK using the sequence number as
an input to the key derivation. The server then updates the expected an input to the key derivation. The server then updates the expected
sequence number to the received sequence number plus one. sequence number to the received sequence number plus one.
In response to the EAP-Initiate/Re-auth message, the server sends an In response to the EAP-Initiate/Re-auth message, the server sends an
EAP-Finish/Re-auth message; this message is integrity protected with EAP-Finish/Re-auth message; this message is integrity protected with
the rIK. The server transports the rMSK along with this message to the rIK. The server transports the rMSK along with this message to
the authenticator. The rMSK is transported in a manner similar to the authenticator. The rMSK is transported in a manner similar to
that of the MSK along with the EAP-Success message in a full EAP that of the MSK along with the EAP-Success message in a full EAP
exchange. Hoeper, et al.[RFC5749] discuss an additional key exchange. Hoeper, et al. [RFC5749] discuss an additional key
distribution protocol that can be used to transport the rRK from an distribution protocol that can be used to transport the rRK from an
EAP server to one of many different ER servers that share a trust EAP server to one of many different ER servers that share a trust
relationship with the EAP server. relationship with the EAP server.
The peer MAY request the rMSK lifetime from the server. If so, the The peer MAY request the rMSK lifetime from the server. If so, the
ER server sends the rMSK lifetime in the EAP-Finish/Re-auth message. ER server sends the rMSK lifetime in the EAP-Finish/Re-auth message.
In an ERP bootstrap exchange, the peer MAY ask the server for the rRK In an ERP bootstrap exchange, the peer MAY ask the server for the rRK
lifetime. If so, the ER server sends the rRK lifetime in the EAP- lifetime. If so, the ER server sends the rRK lifetime in the EAP-
Finish/Re-auth message. Finish/Re-auth message.
skipping to change at page 10, line 26 skipping to change at page 11, line 24
Re-auth/ Re-auth/ Re-auth/ Re-auth/
Bootstrap Bootstrap) Bootstrap Bootstrap)
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
Re-auth/ Re-auth/ Re-auth/ Re-auth/
Bootstrap Bootstrap) Bootstrap Bootstrap)
Figure 3: ER Explicit Bootstrapping Exchange/ERP with the Home ER Figure 3: ER Explicit Bootstrapping Exchange/ERP with the Home ER
Sever Sever
3.2. ERP with a Local ER Server 3.2. ERP With a Local ER Server
The defined ER extensions allow the execution of ERP with an ER The defined ER extensions allow the execution of ERP with an ER
server in the local domain (access network) if the peer moves out of server in the local domain (access network) if the peer moves out of
home domain and a local ER server is present in the visited domain. the home domain and a local ER server is present in the visited
The local ER server may be co-located with a local AAA server. The domain. The local ER server may be co-located with a local AAA
peer may learn about the presence of a local ER server in the network server. The peer may learn about the presence of a local ER server
and the local domain name (or ER server name) either via a lower in the network and the local domain name (or ER server name) either
layer advertisement or by means of ERP exchange. The peer uses the via a lower layer advertisement or by means of an ERP exchange. The
domain name and the EMSK to compute the DSRK and from that key, the peer uses the domain name and the EMSK to compute the DSRK and from
DS-rRK; the peer also uses the domain name in the realm portion of that key, the DS-rRK; the peer also uses the domain name in the realm
the keyName-NAI for using ERP in the local domain. Figure 4 shows portion of the keyName-NAI for using ERP in the local domain.
the ER Implicit bootstrapping exchange through local ER Figure 4 shows the ER Implicit bootstrapping exchange through local
Server;Figure 5shows ERP with a local ER server. ER Server;Figure 5shows ERP with a local ER server.
Peer EAP Authenticator Local AAA Agent Home EAP Server Peer EAP Authenticator Local AAA Agent Home EAP Server
/ER Authenticator /Local ER Server /ER Authenticator /Local ER Server
==== ================= =============== =============== ==== ================= =============== ===============
<-- EAP-Request/ -- <-- EAP-Request/ --
Identity Identity
-- EAP Response/--> -- EAP Response/-->
Identity --AAA(EAP Response/--> Identity --AAA(EAP Response/-->
skipping to change at page 12, line 17 skipping to change at page 13, line 17
of the full EAP exchange (e.g., this may be one of the AAA entities, of the full EAP exchange (e.g., this may be one of the AAA entities,
such as AAA proxies, in the path between the EAP authenticator and such as AAA proxies, in the path between the EAP authenticator and
the home EAP server of the peer). In that case, the local ER server the home EAP server of the peer). In that case, the local ER server
requests the DSRK by sending the domain name to the home EAP server requests the DSRK by sending the domain name to the home EAP server
by means of an AAA message. In response, the home EAP server by means of an AAA message. In response, the home EAP server
computes the DSRK by following the procedure specified in [RFC5295] computes the DSRK by following the procedure specified in [RFC5295]
and sends the DSRK and the key name, EMSKname, to the ER server in and sends the DSRK and the key name, EMSKname, to the ER server in
the claimed domain (i.e., the local ER Server). The local domain is the claimed domain (i.e., the local ER Server). The local domain is
responsible for announcing that same domain name to the peer via a responsible for announcing that same domain name to the peer via a
lower layer (for example, through DHCP-based local domain name lower layer (for example, through DHCP-based local domain name
discovery [I-D.ietf-hokey-ldn-discovery], or through the EAP- discovery [RFC6440], or through the EAP-Initiate/Re-auth-Start
Initiate/Re-auth-Start message with the local ER server. message with the local ER server.
After receiving the DSRK and the EMSKname, the local ER server After receiving the DSRK and the EMSKname, the local ER server
computes the DS-rRK and the DS-rIK from the DSRK as defined in computes the DS-rRK and the DS-rIK from the DSRK as defined in
Sections 4.1 and 4.3 below. After receiving the domain name, the Sections 4.1 and 4.3 below. After receiving the domain name, the
peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys
are referred to by a keyName-NAI formed as follows: the username part are referred to by a keyName-NAI formed as follows: the username part
of the NAI is the EMSKname, the realm portion of the NAI is the of the NAI is the EMSKname, the realm portion of the NAI is the
domain name. Both parties also maintain a sequence number domain name. Both parties also maintain a sequence number
(initialized to zero) corresponding to the specific keyName-NAI. (initialized to zero) corresponding to the specific keyName-NAI.
If the peer subsequently attaches to an authenticator within the If the peer subsequently attaches to an authenticator within the
local domain, it may perform an ERP exchange with the local ER server local domain, it may perform an ERP exchange with the local ER server
to obtain a rMSK for the new authenticator. The ERP with the local to obtain a rMSK for the new authenticator. The ERP with the local
ER Server is similar to ERP exchange illustrated in Figure 2. ER Server is similar to the ERP exchange illustrated in Figure 2.
4. ER Key Hierarchy 4. ER Key Hierarchy
Each time the peer re-authenticates to the network, the peer and the Each time the peer re-authenticates to the network, the peer and the
authenticator establish an rMSK. The rMSK serves the same purposes authenticator establish an rMSK. The rMSK serves the same purposes
that an MSK, which is the result of full EAP authentication, serves. that an MSK, which is the result of full EAP authentication, serves.
To prove possession of the rRK, we specify the derivation of another To prove possession of the rRK, we specify the derivation of another
key, the rIK. These keys are derived from the rRK. Together they key, the rIK. These keys are derived from the rRK. Together they
constitute the ER key hierarchy. constitute the ER key hierarchy.
skipping to change at page 16, line 11 skipping to change at page 17, line 11
that rIK. that rIK.
If the server's policy does not allow the use of the cryptosuite If the server's policy does not allow the use of the cryptosuite
selected by the peer, the server SHALL reject the EAP-Initiate/ selected by the peer, the server SHALL reject the EAP-Initiate/
Re-auth message and SHOULD send a list of acceptable cryptosuites in Re-auth message and SHOULD send a list of acceptable cryptosuites in
the EAP-Finish/Re-auth message. the EAP-Finish/Re-auth message.
The rIK length may be different from the key length required by an The rIK length may be different from the key length required by an
integrity algorithm. In case of hash-based MAC algorithms, the key integrity algorithm. In case of hash-based MAC algorithms, the key
is first hashed to the required key length using the HMAC algorithm is first hashed to the required key length using the HMAC algorithm
RFC 2104 [RFC2104]. In case of cipher-based MAC algorithms, if the [RFC2104]. In the case of cipher-based MAC algorithms, if the
required key length is less than 32 octets, the rIK is hashed using required key length is less than 32 octets, the rIK is hashed using
HMAC-SHA256 and the first k octets of the output are used, where k is HMAC-SHA256 and the first k octets of the output are used, where k is
the key length required by the algorithm. If the required key length the key length required by the algorithm. If the required key length
is more than 32 octets, the first k octets of the rIK are used by the is more than 32 octets, the first k octets of the rIK are used by the
cipher-based MAC algorithm. cipher-based MAC algorithm.
4.6. rMSK Derivation 4.6. rMSK Derivation
The rMSK is derived at the peer and server and delivered to the The rMSK is derived at the peer and server and delivered to the
authenticator. The rMSK is derived following an EAP Re-auth Protocol authenticator. The rMSK is derived following an EAP Re-auth Protocol
skipping to change at page 17, line 28 skipping to change at page 18, line 28
expiry of the lifetime. expiry of the lifetime.
o A given rMSK MUST NOT be shared by multiple authenticators. o A given rMSK MUST NOT be shared by multiple authenticators.
5. Protocol Details 5. Protocol Details
5.1. ERP Bootstrapping 5.1. ERP Bootstrapping
We identify two types of bootstrapping for ERP: explicit and We identify two types of bootstrapping for ERP: explicit and
implicit. In implicit bootstrapping, the ER-capable authenticator or implicit. In implicit bootstrapping, the ER-capable authenticator or
local ER server MUST verify whether it has valid rMSK or rRK local ER server MUST verify whether it has a valid rMSK or rRK
corresponding to the peer. If ER capable authenticator or the local corresponding to the peer. If the ER capable authenticator or the
ER server has the key materials corresponding to the peer, it MUST be local ER server has the key materials corresponding to the peer, it
able to respond directly in the same way as the home AAA server does MUST be able to respond directly in the same way as the home AAA
without forwarding the DSRK request to the home domain; if not, the server does without forwarding the DSRK request to the home domain;
ER-capable authenticator or local ER server SHOULD include its domain if not, the ER-capable authenticator or local ER server SHOULD
name in the AAA message encapsulating the first EAP Response message include its domain name in the AAA message encapsulating the first
sent by the peer and request the DSRK from the home EAP server during EAP Response message sent by the peer and request the DSRK from the
the initial EAP exchange. If such EAP exchange is successful, the home EAP server during the initial EAP exchange. If such EAP
home EAP server sends the DSRK for the specified local AAA client or exchange is successful, the home EAP server sends the DSRK for the
agent (derived using the EMSK and the domain name as specified in RFC specified local AAA client or agent (derived using the EMSK and the
5295), EMSKname, and DSRK lifetime along with the EAP-Success domain name as specified in RFC 5295), EMSKname, and DSRK lifetime
message. The local AAA client or agent MUST extract the DSRK, along with the EAP-Success message. The local AAA client or agent
EMSKname, and DSRK lifetime (if present) before forwarding the EAP- MUST extract the DSRK, EMSKname, and DSRK lifetime (if present)
Success message to the peer. Note that the MSK (also present with before forwarding the EAP-Success message to the peer. Note that the
the EAP Success message) is extracted by the EAP authenticator as MSK (also present with the EAP Success message) is extracted by the
usual. The peer learns the domain name through the EAP-Initiate/ EAP authenticator as usual. The peer learns the domain name through
Re-auth-Start message or by means of lower-layer announcement (for the EAP-Initiate/Re-auth-Start message or by means of lower-layer
example, DHCP [I-D.ietf-hokey-ldn-discovery]). When the domain name announcement (for example, DHCP [RFC6440]). When the domain name is
is available to the peer during or after the full EAP authentication, available to the peer during or after the full EAP authentication, it
it attempts to use ERP when it associates with a new authenticator. attempts to use ERP when it associates with a new authenticator.
If the peer knows there is no local ER server presented in the If the peer knows there is no local ER server presented in the
visited domain, it SHOULD initiate Explicit ERP bootstrapping (ERP visited domain, it SHOULD initiate Explicit ERP bootstrapping (ERP
exchange with the bootstrap flag turned on) with the home ER server exchange with the bootstrap flag turned on) with the home ER server
to obtain the rRK. The peer MAY also initiate bootstrapping to fetch to obtain the rRK. The peer MAY also initiate bootstrapping to fetch
information such as the rRK lifetime from the AAA server. information such as the rRK lifetime from the AAA server.
The following steps describe the ERP Explicit Bootstrapping process: The following steps describe the ERP Explicit Bootstrapping process:
o The peer sends the EAP-Initiate/Re-auth message with the o The peer sends the EAP-Initiate/Re-auth message with the
skipping to change at page 19, line 32 skipping to change at page 20, line 32
* If the ER server verifies the authorization of a local ER * If the ER server verifies the authorization of a local ER
server, it MAY include the Authorization Indication TLV to server, it MAY include the Authorization Indication TLV to
indicate to the peer that the server that received the DSRK and indicate to the peer that the server that received the DSRK and
that is advertising the domain included in the domain name TLV that is advertising the domain included in the domain name TLV
is authorized. is authorized.
* An authentication tag MUST be included to prove that the EAP- * An authentication tag MUST be included to prove that the EAP-
Finish/Re-auth message originates at a server that possesses Finish/Re-auth message originates at a server that possesses
the rIK corresponding to the EMSKname-NAI. the rIK corresponding to the EMSKname-NAI.
o If the home ER server gets involved in ERP exchange and the ERP o If the home ER server is involved in the ERP exchange and the ERP
exchange is successful, the home ER server SHOULD request the DSRK exchange is successful, the home ER server SHOULD request the DSRK
from the home EAP server; the home EAP server MUST provide the from the home EAP server; the home EAP server MUST provide the
DSRK for the home ER server (derived using the EMSK and the domain DSRK for the home ER server (derived using the EMSK and the domain
name as specified in RFC 5295), EMSKname, and DSRK lifetime for name as specified in RFC 5295), EMSKname, and DSRK lifetime for
inclusion in the AAA message. The home ER server SHOULD obtain inclusion in the AAA message. The home ER server SHOULD obtain
them before sending the EAP-Finish/Re-auth message. them before sending the EAP-Finish/Re-auth message.
o In addition, the rMSK is sent along with the EAP-Finish/Re-auth o In addition, the rMSK is sent along with the EAP-Finish/Re-auth
message in a AAA attribute (for an example, see Bournelle, et message in a AAA attribute (for an example, see Bournelle, et
al.[I-D.ietf-dime-erp]. al. [I-D.ietf-dime-erp].
o The authenticator receives the rMSK. o The authenticator receives the rMSK.
o When the peer receives an EAP-Finish/Re-auth message with the o When the peer receives an EAP-Finish/Re-auth message with the
bootstrap flag set, if a local domain name is present, it MUST use bootstrap flag set, if a local domain name is present, it MUST use
that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName- that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName-
NAI, and initialize the replay counter for the DS-rIK. If not, NAI, and initialize the replay counter for the DS-rIK. If not,
the peer SHOULD derive the domain-specific keys using the domain the peer SHOULD derive the domain-specific keys using the domain
name it learned via the lower layer or from the EAP-Initiate/ name it learned via the lower layer or from the EAP-Initiate/
Re-auth-Start message. If the peer does not know the domain name, Re-auth-Start message. If the peer does not know the domain name,
skipping to change at page 24, line 12 skipping to change at page 25, line 12
When the peer runs explicit bootstrapping (ERP with the bootstrapping When the peer runs explicit bootstrapping (ERP with the bootstrapping
flag on), there may not be a local ER server available to send a DSRK flag on), there may not be a local ER server available to send a DSRK
Request and the domain name. In that case, the server cannot send Request and the domain name. In that case, the server cannot send
the DSRK and MUST NOT include the domain name TLV. When the peer the DSRK and MUST NOT include the domain name TLV. When the peer
receives a response in the bootstrapping exchange without a domain receives a response in the bootstrapping exchange without a domain
name TLV, it assumes that there is no local ER server. The home ER name TLV, it assumes that there is no local ER server. The home ER
server sends an rMSK to the ER authenticator, however, and the peer server sends an rMSK to the ER authenticator, however, and the peer
SHALL run the TSK establishment protocol as usual. SHALL run the TSK establishment protocol as usual.
5.3. New EAP Packets 5.3. EAP Codes
Two new EAP Codes are defined for the purpose of ERP: EAP-Initiate Two EAP Codes are defined for the purpose of ERP: EAP-Initiate and
and EAP-Finish. The packet format for these messages follows the EAP EAP-Finish. The packet format for these messages follows the EAP
packet format defined in Aboba. et al. [RFC3748]. packet format defined in Aboba, et al. [RFC3748].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ... | Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 7: EAP Packet Figure 7: EAP Packet
Code Code
Two new code values are defined for the purpose of ERP: Two code values are defined for the purpose of ERP:
5 Initiate 5 Initiate
6 Finish 6 Finish
Identifier Identifier
The Identifier field is one octet. The Identifier field MUST The Identifier field is one octet. The Identifier field MUST
be the same if an EAP-Initiate packet is retransmitted due to a be the same if an EAP-Initiate packet is retransmitted due to a
timeout while waiting for a EAP-Finish message. Any new (non- timeout while waiting for a EAP-Finish message. Any new (non-
skipping to change at page 27, line 34 skipping to change at page 28, line 34
'B' - The B flag is used as the bootstrapping flag. If the 'B' - The B flag is used as the bootstrapping flag. If the
flag is turned on, the message is a bootstrap message. flag is turned on, the message is a bootstrap message.
'L' - The L flag is used to request the key lifetimes from the 'L' - The L flag is used to request the key lifetimes from the
server. server.
The remaining 5 bits are set to 0 on transmission and ignored The remaining 5 bits are set to 0 on transmission and ignored
on reception. on reception.
SEQ: A 16-bit sequence number is used for replay protection. The SEQ: An unsigned 16-bit sequence number is used for replay
SEQ number field is initialized to 0 every time a new rRK is protection. The SEQ number field is initialized to 0 every time a
derived. new rRK is derived. The field is encoded in network byte order.
TVs or TLVs: In the TV payloads, there is a 1-octet type payload TVs or TLVs: In the TV payloads, there is a 1-octet type payload
and a value with type-specific length. In the TLV payloads, there and a value with type-specific length. In the TLV payloads, there
is a 1-octet type payload and a 1-octet length payload. The is a 1-octet type payload and a 1-octet length payload. The
length field indicates the length of the value expressed in number length field indicates the length of the value expressed in number
of octets. of octets.
keyName-NAI: This is carried in a TLV payload. The Type is 1. keyName-NAI: This is carried in a TLV payload. The Type is 1.
The NAI is variable in length, not exceeding 253 octets. The The NAI is variable in length, not exceeding 253 octets. The
EMSKname is in the username part of the NAI and is encoded in EMSKname is in the username part of the NAI and is encoded in
hexadecimal values. The EMSKname is 64 bits in length and so hexadecimal values. The EMSKname is 64 bits in length and so
the username portion takes up 16 octets. If the rIK is derived the username portion takes up 16 octets. If the rIK is derived
from the EMSK, the realm part of the NAI is the home domain from the EMSK, the realm part of the NAI is the home domain
name, and if the rIK is derived from a DSRK, the realm part of name, and if the rIK is derived from a DSRK, the realm part of
the NAI is the domain name used in the derivation of the DSRK. the NAI is the domain name used in the derivation of the DSRK.
The NAI syntax follows [RFC4282]. Exactly one keyName-NAI The NAI syntax is specified in Aboba, et al. [RFC4282].
attribute SHALL be present in an EAP-Initiate/Re-auth packet.
Exactly one keyName-NAI attribute SHALL be present in an EAP-
Initiate/Re-auth packet.
In addition, channel binding information MAY be included; see In addition, channel binding information MAY be included; see
Section 5.5 for discussion. See Figure 12 for parameter Section 5.5 for discussion. See Figure 12 for parameter
specification. specification.
Cryptosuite: This field indicates the integrity algorithm used for Cryptosuite: This field indicates the integrity algorithm used for
ERP. Key lengths and output lengths are either indicated or are ERP. Key lengths and output lengths are either indicated or are
obvious from the cryptosuite name. We specify some cryptosuites obvious from the cryptosuite name. We specify some cryptosuites
below: below:
skipping to change at page 28, line 44 skipping to change at page 29, line 46
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|B|L| Reserved | SEQ ~ | Type |R|B|L| Reserved | SEQ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~ | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cryptosuite | Authentication Tag ~ | Cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: EAP-Finish/Re-auth Packet Figure 10: EAP-Finish/Re-auth Packet
Type = 2. Type = 2.
Flags Flags
'R' - The R flag is used as the Result flag. When set to 0, it 'R' - The R flag is used as the Result flag. When set to 0, it
indicates success, and when set to '1', it indicates a failure. indicates success, and when set to '1', it indicates a failure.
'B' - The B flag is used as the bootstrapping flag. If the 'B' - The B flag is used as the bootstrapping flag. If the
flag is turned on, the message is a bootstrap message. flag is turned on, the message is a bootstrap message.
'L' - The L flag is used to indicate the presence of the rRK 'L' - The L flag is used to indicate the presence of the rRK
lifetime TLV. lifetime TLV.
The remaining 5 bits are set to 0 on transmission and ignored The remaining 5 bits are set to 0 on transmission and ignored
on reception. on reception.
SEQ: A 16-bit sequence number is used for replay protection. The SEQ: An unsigned 16-bit sequence number is used for replay
SEQ number field is initialized to 0 every time a new rRK is protection. The SEQ number field is initialized to 0 every time a
derived. new rRK is derived. The field is encoded in network byte order.
TVs or TLVs: In the TV payloads, there is a 1-octet type payload TVs or TLVs: In the TV payloads, there is a 1-octet type payload
and a value with type-specific length. In the TLV payloads, there and a value with type-specific length. In the TLV payloads, there
is a 1-octet type payload and a 1-octet length payload. The is a 1-octet type payload and a 1-octet length payload. The
length field indicates the length of the value expressed in number length field indicates the length of the value expressed in number
of octets. of octets.
keyName-NAI: This is carried in a TLV payload. The Type is 1. keyName-NAI: This is carried in a TLV payload. The Type is 1.
The NAI is variable in length, not exceeding 253 octets. The NAI is variable in length, not exceeding 253 octets.
EMSKname is in the username part of the NAI and is encoded in EMSKname is in the username part of the NAI and is encoded in
hexadecimal values. The EMSKname is 64 bits in length and so hexadecimal values. The EMSKname is 64 bits in length and so
the username portion takes up 16 octets. If the rIK is derived the username portion takes up 16 octets. If the rIK is derived
from the EMSK, the realm part of the NAI is the home domain from the EMSK, the realm part of the NAI is the home domain
name, and if the rIK is derived from a DSRK, the realm part of name, and if the rIK is derived from a DSRK, the realm part of
the NAI is the domain name used in the derivation of the DSRK. the NAI is the domain name used in the derivation of the DSRK.
The NAI syntax follows [RFC4282]. Exactly one instance of the The NAI syntax follows [RFC4282]. Exactly one instance of the
keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth keyName-NAI attribute SHALL be present in an EAP-Finish/Re-auth
message. message.
rRK Lifetime: This is a TV payload. The Type is 2. The value rRK Lifetime: This is a TV payload. The Type is 2. The value
field is a 32-bit field and contains the lifetime of the rRK in field contains an unsigned 32-bit integer in network byte order
seconds. If the 'L' flag is set, the rRK Lifetime attribute representing the lifetime of the rRK in seconds. If the 'L'
SHOULD be present. flag is set, the rRK Lifetime attribute SHOULD be present.
rMSK Lifetime: This is a TV payload. The Type is 3. The value rMSK Lifetime: This is a TV payload. The Type is 3. The value
field is a 32-bit field and contains the lifetime of the rMSK field contains an unsigned 32-bit integer in network byte order
in seconds. If the 'L' flag is set, the rMSK Lifetime representing the lifetime of the rMSK in seconds. If the 'L'
attribute SHOULD be present. flag is set, the rMSK Lifetime attribute SHOULD be present.
Domain-Name: This is a TLV payload. The Type is 4. The domain Domain-Name: This is a TLV payload. The Type is 4. The domain
name is to be used as the realm in an NAI [RFC4282]. Domain- name is to be used as the realm in an NAI [RFC4282]. Domain-
Name attribute MUST be present in an EAP-Finish/Re-auth message Name attribute MUST be present in an EAP-Finish/Re-auth message
if the bootstrapping flag is set and if the local ER server if the bootstrapping flag is set and if the local ER server
sent a DSRK request. sent a DSRK request.
List of cryptosuites: This is a TLV payload. The Type is 5. List of cryptosuites: This is a TLV payload. The Type is 5.
The value field contains a list of cryptosuites, each of size 1 The value field contains a list of cryptosuites, each of size 1
octet. The cryptosuite values are as specified in Figure 9. octet. The cryptosuite values are as specified in Figure 9.
skipping to change at page 32, line 42 skipping to change at page 33, line 42
responded to the message and the response was lost in transit. Thus, responded to the message and the response was lost in transit. Thus,
the peer MUST increment the sequence number and use the new sequence the peer MUST increment the sequence number and use the new sequence
number to send subsequent EAP re-authentication messages. The peer number to send subsequent EAP re-authentication messages. The peer
SHOULD increment the sequence number by 1; however, it may choose to SHOULD increment the sequence number by 1; however, it may choose to
increment by a larger number. If the sequence number wraps back to increment by a larger number. If the sequence number wraps back to
zero, the peer MUST run full EAP authentication. zero, the peer MUST run full EAP authentication.
5.5. Channel Binding 5.5. Channel Binding
ERP provides a protected facility to carry channel binding (CB) ERP provides a protected facility to carry channel binding (CB)
information, according to the guidelines provided by Aboba, et al. information, according to the guidelines provided by Aboba, et
(see Section 7.15 of [RFC3748]). The TLV type range of 128-191 is al. (see Section 7.15 of [RFC3748]). The TLV type range of 128-191
reserved to carry CB information in the EAP-Initiate/Re-auth and EAP- is reserved to carry CB information in the EAP-Initiate/Re-auth and
Finish/Re-auth messages. Called-Station-Id, Calling-Station-Id, NAS- EAP-Finish/Re-auth messages. Called-Station-Id, Calling-Station-Id,
Identifier, NAS-IP-Address, and NAS-IPv6-Address are some examples of NAS-Identifier, NAS-IP-Address, and NAS-IPv6-Address are some
channel binding information listed in RFC 3748, and they are assigned examples of channel binding information listed in RFC 3748, and they
values 128-132. Additional values are IANA managed based on IETF are assigned values 128-132. Additional values are IANA managed
Consensus [RFC5226]. based on IETF Consensus [RFC5226].
The authenticator MAY provide CB information to the peer via the EAP- The authenticator MAY provide CB information to the peer via the EAP-
Initiate/Re-auth-Start message. The peer sends the information to Initiate/Re-auth-Start message. The peer sends the information to
the server in the EAP-Initiate/Re-auth message; the server verifies the server in the EAP-Initiate/Re-auth message; the server verifies
whether the authenticator identity available via AAA attributes is whether the authenticator identity available via AAA attributes is
the same as the identity provided to the peer. the same as the identity provided to the peer.
If the peer does not include the CB information in the EAP-Initiate/ If the peer does not include the CB information in the EAP-Initiate/
Re-auth message, and if the local ER server's policy requires channel Re-auth message, and if the local ER server's policy requires channel
binding support, it SHALL send the CB attributes for the peer's binding support, it SHALL send the CB attributes for the peer's
skipping to change at page 34, line 46 skipping to change at page 35, line 46
guaranteed, ERP support may be indicated through signaling (e.g., guaranteed, ERP support may be indicated through signaling (e.g.,
piggy-backed on a beacon) or through negotiation. Alternatively, piggy-backed on a beacon) or through negotiation. Alternatively,
clients may recognize environments where ERP is available based on clients may recognize environments where ERP is available based on
pre-configuration. Other similar mechanisms may also be used. When pre-configuration. Other similar mechanisms may also be used. When
ERP support cannot be verified, lower layers may mandate falling back ERP support cannot be verified, lower layers may mandate falling back
to full EAP authentication to accommodate EAP implementations that to full EAP authentication to accommodate EAP implementations that
are not compliant to RFC 3748. are not compliant to RFC 3748.
7. AAA Transport of ERP Messages 7. AAA Transport of ERP Messages
AAA Transport of ERP messages is specified by Hoeper, et al. AAA Transport of ERP messages is specified by Hoeper, et
[RFC5749] and Bournelle, et al. [I-D.ietf-dime-erp]. al. [RFC5749] and Bournelle, et al. [I-D.ietf-dime-erp].
8. Security Considerations 8. Security Considerations
This section provides an analysis of the protocol in accordance with This section provides an analysis of the protocol in accordance with
the AAA key management guidelines described by Housley & Aboba the AAA key management guidelines described by Housley & Aboba
[RFC4962]. [RFC4962].
Cryptographic algorithm independence Cryptographic algorithm independence
The EAP Re-auth Protocol satisfies this requirement. The The EAP Re-auth Protocol satisfies this requirement. The
algorithm chosen by the peer for the MAC generation is algorithm chosen by the peer for the MAC generation is
indicated in the EAP-Initiate/Re-auth message. If the chosen indicated in the EAP-Initiate/Re-auth message. If the chosen
algorithm is unacceptable, the EAP server returns an EAP- algorithm is unacceptable, the EAP server returns an EAP-
Finish/Re-auth message with Failure indication. Algorithm Finish/Re-auth message with Failure indication. Algorithm
agility for the KDF is specified in Salowey, et al. [RFC5295]. agility for the KDF is specified in Salowey, et al. [RFC5295].
Only when the algorithms used are deemed acceptable does the Only when the algorithms used are deemed acceptable does the
server proceed with the derivation of keys and verification of server proceed with the derivation of keys and verification of
the proof of possession of relevant keying material presented the proof of possession of relevant keying material presented
by the peer. A full-blown negotiation of algorithms cannot be by the peer. A full-blown negotiation of algorithms cannot be
provided in a single round trip protocol. Hence, while the provided in a single round trip protocol. Hence, while the
protocol provides algorithm agility, it does not provide true protocol provides algorithm agility, it does not provide true
negotiation. negotiation.
Strong, fresh session keys Strong, fresh session keys
skipping to change at page 39, line 28 skipping to change at page 40, line 28
the access control enforcement point (the authenticator or an the access control enforcement point (the authenticator or an
entity delegated by the authenticator for access control entity delegated by the authenticator for access control
enforcement). The model works as long as entities in the enforcement). The model works as long as entities in the
middle of the network do not use keys intended for other middle of the network do not use keys intended for other
parties to steal service from an access network. If that is parties to steal service from an access network. If that is
not achievable, key delivery must be protected in an end-to-end not achievable, key delivery must be protected in an end-to-end
manner. manner.
9. IANA Considerations 9. IANA Considerations
This document has no IANA actions. This document replaces and obsoletes RFC 5296, and IANA is asked to
change all registered references to that document to point instead to
this document. [RFC Editor note: please remove the previous
paragraph on publication.]
10. References The previous version of this document performed the following IANA
[IANA] actions:
10.1. Normative References 1. It registered Packet Codes "Initiate" and "Finish" in the EAP
Registry. Those are documented throughout this document as "EAP-
Initiate" and "EAP-Finish".
2. It created a Message Types table in the EAP Registry, and
registered several items in that table. Those are documented
throughout this document as "Re-auth-start" and "Re-auth".
3. It created an EAP Initiate and Finish Attributes table in the EAP
registry, and registered several items in that table. Those are
documented in this document in Section 5.3.4.
4. It created a Re-authentication Cryptosuites table in the EAP
registry, and registered several items in that table. Those are
documented in this document at the end of Section 5.3.2.
5. It registered two items in the USRK Key Labels registry:
* Re-auth usage label "EAP Re-authentication Root Key@ietf.org",
documented in this document in Section 4.1.
* DSRK-authorized delivery key "DSRK Delivery Authorized
Key@ietf.org", documented in this document in the description
of "Authorization Indication" in Section 5.3.3.
10. Contributors
Barry Leiba contributed all of the text in Section 9 and, as
Applications Area Director, insisted upon its inclusion as a
condition of publication.
11. Acknowledgements
This document is largely based upon RFC 5296; thanks to all who
partipated in that effort (see Appendix A). In addition, thanks to
Yaron Sheffer, Sebastien Decugis, Ralph Droms, Stephen Farrel,
Charlie Kaufman and Yoav Nir for (mostly) useful comments and review.
12. References
12.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[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.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation of Root Keys from an "Specification for the Derivation of Root Keys from an
Extended Master Session Key (EMSK)", RFC 5295, Extended Master Session Key (EMSK)", RFC 5295,
August 2008. August 2008.
10.2. Informative References 12.2. Informative References
[I-D.ietf-dime-erp] [I-D.ietf-dime-erp]
Bournelle, J., Morand, L., Decugis, S., Wu, W., and G. Decugis, S., Morand, L., Wu, W., Bournelle, J., and G.
Zorn, "Diameter support for EAP Re-authentication Protocol Zorn, "Diameter Support for the EAP Re-authentication
(ERP)", draft-ietf-dime-erp-07 (work in progress), Protocol (ERP)", draft-ietf-dime-erp-09 (work in
September 2011. progress), February 2012.
[I-D.ietf-hokey-ldn-discovery]
Zorn, G., Wu, W., and Y. Wang, "The ERP Local Domain Name
DHCPv6 Option", draft-ietf-hokey-ldn-discovery-10 (work in
progress), April 2011.
[I-D.nir-ipsecme-erx] [I-D.nir-ipsecme-erx]
Nir, Y. and W. Wu, "An IKEv2 Extension for Supporting Nir, Y. and W. Wu, "An IKEv2 Extension for Supporting
ERP", draft-nir-ipsecme-erx-01 (work in progress), ERP", draft-nir-ipsecme-erx-03 (work in progress),
July 2011. April 2012.
[IANA] "Internet Assigned Numbers Authority",
<http://www.iana.org/>.
[IEEE_802.1X] [IEEE_802.1X]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area Networks: Port Standards for Local and Metropolitan Area Networks: Port
based Network Access Control, IEEE Std 802.1X-2004", based Network Access Control, IEEE Std 802.1X-2004",
December 2004. December 2004.
[MSKHierarchy] [MSKHierarchy]
Lopez, R., Skarmeta, A., Bournelle, J., Laurent- Lopez, R., Skarmeta, A., Bournelle, J., Laurent-
Maknavicus, M., and J. Combes, "Improved EAP keying Maknavicus, M., and J. Combes, "Improved EAP keying
framework for a secure mobility access service", framework for a secure mobility access service",
IWCMC '06, Proceedings of the 2006 International IWCMC '06, Proceedings of the 2006 International
Conference on Wireless Communications and Conference on Wireless Communications and Mobile
Mobile Computing, New York, NY, USA, 2006. Computing, New York, NY, USA, 2006.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
RFC 3162, August 2001. RFC 3162, August 2001.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key Protocol Method for 3rd Generation Authentication and Key
skipping to change at page 41, line 14 skipping to change at page 43, line 9
BCP 132, RFC 4962, July 2007. BCP 132, RFC 4962, July 2007.
[RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti, [RFC5169] Clancy, T., Nakhjiri, M., Narayanan, V., and L. Dondeti,
"Handover Key Management and Re-Authentication Problem "Handover Key Management and Re-Authentication Problem
Statement", RFC 5169, March 2008. Statement", RFC 5169, March 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re-
authentication Protocol (ERP)", RFC 5296, August 2008.
[RFC5749] Hoeper, K., Nakhjiri, M., and Y. Ohba, "Distribution of [RFC5749] Hoeper, K., Nakhjiri, M., and Y. Ohba, "Distribution of
EAP-Based Keys for Handover and Re-Authentication", EAP-Based Keys for Handover and Re-Authentication",
RFC 5749, March 2010. RFC 5749, March 2010.
[RFC5996] Kaufman, C., Hoffman , P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
Appendix A. Acknowledgments [RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication
Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440,
December 2011.
A.1. RFC 5296 Appendix A. RFC 5296 Acknowledgments
In writing this document, we benefited from discussing the problem In writing this document, we benefited from discussing the problem
space and the protocol itself with a number of folks including space and the protocol itself with a number of folks including
Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, Bernard Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey,
Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, Jesse Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar,
Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi Parag Agashe, Dinesh Dharmaraju, Pasi Eronen, Dan Harkins, Yoshi
Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of Ohba, Glen Zorn, Alan DeKok, Katrin Hoeper, and other participants of
the HOKEY working group. The credit for the idea to use EAP- the HOKEY working group. The credit for the idea to use EAP-
Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link- Initiate/Re-auth-Start goes to Charles Clancy, and the multiple link-
layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba. Katrin layer SAs idea to mitigate the DoS attack goes to Yoshi Ohba. Katrin
Hoeper suggested the use of the windowing technique to handle Hoeper suggested the use of the windowing technique to handle
multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for
the suggestion to use hexadecimal encoding for rIKname when sent as the suggestion to use hexadecimal encoding for rIKname when sent as
part of keyName-NAI field. Thanks to Bernard Aboba for suggestions part of keyName-NAI field. Thanks to Bernard Aboba for suggestions
in clarifying the EAP lock-step operation, and Joe Salowey and Glen in clarifying the EAP lock-step operation, and Joe Salowey and Glen
Zorn for help in specifying AAA transport of ERP messages. Thanks to Zorn for help in specifying AAA transport of ERP messages. Thanks to
Sam Hartman for the DSRK Authorization Indication mechanism. Sam Hartman for the DSRK Authorization Indication mechanism.
A.2. RFC 5296bis
Thanks to Yaron Sheffer and Yoav Nir for useful comments.
Appendix B. Sample ERP Exchange Appendix B. Sample ERP Exchange
0. Authenticator --> Peer: 0. Authenticator --> Peer:
EAP-Initiate/Re-auth-Start [Optional] EAP-Initiate/Re-auth-Start [Optional]
1. Peer --> Authenticator: 1. Peer --> Authenticator:
EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite, EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite,
Auth-tag*) Auth-tag*)
1a. Authenticator --> Re-auth-Server: 1a. Authenticator --> Re-auth-Server:
AAA-Request AAA-Request
skipping to change at page 42, line 37 skipping to change at page 44, line 37
2b. Authenticator --> Peer: 2b. Authenticator --> Peer:
EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info], EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info],
Auth-tag*) Auth-tag*)
* Auth-tag computation is over the entire EAP Initiate/Finish message; * Auth-tag computation is over the entire EAP Initiate/Finish message;
the code values for Initiate and Finish are different and thus the code values for Initiate and Finish are different and thus
reflection attacks are mitigated. reflection attacks are mitigated.
Authors' Addresses Authors' Addresses
Qin Wu (editor)
Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District
Nanjing, JiangSu 210012
China
Email: Sunseawq@huawei.com
Zhen Cao Zhen Cao
China Mobile China Mobile
53A Xibianmennei Ave., Xuanwu District 53A Xibianmennei Ave., Xuanwu District
Beijing, Beijing 100053 Beijing, Beijing 100053
P.R. China P.R. China
Email: caozhen@chinamobile.com Email: caozhen@chinamobile.com
Baohong He
China Academy of Telecommunication Research
China
Email: hebaohong@catr.cn
Yang Shi
Huawei Technologies Co., Ltd.
156, Beiqing Road, Zhongguancun, Haidian District
Beijing
P.R. China
Phone: +86 10 60614043
Email: shiyang1@huawei.com
Qin Wu (editor)
Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District
Nanjing, JiangSu 210012
China
Email: Sunseawq@huawei.com
Glen Zorn (editor) Glen Zorn (editor)
Network Zen Network Zen
227/358 Thanon Sanphawut 227/358 Thanon Sanphawut
Bang Na, Bangkok 10260 Bang Na, Bangkok 10260
Thailand Thailand
Phone: +66 (0) 87-0404617 Phone: +66 (0) 87-0404617
Email: glenzorn@gmail.com Email: glenzorn@gmail.com
Yang Shi
H3C Tech. Co., Ltd
Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District
Beijing 100085
China
Email: young@h3c.com
Baohong He
China
Email: hebaohong@catr.cn
 End of changes. 46 change blocks. 
153 lines changed or deleted 237 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/