draft-ietf-hokey-rfc5296bis-01.txt | draft-ietf-hokey-rfc5296bis-02.txt | |||
---|---|---|---|---|
Network Working Group Q. Wu, Ed. | Network Working Group Q. Wu, Ed. | |||
Internet-Draft Huawei | Internet-Draft Huawei | |||
Obsoletes: 5296 (if approved) Z. Cao | Obsoletes: 5296 (if approved) Z. Cao | |||
Intended status: Standards Track China Mobile | Intended status: Standards Track China Mobile | |||
Expires: April 23, 2011 Y. Shi | Expires: September 15, 2011 Y. Shi | |||
H3C | H3C | |||
B. He | B. He | |||
CATR | CATR | |||
October 20, 2010 | March 14, 2011 | |||
EAP Extensions for EAP Re-authentication Protocol (ERP) | EAP Extensions for EAP Re-authentication Protocol (ERP) | |||
draft-ietf-hokey-rfc5296bis-01 | draft-ietf-hokey-rfc5296bis-02 | |||
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 43 | 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 April 23, 2011. | This Internet-Draft will expire on September 15, 2011. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 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 | |||
skipping to change at page 3, line 23 | skipping to change at page 3, line 23 | |||
4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 | 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 | |||
4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 14 | 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 14 | |||
4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 14 | 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 14 | |||
4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 15 | 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 15 | |||
4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 15 | 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16 | 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16 | |||
4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 | 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 | |||
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17 | 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17 | |||
5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17 | 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17 | |||
5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20 | 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 22 | 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 23 | |||
5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 23 | 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 23 | |||
5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 24 | 5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 24 | |||
5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 25 | 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 25 | |||
5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 26 | 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 26 | |||
5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 26 | 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 26 | |||
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 . . . . . . . . . . . . . . 28 | |||
5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31 | 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31 | |||
5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32 | 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32 | |||
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32 | 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 33 | |||
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33 | 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33 | |||
7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 34 | 7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 35 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . . 39 | 10.1. draft-ietf-hokey-rfc5296bis-02 . . . . . . . . . . . . . . 39 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . . 40 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 41 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 40 | |||
A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 41 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 40 | |||
A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 41 | Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 42 | |||
A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 42 | ||||
A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 42 | ||||
Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 42 | Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 42 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 | |||
1. Introduction | 1. Introduction | |||
The Extensible Authentication Protocol (EAP) is a an authentication | The Extensible Authentication Protocol (EAP) is a an authentication | |||
framework that supports multiple authentication methods. The primary | framework that supports multiple authentication methods. The primary | |||
purpose is network access authentication, and a key-generating method | purpose is network access authentication, and a key-generating method | |||
is used when the lower layer wants to enforce access control. The | is used when the lower layer wants to enforce access control. The | |||
EAP keying hierarchy defines two keys to be derived by all key- | EAP keying hierarchy defines two keys to be derived by all key- | |||
generating EAP methods: the Master Session Key (MSK) and the Extended | generating EAP methods: the Master Session Key (MSK) and the Extended | |||
MSK (EMSK). In the most common deployment scenario, an EAP peer and | MSK (EMSK). In the most common deployment scenario, an EAP peer and | |||
skipping to change at page 5, line 8 | skipping to change at page 5, line 8 | |||
efficient re-authentication using EAP. The protocol that uses these | efficient re-authentication using EAP. The protocol that uses these | |||
extensions is itself referred to as the EAP Re-authentication | extensions is itself referred to as the EAP Re-authentication | |||
Protocol (ERP). It supports EAP method-independent re-authentication | Protocol (ERP). It supports EAP method-independent re-authentication | |||
for a peer that has valid, unexpired key material from a previously | for a peer that has valid, unexpired key material from a previously | |||
performed EAP authentication. The protocol and the key hierarchy | performed EAP authentication. The protocol and the key hierarchy | |||
required for EAP re-authentication are described in this document. | required for EAP re-authentication are described in this document. | |||
Note that to support ERP, lower-layer specifications may need to be | Note that to support ERP, lower-layer specifications may need to be | |||
revised to allow carrying EAP messages that have a code value higher | revised to allow carrying EAP messages that have a code value higher | |||
than 4 and to accommodate the peer-initiated nature of ERP. | than 4 and to accommodate the peer-initiated nature of ERP. | |||
Specifically, the IEEE802.1x specification must be revised and RFC | Specifically, the IEEE802.1x specification [IEEE_802.1X] must be | |||
4306 must be updated to carry ERP messages. | revised and RFC 5996 [RFC5996] must be updated to carry ERP messages. | |||
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 26 | skipping to change at page 7, line 26 | |||
<----AAA(MSK, EAP-Success)------ | <----AAA(MSK, EAP-Success)------ | |||
<---EAP-Success--------- | <---EAP-Success--------- | |||
Figure 1: EAP Authentication | Figure 1: EAP Authentication | |||
Peer ER Authenticator ER 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]) | |||
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- | <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- | |||
Re-auth/ Re-auth/ | Re-auth/ Re-auth/ | |||
[Bootstrap] [Bootstrap]) | [Bootstrap] [Bootstrap]) | |||
skipping to change at page 10, line 11 | skipping to change at page 10, line 11 | |||
with the home ER server to obtain the domain name. | with the home ER server to obtain the domain name. | |||
The defined ER extensions allow executing the ERP with an ER server | The defined ER extensions allow executing the ERP with an ER server | |||
in the home domain. The home ER server may be co- located with a | in the home domain. The home ER server may be co- located with a | |||
home AAA server. The ERP with the Home ER Server is the similar as | home AAA server. The ERP with the Home ER Server is the similar as | |||
ERP exchange described in Figure 2. | ERP exchange described in Figure 2. | |||
Peer ER Authenticator Home ER Server | Peer ER Authenticator Home ER Server | |||
==== ============= ====== | ==== ============= ====== | |||
[<-- EAP-Initiate/ ----- | <-- EAP-Initiate/ ----- | |||
Re-auth-Start] | Re-auth-Start | |||
[<-- EAP-Request/ ------ | [<-- EAP-Request/ ------ | |||
Identity] | Identity] | |||
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> | ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> | |||
Re-auth/ Re-auth/ | Re-auth/ Re-auth/ | |||
[Bootstrap] [Bootstrap]) | [Bootstrap] [Bootstrap]) | |||
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- | <--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/--------- | |||
Re-auth/ Re-auth/ | Re-auth/ Re-auth/ | |||
[Bootstrap] [Bootstrap]) | [Bootstrap] [Bootstrap]) | |||
skipping to change at page 11, line 35 | skipping to change at page 11, line 35 | |||
<--- AAA(MSK, ----- | <--- AAA(MSK, ----- | |||
EAP-Success) | EAP-Success) | |||
<---EAP-Success----- | <---EAP-Success----- | |||
Figure 4: 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 5: Local ERP Exchange | Figure 5: Local ERP Exchange | |||
skipping to change at page 17, line 25 | 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 AAA client or | bootstrapping. In implicit bootstrapping, if the local AAA client or | |||
agent supporting EAP re-authentication SHOULD include its domain name | Agent do not have the keying material(e.g., rMSK or rRK) | |||
and SHOULD request the DSRK from the home AAA server during the | corresponding to the peer, the local AAA client or agent supporting | |||
initial EAP exchange, in the AAA message encapsulating the first EAP | EAP re-authentication SHOULD include its domain name and SHOULD | |||
Response message sent by the peer. If such EAP exchange is | request the DSRK from the home AAA server during the initial EAP | |||
successful, the home EAP server sends the DSRK for the specified | exchange, in the AAA message encapsulating the first EAP Response | |||
local AAA client or agent (derived using the EMSK and the domain name | message sent by the peer. If such EAP exchange is successful, the | |||
as specified in [RFC5295]), EMSKname, and DSRK lifetime along with | home EAP server sends the DSRK for the specified local AAA client or | |||
the EAP-Success message. The local AAA client or agent MUST extract | agent (derived using the EMSK and the domain name as specified in | |||
the DSRK, EMSKname, and DSRK lifetime (if present) before forwarding | [RFC5295]), EMSKname, and DSRK lifetime along with the EAP-Success | |||
the EAP-Success message to the peer, as specified in | message. The local AAA client or agent MUST extract the DSRK, | |||
[I-D.ietf-dime-erp]. Note that the MSK (also present along with the | EMSKname, and DSRK lifetime (if present) before forwarding the EAP- | |||
EAP Success message) is extracted by the EAP authenticator as usual. | Success message to the peer, as specified in [I-D.ietf-dime-erp]. | |||
The peer learns the domain name through the EAP-Initiate/ | Note that the MSK (also present along with the EAP Success message) | |||
Re-auth-Start message, lower-layer announcements | is extracted by the EAP authenticator as usual. The peer learns the | |||
[I-D.ietf-hokey-ldn-discovery] or via ER Explicit bootstrapping | domain name through the EAP-Initiate/Re-auth-Start message, lower- | |||
exchange. When the domain name is available to the peer during or | layer announcements [I-D.ietf-hokey-ldn-discovery] . When the domain | |||
after the full EAP authentication, it attempts to use ERP when it | name is available to the peer during or after the full EAP | |||
associates with a new authenticator. | 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 through the EAP-Initiate/Re-auth-Start message or via the lower- | name through the EAP-Initiate/Re-auth-Start message or via the lower- | |||
layer announcement, due to a missed announcement or lack of support | layer announcement, due to a missed announcement or lack of support | |||
for domain name announcements in a specific lower layer), it SHOULD | for domain name announcements in a specific lower layer), it SHOULD | |||
initiate Explicit ER bootstrap exchange (ERP exchange with the | initiate Explicit ERP bootstrapping (ERP exchange with the bootstrap | |||
bootstrap flag turned on) with the ER server in the same (visited) | flag turned on) with the ER server to obtain the local domain name. | |||
domain as the peer to obtain the local domain name. The peer MAY | ||||
also initiate bootstrapping to fetch information such as the rRK | ||||
lifetime from the AAA server. | ||||
The following steps describe the ERP explicit bootstrapping process: | The peer MAY also initiate bootstrapping to fetch information such as | |||
the rRK lifetime from the AAA server. | ||||
The following steps describe the ERP Explicit Bootstrapping process: | ||||
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 ER 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] and | |||
rest of the process is similar to that described in [RFC3579]. | may include its domain name in the AAA message encapsulating the | |||
EAP-Initiate/Re-auth message sent by the peer. The rest of the | ||||
process is similar to that described in [RFC3579]. | ||||
o Upon receipt of an EAP-Initiate/Re-auth message, the server | o If a local ER server is present, the local ER server MUST verify | |||
verifies whether the message is fresh or is a replay by evaluating | whether it has DSRK corresponding to the peer. If the local ER | |||
whether the received sequence number is equal to or greater than | server has the key materials corresponding to the peer, it MUST be | |||
the expected sequence number for that rIK. The server then | able to respond directly in the same way as the home ER server | |||
verifies to ensure that the cryptosuite used by the peer is | does described in the following step without forwarding the ERP | |||
acceptable. Next, it verifies the origin authentication of the | message to the home domain, even if this message contains the 'B' | |||
message by looking up the rIK. If any of the checks fail, the | (bootstrapping) flag. Otherwise, the local ER server MUST include | |||
server sends an EAP-Finish/Re-auth message with the Result flag | the DSRK request and its domain name in the AAA message | |||
set to '1'. Please refer to Section 5.2.2 for details on failure | encapsulating the EAP-Initiate/Re-auth message sent by the peer. | |||
handling. This error MUST NOT have any correlation to any EAP- | ||||
Success message that may have been received by the EAP | o Upon receipt of an EAP-Initiate/Re-auth message, the home ER | |||
server verifies whether the message is fresh or is a replay by | ||||
evaluating whether the received sequence number is equal to or | ||||
greater than the expected sequence number for that rIK. The home | ||||
ER server then verifies to ensure that the cryptosuite used by the | ||||
peer is acceptable. Next, it verifies the origin authentication | ||||
of the message by looking up the rIK. If any of the checks fail, | ||||
the home ER 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 handling. This error MUST NOT have any correlation to | ||||
any EAP-Success message that may have been received by the EAP | ||||
authenticator and the peer earlier. If the EAP-Initiate/Re-auth | authenticator and the peer earlier. If the EAP-Initiate/Re-auth | |||
message is well-formed and valid, the server prepares the EAP- | message is well-formed and valid, the server prepares the EAP- | |||
Finish/Re-auth message. The bootstrap flag MUST be set to | Finish/Re-auth message. The bootstrap flag MUST be set to | |||
indicate that this is a bootstrapping exchange. The message | indicate that this is a bootstrapping exchange. The message | |||
contains the following fields: | contains the following fields: | |||
* A sequence number for replay protection. | * A sequence number for replay protection. | |||
* The same keyName-NAI as in the EAP-Initiate/Re-auth message. | * The same keyName-NAI as in the EAP-Initiate/Re-auth message. | |||
skipping to change at page 19, line 16 | skipping to change at page 19, line 26 | |||
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, the ER server MUST include the | * If the bootstrap flag is set, the ER server MUST include the | |||
domain name to which the DSRK is being sent along with the EAP- | domain name to which the DSRK is being sent along with the EAP- | |||
Finish/Re-auth message. | Finish/Re-auth message. | |||
* If the ER server verifies the authorization of a local domain | * If the ER server verifies the authorization of a local ER | |||
server, it MAY include the Authorization Indication TLV to | server, it MAY include the Authorization Indication TLV to | |||
indicate to the peer that the server (that received the DSRK | indicate to the peer that the server (that received the DSRK | |||
and 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, the ER server SHOULD request | o If the home ER server gets involved in ERP exchange and the ERP | |||
the DSRK from the home EAP server during the initial EAP exchange | exchange is successful, the home ER server SHOULD request the DSRK | |||
as specified in [I-D.ietf-dime-local-keytran], the home EAP server | from the home EAP server during this ERP Explicit Bootstrapping as | |||
specified in [I-D.ietf-dime-local-keytran], the home EAP server | ||||
MUST include the DSRK for the local ER server (derived using the | MUST include the DSRK for the local ER server (derived using the | |||
EMSK and the domain name as specified in [RFC5295]), EMSKname, and | EMSK and the domain name as specified in [RFC5295]), EMSKname, and | |||
DSRK lifetime along with the EAP-Finish/Re-auth message. | 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 ER server MUST extract the DSRK, EMSKname, and DSRK lifetime | o The local ER server MUST extract the DSRK, EMSKname, and DSRK | |||
(if present) before forwarding the EAP-Success message to the | lifetime (if present) before forwarding the EAP-Success message to | |||
peer, as specified in [I-D.ietf-dime-erp]. | the peer, as specified in [I-D.ietf-dime-erp]. | |||
o The authenticator receives the rMSK. | o The authenticator receives the rMSK. | |||
o When the peer receives an EAP-Finish/Re-auth message with the | o When the peer receives an EAP-Finish/Re-auth message with the | |||
bootstrap flag set, if a local domain name is present, it MUST use | bootstrap flag set, if a local domain name is present, it MUST use | |||
that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName- | that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName- | |||
NAI, and initialize the replay counter for the DS-rIK. If not, | NAI, and initialize the replay counter for the DS-rIK. If not, | |||
the peer SHOULD derive the domain-specific keys using the domain | the peer SHOULD derive the domain-specific keys using the domain | |||
name it learned via the lower layer or from the EAP-Initiate/ | name it learned via the lower layer or from the EAP-Initiate/ | |||
Re-auth-Start message. If the peer does not know the domain name, | Re-auth-Start message. If the peer does not know the domain name, | |||
skipping to change at page 21, line 7 | skipping to change at page 21, line 20 | |||
Operational Considerations at the Peer: | Operational Considerations at the Peer: | |||
ERP requires that the peer maintain retransmission timers for | ERP requires that the peer maintain retransmission timers for | |||
reliable transport of EAP re-authentication messages. The | reliable transport of EAP re-authentication messages. The | |||
reliability considerations of Section 4.3 of RFC 3748 apply with the | reliability considerations of Section 4.3 of RFC 3748 apply with the | |||
peer as the retransmitting entity. | peer as the retransmitting entity. | |||
The EAP Re-auth Protocol has the following steps: | The EAP Re-auth Protocol has the following steps: | |||
The ERP-capable authenticator sends the EAP-Initiate/Re-auth-Start | ||||
message to trigger the ERP exchange. | ||||
The peer sends an EAP-Initiate/Re-auth message. At a minimum, the | The peer sends an EAP-Initiate/Re-auth message. At a minimum, the | |||
message SHALL include the following fields: | message SHALL include the following fields: | |||
a 16-bit sequence number for replay protection | a 16-bit sequence number for replay protection | |||
keyName-NAI as a TLV attribute to identify the rIK used to | keyName-NAI as a TLV attribute to identify the rIK used to | |||
integrity protect the message. | integrity protect the message. | |||
cryptosuite to indicate the authentication algorithm used to | cryptosuite to indicate the authentication algorithm used to | |||
compute the integrity checksum. | compute the integrity checksum. | |||
skipping to change at page 26, line 11 | skipping to change at page 26, line 26 | |||
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 12 for parameter | Section 5.5 for discussion. See Figure 12 for parameter | |||
specification. | specification. | |||
5.3.1.1. Authenticator Operation | 5.3.1.1. Authenticator Operation | |||
The authenticator MAY send the EAP-Initiate/Re-auth-Start message to | The authenticator SHOULD send the EAP-Initiate/Re-auth-Start message | |||
indicate support for ERP to the peer and to initiate ERP if the peer | to indicate support for ERP to the peer and to initiate ERP if the | |||
has already performed full EAP authentication and has unexpired key | peer has already performed full EAP authentication and has unexpired | |||
material. The authenticator SHOULD include the domain name TLV to | key material. The authenticator SHOULD include the domain name TLV | |||
allow the peer to learn it without lower-layer support or the ERP | to allow the peer to learn it without lower-layer support or the ERP | |||
bootstrapping exchange. | bootstrapping exchange. | |||
The authenticator MAY include channel binding information so that the | The authenticator MAY include channel binding information so that the | |||
peer can send the information to the server in the EAP-Initiate/ | peer can send the information to the server in the EAP-Initiate/ | |||
Re-auth message so that the server can verify whether the | Re-auth message so that the server can verify whether the | |||
authenticator is claiming the same identity to both parties. | authenticator is claiming the same identity to both parties. | |||
The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start | The authenticator MAY re-transmit the EAP-Initiate/Re-auth-Start | |||
message a few times for reliable transport. | message a few times for reliable transport. | |||
skipping to change at page 34, line 18 | skipping to change at page 34, line 32 | |||
matter; this specification recommends a value of 100 milliseconds. | matter; this specification recommends a value of 100 milliseconds. | |||
The lower layer may provide facilities for exchanging information | The lower layer may provide facilities for exchanging information | |||
between the peer and the authenticator about support for ERP, for the | between the peer and the authenticator about support for ERP, for the | |||
authenticator to send the domain name information and channel binding | authenticator to send the domain name information and channel binding | |||
information to the peer | information to the peer | |||
Note that to support ERP, lower-layer specifications may need to be | Note that to support ERP, lower-layer specifications may need to be | |||
revised. Specifically, the IEEE802.1x specification must be revised | revised. Specifically, the IEEE802.1x specification must be revised | |||
to allow carrying EAP messages of the new codes defined in this | to allow carrying EAP messages of the new codes defined in this | |||
document in order to support ERP. Similarly, RFC 4306 must be | document in order to support ERP. Similarly, RFC 5996 must be | |||
updated to include EAP code values higher than 4 in order to use ERP | updated to include EAP code values higher than 4 in order to use ERP | |||
with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may | with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may | |||
also be updated to support peer-initiated ERP for optimized | also be updated to support peer-initiated ERP for optimized | |||
operation. Other lower layers may need similar revisions. | operation. Other lower layers may need similar revisions. | |||
Our analysis indicates that some EAP implementations are not RFC 3748 | Our analysis indicates that some EAP implementations are not RFC 3748 | |||
compliant in that instead of silently dropping EAP packets with code | compliant in that instead of silently dropping EAP packets with code | |||
values higher than 4, they may consider it an error. To accommodate | values higher than 4, they may consider it an error. To accommodate | |||
such non-compliant EAP implementations, additional guidance has been | such non-compliant EAP implementations, additional guidance has been | |||
provided below. Furthermore, it may not be easy to upgrade all the | provided below. Furthermore, it may not be easy to upgrade all the | |||
skipping to change at page 39, line 24 | skipping to change at page 39, line 38 | |||
enforcement). The model works as long as entities in the middle of | enforcement). The model works as long as entities in the middle of | |||
the network do not use keys intended for other parties to steal | the network do not use keys intended for other parties to steal | |||
service from an access network. If that is not achievable, key | service from an access network. If that is not achievable, key | |||
delivery must be protected in an end-to-end manner. | delivery must be protected in an end-to-end manner. | |||
9. IANA Considerations | 9. IANA Considerations | |||
This document has no IANA actions; all values referenced in this | This document has no IANA actions; all values referenced in this | |||
document were previously assigned in RFC 5296 [RFC5296]. | document were previously assigned in RFC 5296 [RFC5296]. | |||
10. References | 10. Change Log | |||
10.1. Normative References | 10.1. draft-ietf-hokey-rfc5296bis-02 | |||
The following are the major changes compared to previous version 00: | ||||
o Change using MAY in section 5.3.1.1 to using SHOULD | ||||
o Mandate sending the EAP-Initiate/Re-auth-Start message instead of | ||||
optional | ||||
o Update obsolete reference RFC4306 into RFC5996 | ||||
o Allow local server respond to the peer directly without forwarding | ||||
the ERP message to the home domain | ||||
11. References | ||||
11.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 | 11.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-05 (work in progress), October 2010. | |||
[I-D.ietf-dime-local-keytran] | [I-D.ietf-dime-local-keytran] | |||
, Q. and G. , "Diameter Attribute-Value Pairs for | , Q. and G. , "Diameter Attribute-Value Pairs for | |||
Cryptographic Key Transport", | Cryptographic Key Transport", | |||
draft-ietf-dime-local-keytran-07 (work in progress), | draft-ietf-dime-local-keytran-07 (work in progress), | |||
July 2010. | July 2010. | |||
[I-D.ietf-hokey-ldn-discovery] | [I-D.ietf-hokey-ldn-discovery] | |||
Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name | Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name | |||
DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in | DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in | |||
skipping to change at page 41, line 22 | skipping to change at page 41, line 51 | |||
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- | [RFC5296] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- | |||
authentication Protocol (ERP)", RFC 5296, August 2008. | 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, | ||||
"Internet Key Exchange Protocol Version 2 (IKEv2)", | ||||
RFC 5996, September 2010. | ||||
Appendix A. Acknowledgments | Appendix A. Acknowledgments | |||
A.1. RFC 5296 | A.1. RFC 5296 | |||
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 | |||
End of changes. 31 change blocks. | ||||
79 lines changed or deleted | 118 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/ |