draft-ietf-hokey-rfc5296bis-02.txt   draft-ietf-hokey-rfc5296bis-03.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: September 15, 2011 Y. Shi Expires: December 2, 2011 Y. Shi
H3C H3C
B. He B. He
CATR CATR
March 14, 2011 May 31, 2011
EAP Extensions for EAP Re-authentication Protocol (ERP) EAP Extensions for EAP Re-authentication Protocol (ERP)
draft-ietf-hokey-rfc5296bis-02 draft-ietf-hokey-rfc5296bis-03
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 September 15, 2011. This Internet-Draft will expire on December 2, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 28 skipping to change at page 3, line 28
4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16
4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17
5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 23 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . 27
5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 27 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 27
5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 28 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 29
5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31
5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 33 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 33
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33
7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 35 7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 39 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.1. draft-ietf-hokey-rfc5296bis-02 . . . . . . . . . . . . . . 39 10.1. Normative References . . . . . . . . . . . . . . . . . . . 40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 10.2. Informative References . . . . . . . . . . . . . . . . . . 40
11.1. Normative References . . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 42 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 42
A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 42 A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 42
A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 42 A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 42
Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 42 A.3. Change Log . . . . . . . . . . . . . . . . . . . . . . . . 42
A.3.1. draft-ietf-hokey-rfc5296bis-02 . . . . . . . . . . . . 42
A.3.2. draft-ietf-hokey-rfc5296bis-03 . . . . . . . . . . . . 42
Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP) is a an authentication The Extensible Authentication Protocol (EAP) is a an authentication
framework that supports multiple authentication methods. The primary framework that supports multiple authentication methods. The primary
purpose is network access authentication, and a key-generating method purpose is network access authentication, and a key-generating method
is used when the lower layer wants to enforce access control. The is used when the lower layer wants to enforce access control. The
EAP keying hierarchy defines two keys to be derived by all key- EAP keying hierarchy defines two keys to be derived by all key-
generating EAP methods: the Master Session Key (MSK) and the Extended generating EAP methods: the Master Session Key (MSK) and the Extended
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, if the local AAA client or bootstrapping. In implicit bootstrapping, the local AAA client or
Agent do not have the keying material(e.g., rMSK or rRK) Agent MUST verify whether it has valid rMSK or rRK corresponding to
corresponding to the peer, the local AAA client or agent supporting the peer. If the local AAA client or Agent has the key materials
EAP re-authentication SHOULD include its domain name and SHOULD corresponding to the peer, it MUST be able to respond directly in the
request the DSRK from the home AAA server during the initial EAP same way as the home AAA server does without forwarding the ERP
exchange, in the AAA message encapsulating the first EAP Response message to the home domain, if the local AAA client or Agent does not
message sent by the peer. If such EAP exchange is successful, the have the keying material(e.g., rMSK or rRK) corresponding to the
home EAP server sends the DSRK for the specified local AAA client or peer, the local AAA client or agent supporting EAP re-authentication
agent (derived using the EMSK and the domain name as specified in SHOULD include its domain name and SHOULD request the DSRK from the
[RFC5295]), EMSKname, and DSRK lifetime along with the EAP-Success home AAA server during the initial EAP exchange, in the AAA message
message. The local AAA client or agent MUST extract the DSRK, encapsulating the first EAP Response message sent by the peer. If
EMSKname, and DSRK lifetime (if present) before forwarding the EAP- such EAP exchange is successful, the home EAP server sends the DSRK
Success message to the peer, as specified in [I-D.ietf-dime-erp]. for the specified local AAA client or agent (derived using the EMSK
Note that the MSK (also present along with the EAP Success message) and the domain name as specified in [RFC5295]), EMSKname, and DSRK
is extracted by the EAP authenticator as usual. The peer learns the lifetime along with the EAP-Success message. The local AAA client or
domain name through the EAP-Initiate/Re-auth-Start message, lower- agent MUST extract the DSRK, EMSKname, and DSRK lifetime (if present)
layer announcements [I-D.ietf-hokey-ldn-discovery] . When the domain before forwarding the EAP-Success message to the peer, as specified
name is available to the peer during or after the full EAP in [I-D.ietf-dime-erp]. Note that the MSK (also present along with
authentication, it attempts to use ERP when it associates with a new the EAP Success message) is extracted by the EAP authenticator as
authenticator. usual. The peer learns the domain name through the EAP-Initiate/
Re-auth-Start message, lower-layer announcements
[I-D.ietf-hokey-ldn-discovery] . 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 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 ERP bootstrapping (ERP exchange with the bootstrap initiate Explicit ERP bootstrapping (ERP exchange with the bootstrap
flag turned on) with the ER server to obtain the local domain name. flag turned on) with the ER server to obtain the local domain name.
The peer MAY also initiate bootstrapping to fetch information such as The peer MAY also initiate bootstrapping to fetch information such as
the rRK lifetime from the AAA server. 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 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
skipping to change at page 18, line 26 skipping to change at page 18, line 29
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 Upon receipt of the EAP-Initiate/ Re-auth message from a peer, the
Re-auth message from a peer, it copies the contents of the ERP-capable authenticator verifies whether it has local domain
keyName-NAI into the User-Name attribute of RADIUS [RFC2865] and name and valid key materials corresponding to the peer. If it
may include its domain name in the AAA message encapsulating the knows local domain name and valid key material corresponding to
EAP-Initiate/Re-auth message sent by the peer. The rest of the the peer, it MUST be able to respond directly in the same way as
process is similar to that described in [RFC3579]. the home ER does with local domain name included. If not, it
copies the contents of the keyName-NAI into the User-Name
attribute of RADIUS [RFC2865] and 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 If a local ER server is present, the local ER server MUST verify o If a local ER server is present, the local ER server MUST verify
whether it has DSRK corresponding to the peer. If the local ER whether it has DSRK corresponding to the peer. If the local ER
server has the key materials corresponding to the peer, it MUST be server has the valid key materials corresponding to the peer, it
able to respond directly in the same way as the home ER server MUST be able to respond directly in the same way as the home ER
does described in the following step without forwarding the ERP server does described in the following step without forwarding the
message to the home domain, even if this message contains the 'B' ERP message to the home domain, even if this message contains the
(bootstrapping) flag. Otherwise, the local ER server MUST include 'B' (bootstrapping) flag. Otherwise, the local ER server MUST
the DSRK request and its domain name in the AAA message include the DSRK request and its domain name in the AAA message
encapsulating the EAP-Initiate/Re-auth message sent by the peer. encapsulating the EAP-Initiate/Re-auth message sent by the peer.
o Upon receipt of an EAP-Initiate/Re-auth message, the home ER o Upon receipt of an EAP-Initiate/Re-auth message, the home ER
server verifies whether the message is fresh or is a replay by server verifies whether the message is fresh or is a replay by
evaluating whether the received sequence number is equal to or evaluating whether the received sequence number is equal to or
greater than the expected sequence number for that rIK. The home greater than the expected sequence number for that rIK. The home
ER server then verifies to ensure that the cryptosuite used by the ER server then verifies to ensure that the cryptosuite used by the
peer is acceptable. Next, it verifies the origin authentication peer is acceptable. Next, it verifies the origin authentication
of the message by looking up the rIK. If any of the checks fail, 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 the home ER server sends an EAP-Finish/Re-auth message with the
skipping to change at page 21, line 47 skipping to change at page 22, line 9
use the corresponding DS-rIK it shares with the local ER server. use the corresponding DS-rIK it shares with the local ER server.
The peer SHOULD set the lifetime flag to request the key lifetimes The peer SHOULD set the lifetime flag to request the key lifetimes
from the server. The peer can use the rRK lifetime to know when from the server. The peer can use the rRK lifetime to know when
to trigger an EAP method exchange and the rMSK lifetime to know to trigger an EAP method exchange and the rMSK lifetime to know
when to trigger another ERP exchange. when to trigger another ERP exchange.
The authenticator copies the contents of the value field of the The authenticator copies the contents of the value field of the
keyName-NAI TLV into the User-Name RADIUS attribute in the AAA keyName-NAI TLV into the User-Name RADIUS attribute in the AAA
message to the ER server. message to the ER server.
The server uses the keyName-NAI to look up the rIK. It MUST first The ER server uses the keyName-NAI to look up the rIK. It MUST
verify whether the sequence number is equal to or greater than the first verify whether the sequence number is equal to or greater
expected sequence number. If the server supports a sequence than the expected sequence number. If the ER server supports a
number window size greater than 1, it MUST verify whether the sequence number window size greater than 1, it MUST verify whether
sequence number falls within the window and has not been received the sequence number falls within the window and has not been
before. The server MUST then verify to ensure that the received before. The ER server MUST then verify to ensure that
cryptosuite used by the peer is acceptable. The server then the cryptosuite used by the peer is acceptable. The ER server
proceeds to verify the integrity of the message using the rIK, then proceeds to verify the integrity of the message using the
thereby verifying proof of possession of that key by the peer. If rIK, thereby verifying proof of possession of that key by the
any of these verifications fail, the server MUST send an EAP- peer. If any of these verifications fail, the ER server MUST send
Finish/Re-auth message with the Result flag set to '1' (Failure). 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. (Failure). Please refer to Section 5.2.2 for details on failure
Otherwise, it MUST compute an rMSK from the rRK using the sequence handling. Otherwise, it MUST compute an rMSK from the rRK using
number as the additional input to the key derivation. the sequence number as the additional input to the key derivation.
In response to a well-formed EAP Re-auth/Initiate message, the In response to a well-formed EAP Re-auth/Initiate message, the ER
server MUST send an EAP-Finish/Re-auth message with the following server MUST send an EAP-Finish/Re-auth message with the following
considerations: considerations:
a 16-bit sequence number for replay protection, which MUST be a 16-bit sequence number for replay protection, which MUST be
the same as the received sequence number. The local copy of the same as the received sequence number. The local copy of
the sequence number MUST be incremented by 1. If the server the sequence number MUST be incremented by 1. If the ER server
supports multiple simultaneous ERP exchanges, it MUST instead supports multiple simultaneous ERP exchanges, it MUST instead
update the sequence number window. update the sequence number window.
keyName-NAI as a TLV attribute to identify the rIK used to keyName-NAI as a TLV attribute to identify the rIK used to
integrity protect the message. integrity protect the message.
cryptosuite to indicate the authentication algorithm used to cryptosuite to indicate the authentication algorithm used to
compute the integrity checksum. compute the integrity checksum.
authentication tag over the message. authentication tag over the message.
If the lifetime flag was set in the EAP-Initiate/Re-auth If the lifetime flag was set in the EAP-Initiate/Re-auth
message, the ER server SHOULD include the rRK lifetime and the message, the ER server SHOULD include the rRK lifetime and the
rMSK lifetime. rMSK lifetime.
The server transports the rMSK along with this message to the The ER server transports the rMSK along with this message to the
authenticator. The rMSK is transported in a manner similar to the authenticator. The rMSK is transported in a manner similar to the
MSK transport along with the EAP-Success message in a regular EAP MSK transport along with the EAP-Success message in a regular EAP
exchange. exchange.
The peer looks up the sequence number to verify whether it is The peer looks up the sequence number to verify whether it is
expecting an EAP-Finish/Re-auth message with that sequence number expecting an EAP-Finish/Re-auth message with that sequence number
protected by the keyName-NAI. It then verifies the integrity of protected by the keyName-NAI. It then verifies the integrity of
the message. If the verifications fail, the peer logs an error the message. If the verifications fail, the peer logs an error
and stops the process; otherwise, it proceeds to the next step. and stops the process; otherwise, it proceeds to the next step.
skipping to change at page 26, line 26 skipping to change at page 26, line 41
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 SHOULD send the EAP-Initiate/Re-auth-Start message In order to minimize ERP failure times, the authenticator SHOULD send
to indicate support for ERP to the peer and to initiate ERP if the the EAP-Initiate/Re-auth-Start message to indicate support for ERP to
peer has already performed full EAP authentication and has unexpired the peer and to initiate ERP if the peer has already performed full
key material. The authenticator SHOULD include the domain name TLV EAP authentication and has unexpired key material. The authenticator
to allow the peer to learn it without lower-layer support or the ERP SHOULD include the domain name TLV to allow the peer to learn it
bootstrapping exchange. without lower-layer support or the ERP bootstrapping exchange.
The authenticator MAY include channel binding information so that the The authenticator MAY include channel binding information so 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.
5.3.1.2. Peer Operation 5.3.1.2. Peer Operation
skipping to change at page 38, line 42 skipping to change at page 38, line 49
Authorization restriction Authorization restriction
All the keys derived are limited in lifetime by that of the All the keys derived are limited in lifetime by that of the
parent key or by server policy. Any domain-specific keys are parent key or by server policy. Any domain-specific keys are
further restricted for use only in the domain for which the further restricted for use only in the domain for which the
keys are derived. All the keys specified in this document are keys are derived. All the keys specified in this document are
meant for use in ERP only. Any other restrictions of session meant for use in ERP only. Any other restrictions of session
keys may be imposed by the specific lower layer and are out of keys may be imposed by the specific lower layer and are out of
scope for this specification. scope for this specification.
A denial-of-service (DoS) attack on the peer may be possible when Prevent DoS attack
using the EAP Initiate/Re-auth message. An attacker may send a bogus
EAP-Initiate/Re-auth message, which may be carried by the
authenticator in a RADIUS-Access-Request to the server; in response,
the server may send an EAP-Finish/Re-auth with Failure indication in
a RADIUS Access-Reject message. Note that such attacks may be
plausible with the EAPoL-Start capability of IEEE 802.11 and other
similar facilities in other link layers and where the peer can
initiate EAP authentication. An attacker may use such messages to
start an EAP method run, which fails and may result in the server
sending a RADIUS Access-Reject message, thus resulting in the link-
layer connections being terminated.
To prevent such DoS attacks, an ERP failure should not result in A denial-of-service (DoS) attack on the peer may be possible
deletion of any authorization state established by a full EAP when using the EAP Initiate/Re-auth message. An attacker may
exchange. Alternatively, the lower layers and AAA protocols may send a bogus EAP-Initiate/Re-auth message, which may be carried
define mechanisms to allow two link-layer security associations (SAs) by the authenticator in a RADIUS-Access-Request to the server;
derived from different EAP keying materials for the same peer to in response, the server may send an EAP-Finish/Re-auth with
exist so that smooth migration from the current link layer SA to the Failure indication in a RADIUS Access-Reject message. Note
new one is possible during rekey. These mechanisms prevent the link that such attacks may be plausible with the EAPoL-Start
layer connections from being terminated when a re-authentication capability of IEEE 802.11 and other similar facilities in other
procedure fails due to the bogus EAP-Initiate/Re-auth message. link layers and where the peer can initiate EAP authentication.
An attacker may use such messages to start an EAP method run,
which fails and may result in the server sending a RADIUS
Access-Reject message, thus resulting in the link-layer
connections being terminated.
When a DSRK is sent from a home EAP server to a local domain server To prevent such DoS attacks, an ERP failure should not result
or when a rMSK is sent from an ER server to an authenticator, in the in deletion of any authorization state established by a full
absence of end-to-end security between the entity that is sending the EAP exchange. Alternatively, the lower layers and AAA
key and the entity receiving the key, it is plausible for other protocols may define mechanisms to allow two link-layer
entities to get access to keys being sent to an ER server in another security associations (SAs) derived from different EAP keying
domain. This mode of key transport is similar to that of MSK materials for the same peer to exist so that smooth migration
transport in the context of EAP authentication. We further observe from the current link layer SA to the new one is possible
that ERP is for access authentication and does not support end-to-end during rekey. These mechanisms prevent the link layer
data security. In typical implementations, the traffic is in the connections from being terminated when a re-authentication
clear beyond the access control enforcement point (the authenticator procedure fails due to the bogus EAP-Initiate/Re-auth message.
or an entity delegated by the authenticator for access control
enforcement). The model works as long as entities in the middle of Keying materials Transport
the network do not use keys intended for other parties to steal
service from an access network. If that is not achievable, key When a DSRK is sent from a home EAP server to a local domain
delivery must be protected in an end-to-end manner. server 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 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 domain. This mode of key
transport is similar to that of MSK transport in the context of
EAP authentication. We further observe that ERP is for access
authentication and does not support end-to-end data security.
In typical implementations, the traffic is in the clear beyond
the access control enforcement point (the authenticator or an
entity delegated by the authenticator for access control
enforcement). The model works as long as entities in the
middle of the network do not use keys intended for other
parties to steal service from an access network. If that is
not achievable, key 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. Change Log 10. 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 10.1. Normative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
February 1997. February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.
11.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., Decugis, S., Wu, W., and G.
Support for the EAP Re-authentication Protocol (ERP)", Zorn, "Diameter support for EAP Re-authentication Protocol
draft-ietf-dime-erp-05 (work in progress), October 2010. (ERP)", draft-ietf-dime-erp-06 (work in progress),
May 2011.
[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 42, line 33 skipping to change at page 42, line 31
part of keyName-NAI field. Thanks to Bernard Aboba for suggestions part of keyName-NAI field. Thanks to Bernard Aboba for suggestions
in clarifying the EAP lock-step operation, and Joe Salowey and Glen in clarifying the EAP lock-step operation, and Joe Salowey and Glen
Zorn for help in specifying AAA transport of ERP messages. Thanks to Zorn for help in specifying AAA transport of ERP messages. Thanks to
Sam Hartman for the DSRK Authorization Indication mechanism. Sam Hartman for the DSRK Authorization Indication mechanism.
A.2. RFC 5296bis A.2. RFC 5296bis
Glen Zorn wrote the initial draft for this document and provided Glen Zorn wrote the initial draft for this document and provided
useful reviews. Many thanks to him. useful reviews. Many thanks to him.
A.3. Change Log
A.3.1. draft-ietf-hokey-rfc5296bis-02
The following are the major changes compared to previous version:
o Change using MAY in section 5.3.1.1 to using SHOULD
o Mandate sending the EAP-Initiate/Re-auth-Start message instead of
optional
o Update obsolete reference RFC4306 into RFC5996
o Allow local server respond to the peer directly without forwarding
the ERP message to the home domain
A.3.2. draft-ietf-hokey-rfc5296bis-03
The following are the major changes compared to previous version:
o Add explanation texts to clarify why SHOULD is used instead of
MAY.
o Additional texts to optimize implicit bootstrapping in section
5.1.
o Additional texts to optimize explicit bootstrapping in section
5.1.
o Add two new bullets with text in section 8 unmodified.
Appendix B. Example ERP Exchange 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,
 End of changes. 26 change blocks. 
126 lines changed or deleted 160 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/