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