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/ |