draft-ietf-hokey-rfc5296bis-00.txt | draft-ietf-hokey-rfc5296bis-01.txt | |||
---|---|---|---|---|
Network Working Group G. Zorn, Ed. | Network Working Group Q. Wu, Ed. | |||
Internet-Draft Network Zen | Internet-Draft Huawei | |||
Obsoletes: 5296 (if approved) Q. Wu | Obsoletes: 5296 (if approved) Z. Cao | |||
Intended status: Standards Track Huawei | Intended status: Standards Track China Mobile | |||
Expires: March 17, 2011 Z. Cao | Expires: April 23, 2011 Y. Shi | |||
China Mobile | H3C | |||
September 13, 2010 | B. He | |||
CATR | ||||
October 20, 2010 | ||||
EAP Extensions for EAP Re-authentication Protocol (ERP) | EAP Extensions for EAP Re-authentication Protocol (ERP) | |||
draft-ietf-hokey-rfc5296bis-00 | draft-ietf-hokey-rfc5296bis-01 | |||
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 not repeat | |||
the entire EAP exchange with another authenticator. This document | the entire EAP exchange with another authenticator. This document | |||
specifies extensions to EAP and the EAP keying hierarchy to support | specifies extensions to EAP and the EAP keying hierarchy to support | |||
an EAP method-independent protocol for efficient re-authentication | an EAP method-independent protocol for efficient re-authentication | |||
between the peer and an EAP re-authentication server through any | between the peer and an EAP re-authentication server through any | |||
skipping to change at page 1, line 41 | skipping to change at page 1, line 43 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on March 17, 2011. | This Internet-Draft will expire on April 23, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 3, line 10 | skipping to change at page 3, line 10 | |||
outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
it for publication as an RFC or to translate it into languages other | it for publication as an RFC or to translate it into languages other | |||
than English. | 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 . . . . . . . . . . . . . . . 7 | 3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 9 | |||
3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 9 | 3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 10 | |||
4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 11 | 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 12 | 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 | |||
4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 13 | 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 14 | |||
4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 | 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 14 | |||
4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 14 | 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 15 | |||
4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 14 | 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 15 | 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16 | |||
4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 | 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 | |||
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 16 | 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 16 | 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17 | |||
5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 19 | 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 21 | 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 22 | |||
5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 22 | 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 23 | |||
5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 23 | 5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 24 | |||
5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 24 | 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 25 | |||
5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 25 | 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 26 | |||
5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 25 | 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 26 | |||
5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 25 | 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 26 | |||
5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 27 | 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 28 | |||
5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 30 | 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31 | |||
5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 31 | 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32 | |||
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 31 | 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32 | |||
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 32 | 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33 | |||
7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 33 | 7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 34 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 | 10.1. Normative References . . . . . . . . . . . . . . . . . . . 39 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 39 | 10.2. Informative References . . . . . . . . . . . . . . . . . . 40 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 40 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 41 | |||
A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 40 | A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 40 | A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 40 | Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 42 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
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 47 | skipping to change at page 4, line 47 | |||
via other authenticators. Other solutions for fast re-authentication | via other authenticators. Other solutions for fast re-authentication | |||
exist in the literature [MSKHierarchy]. | exist in the literature [MSKHierarchy]. | |||
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. The EAP re- | |||
authentication problem statement is described in detail in [RFC5169]. | 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 itself is 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 must be revised and RFC | Specifically, the IEEE802.1x specification must be revised and RFC | |||
4306 must be updated to carry ERP messages. | 4306 must be updated to carry ERP messages. | |||
skipping to change at page 5, line 34 | skipping to change at page 5, line 34 | |||
ER Authenticator - An entity that supports the authenticator | ER Authenticator - An entity that supports the authenticator | |||
functionality for EAP re-authentication described in this | functionality for EAP re-authentication described in this | |||
document. All references to "authenticator" in this document | document. All references to "authenticator" in this document | |||
imply an ER authenticator, unless specifically noted otherwise. | imply an ER authenticator, unless specifically noted otherwise. | |||
ER Server - An entity that performs the server portion of ERP | ER Server - An entity that performs the server portion of ERP | |||
described here. This entity may or may not be an EAP server. All | described here. This entity may or may not be an EAP server. All | |||
references to "server" in this document imply an ER server, unless | references to "server" in this document imply an ER server, unless | |||
specifically noted otherwise. An ER server is a logical entity; | specifically noted otherwise. An ER server is a logical entity; | |||
the home ER server is located on the same backend authentication | it may not necessarily be co-located with, or physically part of, | |||
server as the EAP server in the home domain. The local ER server | a full EAP server. | |||
may not necessarily be a full EAP server. | ||||
ERX - EAP re-authentication extensions. | ERX - EAP re-authentication extensions. | |||
ERP - EAP Re-authentication Protocol that uses the re- | ERP - EAP Re-authentication Protocol that uses the re- | |||
authentication extensions. | authentication extensions. | |||
rRK - re-authentication Root Key, derived from the EMSK or DSRK. | rRK - re-authentication Root Key, derived from the EMSK or DSRK. | |||
rIK - re-authentication Integrity Key, derived from the rRK. | rIK - re-authentication Integrity Key, derived from the rRK. | |||
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. | and the authenticator (i.e.,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 itself is derived from the EMSK. The | Specific Root Key (DSRK), which is itself derived from the EMSK. The | |||
rRK is only available to the peer and the ER server and is never | rRK is only available to the peer and the ER server and is never | |||
handed out to any other entity. Further, a re-authentication | handed out to any other entity. Further, a re-authentication | |||
Integrity Key (rIK) is derived from the rRK; the peer and the ER | Integrity Key (rIK) is derived from the rRK; the peer and the ER | |||
server use the rIK to provide proof of possession while performing an | server use the rIK to provide proof of possession while performing an | |||
ERP exchange. The rIK is also never handed out to any entity and is | ERP exchange. The rIK is also never handed out to any entity and is | |||
only available to the peer and server. | only available to the peer and server. | |||
When the ER server is in the home domain, the peer and the server use | ||||
the rIK and rRK derived from the EMSK; and when the ER server is not | ||||
in the home 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 portion of the keyname-NAI in ERP messages. | ||||
3.1. ERP With the Home ER Server | ||||
EAP Peer EAP Authenticator EAP Server | EAP Peer EAP Authenticator EAP Server | |||
======== ================= ========== | ======== ================= ========== | |||
<--- EAP-Request/ ------ | <--- EAP-Request/ ------ | |||
Identity | Identity | |||
----- EAP Response/ ---> | ----- EAP Response/ ---> | |||
Identity ---AAA(EAP Response/Identity)--> | Identity ---AAA(EAP Response/Identity)--> | |||
<--- EAP Method -------> <------ AAA(EAP Method --------> | <--- EAP Method -------> <------ AAA(EAP Method --------> | |||
exchange exchange) | exchange exchange) | |||
<----AAA(MSK, EAP-Success)------ | <----AAA(MSK, EAP-Success)------ | |||
<---EAP-Success--------- | <---EAP-Success--------- | |||
Figure 1: EAP Authentication | Figure 1: EAP Authentication | |||
Peer Authenticator Server | Peer ER Authenticator 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]) | |||
skipping to change at page 8, line 14 | skipping to change at page 8, line 8 | |||
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. | authenticator to trigger the ERP exchange. The EAP-Finish message | |||
also can be used by the authenticator to announce 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, it will send the EAP-Request/ | |||
Identity message. Note that this avoids having two EAP messages in | Identity message. Note that this avoids having two EAP messages in | |||
flight at the same time [RFC3748]. The authenticator may send the | flight at the same time [RFC3748]. The authenticator may send the | |||
EAP-Initiate/Re-auth-Start message and wait for a short, locally | EAP-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. If the peer does not already know, this | |||
skipping to change at page 9, line 39 | skipping to change at page 9, line 36 | |||
In an ERP bootstrap exchange, the peer MAY request the server for the | In an ERP bootstrap exchange, the peer MAY request the server for the | |||
rRK lifetime. If so, the ER server sends the rRK lifetime in the | rRK lifetime. If so, the ER server sends the rRK lifetime in the | |||
EAP-Finish/Re-auth message. | EAP-Finish/Re-auth message. | |||
The peer verifies the replay protection and the integrity of the | The peer verifies the replay protection 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 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 | ||||
local domain. The domain of the ER server is identified by the realm | ||||
portion of the keyname-NAI in ERP messages. | ||||
3.1. ERP With the Home ER Server | ||||
If the peer is in the home domain and does not know the domain name ( | ||||
did not receive the domain name through the EAP-Initiate/ | ||||
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. | ||||
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 | ||||
home AAA server. The ERP with the Home ER Server is the similar as | ||||
ERP exchange described in Figure 2. | ||||
Peer ER Authenticator Home ER Server | ||||
==== ============= ====== | ||||
[<-- EAP-Initiate/ ----- | ||||
Re-auth-Start] | ||||
[<-- EAP-Request/ ------ | ||||
Identity] | ||||
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> | ||||
Re-auth/ Re-auth/ | ||||
[Bootstrap] [Bootstrap]) | ||||
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- | ||||
Re-auth/ Re-auth/ | ||||
[Bootstrap] [Bootstrap]) | ||||
Note: [] brackets indicate optionality. | ||||
Figure 3: ER ExplicitBootstrapping Exchange/ERP with the Home ER | ||||
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 executing the ERP with an ER server | |||
in the local domain (access network). The local ER server may be co- | in the local domain (access network) if the peer moves out of home | |||
located with a local AAA server. The peer may learn about the | domain. The local ER server may be co-located with a local AAA | |||
presence of a local ER server in the network and the local domain | server. The peer may learn about the presence of a local ER server | |||
name (or ER server name) either via the lower layer or by means of | in the network and the local domain name (or ER server name) either | |||
ERP bootstrapping. The peer uses the domain name and the EMSK to | via the lower layer or by means of ERP exchange. The peer uses the | |||
compute the DSRK and from that key, the DS-rRK; the peer also uses | domain name and the EMSK to compute the DSRK and from that key, the | |||
the domain name in the realm portion of the keyName-NAI for using ERP | DS-rRK; the peer also uses the domain name in the realm portion of | |||
in the local domain. Figure 3 shows the full EAP and subsequent | the keyName-NAI for using ERP in the local domain. Figure 4 shows | |||
local ERP exchange; Figure 4 shows it with a local ER server. | the ER Implicit bootstrapping exchange through local ER | |||
Server;Figure 5shows ERP with a local ER server. | ||||
Peer EAP Authenticator Local ER Server Home EAP Server | Peer EAP Authenticator Local AAA Agent Home EAP Server | |||
/ER Authenticator /Local ER Server | ||||
==== ================= =============== =============== | ==== ================= =============== =============== | |||
<-- EAP-Request/ -- | <-- EAP-Request/ -- | |||
Identity | Identity | |||
-- EAP Response/--> | -- EAP Response/--> | |||
Identity --AAA(EAP Response/--> | Identity --AAA(EAP Response/--> | |||
Identity) --AAA(EAP Response/ --> | Identity, --AAA(EAP Response/ --> | |||
Identity, | [domain name]) Identity, | |||
[DSRK Request, | [DSRK Request, | |||
domain name]) | domain name]) | |||
<------------------------ EAP Method exchange------------------> | <------------------------ EAP Method exchange------------------> | |||
<---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 3: Local ERP Exchange, Initial EAP Exchange | Figure 4: Local 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/ --------> | |||
Re-auth Re-auth) | Re-auth Re-auth) | |||
<--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- | <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- | |||
Re-auth Re-auth) | Re-auth Re-auth) | |||
Figure 4: 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 authenticator and the | such as AAA proxies, in the path between the EAP authenticator and | |||
home EAP server of the peer). In that case, the ER server requests | the home EAP server of the peer). In that case, the local ER server | |||
the DSRK by sending the domain name to the EAP server. In response, | requests the DSRK by sending the domain name to the home EAP server | |||
the EAP server computes the DSRK by following the procedure specified | through AAA message. In response, the home EAP server computes the | |||
in [RFC5295] and sends the DSRK and the key name, EMSKname, to the ER | DSRK by following the procedure specified in [RFC5295] and sends the | |||
server in the claimed domain. The local domain is responsible for | DSRK and the key name, EMSKname, to the ER server in the claimed | |||
announcing that same domain name via the lower layer to the peer. | domain (i.e., local ER Server). The local domain is responsible for | |||
announcing that same domain name via the lower layer to the peer, | ||||
If the peer does not know the domain name (did not receive the domain | e.g., DHCP based local domain name discovery specified in | |||
name via the lower-layer announcement, due to a missed announcement | [I-D.ietf-hokey-ldn-discovery], or through the EAP-Initiate/ | |||
or lack of support for domain name announcements in a specific lower | Re-auth-Start message during subsequent ERP with local ER server. | |||
layer), it SHOULD initiate ERP bootstrap exchange with the home ER | ||||
server to obtain the domain name. The local ER server SHALL request | ||||
the home AAA server for the DSRK by sending the domain name in the | ||||
AAA message that carries the EAP-Initiate/Re-auth bootstrap message. | ||||
The local ER server MUST be in the path from the peer to the home ER | ||||
server. If it is not, it cannot request the DSRK. | ||||
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 | Subsequently, when the peer 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. | to obtain an rMSK for the new authenticator. The ERP with the local | |||
ER Server is the similar as ERP exchange described 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 12, line 25 | skipping to change at page 13, line 20 | |||
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 5: 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 according to [RFC5295]. Key | |||
derivations and field encodings, where unspecified, default to that | derivations 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. | |||
skipping to change at page 16, line 31 | skipping to change at page 17, line 25 | |||
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 implicit | |||
bootstrapping. In implicit bootstrapping, the local ER server SHOULD | bootstrapping. In implicit bootstrapping, the local AAA client or | |||
include its domain name and SHOULD request the DSRK from the home AAA | agent supporting EAP re-authentication SHOULD include its domain name | |||
server during the initial EAP exchange, in the AAA message | and SHOULD request the DSRK from the home AAA server during the | |||
encapsulating the first EAP Response message sent by the peer. If | initial EAP exchange, in the AAA message encapsulating the first EAP | |||
the EAP exchange is successful, the server sends the DSRK for the | Response message sent by the peer. If such EAP exchange is | |||
local ER server (derived using the EMSK and the domain name as | successful, the home EAP server sends the DSRK for the specified | |||
specified in [RFC5295]), EMSKname, and DSRK lifetime along with the | local AAA client or agent (derived using the EMSK and the domain name | |||
EAP-Success message. The local ER server MUST extract the DSRK, | as specified in [RFC5295]), EMSKname, and DSRK lifetime along with | |||
EMSKname, and DSRK lifetime (if present) before forwarding the EAP- | the EAP-Success message. The local AAA client or agent MUST extract | |||
Success message to the peer, as specified in [I-D.ietf-dime-erp]. | the DSRK, EMSKname, and DSRK lifetime (if present) before forwarding | |||
Note that the MSK (also present along with the EAP Success message) | the EAP-Success message to the peer, as specified in | |||
is extracted by the EAP authenticator as usual. The peer learns the | [I-D.ietf-dime-erp]. Note that the MSK (also present along with the | |||
domain name through the EAP-Initiate/Re-auth-Start message or via | EAP Success message) is extracted by the EAP authenticator as usual. | |||
lower-layer announcements. When the domain name is available to the | The peer learns the domain name through the EAP-Initiate/ | |||
peer during or after the full EAP authentication, it attempts to use | Re-auth-Start message, lower-layer announcements | |||
ERP when it associates with a new authenticator. | [I-D.ietf-hokey-ldn-discovery] or via ER Explicit bootstrapping | |||
exchange. When the domain name is available to the peer during or | ||||
after the full EAP authentication, 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 does not know the domain name (did not receive the domain | |||
name via the lower-layer announcement, due to a missed announcement | name through the EAP-Initiate/Re-auth-Start message or via the lower- | |||
or lack of support for domain name announcements in a specific lower | layer announcement, due to a missed announcement or lack of support | |||
layer), it SHOULD initiate ERP bootstrap exchange (ERP exchange with | for domain name announcements in a specific lower layer), it SHOULD | |||
the bootstrap flag turned on) with the home ER server to obtain the | initiate Explicit ER bootstrap exchange (ERP exchange with the | |||
domain name. The local ER server behavior is the same as described | bootstrap flag turned on) with the ER server in the same (visited) | |||
above. The peer MAY also initiate bootstrapping to fetch information | domain as the peer to obtain the local domain name. The peer MAY | |||
such as the rRK lifetime from the AAA server. | 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 turned on. The bootstrap message is always | |||
sent to the home AAA server, and the keyname-NAI attribute in the | sent to the 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 When an ERP-capable authenticator receives the EAP-Initiate/ | o When an ERP-capable authenticator receives the EAP-Initiate/ | |||
Re-auth message from a peer, it copies the contents of the | Re-auth message from a peer, it copies the contents of the | |||
keyName-NAI into the User-Name attribute of RADIUS [RFC2865]. The | keyName-NAI into the User-Name attribute of RADIUS [RFC2865]. The | |||
rest of the process is similar to that described in [RFC3579]. | rest of the process is similar to that described in [RFC3579]. | |||
o If a local ER server is present, 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 server | o Upon receipt of an EAP-Initiate/Re-auth message, the server | |||
verifies whether the message is fresh or is a replay by evaluating | verifies whether the message is fresh or is a replay by evaluating | |||
whether the received sequence number is equal to or greater than | whether the received sequence number is equal to or greater than | |||
the expected sequence number for that rIK. The server then | the expected sequence number for that rIK. The server then | |||
verifies to ensure that the cryptosuite used by the peer is | verifies to ensure that the cryptosuite used by the peer is | |||
acceptable. Next, it verifies the origin authentication of the | acceptable. Next, it verifies the origin authentication of the | |||
message by looking up the rIK. If any of the checks fail, the | message by looking up the rIK. If any of the checks fail, the | |||
server sends an EAP-Finish/Re-auth message with the Result flag | server sends an EAP-Finish/Re-auth message with the Result flag | |||
set to '1'. Please refer to Section 5.2.2 for details on failure | set to '1'. Please refer to Section 5.2.2 for details on failure | |||
handling. This error MUST NOT have any correlation to any EAP- | handling. This error MUST NOT have any correlation to any EAP- | |||
skipping to change at page 18, line 16 | skipping to change at page 19, line 12 | |||
* The same keyName-NAI as in the EAP-Initiate/Re-auth message. | * The same keyName-NAI as in the EAP-Initiate/Re-auth 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 in the EAP-Finish/Re-auth message. The server | rMSK lifetime in the EAP-Finish/Re-auth message. The server | |||
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 and a DSRK request is received, | * If the bootstrap flag is set, the ER server MUST include the | |||
the server MUST include the domain name to which the DSRK is | domain name to which the DSRK is being sent along with the EAP- | |||
being sent. | Finish/Re-auth message. | |||
* If the home ER server verifies the authorization of a local | * If the ER server verifies the authorization of a local domain | |||
domain server, it MAY include the Authorization Indication TLV | server, it MAY include the Authorization Indication TLV to | |||
to indicate to the peer that the server (that received the DSRK | indicate to the peer that the server (that received the DSRK | |||
and that is advertising the domain included in the domain name | and that is advertising the domain included in the domain name | |||
TLV) is authorized. | TLV) 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 ERP exchange is successful, and the local ER server sent a | o If the ERP exchange is successful, the ER server SHOULD request | |||
DSRK request, the home ER server MUST include the DSRK for the | the DSRK from the home EAP server during the initial EAP exchange | |||
local ER server (derived using the EMSK and the domain name as | as specified in [I-D.ietf-dime-local-keytran], the home EAP server | |||
specified in [RFC5295]), EMSKname, and DSRK lifetime along with | MUST include the DSRK for the local ER server (derived using the | |||
the EAP-Finish/Re-auth message. | EMSK and the domain name as specified in [RFC5295]), EMSKname, and | |||
DSRK lifetime along with 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 [I-D.ietf-dime-erp]. | |||
o The local ER server MUST extract the DSRK, EMSKname, and DSRK | o The ER server MUST extract the DSRK, EMSKname, and DSRK lifetime | |||
lifetime (if present), before forwarding the EAP-Finish/Re-auth | (if present) before forwarding the EAP-Success message to the | |||
message to the peer, as specified in [I-D.ietf-dime-erp]. | 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, | |||
skipping to change at page 23, line 22 | skipping to change at page 24, line 22 | |||
packet format defined in RFC 3748 [RFC3748]. | packet format defined in RFC 3748 [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 6: EAP Packet | Figure 7: EAP Packet | |||
Code | Code | |||
5 Initiate | 5 Initiate | |||
6 Finish | 6 Finish | |||
Two new code values are defined for the purpose of ERP. | Two new code values are defined for the purpose of ERP. | |||
Identifier | Identifier | |||
skipping to change at page 24, line 19 | skipping to change at page 25, line 19 | |||
auth-Start (assigned Type 1) and Re-auth (assigned Type 2). | auth-Start (assigned Type 1) and Re-auth (assigned 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 parameters shown | |||
in Figure 7. | in 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 7: EAP-Initiate/Re-auth-Start Packet | Figure 8: EAP-Initiate/Re-auth-Start Packet | |||
Type = 1. | Type = 1. | |||
Reserved, MUST be zero. Set to zero on transmission and ignored | Reserved, MUST be zero. Set to zero on transmission and ignored | |||
on reception. | on reception. | |||
One or more TVs or TLVs are used to convey information to the | One or more TVs or TLVs are used to convey information to the | |||
peer; for instance, the authenticator may send the domain name to | peer; for instance, the authenticator may send the domain name to | |||
the peer. | the peer. | |||
skipping to change at page 25, line 6 | skipping to change at page 26, line 6 | |||
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 attribute 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 11 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 | |||
The authenticator MAY send the EAP-Initiate/Re-auth-Start message to | The authenticator MAY send the EAP-Initiate/Re-auth-Start message to | |||
indicate support for ERP to the peer and to initiate ERP if the peer | indicate support for ERP to the peer and to initiate ERP if the peer | |||
has already performed full EAP authentication and has unexpired key | has already performed full EAP authentication and has unexpired key | |||
material. The authenticator SHOULD include the domain name TLV to | material. The authenticator SHOULD include the domain name TLV to | |||
allow the peer to learn it without lower-layer support or the ERP | allow the peer to learn it without lower-layer support or the ERP | |||
bootstrapping exchange. | bootstrapping exchange. | |||
skipping to change at page 25, line 39 | skipping to change at page 26, line 39 | |||
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 Initiate code value, it silently | |||
discards the message. If the peer has already sent the EAP-Initiate/ | discards the message. If the peer has already sent the EAP-Initiate/ | |||
Re-auth message to begin the ERP exchange, it silently discards the | Re-auth message to begin the ERP exchange, it silently discards the | |||
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 to compute the DSRK and use the | |||
corresponding DS-rIK to send an EAP-Initiate/Re-auth message to start | corresponding DS-rIK to send an EAP-Initiate/Re-auth message to start | |||
an ERP exchange with the local ER server. If the peer has already | an ERP exchange with the local ER server. If there are the local ER | |||
initiated an ERP exchange with the home ER server, it MAY choose to | server between the peer and the home ER server and the peer has | |||
not start an ERP exchange with the local ER server. | already initiated an ERP exchange with the local ER server, it SHOULD | |||
choose to 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 8. | 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 ~ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 8: EAP-Initiate/Re-auth Packet | Figure 9: EAP-Initiate/Re-auth Packet | |||
Type = 2. | Type = 2. | |||
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. | |||
skipping to change at page 27, line 7 | skipping to change at page 28, line 7 | |||
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 128 octets. If the rIK is | the username portion takes up 128 octets. If the rIK is | |||
derived from the EMSK, the realm part of the NAI is the home | derived 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 | domain 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 | part of the NAI is the domain name used in the derivation of | |||
the DSRK. The NAI syntax follows [RFC4282]. Exactly one | the DSRK. The NAI syntax follows [RFC4282]. Exactly one | |||
keyName-NAI attribute SHALL be present in an EAP-Initiate/ | keyName-NAI attribute SHALL be present in an EAP-Initiate/ | |||
Re-auth packet. | 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 11 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: | |||
* 0 RESERVED | * 0 RESERVED | |||
* 1 HMAC-SHA256-64 | * 1 HMAC-SHA256-64 | |||
skipping to change at page 27, line 33 | skipping to change at page 28, line 33 | |||
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 9. | 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 ~ | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 9: 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. | |||
skipping to change at page 29, line 13 | skipping to change at page 30, line 13 | |||
attribute SHOULD be present. | 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 8. | octet. The cryptosuite values are as specified in Figure 9. | |||
The server SHOULD include this attribute if the cryptosuite | The server SHOULD include this attribute if the cryptosuite | |||
used in the EAP-Initiate/Re-auth message was not acceptable and | used in the EAP-Initiate/Re-auth message was not acceptable and | |||
the message is being rejected. The server MAY include this | the message is being rejected. The server MAY include this | |||
attribute in other cases. The server MAY use this attribute to | attribute in other cases. The server MAY use this attribute to | |||
signal to the peer about its cryptographic algorithm | signal to the peer about its cryptographic algorithm | |||
capabilities. | capabilities. | |||
Authorization Indication: This is a TLV payload. The Type is | Authorization Indication: This is a TLV payload. The Type is | |||
6. This attribute MAY be included in the EAP-Finish/Re-auth | 6. This attribute MAY be included in the EAP-Finish/Re-auth | |||
message when a DSRK is delivered to a local ER server and if | message when a DSRK is delivered to a local ER server and if | |||
the home ER server can verify the authorization of the local ER | the home EAP server can verify the authorization of the local | |||
server to advertise the domain name included in the domain TLV | ER server to advertise the domain name included in the domain | |||
in the same message. The value field in the TLV contains an | TLV in the same message. The value field in the TLV contains | |||
authentication tag computed over the entire packet, starting | an authentication tag computed over the entire packet, starting | |||
from the first bit of the code field to the last bit of the | from the first bit of the code field to the last bit of the | |||
cryptosuite field, with the value field of the Authorization | cryptosuite field, with the value field of the Authorization | |||
Indication TLV filled with all 0s for the computation. The key | Indication TLV filled with all 0s for the computation. The key | |||
used for the computation MUST be derived from the EMSK with key | used for the computation MUST be derived from the EMSK with key | |||
label "DSRK Delivery Authorized Key@ietf.org" and optional data | label "DSRK Delivery Authorized Key@ietf.org" and optional data | |||
containing an ASCII string representing the key management | containing an ASCII string representing the key management | |||
domain that the DSRK is being derived for. | domain that the DSRK is being derived for. | |||
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 11 for parameter | Section 5.5 for discussion. See Figure 12 for parameter | |||
specification. The server sends this information so that the | specification. The server sends this information so that the | |||
peer can verify the information seen at the lower layer, if | peer can verify the information seen at the lower layer, if | |||
channel binding is to be supported. | channel binding is to be supported. | |||
Cryptosuite: This field indicates the integrity algorithm and the | Cryptosuite: This field indicates the integrity algorithm and the | |||
PRF used for ERP. Key lengths and output lengths are either | PRF used for ERP. Key lengths and output lengths are either | |||
indicated or are obvious from the cryptosuite name. | indicated or are obvious from the cryptosuite name. | |||
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 | |||
skipping to change at page 30, line 16 | skipping to change at page 31, line 16 | |||
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 10: 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 11: 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. | |||
'2' - rRK Lifetime: This is a TV payload. | '2' - rRK Lifetime: This is a TV payload. | |||
'3' - rMSK Lifetime: This is a TV payload. | '3' - rMSK Lifetime: This is a TV payload. | |||
'4' - domain name: This is a TLV payload. | '4' - domain name: This is a TLV payload. | |||
skipping to change at page 35, line 48 | skipping to change at page 36, line 48 | |||
keys derived from it. Moreover, there is no forward secrecy | keys derived from it. Moreover, there is no forward secrecy | |||
within ERP. Thus, compromise of an DSRK retroactively | within ERP. Thus, compromise of an DSRK retroactively | |||
compromises all ERP keys. | compromises all ERP keys. | |||
It is RECOMMENDED that the AAA protocol be protected using | It is RECOMMENDED that the AAA protocol be protected using | |||
IPsec or TLS so that the keys are protected in transit. Note, | IPsec or TLS so that the keys are protected in transit. Note, | |||
however, that keys may be exposed to AAA proxies along the way | however, that keys may be exposed to AAA proxies along the way | |||
and compromise of any of those proxies may result in compromise | and compromise of any of those proxies may result in compromise | |||
of keys being transported through them. | of keys being transported through them. | |||
The home ER server MUST NOT hand out a given DSRK to a local | The home EAP server MUST NOT hand out a given DSRK to a local | |||
domain server more than once, unless it can verify that the | domain server more than once, unless it can verify that the | |||
entity receiving the DSRK after the first time is the same as | entity receiving the DSRK after the first time is the same as | |||
that received the DSRK originally. If the home ER server | that received the DSRK originally. If the home EAP server | |||
verifies authorization of a local domain server, it MAY hand | verifies authorization of a local domain server, it MAY hand | |||
out the DSRK to that domain more than once. In this case, the | out the DSRK to that domain more than once. In this case, the | |||
home ER server includes the Authorization Indication TLV to | home EAP server includes the Authorization Indication TLV to | |||
assure the peer that DSRK delivery is secure. | assure the peer that DSRK delivery is secure. | |||
Confirm cryptosuite selection | Confirm cryptosuite selection | |||
Crypto algorithms for integrity and key derivation in the | Crypto algorithms for integrity and key derivation in the | |||
context of ERP MAY be the same as that used by the EAP method. | context of ERP MAY be the same as that used by the EAP method. | |||
In that case, the EAP method is responsible for confirming the | In that case, the EAP method is responsible for confirming the | |||
cryptosuite selection. Furthermore, the cryptosuite is | cryptosuite selection. Furthermore, the cryptosuite is | |||
included in the ERP exchange by the peer and confirmed by the | included in the ERP exchange by the peer and confirmed by the | |||
server. The protocol allows the server to reject the | server. The protocol allows the server to reject the | |||
skipping to change at page 37, line 51 | skipping to change at page 38, line 51 | |||
To prevent such DoS attacks, an ERP failure should not result in | To prevent such DoS attacks, an ERP failure should not result in | |||
deletion of any authorization state established by a full EAP | deletion of any authorization state established by a full EAP | |||
exchange. Alternatively, the lower layers and AAA protocols may | exchange. Alternatively, the lower layers and AAA protocols may | |||
define mechanisms to allow two link-layer security associations (SAs) | define mechanisms to allow two link-layer security associations (SAs) | |||
derived from different EAP keying materials for the same peer to | derived from different EAP keying materials for the same peer to | |||
exist so that smooth migration from the current link layer SA to the | exist so that smooth migration from the current link layer SA to the | |||
new one is possible during rekey. These mechanisms prevent the link | new one is possible during rekey. These mechanisms prevent the link | |||
layer connections from being terminated when a re-authentication | layer connections from being terminated when a re-authentication | |||
procedure fails due to the bogus EAP-Initiate/Re-auth message. | procedure fails due to the bogus EAP-Initiate/Re-auth message. | |||
When a DSRK is sent from a home ER server to a local domain server or | When a DSRK is sent from a home EAP server to a local domain server | |||
when a rMSK is sent from an ER server to an authenticator, in the | or when a rMSK is sent from an ER server to an authenticator, in the | |||
absence of end-to-end security between the entity that is sending the | absence of end-to-end security between the entity that is sending the | |||
key and the entity receiving the key, it is plausible for other | key and the entity receiving the key, it is plausible for other | |||
entities to get access to keys being sent to an ER server in another | entities to get access to keys being sent to an ER server in another | |||
domain. This mode of key transport is similar to that of MSK | domain. This mode of key transport is similar to that of MSK | |||
transport in the context of EAP authentication. We further observe | transport in the context of EAP authentication. We further observe | |||
that ERP is for access authentication and does not support end-to-end | that ERP is for access authentication and does not support end-to-end | |||
data security. In typical implementations, the traffic is in the | data security. In typical implementations, the traffic is in the | |||
clear beyond the access control enforcement point (the authenticator | clear beyond the access control enforcement point (the authenticator | |||
or an entity delegated by the authenticator for access control | or an entity delegated by the authenticator for access control | |||
enforcement). The model works as long as entities in the middle of | enforcement). The model works as long as entities in the middle of | |||
skipping to change at page 39, line 12 | skipping to change at page 40, line 12 | |||
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., Wu, W., and G. Zorn, "Diameter | Bournelle, J., Morand, L., Wu, W., and G. Zorn, "Diameter | |||
Support for the EAP Re-authentication Protocol (ERP)", | Support for the EAP Re-authentication Protocol (ERP)", | |||
draft-ietf-dime-erp-04 (work in progress), September 2010. | draft-ietf-dime-erp-04 (work in progress), September 2010. | |||
[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] | ||||
Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name | ||||
DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in | ||||
progress), September 2010. | ||||
[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", | |||
skipping to change at page 40, line 35 | 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 | |||
TBC | Glen Zorn wrote the initial draft for this document and provided | |||
useful reviews. Many thanks to him. | ||||
Appendix B. Example ERP Exchange | Appendix B. Example ERP Exchange | |||
0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start] | 0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start] | |||
1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI, | 1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI, | |||
cryptosuite,Auth-tag*) | cryptosuite,Auth-tag*) | |||
1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id, | 1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id, | |||
EAP Initiate/Re-auth(SEQ,keyName-NAI, | EAP Initiate/Re-auth(SEQ,keyName-NAI, | |||
cryptosuite,Auth-tag*) | cryptosuite,Auth-tag*) | |||
2. ER-Server --> Authenticator: AAA-Response{rMSK, | 2. ER-Server --> Authenticator: AAA-Response{rMSK, | |||
skipping to change at page 41, line 26 | skipping to change at page 42, line 29 | |||
2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI, | 2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI, | |||
cryptosuite,[CB-Info],Auth-tag*) | 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 | |||
Glen Zorn (editor) | Qin Wu (editor) | |||
Network Zen | ||||
1463 East Republican Street | ||||
#358 | ||||
Seattle, Washington 98112 | ||||
US | ||||
Email: gwz@net-zen.net | ||||
Qin Wu | ||||
Huawei Technologies Co., Ltd. | Huawei Technologies Co., Ltd. | |||
101 Software Avenue, Yuhua District | 101 Software Avenue, Yuhua District | |||
Nanjing, JiangSu 210012 | Nanjing, JiangSu 210012 | |||
China | China | |||
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 | |||
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. 54 change blocks. | ||||
171 lines changed or deleted | 211 lines changed or added | |||
This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |