draft-ietf-hokey-rfc5296bis-00.txt   draft-ietf-hokey-rfc5296bis-01.txt 
Network Working Group G. Zorn, Ed. Network Working Group Q. Wu, Ed.
Internet-Draft Network Zen Internet-Draft Huawei
Obsoletes: 5296 (if approved) Q. Wu Obsoletes: 5296 (if approved) Z. Cao
Intended status: Standards Track Huawei Intended status: Standards Track China Mobile
Expires: March 17, 2011 Z. Cao Expires: April 23, 2011 Y. Shi
China Mobile H3C
September 13, 2010 B. He
CATR
October 20, 2010
EAP Extensions for EAP Re-authentication Protocol (ERP) EAP Extensions for EAP Re-authentication Protocol (ERP)
draft-ietf-hokey-rfc5296bis-00 draft-ietf-hokey-rfc5296bis-01
Abstract Abstract
The Extensible Authentication Protocol (EAP) is a generic framework The Extensible Authentication Protocol (EAP) is a generic framework
supporting multiple types of authentication methods. In systems supporting multiple types of authentication methods. In systems
where EAP is used for authentication, it is desirable to not repeat where EAP is used for authentication, it is desirable to not repeat
the entire EAP exchange with another authenticator. This document the entire EAP exchange with another authenticator. This document
specifies extensions to EAP and the EAP keying hierarchy to support specifies extensions to EAP and the EAP keying hierarchy to support
an EAP method-independent protocol for efficient re-authentication an EAP method-independent protocol for efficient re-authentication
between the peer and an EAP re-authentication server through any between the peer and an EAP re-authentication server through any
skipping to change at page 1, line 41 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 17, 2011. This Internet-Draft will expire on April 23, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 6 3. ERP Description . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 7 3.1. ERP With the Home ER Server . . . . . . . . . . . . . . . 9
3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 9 3.2. ERP with a Local ER Server . . . . . . . . . . . . . . . . 10
4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 11 4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 12 4.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . . . 13
4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 13 4.2. rRK Properties . . . . . . . . . . . . . . . . . . . . . . 14
4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 13 4.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . . . 14
4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 14 4.4. rIK Properties . . . . . . . . . . . . . . . . . . . . . . 15
4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 14 4.5. rIK Usage . . . . . . . . . . . . . . . . . . . . . . . . 15
4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 15 4.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . . . 16
4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16 4.7. rMSK Properties . . . . . . . . . . . . . . . . . . . . . 16
5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 16 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 16 5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 17
5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Steps in ERP . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 21 5.2.1. Multiple Simultaneous Runs of ERP . . . . . . . . . . 22
5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 22 5.2.2. ERP Failure Handling . . . . . . . . . . . . . . . . . 23
5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 23 5.3. New EAP Packets . . . . . . . . . . . . . . . . . . . . . 24
5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 24 5.3.1. EAP-Initiate/Re-auth-Start Packet . . . . . . . . . . 25
5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 25 5.3.1.1. Authenticator Operation . . . . . . . . . . . . . 26
5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 25 5.3.1.2. Peer Operation . . . . . . . . . . . . . . . . . . 26
5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 25 5.3.2. EAP-Initiate/Re-auth Packet . . . . . . . . . . . . . 26
5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 27 5.3.3. EAP-Finish/Re-auth Packet . . . . . . . . . . . . . . 28
5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 30 5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 31
5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 31 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 32
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 31 5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32
6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 32 6. Lower-Layer Considerations . . . . . . . . . . . . . . . . . . 33
7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 33 7. Transport of ERP Messages . . . . . . . . . . . . . . . . . . 34
8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 8. Security Considerations . . . . . . . . . . . . . . . . . . . 35
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 10.1. Normative References . . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . . 39 10.2. Informative References . . . . . . . . . . . . . . . . . . 40
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 40 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 41
A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 40 A.1. RFC 5296 . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 40 A.2. RFC 5296bis . . . . . . . . . . . . . . . . . . . . . . . 41
Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 40 Appendix B. Example ERP Exchange . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP) is a an authentication The Extensible Authentication Protocol (EAP) is a an authentication
framework that supports multiple authentication methods. The primary framework that supports multiple authentication methods. The primary
purpose is network access authentication, and a key-generating method purpose is network access authentication, and a key-generating method
is used when the lower layer wants to enforce access control. The is used when the lower layer wants to enforce access control. The
EAP keying hierarchy defines two keys to be derived by all key- EAP keying hierarchy defines two keys to be derived by all key-
generating EAP methods: the Master Session Key (MSK) and the Extended generating EAP methods: the Master Session Key (MSK) and the Extended
MSK (EMSK). In the most common deployment scenario, an EAP peer and MSK (EMSK). In the most common deployment scenario, an EAP peer and
skipping to change at page 4, line 47 skipping to change at page 4, line 47
via other authenticators. Other solutions for fast re-authentication via other authenticators. Other solutions for fast re-authentication
exist in the literature [MSKHierarchy]. exist in the literature [MSKHierarchy].
In conclusion, to achieve low latency handovers, there is a need for In conclusion, to achieve low latency handovers, there is a need for
a method-independent re-authentication protocol that completes in a method-independent re-authentication protocol that completes in
less than 2 round trips, preferably with a local server. The EAP re- less than 2 round trips, preferably with a local server. The EAP re-
authentication problem statement is described in detail in [RFC5169]. authentication problem statement is described in detail in [RFC5169].
This document specifies EAP Re-authentication Extensions (ERXs) for This document specifies EAP Re-authentication Extensions (ERXs) for
efficient re-authentication using EAP. The protocol that uses these efficient re-authentication using EAP. The protocol that uses these
extensions itself is referred to as the EAP Re-authentication extensions is itself referred to as the EAP Re-authentication
Protocol (ERP). It supports EAP method-independent re-authentication Protocol (ERP). It supports EAP method-independent re-authentication
for a peer that has valid, unexpired key material from a previously for a peer that has valid, unexpired key material from a previously
performed EAP authentication. The protocol and the key hierarchy performed EAP authentication. The protocol and the key hierarchy
required for EAP re-authentication are described in this document. required for EAP re-authentication are described in this document.
Note that to support ERP, lower-layer specifications may need to be Note that to support ERP, lower-layer specifications may need to be
revised to allow carrying EAP messages that have a code value higher revised to allow carrying EAP messages that have a code value higher
than 4 and to accommodate the peer-initiated nature of ERP. than 4 and to accommodate the peer-initiated nature of ERP.
Specifically, the IEEE802.1x specification must be revised and RFC Specifically, the IEEE802.1x specification must be revised and RFC
4306 must be updated to carry ERP messages. 4306 must be updated to carry ERP messages.
skipping to change at page 5, line 34 skipping to change at page 5, line 34
ER Authenticator - An entity that supports the authenticator ER Authenticator - An entity that supports the authenticator
functionality for EAP re-authentication described in this functionality for EAP re-authentication described in this
document. All references to "authenticator" in this document document. All references to "authenticator" in this document
imply an ER authenticator, unless specifically noted otherwise. imply an ER authenticator, unless specifically noted otherwise.
ER Server - An entity that performs the server portion of ERP ER Server - An entity that performs the server portion of ERP
described here. This entity may or may not be an EAP server. All described here. This entity may or may not be an EAP server. All
references to "server" in this document imply an ER server, unless references to "server" in this document imply an ER server, unless
specifically noted otherwise. An ER server is a logical entity; specifically noted otherwise. An ER server is a logical entity;
the home ER server is located on the same backend authentication it may not necessarily be co-located with, or physically part of,
server as the EAP server in the home domain. The local ER server a full EAP server.
may not necessarily be a full EAP server.
ERX - EAP re-authentication extensions. ERX - EAP re-authentication extensions.
ERP - EAP Re-authentication Protocol that uses the re- ERP - EAP Re-authentication Protocol that uses the re-
authentication extensions. authentication extensions.
rRK - re-authentication Root Key, derived from the EMSK or DSRK. rRK - re-authentication Root Key, derived from the EMSK or DSRK.
rIK - re-authentication Integrity Key, derived from the rRK. rIK - re-authentication Integrity Key, derived from the rRK.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
ERP allows a peer and server to mutually verify proof of possession ERP allows a peer and server to mutually verify proof of possession
of keying material from an earlier EAP method run and to establish a of keying material from an earlier EAP method run and to establish a
security association between the peer and the authenticator. The security association between the peer and the authenticator. The
authenticator acts as a pass-through entity for the Re-authentication authenticator acts as a pass-through entity for the Re-authentication
Protocol in a manner similar to that of an EAP authenticator Protocol in a manner similar to that of an EAP authenticator
described in RFC 3748 [RFC3748]. ERP is a single round-trip exchange described in RFC 3748 [RFC3748]. ERP is a single round-trip exchange
between the peer and the server; it is independent of the lower layer between the peer and the server; it is independent of the lower layer
and the EAP method used during the full EAP exchange. The ER server and the EAP method used during the full EAP exchange. The ER server
may be in the home domain or in the same (visited) domain as the peer may be in the home domain or in the same (visited) domain as the peer
and the authenticator. and the authenticator (i.e.,local domain).
Figure 2 shows the protocol exchange. The first time the peer Figure 2 shows the protocol exchange. The first time the peer
attaches to any network, it performs a full EAP exchange (shown in attaches to any network, it performs a full EAP exchange (shown in
Figure 1) with the EAP server; as a result, an MSK is distributed to Figure 1) with the EAP server; as a result, an MSK is distributed to
the EAP authenticator. The MSK is then used by the authenticator and the EAP authenticator. The MSK is then used by the authenticator and
the peer to establish TSKs as needed. At the time of the initial EAP the peer to establish TSKs as needed. At the time of the initial EAP
exchange, the peer and the server also derive an EMSK, which is used exchange, the peer and the server also derive an EMSK, which is used
to derive a re-authentication Root Key (rRK). More precisely, a re- to derive a re-authentication Root Key (rRK). More precisely, a re-
authentication Root Key is derived from the EMSK or from a Domain- authentication Root Key is derived from the EMSK or from a Domain-
Specific Root Key (DSRK), which itself is derived from the EMSK. The Specific Root Key (DSRK), which is itself derived from the EMSK. The
rRK is only available to the peer and the ER server and is never rRK is only available to the peer and the ER server and is never
handed out to any other entity. Further, a re-authentication handed out to any other entity. Further, a re-authentication
Integrity Key (rIK) is derived from the rRK; the peer and the ER Integrity Key (rIK) is derived from the rRK; the peer and the ER
server use the rIK to provide proof of possession while performing an server use the rIK to provide proof of possession while performing an
ERP exchange. The rIK is also never handed out to any entity and is ERP exchange. The rIK is also never handed out to any entity and is
only available to the peer and server. only available to the peer and server.
When the ER server is in the home domain, the peer and the server use
the rIK and rRK derived from the EMSK; and when the ER server is not
in the home domain, they use the DS-rIK and DS-rRK corresponding to
the local domain. The domain of the ER server is identified by the
realm portion of the keyname-NAI in ERP messages.
3.1. ERP With the Home ER Server
EAP Peer EAP Authenticator EAP Server EAP Peer EAP Authenticator EAP Server
======== ================= ========== ======== ================= ==========
<--- EAP-Request/ ------ <--- EAP-Request/ ------
Identity Identity
----- EAP Response/ ---> ----- EAP Response/ --->
Identity ---AAA(EAP Response/Identity)--> Identity ---AAA(EAP Response/Identity)-->
<--- EAP Method -------> <------ AAA(EAP Method --------> <--- EAP Method -------> <------ AAA(EAP Method -------->
exchange exchange) exchange exchange)
<----AAA(MSK, EAP-Success)------ <----AAA(MSK, EAP-Success)------
<---EAP-Success--------- <---EAP-Success---------
Figure 1: EAP Authentication Figure 1: EAP Authentication
Peer Authenticator Server Peer ER Authenticator ER Server
==== ============= ====== ==== ============= ======
[<-- EAP-Initiate/ ----- [<-- EAP-Initiate/ -----
Re-auth-Start] Re-auth-Start]
[<-- EAP-Request/ ------ [<-- EAP-Request/ ------
Identity] Identity]
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ----------> ---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
Re-auth/ Re-auth/ Re-auth/ Re-auth/
[Bootstrap] [Bootstrap]) [Bootstrap] [Bootstrap])
skipping to change at page 8, line 14 skipping to change at page 8, line 8
Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this Two new EAP codes, EAP-Initiate and EAP-Finish, are specified in this
document for the purpose of EAP re-authentication. When the peer document for the purpose of EAP re-authentication. When the peer
identifies a target authenticator that supports EAP re- identifies a target authenticator that supports EAP re-
authentication, it performs an ERP exchange, as shown in Figure 2; authentication, it performs an ERP exchange, as shown in Figure 2;
the exchange itself may happen when the peer attaches to a new the exchange itself may happen when the peer attaches to a new
authenticator supporting EAP re-authentication, or prior to authenticator supporting EAP re-authentication, or prior to
attachment. The peer initiates ERP by itself; it may also do so in attachment. The peer initiates ERP by itself; it may also do so in
response to an EAP-Initiate/Re-auth-Start message from the new response to an EAP-Initiate/Re-auth-Start message from the new
authenticator. The EAP-Initiate/Re-auth-Start message allows the authenticator. The EAP-Initiate/Re-auth-Start message allows the
authenticator to trigger the ERP exchange. authenticator to trigger the ERP exchange. The EAP-Finish message
also can be used by the authenticator to announce local domain name.
It is plausible that the authenticator does not know whether the peer It is plausible that the authenticator does not know whether the peer
supports ERP and whether the peer has performed a full EAP supports ERP and whether the peer has performed a full EAP
authentication through another authenticator. The authenticator MAY authentication through another authenticator. The authenticator MAY
initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start
message, and if there is no response, it will send the EAP-Request/ message, and if there is no response, it will send the EAP-Request/
Identity message. Note that this avoids having two EAP messages in Identity message. Note that this avoids having two EAP messages in
flight at the same time [RFC3748]. The authenticator may send the flight at the same time [RFC3748]. The authenticator may send the
EAP-Initiate/Re-auth-Start message and wait for a short, locally EAP-Initiate/Re-auth-Start message and wait for a short, locally
configured amount of time. If the peer does not already know, this configured amount of time. If the peer does not already know, this
skipping to change at page 9, line 39 skipping to change at page 9, line 36
In an ERP bootstrap exchange, the peer MAY request the server for the In an ERP bootstrap exchange, the peer MAY request the server for the
rRK lifetime. If so, the ER server sends the rRK lifetime in the rRK lifetime. If so, the ER server sends the rRK lifetime in the
EAP-Finish/Re-auth message. EAP-Finish/Re-auth message.
The peer verifies the replay protection and the integrity of the The peer verifies the replay protection and the integrity of the
message. It then uses the sequence number in the EAP-Finish/Re-auth message. It then uses the sequence number in the EAP-Finish/Re-auth
message to compute the rMSK. The lower-layer security association message to compute the rMSK. The lower-layer security association
protocol is ready to be triggered after this point. protocol is ready to be triggered after this point.
When the ER server is in the home domain, the peer and the server use
the rIK and rRK derived from the EMSK; and when the ER server is in
the local domain, they use the DS-rIK and DS-rRK corresponding to the
local domain. The domain of the ER server is identified by the realm
portion of the keyname-NAI in ERP messages.
3.1. ERP With the Home ER Server
If the peer is in the home domain and does not know the domain name (
did not receive the domain name through the EAP-Initiate/
Re-auth-Start message or via the lower-layer announcement, due to a
missed announcement or lack of support for domain name announcements
in a specific lower layer) or there is no the local server in the
same domain as the peer, it SHOULD initiate ERP bootstrap exchange
with the home ER server to obtain the domain name.
The defined ER extensions allow executing the ERP with an ER server
in the home domain. The home ER server may be co- located with a
home AAA server. The ERP with the Home ER Server is the similar as
ERP exchange described in Figure 2.
Peer ER Authenticator Home ER Server
==== ============= ======
[<-- EAP-Initiate/ -----
Re-auth-Start]
[<-- EAP-Request/ ------
Identity]
---- EAP-Initiate/ ----> ----AAA(EAP-Initiate/ ---------->
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap])
<--- EAP-Finish/ ------> <---AAA(rMSK,EAP-Finish/---------
Re-auth/ Re-auth/
[Bootstrap] [Bootstrap])
Note: [] brackets indicate optionality.
Figure 3: ER ExplicitBootstrapping Exchange/ERP with the Home ER
Sever
3.2. ERP with a Local ER Server 3.2. ERP with a Local ER Server
The defined ER extensions allow executing the ERP with an ER server The defined ER extensions allow executing the ERP with an ER server
in the local domain (access network). The local ER server may be co- in the local domain (access network) if the peer moves out of home
located with a local AAA server. The peer may learn about the domain. The local ER server may be co-located with a local AAA
presence of a local ER server in the network and the local domain server. The peer may learn about the presence of a local ER server
name (or ER server name) either via the lower layer or by means of in the network and the local domain name (or ER server name) either
ERP bootstrapping. The peer uses the domain name and the EMSK to via the lower layer or by means of ERP exchange. The peer uses the
compute the DSRK and from that key, the DS-rRK; the peer also uses domain name and the EMSK to compute the DSRK and from that key, the
the domain name in the realm portion of the keyName-NAI for using ERP DS-rRK; the peer also uses the domain name in the realm portion of
in the local domain. Figure 3 shows the full EAP and subsequent the keyName-NAI for using ERP in the local domain. Figure 4 shows
local ERP exchange; Figure 4 shows it with a local ER server. the ER Implicit bootstrapping exchange through local ER
Server;Figure 5shows ERP with a local ER server.
Peer EAP Authenticator Local ER Server Home EAP Server Peer EAP Authenticator Local AAA Agent Home EAP Server
/ER Authenticator /Local ER Server
==== ================= =============== =============== ==== ================= =============== ===============
<-- EAP-Request/ -- <-- EAP-Request/ --
Identity Identity
-- EAP Response/--> -- EAP Response/-->
Identity --AAA(EAP Response/--> Identity --AAA(EAP Response/-->
Identity) --AAA(EAP Response/ --> Identity, --AAA(EAP Response/ -->
Identity, [domain name]) Identity,
[DSRK Request, [DSRK Request,
domain name]) domain name])
<------------------------ EAP Method exchange------------------> <------------------------ EAP Method exchange------------------>
<---AAA(MSK, DSRK, ---- <---AAA(MSK, DSRK, ----
EMSKname, EMSKname,
EAP-Success) EAP-Success)
<--- AAA(MSK, ----- <--- AAA(MSK, -----
EAP-Success) EAP-Success)
<---EAP-Success----- <---EAP-Success-----
Figure 3: Local ERP Exchange, Initial EAP Exchange Figure 4: Local ERP Exchange, Initial EAP Exchange
Peer ER Authenticator Local ER Server Peer ER Authenticator Local ER Server
==== ================ =============== ==== ================ ===============
[<-- EAP-Initiate/ -------- [<-- EAP-Initiate/ --------
Re-auth-Start] Re-auth-Start]
[<-- EAP-Request/ --------- [<-- EAP-Request/ ---------
Identity] Identity]
---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ --------> ---- EAP-Initiate/ -------> ----AAA(EAP-Initiate/ -------->
Re-auth Re-auth) Re-auth Re-auth)
<--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/------- <--- EAP-Finish/ ---------- <---AAA(rMSK,EAP-Finish/-------
Re-auth Re-auth) Re-auth Re-auth)
Figure 4: Local ERP Exchange Figure 5: Local ERP Exchange
As shown in Figure 4, the local ER server may be present in the path As shown in Figure 4, the local ER server may be present in the path
of the full EAP exchange (e.g., this may be one of the AAA entities, of the full EAP exchange (e.g., this may be one of the AAA entities,
such as AAA proxies, in the path between the authenticator and the such as AAA proxies, in the path between the EAP authenticator and
home EAP server of the peer). In that case, the ER server requests the home EAP server of the peer). In that case, the local ER server
the DSRK by sending the domain name to the EAP server. In response, requests the DSRK by sending the domain name to the home EAP server
the EAP server computes the DSRK by following the procedure specified through AAA message. In response, the home EAP server computes the
in [RFC5295] and sends the DSRK and the key name, EMSKname, to the ER DSRK by following the procedure specified in [RFC5295] and sends the
server in the claimed domain. The local domain is responsible for DSRK and the key name, EMSKname, to the ER server in the claimed
announcing that same domain name via the lower layer to the peer. domain (i.e., local ER Server). The local domain is responsible for
announcing that same domain name via the lower layer to the peer,
If the peer does not know the domain name (did not receive the domain e.g., DHCP based local domain name discovery specified in
name via the lower-layer announcement, due to a missed announcement [I-D.ietf-hokey-ldn-discovery], or through the EAP-Initiate/
or lack of support for domain name announcements in a specific lower Re-auth-Start message during subsequent ERP with local ER server.
layer), it SHOULD initiate ERP bootstrap exchange with the home ER
server to obtain the domain name. The local ER server SHALL request
the home AAA server for the DSRK by sending the domain name in the
AAA message that carries the EAP-Initiate/Re-auth bootstrap message.
The local ER server MUST be in the path from the peer to the home ER
server. If it is not, it cannot request the DSRK.
After receiving the DSRK and the EMSKname, the local ER server After receiving the DSRK and the EMSKname, the local ER server
computes the DS-rRK and the DS-rIK from the DSRK as defined in computes the DS-rRK and the DS-rIK from the DSRK as defined in
Sections 4.1 and 4.3 below. After receiving the domain name, the Sections 4.1 and 4.3 below. After receiving the domain name, the
peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys peer also derives the DSRK, the DS-rRK, and the DS-rIK. These keys
are referred to by a keyName-NAI formed as follows: the username part are referred to by a keyName-NAI formed as follows: the username part
of the NAI is the EMSKname, the realm portion of the NAI is the of the NAI is the EMSKname, the realm portion of the NAI is the
domain name. Both parties also maintain a sequence number domain name. Both parties also maintain a sequence number
(initialized to zero) corresponding to the specific keyName-NAI. (initialized to zero) corresponding to the specific keyName-NAI.
Subsequently, when the peer attaches to an authenticator within the Subsequently, when the peer attaches to an authenticator within the
local domain, it may perform an ERP exchange with the local ER server local domain, it may perform an ERP exchange with the local ER server
to obtain an rMSK for the new authenticator. to obtain an rMSK for the new authenticator. The ERP with the local
ER Server is the similar as ERP exchange described in Figure 2.
4. ER Key Hierarchy 4. ER Key Hierarchy
Each time the peer re-authenticates to the network, the peer and the Each time the peer re-authenticates to the network, the peer and the
authenticator establish an rMSK. The rMSK serves the same purposes authenticator establish an rMSK. The rMSK serves the same purposes
that an MSK, which is the result of full EAP authentication, serves. that an MSK, which is the result of full EAP authentication, serves.
To prove possession of the rRK, we specify the derivation of another To prove possession of the rRK, we specify the derivation of another
key, the rIK. These keys are derived from the rRK. Together they key, the rIK. These keys are derived from the rRK. Together they
constitute the ER key hierarchy. constitute the ER key hierarchy.
skipping to change at page 12, line 25 skipping to change at page 13, line 20
The rRK is used to derive an rIK, and rMSKs for one or more The rRK is used to derive an rIK, and rMSKs for one or more
authenticators. The figure below shows the key hierarchy with the authenticators. The figure below shows the key hierarchy with the
rRK, rIK, and rMSKs. rRK, rIK, and rMSKs.
rRK rRK
| |
+--------+--------+ +--------+--------+
| | | | | |
rIK rMSK1 ...rMSKn rIK rMSK1 ...rMSKn
Figure 5: Re-authentication Key Hierarchy Figure 6: Re-authentication Key Hierarchy
The derivations in this document are according to [RFC5295]. Key The derivations in this document are according to [RFC5295]. Key
derivations and field encodings, where unspecified, default to that derivations and field encodings, where unspecified, default to that
document. document.
4.1. rRK Derivation 4.1. rRK Derivation
The rRK may be derived from the EMSK or DSRK. This section provides The rRK may be derived from the EMSK or DSRK. This section provides
the relevant key derivations for that purpose. the relevant key derivations for that purpose.
skipping to change at page 16, line 31 skipping to change at page 17, line 25
new rRK. Previously delivered rMSKs MAY still be used until the new rRK. Previously delivered rMSKs MAY still be used until the
expiry of the lifetime. expiry of the lifetime.
o A given rMSK MUST NOT be shared by multiple authenticators. o A given rMSK MUST NOT be shared by multiple authenticators.
5. Protocol Details 5. Protocol Details
5.1. ERP Bootstrapping 5.1. ERP Bootstrapping
We identify two types of bootstrapping for ERP: explicit and implicit We identify two types of bootstrapping for ERP: explicit and implicit
bootstrapping. In implicit bootstrapping, the local ER server SHOULD bootstrapping. In implicit bootstrapping, the local AAA client or
include its domain name and SHOULD request the DSRK from the home AAA agent supporting EAP re-authentication SHOULD include its domain name
server during the initial EAP exchange, in the AAA message and SHOULD request the DSRK from the home AAA server during the
encapsulating the first EAP Response message sent by the peer. If initial EAP exchange, in the AAA message encapsulating the first EAP
the EAP exchange is successful, the server sends the DSRK for the Response message sent by the peer. If such EAP exchange is
local ER server (derived using the EMSK and the domain name as successful, the home EAP server sends the DSRK for the specified
specified in [RFC5295]), EMSKname, and DSRK lifetime along with the local AAA client or agent (derived using the EMSK and the domain name
EAP-Success message. The local ER server MUST extract the DSRK, as specified in [RFC5295]), EMSKname, and DSRK lifetime along with
EMSKname, and DSRK lifetime (if present) before forwarding the EAP- the EAP-Success message. The local AAA client or agent MUST extract
Success message to the peer, as specified in [I-D.ietf-dime-erp]. the DSRK, EMSKname, and DSRK lifetime (if present) before forwarding
Note that the MSK (also present along with the EAP Success message) the EAP-Success message to the peer, as specified in
is extracted by the EAP authenticator as usual. The peer learns the [I-D.ietf-dime-erp]. Note that the MSK (also present along with the
domain name through the EAP-Initiate/Re-auth-Start message or via EAP Success message) is extracted by the EAP authenticator as usual.
lower-layer announcements. When the domain name is available to the The peer learns the domain name through the EAP-Initiate/
peer during or after the full EAP authentication, it attempts to use Re-auth-Start message, lower-layer announcements
ERP when it associates with a new authenticator. [I-D.ietf-hokey-ldn-discovery] or via ER Explicit bootstrapping
exchange. When the domain name is available to the peer during or
after the full EAP authentication, it attempts to use ERP when it
associates with a new authenticator.
If the peer does not know the domain name (did not receive the domain If the peer does not know the domain name (did not receive the domain
name via the lower-layer announcement, due to a missed announcement name through the EAP-Initiate/Re-auth-Start message or via the lower-
or lack of support for domain name announcements in a specific lower layer announcement, due to a missed announcement or lack of support
layer), it SHOULD initiate ERP bootstrap exchange (ERP exchange with for domain name announcements in a specific lower layer), it SHOULD
the bootstrap flag turned on) with the home ER server to obtain the initiate Explicit ER bootstrap exchange (ERP exchange with the
domain name. The local ER server behavior is the same as described bootstrap flag turned on) with the ER server in the same (visited)
above. The peer MAY also initiate bootstrapping to fetch information domain as the peer to obtain the local domain name. The peer MAY
such as the rRK lifetime from the AAA server. also initiate bootstrapping to fetch information such as the rRK
lifetime from the AAA server.
The following steps describe the ERP explicit bootstrapping process: The following steps describe the ERP explicit bootstrapping process:
o The peer sends the EAP-Initiate/Re-auth message with the o The peer sends the EAP-Initiate/Re-auth message with the
bootstrapping flag turned on. The bootstrap message is always bootstrapping flag turned on. The bootstrap message is always
sent to the home AAA server, and the keyname-NAI attribute in the sent to the ER server, and the keyname-NAI attribute in the
bootstrap message is constructed as follows: the username portion bootstrap message is constructed as follows: the username portion
of the NAI contains the EMSKname, and the realm portion contains of the NAI contains the EMSKname, and the realm portion contains
the home domain name. the home domain name.
o In addition, the message MUST contain a sequence number for replay o In addition, the message MUST contain a sequence number for replay
protection, a cryptosuite, and an integrity checksum. The protection, a cryptosuite, and an integrity checksum. The
cryptosuite indicates the authentication algorithm. The integrity cryptosuite indicates the authentication algorithm. The integrity
checksum indicates that the message originated at the claimed checksum indicates that the message originated at the claimed
entity, the peer indicated by the Peer-ID, or the rIKname. entity, the peer indicated by the Peer-ID, or the rIKname.
o The peer MAY additionally set the lifetime flag to request the key o The peer MAY additionally set the lifetime flag to request the key
lifetimes. lifetimes.
o When an ERP-capable authenticator receives the EAP-Initiate/ o When an ERP-capable authenticator receives the EAP-Initiate/
Re-auth message from a peer, it copies the contents of the Re-auth message from a peer, it copies the contents of the
keyName-NAI into the User-Name attribute of RADIUS [RFC2865]. The keyName-NAI into the User-Name attribute of RADIUS [RFC2865]. The
rest of the process is similar to that described in [RFC3579]. rest of the process is similar to that described in [RFC3579].
o If a local ER server is present, the local ER server MUST include
the DSRK request and its domain name in the AAA message
encapsulating the EAP-Initiate/Re-auth message sent by the peer.
o Upon receipt of an EAP-Initiate/Re-auth message, the server o Upon receipt of an EAP-Initiate/Re-auth message, the server
verifies whether the message is fresh or is a replay by evaluating verifies whether the message is fresh or is a replay by evaluating
whether the received sequence number is equal to or greater than whether the received sequence number is equal to or greater than
the expected sequence number for that rIK. The server then the expected sequence number for that rIK. The server then
verifies to ensure that the cryptosuite used by the peer is verifies to ensure that the cryptosuite used by the peer is
acceptable. Next, it verifies the origin authentication of the acceptable. Next, it verifies the origin authentication of the
message by looking up the rIK. If any of the checks fail, the message by looking up the rIK. If any of the checks fail, the
server sends an EAP-Finish/Re-auth message with the Result flag server sends an EAP-Finish/Re-auth message with the Result flag
set to '1'. Please refer to Section 5.2.2 for details on failure set to '1'. Please refer to Section 5.2.2 for details on failure
handling. This error MUST NOT have any correlation to any EAP- handling. This error MUST NOT have any correlation to any EAP-
skipping to change at page 18, line 16 skipping to change at page 19, line 12
* The same keyName-NAI as in the EAP-Initiate/Re-auth message. * The same keyName-NAI as in the EAP-Initiate/Re-auth message.
* If the lifetime flag was set in the EAP-Initiate/Re-auth * If the lifetime flag was set in the EAP-Initiate/Re-auth
message, the ER server SHOULD include the rRK lifetime and the message, the ER server SHOULD include the rRK lifetime and the
rMSK lifetime in the EAP-Finish/Re-auth message. The server rMSK lifetime in the EAP-Finish/Re-auth message. The server
may have a local policy for the network to maintain and enforce may have a local policy for the network to maintain and enforce
lifetime unilaterally. In such cases, the server need not lifetime unilaterally. In such cases, the server need not
respond to the peer's request for the lifetime. respond to the peer's request for the lifetime.
* If the bootstrap flag is set and a DSRK request is received, * If the bootstrap flag is set, the ER server MUST include the
the server MUST include the domain name to which the DSRK is domain name to which the DSRK is being sent along with the EAP-
being sent. Finish/Re-auth message.
* If the home ER server verifies the authorization of a local * If the ER server verifies the authorization of a local domain
domain server, it MAY include the Authorization Indication TLV server, it MAY include the Authorization Indication TLV to
to indicate to the peer that the server (that received the DSRK indicate to the peer that the server (that received the DSRK
and that is advertising the domain included in the domain name and that is advertising the domain included in the domain name
TLV) is authorized. TLV) is authorized.
* An authentication tag MUST be included to prove that the EAP- * An authentication tag MUST be included to prove that the EAP-
Finish/Re-auth message originates at a server that possesses Finish/Re-auth message originates at a server that possesses
the rIK corresponding to the EMSKname-NAI. the rIK corresponding to the EMSKname-NAI.
o If the ERP exchange is successful, and the local ER server sent a o If the ERP exchange is successful, the ER server SHOULD request
DSRK request, the home ER server MUST include the DSRK for the the DSRK from the home EAP server during the initial EAP exchange
local ER server (derived using the EMSK and the domain name as as specified in [I-D.ietf-dime-local-keytran], the home EAP server
specified in [RFC5295]), EMSKname, and DSRK lifetime along with MUST include the DSRK for the local ER server (derived using the
the EAP-Finish/Re-auth message. EMSK and the domain name as specified in [RFC5295]), EMSKname, and
DSRK lifetime along with the EAP-Finish/Re-auth message.
o In addition, the rMSK is sent along with the EAP-Finish/Re-auth o In addition, the rMSK is sent along with the EAP-Finish/Re-auth
message, in a AAA attribute [I-D.ietf-dime-erp]. message, in a AAA attribute [I-D.ietf-dime-erp].
o The local ER server MUST extract the DSRK, EMSKname, and DSRK o The ER server MUST extract the DSRK, EMSKname, and DSRK lifetime
lifetime (if present), before forwarding the EAP-Finish/Re-auth (if present) before forwarding the EAP-Success message to the
message to the peer, as specified in [I-D.ietf-dime-erp]. peer, as specified in [I-D.ietf-dime-erp].
o The authenticator receives the rMSK. o The authenticator receives the rMSK.
o When the peer receives an EAP-Finish/Re-auth message with the o When the peer receives an EAP-Finish/Re-auth message with the
bootstrap flag set, if a local domain name is present, it MUST use bootstrap flag set, if a local domain name is present, it MUST use
that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName- that to derive the appropriate DSRK, DS-rRK, DS-rIK, and keyName-
NAI, and initialize the replay counter for the DS-rIK. If not, NAI, and initialize the replay counter for the DS-rIK. If not,
the peer SHOULD derive the domain-specific keys using the domain the peer SHOULD derive the domain-specific keys using the domain
name it learned via the lower layer or from the EAP-Initiate/ name it learned via the lower layer or from the EAP-Initiate/
Re-auth-Start message. If the peer does not know the domain name, Re-auth-Start message. If the peer does not know the domain name,
skipping to change at page 23, line 22 skipping to change at page 24, line 22
packet format defined in RFC 3748 [RFC3748]. packet format defined in RFC 3748 [RFC3748].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ... | Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 6: EAP Packet Figure 7: EAP Packet
Code Code
5 Initiate 5 Initiate
6 Finish 6 Finish
Two new code values are defined for the purpose of ERP. Two new code values are defined for the purpose of ERP.
Identifier Identifier
skipping to change at page 24, line 19 skipping to change at page 25, line 19
auth-Start (assigned Type 1) and Re-auth (assigned Type 2). auth-Start (assigned Type 1) and Re-auth (assigned Type 2).
Type-Data Type-Data
The Type-Data field varies with the Type of re-authentication The Type-Data field varies with the Type of re-authentication
packet. packet.
5.3.1. EAP-Initiate/Re-auth-Start Packet 5.3.1. EAP-Initiate/Re-auth-Start Packet
The EAP-Initiate/Re-auth-Start packet contains the parameters shown The EAP-Initiate/Re-auth-Start packet contains the parameters shown
in Figure 7. in Figure 8.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | 1 or more TVs or TLVs ~ | Type | Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: EAP-Initiate/Re-auth-Start Packet Figure 8: EAP-Initiate/Re-auth-Start Packet
Type = 1. Type = 1.
Reserved, MUST be zero. Set to zero on transmission and ignored Reserved, MUST be zero. Set to zero on transmission and ignored
on reception. on reception.
One or more TVs or TLVs are used to convey information to the One or more TVs or TLVs are used to convey information to the
peer; for instance, the authenticator may send the domain name to peer; for instance, the authenticator may send the domain name to
the peer. the peer.
skipping to change at page 25, line 6 skipping to change at page 26, line 6
is a 1-octet type payload and a 1-octet length payload. The is a 1-octet type payload and a 1-octet length payload. The
length field indicates the length of the value expressed in number length field indicates the length of the value expressed in number
of octets. of octets.
Domain-Name: This is a TLV payload. The Type is 4. The domain Domain-Name: This is a TLV payload. The Type is 4. The domain
name is to be used as the realm in an NAI [RFC4282]. The name is to be used as the realm in an NAI [RFC4282]. The
Domain-Name attribute SHOULD be present in an EAP-Initiate/ Domain-Name attribute SHOULD be present in an EAP-Initiate/
Re-auth-Start message. Re-auth-Start message.
In addition, channel binding information MAY be included; see In addition, channel binding information MAY be included; see
Section 5.5 for discussion. See Figure 11 for parameter Section 5.5 for discussion. See Figure 12 for parameter
specification. specification.
5.3.1.1. Authenticator Operation 5.3.1.1. Authenticator Operation
The authenticator MAY send the EAP-Initiate/Re-auth-Start message to The authenticator MAY send the EAP-Initiate/Re-auth-Start message to
indicate support for ERP to the peer and to initiate ERP if the peer indicate support for ERP to the peer and to initiate ERP if the peer
has already performed full EAP authentication and has unexpired key has already performed full EAP authentication and has unexpired key
material. The authenticator SHOULD include the domain name TLV to material. The authenticator SHOULD include the domain name TLV to
allow the peer to learn it without lower-layer support or the ERP allow the peer to learn it without lower-layer support or the ERP
bootstrapping exchange. bootstrapping exchange.
skipping to change at page 25, line 39 skipping to change at page 26, line 39
the EAP-Initiate/Re-auth-Start message from the authenticator. If the EAP-Initiate/Re-auth-Start message from the authenticator. If
the peer does not recognize the Initiate code value, it silently the peer does not recognize the Initiate code value, it silently
discards the message. If the peer has already sent the EAP-Initiate/ discards the message. If the peer has already sent the EAP-Initiate/
Re-auth message to begin the ERP exchange, it silently discards the Re-auth message to begin the ERP exchange, it silently discards the
message. message.
If the EAP-Initiate/Re-auth-Start message contains the domain name, If the EAP-Initiate/Re-auth-Start message contains the domain name,
and if the peer does not already have the domain information, the and if the peer does not already have the domain information, the
peer SHOULD use the domain name to compute the DSRK and use the peer SHOULD use the domain name to compute the DSRK and use the
corresponding DS-rIK to send an EAP-Initiate/Re-auth message to start corresponding DS-rIK to send an EAP-Initiate/Re-auth message to start
an ERP exchange with the local ER server. If the peer has already an ERP exchange with the local ER server. If there are the local ER
initiated an ERP exchange with the home ER server, it MAY choose to server between the peer and the home ER server and the peer has
not start an ERP exchange with the local ER server. already initiated an ERP exchange with the local ER server, it SHOULD
choose to not start an ERP exchange with the home ER server.
5.3.2. EAP-Initiate/Re-auth Packet 5.3.2. EAP-Initiate/Re-auth Packet
The EAP-Initiate/Re-auth packet contains the parameters shown in The EAP-Initiate/Re-auth packet contains the parameters shown in
Figure 8. Figure 9.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|B|L| Reserved| SEQ | | Type |R|B|L| Reserved| SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~ | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cryptosuite | Authentication Tag ~ | cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: EAP-Initiate/Re-auth Packet Figure 9: EAP-Initiate/Re-auth Packet
Type = 2. Type = 2.
Flags Flags
'R' - The R flag is set to 0 and ignored upon reception. 'R' - The R flag is set to 0 and ignored upon reception.
'B' - The B flag is used as the bootstrapping flag. If the 'B' - The B flag is used as the bootstrapping flag. If the
flag is turned on, the message is a bootstrap message. flag is turned on, the message is a bootstrap message.
skipping to change at page 27, line 7 skipping to change at page 28, line 7
hexadecimal values. The EMSKname is 64 bits in length and so hexadecimal values. The EMSKname is 64 bits in length and so
the username portion takes up 128 octets. If the rIK is the username portion takes up 128 octets. If the rIK is
derived from the EMSK, the realm part of the NAI is the home derived from the EMSK, the realm part of the NAI is the home
domain name, and if the rIK is derived from a DSRK, the realm domain name, and if the rIK is derived from a DSRK, the realm
part of the NAI is the domain name used in the derivation of part of the NAI is the domain name used in the derivation of
the DSRK. The NAI syntax follows [RFC4282]. Exactly one the DSRK. The NAI syntax follows [RFC4282]. Exactly one
keyName-NAI attribute SHALL be present in an EAP-Initiate/ keyName-NAI attribute SHALL be present in an EAP-Initiate/
Re-auth packet. Re-auth packet.
In addition, channel binding information MAY be included; see In addition, channel binding information MAY be included; see
Section 5.5 for discussion. See Figure 11 for parameter Section 5.5 for discussion. See Figure 12 for parameter
specification. specification.
Cryptosuite: This field indicates the integrity algorithm used for Cryptosuite: This field indicates the integrity algorithm used for
ERP. Key lengths and output lengths are either indicated or are ERP. Key lengths and output lengths are either indicated or are
obvious from the cryptosuite name. We specify some cryptosuites obvious from the cryptosuite name. We specify some cryptosuites
below: below:
* 0 RESERVED * 0 RESERVED
* 1 HMAC-SHA256-64 * 1 HMAC-SHA256-64
skipping to change at page 27, line 33 skipping to change at page 28, line 33
HMAC-SHA256-128 is mandatory to implement and should be enabled in HMAC-SHA256-128 is mandatory to implement and should be enabled in
the default configuration. the default configuration.
Authentication Tag: This field contains the integrity checksum Authentication Tag: This field contains the integrity checksum
over the ERP packet, excluding the authentication tag field over the ERP packet, excluding the authentication tag field
itself. The length of the field is indicated by the Cryptosuite. itself. The length of the field is indicated by the Cryptosuite.
5.3.3. EAP-Finish/Re-auth Packet 5.3.3. EAP-Finish/Re-auth Packet
The EAP-Finish/Re-auth packet contains the parameters shown in The EAP-Finish/Re-auth packet contains the parameters shown in
Figure 9. Figure 10.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|B|L| Reserved | SEQ ~ | Type |R|B|L| Reserved | SEQ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~ | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cryptosuite | Authentication Tag ~ | cryptosuite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: EAP-Finish/Re-auth Packet Figure 10: EAP-Finish/Re-auth Packet
Type = 2. Type = 2.
Flags Flags
'R' - The R flag is used as the Result flag. When set to 0, it 'R' - The R flag is used as the Result flag. When set to 0, it
indicates success, and when set to '1', it indicates a failure. indicates success, and when set to '1', it indicates a failure.
'B' - The B flag is used as the bootstrapping flag. If the 'B' - The B flag is used as the bootstrapping flag. If the
flag is turned on, the message is a bootstrap message. flag is turned on, the message is a bootstrap message.
skipping to change at page 29, line 13 skipping to change at page 30, line 13
attribute SHOULD be present. attribute SHOULD be present.
Domain-Name: This is a TLV payload. The Type is 4. The domain Domain-Name: This is a TLV payload. The Type is 4. The domain
name is to be used as the realm in an NAI [RFC4282]. Domain- name is to be used as the realm in an NAI [RFC4282]. Domain-
Name attribute MUST be present in an EAP-Finish/Re-auth message Name attribute MUST be present in an EAP-Finish/Re-auth message
if the bootstrapping flag is set and if the local ER server if the bootstrapping flag is set and if the local ER server
sent a DSRK request. sent a DSRK request.
List of cryptosuites: This is a TLV payload. The Type is 5. List of cryptosuites: This is a TLV payload. The Type is 5.
The value field contains a list of cryptosuites, each of size 1 The value field contains a list of cryptosuites, each of size 1
octet. The cryptosuite values are as specified in Figure 8. octet. The cryptosuite values are as specified in Figure 9.
The server SHOULD include this attribute if the cryptosuite The server SHOULD include this attribute if the cryptosuite
used in the EAP-Initiate/Re-auth message was not acceptable and used in the EAP-Initiate/Re-auth message was not acceptable and
the message is being rejected. The server MAY include this the message is being rejected. The server MAY include this
attribute in other cases. The server MAY use this attribute to attribute in other cases. The server MAY use this attribute to
signal to the peer about its cryptographic algorithm signal to the peer about its cryptographic algorithm
capabilities. capabilities.
Authorization Indication: This is a TLV payload. The Type is Authorization Indication: This is a TLV payload. The Type is
6. This attribute MAY be included in the EAP-Finish/Re-auth 6. This attribute MAY be included in the EAP-Finish/Re-auth
message when a DSRK is delivered to a local ER server and if message when a DSRK is delivered to a local ER server and if
the home ER server can verify the authorization of the local ER the home EAP server can verify the authorization of the local
server to advertise the domain name included in the domain TLV ER server to advertise the domain name included in the domain
in the same message. The value field in the TLV contains an TLV in the same message. The value field in the TLV contains
authentication tag computed over the entire packet, starting an authentication tag computed over the entire packet, starting
from the first bit of the code field to the last bit of the from the first bit of the code field to the last bit of the
cryptosuite field, with the value field of the Authorization cryptosuite field, with the value field of the Authorization
Indication TLV filled with all 0s for the computation. The key Indication TLV filled with all 0s for the computation. The key
used for the computation MUST be derived from the EMSK with key used for the computation MUST be derived from the EMSK with key
label "DSRK Delivery Authorized Key@ietf.org" and optional data label "DSRK Delivery Authorized Key@ietf.org" and optional data
containing an ASCII string representing the key management containing an ASCII string representing the key management
domain that the DSRK is being derived for. domain that the DSRK is being derived for.
In addition, channel binding information MAY be included: see In addition, channel binding information MAY be included: see
Section 5.5 for discussion. See Figure 11 for parameter Section 5.5 for discussion. See Figure 12 for parameter
specification. The server sends this information so that the specification. The server sends this information so that the
peer can verify the information seen at the lower layer, if peer can verify the information seen at the lower layer, if
channel binding is to be supported. channel binding is to be supported.
Cryptosuite: This field indicates the integrity algorithm and the Cryptosuite: This field indicates the integrity algorithm and the
PRF used for ERP. Key lengths and output lengths are either PRF used for ERP. Key lengths and output lengths are either
indicated or are obvious from the cryptosuite name. indicated or are obvious from the cryptosuite name.
Authentication Tag: This field contains the integrity checksum Authentication Tag: This field contains the integrity checksum
over the ERP packet, excluding the authentication tag field over the ERP packet, excluding the authentication tag field
skipping to change at page 30, line 16 skipping to change at page 31, line 16
The TV attributes that may be present in the EAP-Initiate or EAP- The TV attributes that may be present in the EAP-Initiate or EAP-
Finish messages are of the following format: Finish messages are of the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value ... | Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: TV Attribute Format Figure 11: TV Attribute Format
The TLV attributes that may be present in the EAP-Initiate or EAP- The TLV attributes that may be present in the EAP-Initiate or EAP-
Finish messages are of the following format: Finish messages are of the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... | Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: TLV Attribute Format Figure 12: TLV Attribute Format
The following Types are defined in this document: The following Types are defined in this document:
'1' - keyName-NAI: This is a TLV payload. '1' - keyName-NAI: This is a TLV payload.
'2' - rRK Lifetime: This is a TV payload. '2' - rRK Lifetime: This is a TV payload.
'3' - rMSK Lifetime: This is a TV payload. '3' - rMSK Lifetime: This is a TV payload.
'4' - domain name: This is a TLV payload. '4' - domain name: This is a TLV payload.
skipping to change at page 35, line 48 skipping to change at page 36, line 48
keys derived from it. Moreover, there is no forward secrecy keys derived from it. Moreover, there is no forward secrecy
within ERP. Thus, compromise of an DSRK retroactively within ERP. Thus, compromise of an DSRK retroactively
compromises all ERP keys. compromises all ERP keys.
It is RECOMMENDED that the AAA protocol be protected using It is RECOMMENDED that the AAA protocol be protected using
IPsec or TLS so that the keys are protected in transit. Note, IPsec or TLS so that the keys are protected in transit. Note,
however, that keys may be exposed to AAA proxies along the way however, that keys may be exposed to AAA proxies along the way
and compromise of any of those proxies may result in compromise and compromise of any of those proxies may result in compromise
of keys being transported through them. of keys being transported through them.
The home ER server MUST NOT hand out a given DSRK to a local The home EAP server MUST NOT hand out a given DSRK to a local
domain server more than once, unless it can verify that the domain server more than once, unless it can verify that the
entity receiving the DSRK after the first time is the same as entity receiving the DSRK after the first time is the same as
that received the DSRK originally. If the home ER server that received the DSRK originally. If the home EAP server
verifies authorization of a local domain server, it MAY hand verifies authorization of a local domain server, it MAY hand
out the DSRK to that domain more than once. In this case, the out the DSRK to that domain more than once. In this case, the
home ER server includes the Authorization Indication TLV to home EAP server includes the Authorization Indication TLV to
assure the peer that DSRK delivery is secure. assure the peer that DSRK delivery is secure.
Confirm cryptosuite selection Confirm cryptosuite selection
Crypto algorithms for integrity and key derivation in the Crypto algorithms for integrity and key derivation in the
context of ERP MAY be the same as that used by the EAP method. context of ERP MAY be the same as that used by the EAP method.
In that case, the EAP method is responsible for confirming the In that case, the EAP method is responsible for confirming the
cryptosuite selection. Furthermore, the cryptosuite is cryptosuite selection. Furthermore, the cryptosuite is
included in the ERP exchange by the peer and confirmed by the included in the ERP exchange by the peer and confirmed by the
server. The protocol allows the server to reject the server. The protocol allows the server to reject the
skipping to change at page 37, line 51 skipping to change at page 38, line 51
To prevent such DoS attacks, an ERP failure should not result in To prevent such DoS attacks, an ERP failure should not result in
deletion of any authorization state established by a full EAP deletion of any authorization state established by a full EAP
exchange. Alternatively, the lower layers and AAA protocols may exchange. Alternatively, the lower layers and AAA protocols may
define mechanisms to allow two link-layer security associations (SAs) define mechanisms to allow two link-layer security associations (SAs)
derived from different EAP keying materials for the same peer to derived from different EAP keying materials for the same peer to
exist so that smooth migration from the current link layer SA to the exist so that smooth migration from the current link layer SA to the
new one is possible during rekey. These mechanisms prevent the link new one is possible during rekey. These mechanisms prevent the link
layer connections from being terminated when a re-authentication layer connections from being terminated when a re-authentication
procedure fails due to the bogus EAP-Initiate/Re-auth message. procedure fails due to the bogus EAP-Initiate/Re-auth message.
When a DSRK is sent from a home ER server to a local domain server or When a DSRK is sent from a home EAP server to a local domain server
when a rMSK is sent from an ER server to an authenticator, in the or when a rMSK is sent from an ER server to an authenticator, in the
absence of end-to-end security between the entity that is sending the absence of end-to-end security between the entity that is sending the
key and the entity receiving the key, it is plausible for other key and the entity receiving the key, it is plausible for other
entities to get access to keys being sent to an ER server in another entities to get access to keys being sent to an ER server in another
domain. This mode of key transport is similar to that of MSK domain. This mode of key transport is similar to that of MSK
transport in the context of EAP authentication. We further observe transport in the context of EAP authentication. We further observe
that ERP is for access authentication and does not support end-to-end that ERP is for access authentication and does not support end-to-end
data security. In typical implementations, the traffic is in the data security. In typical implementations, the traffic is in the
clear beyond the access control enforcement point (the authenticator clear beyond the access control enforcement point (the authenticator
or an entity delegated by the authenticator for access control or an entity delegated by the authenticator for access control
enforcement). The model works as long as entities in the middle of enforcement). The model works as long as entities in the middle of
skipping to change at page 39, line 12 skipping to change at page 40, line 12
Extended Master Session Key (EMSK)", RFC 5295, Extended Master Session Key (EMSK)", RFC 5295,
August 2008. August 2008.
10.2. Informative References 10.2. Informative References
[I-D.ietf-dime-erp] [I-D.ietf-dime-erp]
Bournelle, J., Morand, L., Wu, W., and G. Zorn, "Diameter Bournelle, J., Morand, L., Wu, W., and G. Zorn, "Diameter
Support for the EAP Re-authentication Protocol (ERP)", Support for the EAP Re-authentication Protocol (ERP)",
draft-ietf-dime-erp-04 (work in progress), September 2010. draft-ietf-dime-erp-04 (work in progress), September 2010.
[I-D.ietf-dime-local-keytran]
, Q. and G. , "Diameter Attribute-Value Pairs for
Cryptographic Key Transport",
draft-ietf-dime-local-keytran-07 (work in progress),
July 2010.
[I-D.ietf-hokey-ldn-discovery]
Zorn, G., Wu, Q., and Y. Wang, "The Local Domain Name
DHCPv6 Option", draft-ietf-hokey-ldn-discovery-05 (work in
progress), September 2010.
[IEEE_802.1X] [IEEE_802.1X]
Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE
Standards for Local and Metropolitan Area Networks: Port Standards for Local and Metropolitan Area Networks: Port
based Network Access Control, IEEE Std 802.1X-2004", based Network Access Control, IEEE Std 802.1X-2004",
December 2004. December 2004.
[MSKHierarchy] [MSKHierarchy]
Lopez, R., Skarmeta, A., Bournelle, J., Laurent- Lopez, R., Skarmeta, A., Bournelle, J., Laurent-
Maknavicus, M., and J. Combes, "Improved EAP keying Maknavicus, M., and J. Combes, "Improved EAP keying
framework for a secure mobility access service", framework for a secure mobility access service",
skipping to change at page 40, line 35 skipping to change at page 41, line 45
Hoeper suggested the use of the windowing technique to handle Hoeper suggested the use of the windowing technique to handle
multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for multiple simultaneous ER exchanges. Many thanks to Pasi Eronen for
the suggestion to use hexadecimal encoding for rIKname when sent as the suggestion to use hexadecimal encoding for rIKname when sent as
part of keyName-NAI field. Thanks to Bernard Aboba for suggestions part of keyName-NAI field. Thanks to Bernard Aboba for suggestions
in clarifying the EAP lock-step operation, and Joe Salowey and Glen in clarifying the EAP lock-step operation, and Joe Salowey and Glen
Zorn for help in specifying AAA transport of ERP messages. Thanks to Zorn for help in specifying AAA transport of ERP messages. Thanks to
Sam Hartman for the DSRK Authorization Indication mechanism. Sam Hartman for the DSRK Authorization Indication mechanism.
A.2. RFC 5296bis A.2. RFC 5296bis
TBC Glen Zorn wrote the initial draft for this document and provided
useful reviews. Many thanks to him.
Appendix B. Example ERP Exchange Appendix B. Example ERP Exchange
0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start] 0. Authenticator --> Peer: [EAP-Initiate/Re-auth-Start]
1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI, 1. Peer --> Authenticator: EAP Initiate/Re-auth(SEQ, keyName-NAI,
cryptosuite,Auth-tag*) cryptosuite,Auth-tag*)
1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id, 1a. Authenticator --> Re-auth-Server: AAA-Request{Authenticator-Id,
EAP Initiate/Re-auth(SEQ,keyName-NAI, EAP Initiate/Re-auth(SEQ,keyName-NAI,
cryptosuite,Auth-tag*) cryptosuite,Auth-tag*)
2. ER-Server --> Authenticator: AAA-Response{rMSK, 2. ER-Server --> Authenticator: AAA-Response{rMSK,
skipping to change at page 41, line 26 skipping to change at page 42, line 29
2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI, 2b. Authenticator --> Peer: EAP-Finish/Re-auth(SEQ,keyName-NAI,
cryptosuite,[CB-Info],Auth-tag*) cryptosuite,[CB-Info],Auth-tag*)
* Auth-tag computation is over the entire EAP Initiate/Finish message; * Auth-tag computation is over the entire EAP Initiate/Finish message;
the code values for Initiate and Finish are different and thus the code values for Initiate and Finish are different and thus
reflection attacks are mitigated. reflection attacks are mitigated.
Authors' Addresses Authors' Addresses
Glen Zorn (editor) Qin Wu (editor)
Network Zen
1463 East Republican Street
#358
Seattle, Washington 98112
US
Email: gwz@net-zen.net
Qin Wu
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
101 Software Avenue, Yuhua District 101 Software Avenue, Yuhua District
Nanjing, JiangSu 210012 Nanjing, JiangSu 210012
China China
Email: Sunseawq@huawei.com Email: Sunseawq@huawei.com
Zhen Cao Zhen Cao
China Mobile China Mobile
53A Xibianmennei Ave., Xuanwu District 53A Xibianmennei Ave., Xuanwu District
Beijing, Beijing 100053 Beijing, Beijing 100053
P.R. China P.R. China
Email: caozhen@chinamobile.com Email: caozhen@chinamobile.com
Yang Shi
H3C Tech. Co., Ltd
Digital Technology Plaza, NO.9 Shangdi 9th Street,Haidian District
Beijing 100085
China
Email: young@h3c.com
Baohong He
China
Email: hebaohong@catr.cn
 End of changes. 54 change blocks. 
171 lines changed or deleted 211 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/