draft-ietf-hokey-rfc5296bis-04.txt   draft-ietf-hokey-rfc5296bis-05.txt 
Network Working Group Q. Wu, Ed. Network Working Group Q. Wu, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Obsoletes: 5296 (if approved) Z. Cao Obsoletes: 5296 (if approved) Z. Cao
Intended status: Standards Track China Mobile Intended status: Standards Track China Mobile
Expires: January 12, 2012 Y. Shi Expires: May 1, 2012 G. Zorn, Ed.
Network Zen
Y. Shi
H3C H3C
B. He B. He
CATR CATR
July 11, 2011 October 29, 2011
EAP Extensions for EAP Re-authentication Protocol (ERP) EAP Extensions for EAP Re-authentication Protocol (ERP)
draft-ietf-hokey-rfc5296bis-04 draft-ietf-hokey-rfc5296bis-05
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 not repeat where EAP is used for authentication, it is desirable to avoid
the entire EAP exchange with another authenticator. This document repeating the entire EAP exchange with another authenticator. This
specifies extensions to EAP and the EAP keying hierarchy to support document specifies extensions to EAP and the EAP keying hierarchy to
an EAP method-independent protocol for efficient re-authentication support an EAP method-independent protocol for efficient re-
between the peer and an EAP re-authentication server through any authentication between the peer and an EAP re-authentication server
authenticator. The re-authentication server may be in the home through any authenticator. The re-authentication server may be in
network or in the local network to which the peer is connecting. the home network or in the local network to which the peer is
connecting.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 12, 2012. This Internet-Draft will expire on May 1, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 2, line 15 skipping to change at page 3, line 5
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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . 9
3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 10 3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 10
4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 12 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 13
4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 14 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 14
4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 14 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 14
4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 15 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 15
4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 15 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16
4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17
5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 23 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 22
5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 23 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 23
5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 24 5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 24
5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 25 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 25
5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 26 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 26
5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 27 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 26
5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 27 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 26
5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 29 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 28
5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31
5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 33 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33
7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 35 7. AAA Transport of ERP Messages . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Normative References . . . . . . . . . . . . . . . . . . . 40 10.1. Normative References . . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . . 40 10.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 42 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 41
A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 42 A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 42 A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 41
A.3. Change Log . . . . . . . . . . . . . . . . . . . . . . . . 42 Appendix B. Sample ERP Exchange . . . . . . . . . . . . . . . . . 41
A.3.1. draft-ietf-hokey-rfc5296bis-02 . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
A.3.2. draft-ietf-hokey-rfc5296bis-03 . . . . . . . . . . . . 42
Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
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 26 skipping to change at page 4, line 26
by the EAP authenticator enforces access control. After successful by the EAP authenticator enforces access control. After successful
authentication, the EAP server transports the MSK to the EAP authentication, the EAP server transports the MSK to the EAP
authenticator; the EAP authenticator and the EAP peer establish authenticator; the EAP authenticator and the EAP peer establish
transient session keys (TSKs) using the MSK as the authentication transient session keys (TSKs) using the MSK as the authentication
key, key derivation key, or a key transport key, and use the TSK for key, key derivation key, or a key transport key, and use the TSK for
per-packet access enforcement. per-packet access enforcement.
When a peer moves from one authenticator to another, it is desirable When a peer moves from one authenticator to another, it is desirable
to avoid a full EAP authentication to support fast handovers. The to avoid a full EAP authentication to support fast handovers. The
full EAP exchange with another run of the EAP method can take several full EAP exchange with another run of the EAP method can take several
round trips and significant time to complete, causing delays in round trips and significant time to complete, causing increased
handover times. Some EAP methods specify the use of state from the handover times. Some EAP methods specify the use of state from the
initial authentication to optimize re-authentications by reducing the initial authentication to optimize re-authentications by reducing the
computational overhead, but method-specific re-authentication takes computational overhead (e.g., EAP-AKA [RFC4187]), but method-specific
at least 2 round trips with the original EAP server in most cases re-authentication takes at least 2 round trips with the original EAP
(e.g., [RFC4187]). It is also important to note that several methods server in most cases. It is also important to note that several
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, compromise of an solution to lower handover times. In that case, however, the
authenticator results in compromise of keying material established compromise of one authenticator results in the compromise of keying
via other authenticators. Other solutions for fast re-authentication material established via other authenticators. Other solutions for
exist in the literature [MSKHierarchy]. fast re-authentication exist in the literature: for example, see
Lopez, et al. [MSKHierarchy]; Clancy, et al. have described the EAP
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. The EAP re- less than 2 round trips, preferably with a local server.
authentication problem statement is described in detail in [RFC5169].
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
for a peer that has valid, unexpired key material from a previously for a peer that has valid, unexpired key material from a previously
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 IEEE802.1x specification [IEEE_802.1X] must be Specifically, the Internet Key Exchange (IKE) protocol [RFC5996] must
revised and RFC 5996 [RFC5996] must be updated to carry ERP messages. be updated to carry ERP messages; work is in progress on this project
[I-D.nir-ipsecme-erx].
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 6, line 30 skipping to change at page 6, line 30
ERP allows a peer and server to mutually verify proof of possession ERP allows a peer and server to mutually verify proof of possession
of keying material from an earlier EAP method run and to establish a of keying material from an earlier EAP method run and to establish a
security association between the peer and the authenticator. The security association between the peer and the authenticator. The
authenticator acts as a pass-through entity for the Re-authentication authenticator acts as a pass-through entity for the Re-authentication
Protocol in a manner similar to that of an EAP authenticator Protocol in a manner similar to that of an EAP authenticator
described in RFC 3748 [RFC3748]. ERP is a single round-trip exchange described in RFC 3748 [RFC3748]. ERP is a single round-trip exchange
between the peer and the server; it is independent of the lower layer between the peer and the server; it is independent of the lower layer
and the EAP method used during the full EAP exchange. The ER server and the EAP method used during the full EAP exchange. The ER server
may be in the home domain or in the same (visited) domain as the peer may be in the home domain or in the same (visited) domain as the peer
and the authenticator (i.e.,local domain). and the authenticator (i.e., the local domain).
Figure 2 shows the protocol exchange. The first time the peer Figure 2 shows the protocol exchange. The first time the peer
attaches to any network, it performs a full EAP exchange (shown in attaches to any network, it performs a full EAP exchange (shown in
Figure 1) with the EAP server; as a result, an MSK is distributed to Figure 1) with the EAP server; as a result, an MSK is distributed to
the EAP authenticator. The MSK is then used by the authenticator and the EAP authenticator. The MSK is then used by the authenticator and
the peer to establish TSKs as needed. At the time of the initial EAP the peer to establish TSKs as needed. At the time of the initial EAP
exchange, the peer and the server also derive an EMSK, which is used exchange, the peer and the server also derive an EMSK, which is used
to derive a re-authentication Root Key (rRK). More precisely, a re- to derive a re-authentication Root Key (rRK). More precisely, a re-
authentication Root Key is derived from the EMSK or from a Domain- authentication Root Key is derived from the EMSK or from a Domain-
Specific Root Key (DSRK), which is itself derived from the EMSK. The Specific Root Key (DSRK), which is itself derived from the EMSK. The
skipping to change at page 8, line 9 skipping to change at page 8, line 9
Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this Two new 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 local domain name. also can be used by the authenticator to announce the local domain
name.
It is plausible that the authenticator does not know whether the peer It is plausible that the authenticator does not know whether the peer
supports ERP and whether the peer has performed a full EAP supports ERP and whether the peer has performed a full EAP
authentication through another authenticator. The authenticator MAY authentication through another authenticator. The authenticator MAY
initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start
message, and if there is no response, it will send the EAP-Request/ message, and if there is no response, send the EAP-Request/Identity
Identity message. Note that this avoids having two EAP messages in message. Note that this avoids having two EAP messages in flight at
flight at the same time [RFC3748]. The authenticator may send the the same time [RFC3748]. The authenticator may send the EAP-
EAP-Initiate/Re-auth-Start message and wait for a short, locally Initiate/Re-auth-Start message and wait for a short, locally
configured amount of time. If the peer does not already know, this configured amount of time. This message indicates to the peer that
message indicates to the peer that the authenticator supports ERP. the authenticator supports ERP. In response to this trigger from the
In response to this trigger from the authenticator, the peer can authenticator, the peer can initiate the ERP exchange by sending an
initiate the ERP exchange by sending an EAP-Initiate/Re-auth message. EAP-Initiate/Re-auth message. If there is no response from the peer
If there is no response from the peer after the necessary after the necessary number of retransmissions (see Section 6), the
retransmissions (see Section 6), the authenticator MUST initiate EAP authenticator MUST initiate EAP by sending an EAP-Request message,
by sending an EAP-Request message, typically the EAP-Request/Identity typically the EAP-Request/Identity message. Note that the
message. Note that the authenticator may receive an EAP-Initiate/ authenticator may receive an EAP-Initiate/Re-auth message after it
Re-auth message after it has sent an EAP-Request/Identity message. has sent an EAP-Request/Identity message. If the authenticator
If the authenticator supports ERP, it MUST proceed with the ERP supports ERP, it MUST proceed with the ERP exchange. When the EAP-
exchange. When the EAP-Request/Identity times out, the authenticator Request/Identity times out, the authenticator MUST NOT close the
MUST NOT close the connection if an ERP exchange is in progress or connection if an ERP exchange is in progress or has already succeeded
has already succeeded in establishing a re-authentication MSK. in establishing a re-authentication MSK.
If the authenticator does not support ERP, it drops EAP-Initiate/ If the authenticator does not support ERP, it will silently discard
Re-auth messages [RFC3748] as the EAP code of those packets is EAP-Initiate/Re-auth messages (Section 5.3.2) since the EAP code of
greater than 4. An ERP-capable peer will exhaust the EAP-Initiate/ those packets is greater than 4 ([RFC3748], Section 4). An ERP-
Re-auth message retransmissions and fall back to EAP authentication capable peer will exhaust the EAP-Initiate/Re-auth message
by responding to EAP Request/Identity messages from the retransmissions and fall back to EAP authentication by responding to
authenticator. If the peer does not support ERP or if it does not EAP Request/Identity messages from the authenticator. If the peer
have unexpired key material from a previous EAP authentication, it does not support ERP or if it does not have unexpired key material
drops EAP-Initiate/Re-auth-Start messages. If there is no response from a previous EAP authentication, it drops EAP-Initiate/
to the EAP-Initiate/Re-auth-Start message, the authenticator SHALL Re-auth-Start messages. If there is no response to the EAP-Initiate/
send an EAP Request message (typically EAP Request/Identity) to start Re-auth-Start message, the authenticator SHALL send an EAP Request
EAP authentication. From this stage onwards, RFC 3748 rules apply. message (typically EAP Request/Identity) to start EAP authentication.
Note that this may introduce some delay in starting EAP. In some From this point onward, RFC 3748 rules apply. Note that this may
lower layers, the delay can be minimized or even avoided by the peer introduce some delay in starting EAP. In some lower layers, the
initiating EAP by sending messages such as EAPoL-Start in the IEEE delay can be minimized or even avoided by the peer initiating EAP by
802.1X specification [IEEE_802.1X]. sending messages such as EAPoL-Start [IEEE_802.1X].
The peer sends an EAP-Initiate/Re-auth message that contains the The peer sends an EAP-Initiate/Re-auth message that contains the
keyName-NAI to identify the ER server's domain and the rIK used to keyName-NAI to identify the ER server's domain and the rIK used to
protect the message, and a sequence number for replay protection. protect the message, and a sequence number for replay protection.
The EAP-Initiate/Re-auth message is integrity protected with the rIK. The EAP-Initiate/Re-auth message is integrity protected with the rIK.
The authenticator uses the realm in the keyName-NAI [RFC4282] field The authenticator uses the realm in the keyName-NAI [RFC4282] field
to send the message to the appropriate ER server. The server uses to send the message to the appropriate ER server. The server uses
the keyName to look up the rIK. The server, after verifying proof of the keyName to look up the rIK. The server, after verifying proof of
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 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. Ongoing work in [RFC5749] describes 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 server for the rMSK lifetime. If so, the ER The peer MAY request the rMSK lifetime from the server. If so, the
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 request the server for the In an ERP bootstrap exchange, the peer MAY ask the server for the rRK
rRK lifetime. If so, the ER server sends the rRK lifetime in the lifetime. If so, the ER server sends the rRK lifetime in the EAP-
EAP-Finish/Re-auth message. Finish/Re-auth message.
The peer verifies the replay protection and the integrity of the The peer verifies the sequence number and the integrity of the
message. It then uses the sequence number in the EAP-Finish/Re-auth message. It then uses the sequence number in the EAP-Finish/Re-auth
message to compute the rMSK. The lower-layer security association message to compute the rMSK. The lower-layer security association
protocol is ready to be triggered after this point. protocol is ready to be triggered after this point.
When the ER server is in the home domain, the peer and the server use The ER server is located either in the home domain or in the visited
domain. When the ER server is in the home domain and there is no
local ER server in the visited domain, the peer and the server use
the rIK and rRK derived from the EMSK; and when the ER server is in the rIK and rRK derived from the EMSK; and when the ER server is in
the local domain, they use the DS-rIK and DS-rRK corresponding to the the local domain, they use the DS-rIK and DS-rRK corresponding to the
local domain. The domain of the ER server is identified by the realm local domain. The domain of the ER server is identified by the realm
portion of the keyname-NAI in ERP messages. portion of the keyname-NAI in ERP messages.
3.1. ERP With the Home ER Server 3.1. ERP With the Home ER Server
If the peer is in the home domain and does not know the domain name ( If the peer is in the home domain or there is no local server in the
did not receive the domain name through the EAP-Initiate/ same domain as the peer, it SHOULD initiate an ERP bootstrap exchange
Re-auth-Start message or via the lower-layer announcement, due to a
missed announcement or lack of support for domain name announcements
in a specific lower layer) or there is no the local server in the
same domain as the peer, it SHOULD initiate ERP bootstrap exchange
with the home ER server to obtain the domain name. with the home ER server to obtain the domain name.
The defined ER extensions allow executing the ERP with an ER server The defined ER extensions allow executing the ERP with an ER server
in the home domain. The home ER server may be co- located with a in the home domain. The home ER server may be co-located with a home
home AAA server. The ERP with the Home ER Server is the similar as AAA server. ERP with the Home ER Server is similar to the ERP
ERP exchange described in Figure 2. exchange described in Figure 2.
Peer ER Authenticator Home ER Server Peer ER Authenticator Home ER Server
==== ============= ====== ==== ============= ======
<-- EAP-Initiate/ ----- <-- EAP-Initiate/ -----
Re-auth-Start Re-auth-Start
[<-- EAP-Request/ ------ [<-- EAP-Request/ ------
Identity] Identity]
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
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)
Note: [] brackets indicate optionality.
Figure 3: ER ExplicitBootstrapping 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 executing the ERP with an ER server The defined ER extensions allow the execution of ERP with an ER
in the local domain (access network) if the peer moves out of home server in the local domain (access network) if the peer moves out of
domain. The local ER server may be co-located with a local AAA home domain and a local ER server is present in the visited domain.
server. The peer may learn about the presence of a local ER server The local ER server may be co-located with a local AAA server. The
in the network and the local domain name (or ER server name) either peer may learn about the presence of a local ER server in the network
via the lower layer or by means of ERP exchange. The peer uses the and the local domain name (or ER server name) either via a lower
layer advertisement or by means of ERP exchange. The peer uses the
domain name and the EMSK to compute the DSRK and from that key, the domain name and the EMSK to compute the DSRK and from that key, the
DS-rRK; the peer also uses the domain name in the realm portion of DS-rRK; the peer also uses the domain name in the realm portion of
the keyName-NAI for using ERP in the local domain. Figure 4 shows the keyName-NAI for using ERP in the local domain. Figure 4 shows
the ER Implicit bootstrapping exchange through local ER the ER Implicit bootstrapping exchange through local ER
Server;Figure 5shows ERP with a local ER server. 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
==== ================= =============== =============== ==== ================= =============== ===============
skipping to change at page 11, line 30 skipping to change at page 11, line 30
<---AAA(MSK, DSRK, ---- <---AAA(MSK, DSRK, ----
EMSKname, EMSKname,
EAP-Success) EAP-Success)
<--- AAA(MSK, ----- <--- AAA(MSK, -----
EAP-Success) EAP-Success)
<---EAP-Success----- <---EAP-Success-----
Figure 4: Local ERP Exchange, Initial EAP Exchange Figure 4: Implicit Bootstrapping ERP Exchange, Initial EAP Exchange
Peer ER Authenticator Local ER Server Peer ER Authenticator Local ER Server
==== ================ =============== ==== ================ ===============
<-- EAP-Initiate/ -------- <-- EAP-Initiate/ --------
Re-auth-Start Re-auth-Start
[<-- EAP-Request/ --------- [<-- EAP-Request/ ---------
Identity] Identity]
---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ --------> ---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ -------->
skipping to change at page 12, line 11 skipping to change at page 12, line 11
<--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/-------
Re-auth Re-auth) Re-auth Re-auth)
Figure 5: Local ERP Exchange Figure 5: Local ERP Exchange
As shown in Figure 4, the local ER server may be present in the path As shown in Figure 4, the local ER server may be present in the path
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
through AAA message. In response, the home EAP server computes the by means of an AAA message. In response, the home EAP server
DSRK by following the procedure specified in [RFC5295] and sends the computes the DSRK by following the procedure specified in [RFC5295]
DSRK and the key name, EMSKname, to the ER server in the claimed and sends the DSRK and the key name, EMSKname, to the ER server in
domain (i.e., local ER Server). The local domain is responsible for the claimed domain (i.e., the local ER Server). The local domain is
announcing that same domain name via the lower layer to the peer, responsible for announcing that same domain name to the peer via a
e.g., DHCP based local domain name discovery specified in lower layer (for example, through DHCP-based local domain name
[I-D.ietf-hokey-ldn-discovery], or through the EAP-Initiate/ discovery [I-D.ietf-hokey-ldn-discovery], or through the EAP-
Re-auth-Start message during subsequent ERP with local ER server. Initiate/Re-auth-Start 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.
Subsequently, when the peer 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 an 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 the similar as ERP exchange described in Figure 2. ER Server is similar to 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.
The rRK is derived from either the EMSK or a DSRK as specified in The rRK is derived from either the EMSK or a DSRK as specified in
Section 4.1. For the purpose of rRK derivation, this document Section 4.1. For the purpose of rRK derivation, this document
specifies derivation of a Usage-Specific Root Key (USRK) or a Domain- specifies derivation of a Usage-Specific Root Key (USRK) or a Domain-
Specific USRK (DSUSRK) in accordance with [RFC5295] for re- Specific USRK (DSUSRK) [RFC5295] for re-authentication. The USRK
authentication. The USRK designated for re-authentication is the re- designated for re-authentication is the re-authentication root key
authentication root key (rRK). A DSUSRK designated for re- (rRK). A DSUSRK designated for re-authentication is the DS-rRK
authentication is the DS-rRK available to a local ER server in a available to a local ER server in a particular domain. For
particular domain. For simplicity, the keys are referred to without simplicity, the keys are referred to without the DS label in the rest
the DS label in the rest of the document. However, the scope of the of the document. However, the scope of the various keys is limited
various keys is limited to just the respective domains they are to just the respective domains for which they are derived, in the
derived for, in the case of the domain specific keys. Based on the case of the domain specific keys. Based on the ER server with which
ER server with which the peer performs the ERP exchange, it knows the the peer performs the ERP exchange, it knows the corresponding keys
corresponding keys that must be used. that must be used.
The rRK is used to derive an rIK, and rMSKs for one or more The rRK is used to derive an rIK, and rMSKs for one or more
authenticators. The figure below shows the key hierarchy with the authenticators. The figure below shows the key hierarchy with the
rRK, rIK, and rMSKs. rRK, rIK, and rMSKs.
rRK rRK
| |
+--------+--------+ +--------+--------+
| | | | | |
rIK rMSK1 ...rMSKn rIK rMSK1 ...rMSKn
Figure 6: Re-authentication Key Hierarchy Figure 6: Re-authentication Key Hierarchy
The derivations in this document are according to [RFC5295]. Key The derivations in this document are from RFC 5295. Key derivations
derivations and field encodings, where unspecified, default to that and field encodings, where unspecified, default to that document.
document.
4.1. rRK Derivation 4.1. rRK Derivation
The rRK may be derived from the EMSK or DSRK. This section provides The rRK may be derived from the EMSK or DSRK. This section provides
the relevant key derivations for that purpose. the relevant key derivations for that purpose.
The rRK is derived as specified in [RFC5295]. The rRK is derived as specified in RFC 5295.
rRK = KDF (K, S), where rRK = KDF (K, S), where
K = EMSK or K = DSRK and K = EMSK or K = DSRK and
S = rRK Label | "\0" | length S = rRK Label | "\0" | length
The rRK Label is an IANA-assigned 8-bit ASCII string: The rRK Label is an IANA-assigned 8-bit ASCII string:
EAP Re-authentication Root Key@ietf.org EAP Re-authentication Root Key@ietf.org
assigned from the "USRK key labels" name space in accordance with assigned from the "USRK key labels" name space in accordance with the
[RFC5295]. policy stated in RFC 5295.
The KDF and algorithm agility for the KDF are as defined in The KDF and algorithm agility for the KDF are as defined in RFC 5295.
[RFC5295].
An rRK derived from the DSRK is referred to as a DS-rRK in the rest An rRK derived from the DSRK is referred to as a DS-rRK in the rest
of the document. All the key derivation and properties specified in of the document. All the key derivation and properties specified in
this section remain the same. this section remain the same.
4.2. rRK Properties 4.2. rRK Properties
The rRK has the following properties. These properties apply to the The rRK has the following properties. These properties apply to the
rRK regardless of the parent key used to derive it. rRK regardless of the parent key used to derive it.
o The length of the rRK MUST be equal to the length of the parent o The length of the rRK MUST be equal to the length of the parent
key used to derive it. key used to derive it.
o The rRK is to be used only as a root key for re-authentication and o The rRK is to be used only as a root key for re-authentication and
never used to directly protect any data. never used to directly protect any data.
o The rRK is only used for derivation of rIK and rMSK as specified o The rRK is only used for the derivation of the rIK and rMSK as
in this document. specified in this document.
o The rRK MUST remain on the peer and the server that derived it and o The rRK MUST remain on the peer and the server that derived it and
MUST NOT be transported to any other entity. MUST NOT be transported to any other entity.
o The lifetime of the rRK is never greater than that of its parent o The lifetime of the rRK is never greater than that of its parent
key. The rRK is expired when the parent key expires and MUST be key. The rRK is expired when the parent key expires and MUST be
removed from use at that time. removed from use at that time.
4.3. rIK Derivation 4.3. rIK Derivation
skipping to change at page 14, line 46 skipping to change at page 14, line 46
K = rRK and K = rRK and
S = rIK Label | "\0" | cryptosuite | length S = rIK Label | "\0" | cryptosuite | length
The rIK Label is the 8-bit ASCII string: The rIK Label is the 8-bit ASCII string:
Re-authentication Integrity Key@ietf.org Re-authentication Integrity Key@ietf.org
The length field refers to the length of the rIK in octets encoded as The length field refers to the length of the rIK in octets encoded as
specified in [RFC5295]. specified in RFC 5295.
The cryptosuite and length of the rIK are part of the input to the The cryptosuite and length of the rIK are part of the input to the
key derivation function to ensure cryptographic separation of keys if key derivation function to ensure cryptographic separation of keys if
different rIKs of different lengths for use with different Message different rIKs of different lengths (for example, for use with
Authentication Code (MAC) algorithms are derived from the same rRK. different Message Authentication Code (MAC) algorithms) are derived
The cryptosuite is encoded as an 8-bit number; see Section 5.3.2 for from the same rRK. The cryptosuite is encoded as an 8-bit number;
the cryptosuite specification. see Section 5.3.2 for the cryptosuite specification.
The rIK is referred to by EMSKname-NAI within the context of ERP The rIK is referred to by the EMSKname-NAI within the context of ERP
messages. The username part of EMSKname-NAI is the EMSKname; the messages. The username part of EMSKname-NAI is the EMSKname; the
realm is the domain name of the ER server. In case of ERP with the realm is the domain name of the ER server. In case of ERP with the
home ER server, the peer uses the realm from its original NAI; in home ER server, the peer uses the realm from its original NAI; in
case of a local ER server, the peer uses the domain name received at case of a local ER server, the peer uses the domain name received at
the lower layer or through an ERP bootstrapping exchange. the lower layer or through an ERP bootstrapping exchange.
An rIK derived from a DS-rRK is referred to as a DS-rIK in the rest A rIK derived from a DS-rRK is referred to as a DS-rIK in the rest of
of the document. All the key derivation and properties specified in the document. All of the key derivation and properties specified in
this section remain the same. this section remain the same.
4.4. rIK Properties 4.4. rIK Properties
The rIK has the following properties. The rIK has the following properties.
o The length of the rIK MUST be equal to the length of the rRK. o The length of the rIK MUST be equal to the length of the rRK.
o The rIK is only used for authentication of the ERP exchange as o The rIK is only used for authentication of the ERP exchange as
specified in this document. specified in this document.
skipping to change at page 15, line 40 skipping to change at page 15, line 40
o The rIK is cryptographically separate from any other keys derived o The rIK is cryptographically separate from any other keys derived
from the rRK. from the rRK.
o The lifetime of the rIK is never greater than that of its parent o The lifetime of the rIK is never greater than that of its parent
key. The rIK MUST be expired when the EMSK expires and MUST be key. The rIK MUST be expired when the EMSK expires and MUST be
removed from use at that time. removed from use at that time.
4.5. rIK Usage 4.5. rIK Usage
The rIK is the key whose possession is demonstrated by the peer and The rIK is the key the possession of which is demonstrated by the
the ERP server to the other party. The peer demonstrates possession peer and the ERP server to the other party. The peer demonstrates
of the rIK by computing the integrity checksum over the EAP-Initiate/ possession of the rIK by computing the integrity checksum over the
Re-auth message. When the peer uses the rIK for the first time, it EAP-Initiate/Re-auth message. When the peer uses the rIK for the
can choose the integrity algorithm to use with the rIK. The peer and first time, it can choose the integrity algorithm to use with the
the server MUST use the same integrity algorithm with a given rIK for rIK. The peer and the server MUST use the same integrity algorithm
all ERP messages protected with that key. The peer and the server with a given rIK for all ERP messages protected with that key. The
store the algorithm information after the first use, and they employ peer and the server store the algorithm information after the first
the same algorithm for all subsequent uses of that rIK. use, and they employ the same algorithm for all subsequent uses of
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 as specified in [RFC2104]. is first hashed to the required key length using the HMAC algorithm
In case of cipher-based MAC algorithms, if the required key length is RFC 2104 [RFC2104]. In case of cipher-based MAC algorithms, if the
less than 32 octets, the rIK is hashed using HMAC-SHA256 and the required key length is less than 32 octets, the rIK is hashed using
first k octets of the output are used, where k is the key length HMAC-SHA256 and the first k octets of the output are used, where k is
required by the algorithm. If the required key length is more than the key length required by the algorithm. If the required key length
32 octets, the first k octets of the rIK are used by the cipher-based is more than 32 octets, the first k octets of the rIK are used by the
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
exchange. exchange.
The rMSK is derived as follows. The rMSK is derived as follows.
rMSK = KDF (K, S), where rMSK = KDF (K, S), where
K = rRK and K = rRK and
S = rMSK label | "\0" | SEQ | length S = rMSK label | "\0" | SEQ | length
The rMSK label is the 8-bit ASCII string: The rMSK label is the 8-bit ASCII string:
Re-authentication Master Session Key@ietf.org Re-authentication Master Session Key@ietf.org
The length field refers to the length of the rMSK in octets. The The length field refers to the length of the rMSK in octets. The
length field is encoded as specified in [RFC5295]. length field is encoded as specified in RFC 5295.
SEQ is the sequence number sent by the peer in the EAP-Initiate/ SEQ is the sequence number sent by the peer in the EAP-Initiate/
Re-auth message. This field is encoded as a 16-bit number in network Re-auth message. This field is encoded as a 16-bit number in network
byte order (see Section 5.3.2). byte order (see Section 5.3.2).
An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest An rMSK derived from a DS-rRK is referred to as a DS-rIK in the rest
of the document. All the key derivation and properties specified in of the document. The key derivation and properties specified in this
this section remain the same. section remain the same.
4.7. rMSK Properties 4.7. rMSK Properties
The rMSK has the following properties: The rMSK has the following properties:
o The length of the rMSK MUST be equal to the length of the rRK. o The length of the rMSK MUST be equal to the length of the rRK.
o The rMSK is delivered to the authenticator and is used for the o The rMSK is delivered to the authenticator and is used for the
same purposes that an MSK is used at an authenticator. same purposes that an MSK is used at an authenticator.
skipping to change at page 17, line 24 skipping to change at page 17, line 26
o If a new rRK is derived, subsequent rMSKs MUST be derived from the o If a new rRK is derived, subsequent rMSKs MUST be derived from the
new rRK. Previously delivered rMSKs MAY still be used until the new rRK. Previously delivered rMSKs MAY still be used until the
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 implicit We identify two types of bootstrapping for ERP: explicit and
bootstrapping. In implicit bootstrapping, the local AAA client or implicit. In implicit bootstrapping, the ER-capable authenticator or
Agent MUST verify whether it has valid rMSK or rRK corresponding to local ER server MUST verify whether it has valid rMSK or rRK
the peer. If the local AAA client or Agent has the key materials corresponding to the peer. If ER capable authenticator or the local
corresponding to the peer, it MUST be able to respond directly in the ER server has the key materials corresponding to the peer, it MUST be
same way as the home AAA server does without forwarding the ERP able to respond directly in the same way as the home AAA server does
message to the home domain, if the local AAA client or Agent does not without forwarding the DSRK request to the home domain; if not, the
have the keying material(e.g., rMSK or rRK) corresponding to the ER-capable authenticator or local ER server SHOULD include its domain
peer, the local AAA client or agent supporting EAP re-authentication name in the AAA message encapsulating the first EAP Response message
SHOULD include its domain name and SHOULD request the DSRK from the sent by the peer and request the DSRK from the home EAP server during
home AAA server during the initial EAP exchange, in the AAA message the initial EAP exchange. If such EAP exchange is successful, the
encapsulating the first EAP Response message sent by the peer. If home EAP server sends the DSRK for the specified local AAA client or
such EAP exchange is successful, the home EAP server sends the DSRK agent (derived using the EMSK and the domain name as specified in RFC
for the specified local AAA client or agent (derived using the EMSK 5295), EMSKname, and DSRK lifetime along with the EAP-Success
and the domain name as specified in [RFC5295]), EMSKname, and DSRK message. The local AAA client or agent MUST extract the DSRK,
lifetime along with the EAP-Success message. The local AAA client or EMSKname, and DSRK lifetime (if present) before forwarding the EAP-
agent 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, as specified
in [I-D.ietf-dime-erp]. Note that the MSK (also present along with
the EAP Success message) is extracted by the EAP authenticator as the EAP Success message) is extracted by the EAP authenticator as
usual. The peer learns the domain name through the EAP-Initiate/ usual. The peer learns the domain name through the EAP-Initiate/
Re-auth-Start message, lower-layer announcements Re-auth-Start message or by means of lower-layer announcement (for
[I-D.ietf-hokey-ldn-discovery] . When the domain name is available example, DHCP [I-D.ietf-hokey-ldn-discovery]). When the domain name
to the peer during or after the full EAP authentication, it attempts is available to the peer during or after the full EAP authentication,
to use ERP when it associates with a new authenticator. it attempts to use ERP when it associates with a new authenticator.
If the peer does not know the domain name (did not receive the domain If the peer knows there is no local ER server presented in the
name through the EAP-Initiate/Re-auth-Start message or via the lower- visited domain, it SHOULD initiate Explicit ERP bootstrapping (ERP
layer announcement, due to a missed announcement or lack of support exchange with the bootstrap flag turned on) with the home ER server
for domain name announcements in a specific lower layer), it SHOULD to obtain the rRK. The peer MAY also initiate bootstrapping to fetch
initiate Explicit ERP bootstrapping (ERP exchange with the bootstrap information such as the rRK lifetime from the AAA server.
flag turned on) with the ER server to obtain the local domain name.
The peer MAY also initiate bootstrapping to fetch 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
bootstrapping flag turned on. The bootstrap message is always bootstrapping flag set (1). The bootstrap message is always sent
sent to the ER server, and the keyname-NAI attribute in the to the home ER server, and the keyname-NAI attribute in the
bootstrap message is constructed as follows: the username portion bootstrap message is constructed as follows: the username portion
of the NAI contains the EMSKname, and the realm portion contains of the NAI contains the EMSKname, and the realm portion contains
the home domain name. the home domain name.
o In addition, the message MUST contain a sequence number for replay o In addition, the message MUST contain a sequence number for replay
protection, a cryptosuite, and an integrity checksum. The protection, a cryptosuite, and an integrity checksum. The
cryptosuite indicates the authentication algorithm. The integrity cryptosuite indicates the authentication algorithm. The integrity
checksum indicates that the message originated at the claimed checksum indicates that the message originated at the claimed
entity, the peer indicated by the Peer-ID, or the rIKname. entity, the peer indicated by the Peer-ID, or the rIKname.
o The peer MAY additionally set the lifetime flag to request the key o The peer MAY additionally set the lifetime flag to request the key
lifetimes. lifetimes.
o Upon receipt of the EAP-Initiate/ Re-auth message from a peer, the o Upon receipt of the EAP-Initiate/Re-auth message from a peer, the
ERP-capable authenticator verifies whether it has local domain ERP-capable authenticator verifies whether it has the local domain
name and valid key materials corresponding to the peer. If it name and valid key materials corresponding to the peer. If it
knows local domain name and valid key material corresponding to knows the local domain name and has valid key material
the peer, it MUST be able to respond directly in the same way as corresponding to the peer, it MUST be able to respond directly in
the home ER does with local domain name included. If not, it the same way as the home ER does with local domain name included.
copies the contents of the keyName-NAI into the User-Name If not, it copies the contents of the keyName-NAI into the
attribute of RADIUS [RFC2865] and may include its domain name in appropriate AAA attribute and may include its domain name in the
the AAA message encapsulating the EAP-Initiate/Re-auth message AAA message encapsulating the EAP-Initiate/Re-auth message sent by
sent by the peer. The rest of the process is similar to that the peer.
described in [RFC3579].
o If a local ER server is present, the local ER server MUST verify
whether it has DSRK corresponding to the peer. If the local ER
server has the valid key materials corresponding to the peer, it
MUST be able to respond directly in the same way as the home ER
server does described in the following step without forwarding the
ERP message to the home domain, even if this message contains the
'B' (bootstrapping) flag. Otherwise, the local ER server MUST
include the DSRK request and its domain name in the AAA message
encapsulating the EAP-Initiate/Re-auth message sent by the peer.
o Upon receipt of an EAP-Initiate/Re-auth message, the home ER o Upon receipt of an EAP-Initiate/Re-auth message, the home ER
server verifies whether the message is fresh or is a replay by server verifies whether the message is fresh or is a replay by
evaluating whether the received sequence number is equal to or evaluating whether the received sequence number is equal to or
greater than the expected sequence number for that rIK. The home greater than the expected sequence number for that rIK. The home
ER server then verifies to ensure that the cryptosuite used by the ER server then verifies that the cryptosuite used by the peer is
peer is acceptable. Next, it verifies the origin authentication acceptable. Next, it verifies the integrity of the message by
of the message by looking up the rIK. If any of the checks fail, looking up the rIK and checking integrity checksum contained in
the home ER server sends an EAP-Finish/Re-auth message with the the Authentication Tag field. If any of the checks fail, the home
Result flag set to '1'. Please refer to Section 5.2.2 for details ER server sends an EAP-Finish/Re-auth message with the Result flag
on failure handling. This error MUST NOT have any correlation to set to '1'. Please refer to Section 5.2.2 for details on failure
any EAP-Success message that may have been received by the EAP handling. This error MUST NOT have any correlation to any EAP-
Success message that may have been received by the EAP
authenticator and the peer earlier. If the EAP-Initiate/Re-auth authenticator and the peer earlier. If the EAP-Initiate/Re-auth
message is well-formed and valid, the server prepares the EAP- message is well-formed and valid, the server prepares the EAP-
Finish/Re-auth message. The bootstrap flag MUST be set to Finish/Re-auth message. The bootstrap flag MUST be set to
indicate that this is a bootstrapping exchange. The message indicate that this is a bootstrapping exchange. The message
contains the following fields: contains the following fields:
* A sequence number for replay protection. * A sequence number for replay protection.
* The same keyName-NAI as in the EAP-Initiate/Re-auth message. * The same keyName-NAI as in the EAP-Initiate/Re-auth message.
skipping to change at page 19, line 39 skipping to change at page 19, line 24
may have a local policy for the network to maintain and enforce may have a local policy for the network to maintain and enforce
lifetime unilaterally. In such cases, the server need not lifetime unilaterally. In such cases, the server need not
respond to the peer's request for the lifetime. respond to the peer's request for the lifetime.
* If the bootstrap flag is set, the ER server MUST include the * If the bootstrap flag is set, the ER server MUST include the
domain name to which the DSRK is being sent along with the EAP- domain name to which the DSRK is being sent along with the EAP-
Finish/Re-auth message. Finish/Re-auth message.
* 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 indicate to the peer that the server that received the DSRK and
and that is advertising the domain included in the domain name that is advertising the domain included in the domain name TLV
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 gets involved in 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 during this ERP Explicit Bootstrapping as from the home EAP server; the home EAP server MUST provide the
specified in [I-D.ietf-dime-local-keytran], the home EAP server DSRK for the home ER server (derived using the EMSK and the domain
MUST include the DSRK for the local ER server (derived using the name as specified in RFC 5295), EMSKname, and DSRK lifetime for
EMSK and the domain name as specified in [RFC5295]), EMSKname, and inclusion in the AAA message. The home ER server SHOULD obtain
DSRK lifetime along with 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 [I-D.ietf-dime-erp]. message in a AAA attribute (for an example, see Bournelle, et
al.[I-D.ietf-dime-erp].
o The local ER server MUST extract the DSRK, EMSKname, and DSRK
lifetime (if present) before forwarding the EAP-Success message to
the peer, as specified in [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,
it must assume that there is no local ER server available. it must assume that there is no local ER server available.
o The peer MAY also verify the Authorization Indication TLV. o The peer MAY also verify the Authorization Indication TLV.
o The procedures for encapsulating the ERP and obtaining relevant o The procedures for encapsulating ERP and obtaining relevant keys
keys using Diameter are specified in [I-D.ietf-dime-erp]. using Diameter are specified in [I-D.ietf-dime-erp].
Since the ER bootstrapping exchange is typically done immediately Since the ER bootstrapping exchange is typically done immediately
following the full EAP exchange, it is feasible that the process is following the full EAP exchange, it is feasible that the process is
completed through the same entity that served as the EAP completed through the same entity that served as the EAP
authenticator for the full EAP exchange. In this case, the lower authenticator for the full EAP exchange. In this case, the lower
layer may already have established TSKs based on the MSK received layer may already have established TSKs based on the MSK received
earlier. The lower layer may then choose to ignore the rMSK that was earlier. The lower layer may then choose to ignore the rMSK that was
received with the ER bootstrapping exchange. Alternatively, the received with the ER bootstrapping exchange. Alternatively, the
lower layer may choose to establish a new TSK using the rMSK. In lower layer may choose to establish a new TSK using the rMSK. In
either case, the authenticator and the peer know which key is used either case, the authenticator and the peer know which key is used
skipping to change at page 21, line 44 skipping to change at page 21, line 26
message SHALL include the following fields: message SHALL include the following fields:
a 16-bit sequence number for replay protection a 16-bit sequence number for replay protection
keyName-NAI as a TLV attribute to identify the rIK used to keyName-NAI as a TLV attribute to identify the rIK used to
integrity protect the message. integrity protect the message.
cryptosuite to indicate the authentication algorithm used to cryptosuite to indicate the authentication algorithm used to
compute the integrity checksum. compute the integrity checksum.
authentication tag over the message. Authentication Tag computed over the message.
When the peer is performing ERP with a local ER server, it MUST When the peer is performing ERP with a local ER server, it MUST
use the corresponding DS-rIK it shares with the local ER server. use the corresponding DS-rIK it shares with the local ER server.
The peer SHOULD set the lifetime flag to request the key lifetimes The peer SHOULD set the lifetime flag to request the key lifetimes
from the server. The peer can use the rRK lifetime to know when from the server. The peer can use the rRK lifetime to know when
to trigger an EAP method exchange and the rMSK lifetime to know to trigger an EAP method exchange and the rMSK lifetime to know
when to trigger another ERP exchange. when to trigger another ERP exchange.
The authenticator copies the contents of the value field of the The authenticator copies the contents of the value field of the
keyName-NAI TLV into the User-Name RADIUS attribute in the AAA keyName-NAI TLV into an appropriate attribute (e.g, User-Name
message to the ER server. [RFC2865]) in the AAA message to the ER server.
The ER server uses the keyName-NAI to look up the rIK. It MUST The ER server uses the keyName-NAI to look up the rIK. It MUST
first verify whether the sequence number is equal to or greater first verify whether the sequence number is equal to or greater
than the expected sequence number. If the ER server supports a than the expected sequence number. If the ER server supports a
sequence number window size greater than 1, it MUST verify whether sequence number window size greater than 1, it MUST verify whether
the sequence number falls within the window and has not been the sequence number falls within the window and has not been
received before. The ER server MUST then verify to ensure that received before. The ER server MUST then verify that the
the cryptosuite used by the peer is acceptable. The ER server cryptosuite used by the peer is acceptable. The ER server then
then proceeds to verify the integrity of the message using the proceeds to verify the integrity of the message using the rIK,
rIK, thereby verifying proof of possession of that key by the thereby verifying proof of possession of that key by the peer. If
peer. If any of these verifications fail, the ER server MUST send any of these verifications fail, the ER server MUST send an EAP-
an EAP-Finish/Re-auth message with the Result flag set to '1' Finish/Re-auth message with the Result flag set to '1' (Failure).
(Failure). Please refer to Section 5.2.2 for details on failure Please refer to Section 5.2.2 for details on failure handling.
handling. Otherwise, it MUST compute an rMSK from the rRK using Otherwise, it MUST compute an rMSK from the rRK using the sequence
the sequence number as the additional input to the key derivation. number as the additional input to the key derivation.
In response to a well-formed EAP Re-auth/Initiate message, the ER In response to a well-formed EAP Re-auth/Initiate message, the ER
server MUST send an EAP-Finish/Re-auth message with the following server MUST send an EAP-Finish/Re-auth message with the following
considerations: contents:
a 16-bit sequence number for replay protection, which MUST be a 16-bit sequence number for replay protection, which MUST be
the same as the received sequence number. The local copy of the same as the received sequence number. The local copy of
the sequence number MUST be incremented by 1. If the ER server the sequence number MUST be incremented by 1. If the ER server
supports multiple simultaneous ERP exchanges, it MUST instead supports multiple simultaneous ERP exchanges, it MUST instead
update the sequence number window. update the sequence number window.
keyName-NAI as a TLV attribute to identify the rIK used to keyName-NAI as a TLV attribute to identify the rIK used to
integrity protect the message. integrity protect the message.
cryptosuite to indicate the authentication algorithm used to cryptosuite to indicate the authentication algorithm used to
compute the integrity checksum. compute the integrity checksum.
authentication tag over the message. Authentication Tag over the message.
If the lifetime flag was set in the EAP-Initiate/Re-auth If the lifetime flag was set in the EAP-Initiate/Re-auth
message, the ER server SHOULD include the rRK lifetime and the message, the ER server SHOULD include the rRK lifetime and the
rMSK lifetime. rMSK lifetime.
The ER server transports the rMSK along with this message to the The ER server causes the rMSK along with this message to to be
authenticator. The rMSK is transported in a manner similar to the transported to the authenticator. The rMSK is transported in a
MSK transport along with the EAP-Success message in a regular EAP manner similar to the MSK and the EAP-Success message in a regular
exchange. EAP exchange.
The peer looks up the sequence number to verify whether it is The peer looks up the sequence number to verify whether it is
expecting an EAP-Finish/Re-auth message with that sequence number expecting an EAP-Finish/Re-auth message with that sequence number
protected by the keyName-NAI. It then verifies the integrity of protected by the keyName-NAI. It then verifies the integrity of
the message. If the verifications fail, the peer logs an error the message. If the verifications fail, the peer logs an error
and stops the process; otherwise, it proceeds to the next step. and stops the process; otherwise, it proceeds to the next step.
The peer uses the sequence number to compute the rMSK. The peer uses the sequence number to compute the rMSK.
The lower-layer security association protocol can be triggered at The lower-layer security association protocol can be triggered at
skipping to change at page 23, line 45 skipping to change at page 23, line 26
Type 5) along with the EAP-Finish/Re-auth message. In this case, the Type 5) along with the EAP-Finish/Re-auth message. In this case, the
server MUST indicate the cryptosuite used to protect the EAP-Finish/ server MUST indicate the cryptosuite used to protect the EAP-Finish/
Re-auth message in the cryptosuite. The rIK used with the EAP- Re-auth message in the cryptosuite. The rIK used with the EAP-
Finish/Re-auth message in this case MUST be computed as specified in Finish/Re-auth message in this case MUST be computed as specified in
Section 4.3 using the new cryptosuite. If the server does not have a Section 4.3 using the new cryptosuite. If the server does not have a
valid rIK for the peer, the EAP-Finish/Re-auth message indicating a valid rIK for the peer, the EAP-Finish/Re-auth message indicating a
failure will be unauthenticated; the server MAY include a list of failure will be unauthenticated; the server MAY include a list of
acceptable cryptosuites in the message. acceptable cryptosuites in the message.
The peer, upon receiving an EAP-Finish/Re-auth message with the The peer, upon receiving an EAP-Finish/Re-auth message with the
Result flag set to '1', MUST verify the sequence number and the Result flag set to '1', MUST verify the sequence number and, if
Authentication Tag to determine the validity of the message. If the possible, the Authentication Tag to determine the validity of the
peer supports the cryptosuite, it MUST verify the integrity of the message. If the peer supports the cryptosuite, it MUST verify the
received EAP-Finish/Re-auth message. If the EAP-Finish message integrity of the received EAP-Finish/Re-auth message. If the EAP-
contains a TLV of Type 5, the peer SHOULD retry the ERP exchange with Finish message contains a TLV of Type 5, the peer SHOULD retry the
a cryptosuite picked from the list included by the server. The peer ERP exchange with a cryptosuite picked from the list included by the
MUST use the appropriate rIK for the subsequent ERP exchange, by server. The peer MUST use the appropriate rIK for the subsequent ERP
computing it with the corresponding cryptosuite, as specified in exchange, by computing it with the corresponding cryptosuite, as
Section 4.3. If the PRF in the chosen cryptosuite is different from specified in Section 4.3. If the PRF in the chosen cryptosuite is
the PRF originally used by the peer, it MUST derive a new DSRK (if different from the PRF originally used by the peer, it MUST derive a
required), rRK, and rIK before proceeding with the subsequent ERP new DSRK (if required), rRK, and rIK before proceeding with the
exchange. subsequent ERP exchange.
If the peer cannot verify the integrity of the received message, it If the peer cannot verify the integrity of the received message, it
MAY choose to retry the ERP exchange with one of the cryptosuites in MAY choose to retry the ERP exchange with one of the cryptosuites in
the TLV of Type 5, after a failure has been clearly determined the List of cryptosuites TLV, after a failure has been clearly
following the procedure in the next paragraph. determined following the procedure in the next paragraph.
If the replay or integrity checks fail, the failure message may have If the replay or integrity checks fail, the failure message may have
been sent by an attacker. It may also imply that the server and peer been sent by an attacker. It may also mean that the server and peer
do not support the same cryptosuites; however, the peer cannot do not support the same cryptosuites; however, the peer cannot
determine if that is the case. Hence, the peer SHOULD continue the determine if that is the case. Hence, the peer SHOULD continue the
ERP exchange per the retransmission timers before declaring a ERP exchange per the retransmission timers before declaring a
failure. failure.
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. New EAP Packets
Two new EAP Codes are defined for the purpose of ERP: EAP-Initiate Two new EAP Codes are defined for the purpose of ERP: EAP-Initiate
and EAP-Finish. The packet format for these messages follows the EAP and EAP-Finish. The packet format for these messages follows the EAP
packet format defined in RFC 3748 [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:
5 Initiate 5 Initiate
6 Finish
Two new code values are defined for the purpose of ERP. 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 Finish message. Any new (non- timeout while waiting for a EAP-Finish message. Any new (non-
retransmission) Initiate message MUST use a new Identifier retransmission) EAP-Initiate message MUST use a new Identifier
field. field.
The Identifier field of the Finish message MUST match that of The Identifier field of the EAP-Finish message MUST match that
the currently outstanding Initiate message. A peer or of the currently outstanding EAP-Initiate message. A peer or
authenticator receiving a Finish message whose Identifier value authenticator receiving a EAP-Finish message whose Identifier
does not match that of the currently outstanding Initiate value does not match that of the currently outstanding EAP-
message MUST silently discard the packet. Initiate message MUST silently discard the packet.
In order to avoid confusion between new EAP-Initiate messages In order to avoid confusion between new EAP-Initiate messages
and retransmissions, the peer must choose an Identifier value and retransmissions, the peer must choose an Identifier value
that is different from the previous EAP-Initiate message, that is different from the previous EAP-Initiate message,
especially if that exchange has not finished. It is especially if that exchange has not finished. It is
RECOMMENDED that the authenticator clear EAP Re-auth state RECOMMENDED that the authenticator clear EAP Re-auth state
after 300 seconds. after 300 seconds.
Type Type
This field indicates that this is an ERP exchange. Two type This field indicates that this is an ERP exchange. Two type
values are defined in this document for this purpose -- Re- values are defined in this document for this purpose -- Re-
auth-Start (assigned Type 1) and Re-auth (assigned Type 2). auth-Start (Type 1) and Re-auth (Type 2).
Type-Data Type-Data
The Type-Data field varies with the Type of re-authentication The Type-Data field varies with the Type of re-authentication
packet. packet.
5.3.1. EAP-Initiate/Re-auth-Start Packet 5.3.1. EAP-Initiate/Re-auth-Start Packet
The EAP-Initiate/Re-auth-Start packet contains the parameters shown The EAP-Initiate/Re-auth-Start packet contains the fields shown in
in Figure 8. Figure 8.
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 | Reserved | 1 or more TVs or TLVs ~ | Type | Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: EAP-Initiate/Re-auth-Start Packet Figure 8: EAP-Initiate/Re-auth-Start Packet
Type = 1. Type = 1.
skipping to change at page 26, line 32 skipping to change at page 26, line 7
the peer. the peer.
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.
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]. The name is to be used as the realm in an NAI [RFC4282]. The
Domain-Name attribute SHOULD be present in an EAP-Initiate/ Domain-Name TLV SHOULD be present in an EAP-Initiate/
Re-auth-Start message. Re-auth-Start message.
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.
5.3.1.1. Authenticator Operation 5.3.1.1. Authenticator Operation
In order to minimize ERP failure times, the authenticator SHOULD send In order to minimize ERP failure times, the authenticator SHOULD send
the EAP-Initiate/Re-auth-Start message to indicate support for ERP to the EAP-Initiate/Re-auth-Start message to indicate support for ERP to
the peer and to initiate ERP if the peer has already performed full the peer and to initiate ERP if the peer has already performed full
EAP authentication and has unexpired key material. The authenticator EAP authentication and has unexpired key material. The authenticator
SHOULD include the domain name TLV to allow the peer to learn it SHOULD include the Domain-Name TLV to allow the peer to learn it
without lower-layer support or the ERP bootstrapping exchange. without requiring either lower-layer support or the ERP bootstrapping
exchange.
The authenticator MAY include channel binding information so that the The authenticator MAY include channel binding information so so that
peer can send the information to the server in the EAP-Initiate/ the server can verify whether the authenticator is claiming the same
Re-auth message so that the server can verify whether the identity to both parties.
authenticator is claiming the same identity to both parties.
The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start
message a few times for reliable transport. message a few times for reliable transport.
5.3.1.2. Peer Operation 5.3.1.2. Peer Operation
The peer SHOULD send the EAP-Initiate/Re-auth message in response to The peer SHOULD send the EAP-Initiate/Re-auth message in response to
the EAP-Initiate/Re-auth-Start message from the authenticator. If the EAP-Initiate/Re-auth-Start message from the authenticator. If
the peer does not recognize the Initiate code value, it silently the peer does not recognize the EAP-Initiate code value or if the
discards the message. If the peer has already sent the EAP-Initiate/ peer has already sent the EAP-Initiate/Re-auth message to begin the
Re-auth message to begin the ERP exchange, it silently discards the ERP exchange, it MUST silently discard the EAP-Initiate/Re-auth-Start
message. message.
If the EAP-Initiate/Re-auth-Start message contains the domain name, If the EAP-Initiate/Re-auth-Start message contains the domain name,
and if the peer does not already have the domain information, the and if the peer does not already have the domain information, the
peer SHOULD use the domain name to compute the DSRK and use the peer SHOULD use the domain name contained in the message to compute
corresponding DS-rIK to send an EAP-Initiate/Re-auth message to start the DSRK and use the corresponding DS-rIK to send an EAP-Initiate/
an ERP exchange with the local ER server. If there are the local ER Re-auth message to start an ERP exchange with the local ER server.
server between the peer and the home ER server and the peer has If there is a local ER server between the peer and the home ER server
already initiated an ERP exchange with the local ER server, it SHOULD and the peer has already initiated an ERP exchange with the local ER
choose to not start an ERP exchange with the home ER server. server, it SHOULD not start an ERP exchange with the home ER server.
5.3.2. EAP-Initiate/Re-auth Packet 5.3.2. EAP-Initiate/Re-auth Packet
The EAP-Initiate/Re-auth packet contains the parameters shown in The EAP-Initiate/Re-auth packet contains the parameters shown in
Figure 9. Figure 9.
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 28, line 11 skipping to change at page 27, line 31
Flags Flags
'R' - The R flag is set to 0 and ignored upon reception. 'R' - The R flag is set to 0 and ignored upon reception.
'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 rest of the 5 bits are set to 0 and ignored on reception. The remaining 5 bits are set to 0 on transmission and ignored
on reception.
SEQ: A 16-bit sequence number is used for replay protection. The SEQ: A 16-bit sequence number is used for replay protection. The
SEQ number field is initialized to 0 every time a new rRK is SEQ number field is initialized to 0 every time a new rRK is
derived. derived.
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.
skipping to change at page 28, line 51 skipping to change at page 28, line 23
below: below:
* 0 RESERVED * 0 RESERVED
* 1 HMAC-SHA256-64 * 1 HMAC-SHA256-64
* 2 HMAC-SHA256-128 * 2 HMAC-SHA256-128
* 3 HMAC-SHA256-256 * 3 HMAC-SHA256-256
HMAC-SHA256-128 is mandatory to implement and should be enabled in HMAC-SHA256-128 is mandatory to implement and SHOULD be enabled in
the default configuration. the default configuration.
Authentication Tag: This field contains the integrity checksum Authentication Tag: This field contains the integrity checksum
over the ERP packet, excluding the authentication tag field over the ERP packet, excluding the authentication tag field
itself. The length of the field is indicated by the Cryptosuite. itself. The length of the field is indicated by the Cryptosuite.
5.3.3. EAP-Finish/Re-auth Packet 5.3.3. EAP-Finish/Re-auth Packet
The EAP-Finish/Re-auth packet contains the parameters shown in The EAP-Finish/Re-auth packet contains the parameters shown in
Figure 10. Figure 10.
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 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 29, line 41 skipping to change at page 29, line 18
'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 rest of the 5 bits are set to 0 and ignored on reception. The remaining 5 bits are set to 0 on transmission and ignored
on reception.
SEQ: A 16-bit sequence number is used for replay protection. The SEQ: A 16-bit sequence number is used for replay protection. The
SEQ number field is initialized to 0 every time a new rRK is SEQ number field is initialized to 0 every time a new rRK is
derived. derived.
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.
skipping to change at page 31, line 28 skipping to change at page 31, line 10
Authentication Tag: This field contains the integrity checksum Authentication Tag: This field contains the integrity checksum
over the ERP packet, excluding the authentication tag field over the ERP packet, excluding the authentication tag field
itself. The length of the field is indicated by the Cryptosuite. itself. The length of the field is indicated by the Cryptosuite.
5.3.4. TV and TLV Attributes 5.3.4. TV and TLV Attributes
The TV attributes that may be present in the EAP-Initiate or EAP- The TV attributes that may be present in the EAP-Initiate or EAP-
Finish messages are of the following format: Finish messages are of the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value ... | Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: TV Attribute Format Figure 11: TV Attribute Format
The TLV attributes that may be present in the EAP-Initiate or EAP- The TLV attributes that may be present in the EAP-Initiate or EAP-
Finish messages are of the following format: Finish messages are of the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... | Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: TLV Attribute Format Figure 12: TLV Attribute Format
The following Types are defined in this document: The following Types are defined in this document:
'1' - keyName-NAI: This is a TLV payload. '1' - keyName-NAI: This is a TLV payload.
skipping to change at page 32, line 37 skipping to change at page 32, line 16
'131' - NAS-IP-Address [RFC2865] '131' - NAS-IP-Address [RFC2865]
'132' - NAS-IPv6-Address [RFC3162] '132' - NAS-IPv6-Address [RFC3162]
The length field indicates the length of the value part of the The length field indicates the length of the value part of the
attribute in octets. attribute in octets.
5.4. Replay Protection 5.4. Replay Protection
For replay protection, ERP uses sequence numbers. The sequence For replay protection, ERP uses sequence numbers. The sequence
number is maintained per rIK and is initialized to zero in both number is maintained on a per rIK basis and is initialized to zero in
directions. In the first EAP-Initiate/Re-auth message, the peer uses both directions. In the first EAP-Initiate/Re-auth message, the peer
the sequence number zero or higher. Note that the when the sequence uses a sequence number value of zero or higher. Note that the when
number rotates, the rIK MUST be changed by running EAP the sequence number wraps back to zero, the rIK MUST be changed by
authentication. The server expects a sequence number of zero or running a full EAP authentication. The server expects a sequence
higher. When the server receives an EAP-Initiate/Re-auth message, it number of zero or higher. When the server receives an EAP-Initiate/
uses the same sequence number in the EAP-Finish/Re-auth message. The Re-auth message, it uses the same sequence number in the EAP-Finish/
server then sets the expected sequence number to the received Re-auth message. The server then sets the expected sequence number
sequence number plus 1. The server accepts sequence numbers greater to the received sequence number plus 1. The server MUST accept
than or equal to the expected sequence number. sequence numbers greater than or equal to the expected sequence
number.
If the peer sends an EAP-Initiate/Re-auth message, but does not If the peer sends an EAP-Initiate/Re-auth message, but does not
receive a response, it retransmits the request (with no changes to receive a response, it retransmits the request (with no changes to
the message itself) a pre-configured number of times before giving the message itself) a pre-configured number of times before giving
up. However, it is plausible that the server itself may have up. However, it is plausible that the server itself may have
responded to the message and it was lost in transit. Thus, the peer responded to the message and the response was lost in transit. Thus,
MUST increment the sequence number and use the new sequence number to the peer MUST increment the sequence number and use the new sequence
send subsequent EAP re-authentication messages. The peer SHOULD number to send subsequent EAP re-authentication messages. The peer
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. When the sequence number rotates, the increment by a larger number. If the sequence number wraps back to
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 in Section 7.15 of information, according to the guidelines provided by Aboba, et al.
[RFC3748]. The TLV type range of 128-191 is reserved to carry CB (see Section 7.15 of [RFC3748]). The TLV type range of 128-191 is
information in the EAP-Initiate/Re-auth and EAP-Finish/Re-auth reserved to carry CB information in the EAP-Initiate/Re-auth and EAP-
messages. Called-Station-Id, Calling-Station-Id, NAS-Identifier, Finish/Re-auth messages. Called-Station-Id, Calling-Station-Id, NAS-
NAS-IP-Address, and NAS-IPv6-Address are some examples of channel Identifier, NAS-IP-Address, and NAS-IPv6-Address are some examples of
binding information listed in RFC 3748, and they are assigned values channel binding information listed in RFC 3748, and they are assigned
128-132. Additional values are IANA managed based on IETF Consensus values 128-132. Additional values are IANA managed based on IETF
[RFC5226]. 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 33, line 42 skipping to change at page 33, line 23
authenticator has sent the CB parameters, and it proceeds with the authenticator has sent the CB parameters, and it proceeds with the
lower-layer security association establishment if the attributes lower-layer security association establishment if the attributes
match. Otherwise, the peer SHALL NOT proceed with the lower-layer match. Otherwise, the peer SHALL NOT proceed with the lower-layer
security association establishment. security association establishment.
6. Lower-Layer Considerations 6. Lower-Layer Considerations
The authenticator is responsible for retransmission of EAP-Initiate/ The authenticator is responsible for retransmission of EAP-Initiate/
Re-auth-Start messages. The authenticator MAY retransmit the message Re-auth-Start messages. The authenticator MAY retransmit the message
a few times or until it receives an EAP-Initiate/Re-auth message from a few times or until it receives an EAP-Initiate/Re-auth message from
the peer. The authenticator may not know whether the peer supports the peer. The authenticator might not know if the peer supports ERP;
ERP; in those cases, the peer may be silently dropping the EAP- in those cases, the peer could be silently discarding the EAP-
Initiate/Re-auth-Start packets. Thus, retransmission of these Initiate/Re-auth-Start packets. Thus, retransmission of these
packets should be kept to a minimum. The exact number is up to each packets should be kept to a minimum. The exact number is up to each
lower layer. lower layer.
The Identifier value in the EAP-Initiate/Re-auth packet is The Identifier value in the EAP-Initiate/Re-auth packet is
independent of the Identifier value in the EAP-Initiate/Re-auth-Start independent of the Identifier value in the EAP-Initiate/Re-auth-Start
packet. packet.
The peer is responsible for retransmission of EAP-Initiate/Re-auth The peer is responsible for retransmission of EAP-Initiate/Re-auth
messages. messages.
Retransmitted packets MUST be sent with the same Identifier value in Retransmitted packets MUST be sent with the same Identifier value in
order to distinguish them from new packets. By default, where the order to distinguish them from new packets. By default, where the
EAP-Initiate message is sent over an unreliable lower layer, the EAP-Initiate message is sent over an unreliable lower layer, the
retransmission timer SHOULD be dynamically estimated. A maximum of retransmission timer SHOULD be dynamically estimated. A maximum of
3-5 retransmissions is suggested (this is based on the recommendation 3-5 retransmissions is suggested [RFC3748]. Where the EAP-Initiate
of [RFC3748]). Where the EAP-Initiate message is sent over a message is sent over a reliable lower layer, the retransmission timer
reliable lower layer, the retransmission timer SHOULD be set to an SHOULD be set to an infinite value, so that retransmissions do not
infinite value, so that retransmissions do not occur at the EAP occur at the EAP layer. Please refer to RFC 3748 for additional
layer. Please refer to RFC 3748 [RFC3748] for additional guidance on guidance on setting timers.
setting timers.
The Identifier value in the EAP-Finish/Re-auth packet is the same as The Identifier value in the EAP-Finish/Re-auth packet is the same as
the Identifier value in the EAP-Initiate/Re-auth packet. the Identifier value in the EAP-Initiate/Re-auth packet.
If an authenticator receives a valid duplicate EAP-Initiate/Re-auth If an authenticator receives a valid duplicate EAP-Initiate/Re-auth
message for which it has already sent an EAP-Finish/Re-auth message, message for which it has already sent an EAP-Finish/Re-auth message,
it MUST resend the EAP-Finish/Re-auth message without reprocessing it MUST resend the EAP-Finish/Re-auth message without reprocessing
the EAP-Initiate/Re-auth message. To facilitate this, the the EAP-Initiate/Re-auth message. To facilitate this, the
authenticator SHALL store a copy of the EAP-Finish/Re-auth message authenticator SHALL store a copy of the EAP-Finish/Re-auth message
for a finite amount of time. The actual value of time is a local for a finite amount of time. The actual value of time is a local
matter; this specification recommends a value of 100 milliseconds. matter; this specification recommends a value of 100 milliseconds.
The lower layer may provide facilities for exchanging information The lower layer may provide facilities for exchanging information
between the peer and the authenticator about support for ERP, for the between the peer and the authenticator about support for ERP, for the
authenticator to send the domain name information and channel binding authenticator to send the domain name information and channel binding
information to the peer information to the peer
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. Specifically, the IEEE802.1x specification must be revised revised. Specifically, RFC 5996 must be updated to include EAP code
to allow carrying EAP messages of the new codes defined in this values higher than 4 in order to use ERP with Internet Key Exchange
document in order to support ERP. Similarly, RFC 5996 must be Protocol version 2 (IKEv2). IKEv2 may also be updated to support
updated to include EAP code values higher than 4 in order to use ERP peer-initiated ERP for optimized operation. Other lower layers may
with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may need similar revisions.
also be updated to support peer-initiated ERP for optimized
operation. Other lower layers may need similar revisions.
Our analysis indicates that some EAP implementations are not RFC 3748 Our analysis indicates that some EAP implementations are not RFC 3748
compliant in that instead of silently dropping EAP packets with code compliant in that instead of silently dropping EAP packets with code
values higher than 4, they may consider it an error. To accommodate values higher than 4, they may consider it an error. To accommodate
such non-compliant EAP implementations, additional guidance has been such non-compliant EAP implementations, additional guidance has been
provided below. Furthermore, it may not be easy to upgrade all the provided below. Furthermore, it may not be easy to upgrade all the
peers in some cases. In such cases, authenticators may be configured peers in some cases. In such cases, authenticators may be configured
to not send EAP-Initiate/Re-auth-Start; peers may learn whether an to not send EAP-Initiate/Re-auth-Start; peers may learn whether an
authenticator supports ERP via configuration, from advertisements at authenticator supports ERP via configuration or from advertisements
the lower layer. at the lower layer.
In order to accommodate implementations that are not compliant to RFC In order to accommodate implementations that are not compliant to RFC
3748, such lower layers SHOULD ensure that both parties support ERP; 3748, such lower layers SHOULD ensure that both parties support ERP;
this is trivial for an instance when using a lower layer that is this is trivial for instance when using a lower layer that is known
known to always support ERP. For lower layers where ERP support is to always support ERP. For lower layers where ERP support is not
not 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. Transport of ERP Messages 7. AAA Transport of ERP Messages
AAA Transport of ERP messages is specified in [RFC5749] and AAA Transport of ERP messages is specified by Hoeper, et al.
[I-D.ietf-dime-erp]. [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 requirements specified in [RFC4962]. the AAA key management guidelines described by Housley & Aboba
[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 [RFC5295]. Only when the agility for the KDF is specified in Salowey, et al. [RFC5295].
algorithms used are acceptable, the server proceeds with Only when the algorithms used are deemed acceptable does the
derivation of keys and verification of the proof of possession server proceed with the derivation of keys and verification of
of relevant keying material by the peer. A full-blown the proof of possession of relevant keying material presented
negotiation of algorithms cannot be provided in a single round by the peer. A full-blown negotiation of algorithms cannot be
trip protocol. Hence, while the protocol provides algorithm provided in a single round trip protocol. Hence, while the
agility, it does not provide true negotiation. protocol provides algorithm agility, it does not provide true
negotiation.
Strong, fresh session keys Strong, fresh session keys
ERP results in the derivation of strong, fresh keys that are ERP results in the derivation of strong, fresh keys that are
unique for the given session. An rMSK is always derived on- unique for the given session. An rMSK is always derived on-
demand when the peer requires a key with a new authenticator. demand when the peer requires a key with a new authenticator.
The derivation ensures that the compromise of one rMSK does not The derivation ensures that the compromise of one rMSK does not
result in the compromise of a different rMSK at any time. result in the compromise of another rMSK at any time.
Limit key scope Limit key scope
The scope of all the keys derived by ERP is well defined. The The scope of all the keys derived by ERP is well defined. The
rRK and rIK are never shared with any entity and always remain rRK and rIK are never shared with any entity and always remain
on the peer and the server. The rMSK is provided only to the on the peer and the server. The rMSK is provided only to the
authenticator through which the peer performs the ERP exchange. authenticator through which the peer performs the ERP exchange.
No other authenticator is authorized to use that rMSK. No other authenticator is authorized to use that rMSK.
Replay detection mechanism Replay detection mechanism
skipping to change at page 38, line 18 skipping to change at page 37, line 45
keying material held by any other peer in the system. Also, keying material held by any other peer in the system. Also,
the rMSK is meant for a single authenticator and is not shared the rMSK is meant for a single authenticator and is not shared
with any other authenticator. Hence, the compromise of one with any other authenticator. Hence, the compromise of one
authenticator does not lead to the compromise of sessions or authenticator does not lead to the compromise of sessions or
keys held by any other authenticator in the system. Hence, the keys held by any other authenticator in the system. Hence, the
EAP Re-auth Protocol allows prevention of the domino effect by EAP Re-auth Protocol allows prevention of the domino effect by
appropriately defining key scope. appropriately defining key scope.
However, if keys are transported using hop-by-hop protection, However, if keys are transported using hop-by-hop protection,
compromise of a proxy may result in compromise of key material, compromise of a proxy may result in compromise of key material,
i.e., the DSRK being sent to a local ER server. e.g., the DSRK being sent to a local ER server.
Bind key to its context Bind key to its context
All the keys derived for ERP are bound to the appropriate All the keys derived for ERP are bound to the appropriate
context using appropriate key labels. Lifetime of a child key context using appropriate key labels. Lifetime of a child key
is less than or equal to that of its parent key as specified in is less than or equal to that of its parent key as specified in
RFC 4962 [RFC4962]. The key usage, lifetime and the parties RFC 4962 [RFC4962]. The key usage, lifetime and the parties
that have access to the keys are specified. that have access to the keys are specified.
Confidentiality of identity Confidentiality of identity
skipping to change at page 38, line 45 skipping to change at page 38, line 24
requirement at the time of development of this specification. requirement at the time of development of this specification.
If the rIKname is not used and the Peer-ID is used instead, the If the rIKname is not used and the Peer-ID is used instead, the
ERP exchange will reveal the Peer-ID over the wire. ERP exchange will reveal the Peer-ID over the wire.
Authorization restriction Authorization restriction
All the keys derived are limited in lifetime by that of the All the keys derived are limited in lifetime by that of the
parent key or by server policy. Any domain-specific keys are parent key or by server policy. Any domain-specific keys are
further restricted for use only in the domain for which the further restricted for use only in the domain for which the
keys are derived. All the keys specified in this document are keys are derived. All the keys specified in this document are
meant for use in ERP only. Any other restrictions of session meant for use in ERP only. Other restrictions on the use of
keys may be imposed by the specific lower layer and are out of session keys may be imposed by the specific lower layer but are
scope for this specification. out of scope for this specification.
Prevent DoS attack Prevent DoS attack
A denial-of-service (DoS) attack on the peer may be possible A denial-of-service (DoS) attack on the peer may be possible
when using the EAP Initiate/Re-auth message. An attacker may when using the EAP Initiate/Re-auth message. An attacker may
send a bogus EAP-Initiate/Re-auth message, which may be carried send a bogus EAP-Initiate/Re-auth message, which may be carried
by the authenticator in a RADIUS-Access-Request to the server; by the authenticator in a AAA request to the server; in
in response, the server may send an EAP-Finish/Re-auth with response, the server may send an EAP-Finish/Re-auth with
Failure indication in a RADIUS Access-Reject message. Note Failure indication in a AAA reply. Note that such attacks may
that such attacks may be plausible with the EAPoL-Start be possible with the EAPoL-Start capability of IEEE 802.11 and
capability of IEEE 802.11 and other similar facilities in other other similar facilities in other link layers and where the
link layers and where the peer can initiate EAP authentication. peer can initiate EAP authentication. An attacker may use such
An attacker may use such messages to start an EAP method run, messages to start an EAP method run, which fails and may result
which fails and may result in the server sending a RADIUS in the server sending a rejection message, thus resulting in
Access-Reject message, thus resulting in the link-layer the link-layer connections being terminated.
connections being terminated.
To prevent such DoS attacks, an ERP failure should not result To prevent such DoS attacks, an ERP failure should not result
in deletion of any authorization state established by a full in deletion of any authorization state established by a full
EAP exchange. Alternatively, the lower layers and AAA EAP exchange. Alternatively, the lower layers and AAA
protocols may define mechanisms to allow two link-layer protocols may define mechanisms to allow two link-layer
security associations (SAs) derived from different EAP keying security associations (SAs) derived from different EAP keying
materials for the same peer to exist so that smooth migration materials for the same peer to exist so that smooth migration
from the current link layer SA to the new one is possible from the current link layer SA to the new one is possible
during rekey. These mechanisms prevent the link layer during rekey. These mechanisms prevent the link layer
connections from being terminated when a re-authentication connections from being terminated when a re-authentication
procedure fails due to the bogus EAP-Initiate/Re-auth message. procedure fails due to a bogus EAP-Initiate/Re-auth message.
Keying materials Transport Keying materials Transport
When a DSRK is sent from a home EAP server to a local domain When a DSRK is sent from the home EAP server to a local domain
server or when a rMSK is sent from an ER server to an server or when a rMSK is sent from an ER server to an
authenticator, in the absence of end-to-end security between authenticator, in the absence of end-to-end security between
the entity that is sending the key and the entity receiving the the entity that is sending the key and the entity receiving the
key, it is plausible for other entities to get access to keys key, it is plausible for other entities to get access to keys
being sent to an ER server in another domain. This mode of key being sent to an ER server in another domain. This mode of key
transport is similar to that of MSK transport in the context of transport is similar to that of MSK transport in the context of
EAP authentication. We further observe that ERP is for access EAP authentication. We further observe that ERP is for access
authentication and does not support end-to-end data security. authentication and does not support end-to-end data security.
In typical implementations, the traffic is in the clear beyond In typical implementations, the traffic is in the clear beyond
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; all values referenced in this This document has no IANA actions.
document were previously assigned in RFC 5296 [RFC5296].
10. References 10. References
10.1. Normative References 10.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
skipping to change at page 40, line 33 skipping to change at page 40, line 12
[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 10.2. Informative References
[I-D.ietf-dime-erp] [I-D.ietf-dime-erp]
Bournelle, J., Morand, L., Decugis, S., Wu, W., and G. Bournelle, J., Morand, L., Decugis, S., Wu, W., and G.
Zorn, "Diameter support for EAP Re-authentication Protocol Zorn, "Diameter support for EAP Re-authentication Protocol
(ERP)", draft-ietf-dime-erp-06 (work in progress), (ERP)", draft-ietf-dime-erp-07 (work in progress),
May 2011. September 2011.
[I-D.ietf-dime-local-keytran]
, Q. and G. , "Diameter Attribute-Value Pairs for
Cryptographic Key Transport",
draft-ietf-dime-local-keytran-07 (work in progress),
July 2010.
[I-D.ietf-hokey-ldn-discovery] [I-D.ietf-hokey-ldn-discovery]
Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name Zorn, G., Wu, W., and Y. Wang, "The ERP Local Domain Name
DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in DHCPv6 Option", draft-ietf-hokey-ldn-discovery-10 (work in
progress), September 2010. progress), April 2011.
[I-D.nir-ipsecme-erx]
Nir, Y. and W. Wu, "An IKEv2 Extension for Supporting
ERP", draft-nir-ipsecme-erx-01 (work in progress),
July 2011.
[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
skipping to change at page 41, line 20 skipping to change at page 40, line 46
Conference on Wireless Communications and Conference on Wireless Communications and
Mobile Computing, New York, NY, USA, 2006. Mobile 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.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[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
Agreement (EAP-AKA)", RFC 4187, January 2006. Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, [RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management", Authorization, and Accounting (AAA) Key Management",
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 Appendix A. Acknowledgments
skipping to change at page 42, line 28 skipping to change at page 41, line 45
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 A.2. RFC 5296bis
Glen Zorn wrote the initial draft for this document and provided Thanks to Yaron Sheffer and Yoav Nir for useful comments.
useful reviews. Many thanks to him.
A.3. Change Log
A.3.1. draft-ietf-hokey-rfc5296bis-02
The following are the major changes compared to previous version:
o Change using MAY in section 5.3.1.1 to using SHOULD
o Mandate sending the EAP-Initiate/Re-auth-Start message instead of
optional
o Update obsolete reference RFC4306 into RFC5996
o Allow local server respond to the peer directly without forwarding
the ERP message to the home domain
A.3.2. draft-ietf-hokey-rfc5296bis-03
The following are the major changes compared to previous version:
o Add explanation texts to clarify why SHOULD is used instead of
MAY.
o Additional texts to optimize implicit bootstrapping in section
5.1.
o Additional texts to optimize explicit bootstrapping in section
5.1.
o Add two new bullets with text in section 8 unmodified.
Appendix B. Example ERP Exchange
0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start] Appendix B. Sample ERP Exchange
0. Authenticator --> Peer:
EAP-Initiate/Re-auth-Start [Optional]
1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI, 1. Peer --> Authenticator:
cryptosuite,Auth-tag*) EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite,
Auth-tag*)
1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id, 1a. Authenticator --> Re-auth-Server:
EAP Initiate/Re-auth(SEQ,keyName-NAI, AAA-Request
cryptosuite,Auth-tag*) {
Authenticator-Id,
EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite,
Auth-tag*)
}
2. ER-Server --> Authenticator: AAA-Response{rMSK, 2. ER-Server --> Authenticator:
EAP-Finish/Re-auth(SEQ,keyName-NAI, AAA-Response
cryptosuite,[CB-Info],Auth-tag*) {
rMSK,
EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info],
Auth-tag*)
}
2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI, 2b. Authenticator --> Peer:
cryptosuite,[CB-Info],Auth-tag*) EAP-Finish/Re-auth(SEQ, keyName-NAI, cryptosuite, [CB-Info],
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) Qin Wu (editor)
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
skipping to change at page 44, line 12 skipping to change at page 43, line 12
Email: Sunseawq@huawei.com 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
Glen Zorn (editor)
Network Zen
227/358 Thanon Sanphawut
Bang Na, Bangkok 10260
Thailand
Phone: +66 (0) 87-0404617
Email: glenzorn@gmail.com
Yang Shi Yang Shi
H3C Tech. Co., Ltd H3C Tech. Co., Ltd
Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District
Beijing 100085 Beijing 100085
China China
Email: young@h3c.com Email: young@h3c.com
Baohong He Baohong He
China China
 End of changes. 125 change blocks. 
466 lines changed or deleted 413 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/