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/