Network Working Group V. Narayanan
Internet-Draft L. Dondeti
Intended status: Standards Track QUALCOMM, Inc.
Expires: February 25, 2008 August 24, 2007
EAP Extensions for EAP Reauthentication Protocol (ERP)
draft-ietf-hokey-erx-04
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 25, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
The extensible authentication protocol (EAP) is a generic framework
supporting multiple types of authentication methods. In systems
where EAP is used for authentication, it is desirable to not repeat
the entire EAP exchange with another authenticator. This document
specifies, EAP Reauthentication Extensions (ERX), extensions to EAP
and EAP keying hierarchy to support a EAP method-independent protocol
for efficient Re-authentication between the peer and the server
through an authenticator.
Narayanan & Dondeti Expires February 25, 2008 [Page 1]
Internet-Draft ERP August 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ERP Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. ERP with a Local ER Server . . . . . . . . . . . . . . . . 6
4. ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Key Derivations and Properties . . . . . . . . . . . . . . 9
4.1.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . 9
4.1.2. rRK Properties . . . . . . . . . . . . . . . . . . . . 9
4.1.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . 10
4.1.4. rIK Properties . . . . . . . . . . . . . . . . . . . . 10
4.1.5. rIK usage . . . . . . . . . . . . . . . . . . . . . . 11
4.1.6. rMSK Derivation . . . . . . . . . . . . . . . . . . . 11
4.1.7. rMSK Properties . . . . . . . . . . . . . . . . . . . 12
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 12
5.1. ERP Bootstrapping . . . . . . . . . . . . . . . . . . . . 12
5.1.1. ERP Bootstrapping with a Local ER Server . . . . . . . 15
5.2. EAP Re-auth Protocol . . . . . . . . . . . . . . . . . . . 16
5.2.1. Failure Handling . . . . . . . . . . . . . . . . . . . 18
5.3. New EAP Messages . . . . . . . . . . . . . . . . . . . . . 18
5.3.1. EAP Initiate Re-auth Packet . . . . . . . . . . . . . 20
5.3.2. EAP Finish Re-auth Packet . . . . . . . . . . . . . . 22
5.3.3. EAP Initiate Re-auth-Start Packet . . . . . . . . . . 25
5.3.4. TV and TLV Attributes . . . . . . . . . . . . . . . . 26
5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 27
5.5. Channel Binding . . . . . . . . . . . . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. Example ERP Exchange . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 35
Narayanan & Dondeti Expires February 25, 2008 [Page 2]
Internet-Draft ERP August 2007
1. Introduction
The extensible authentication protocol (EAP) is a generic framework
for transport of methods that authenticate two parties; the
authentication is either one-way or mutual. The primary purpose is
network access control, and a key generating method is recommended to
enforce access control. The EAP keying hierarchy defines two keys
that are derived at the top level - the master session key (MSK) and
the extended MSK (EMSK). In the most common deployment scenario, a
peer and a server authenticate each other through a third party known
as the authenticator. The authenticator or an entity controlled by
the authenticator enforces access control. After successful
authentication, the server transports the MSK to the authenticator;
the authenticator and the peer derive transient session keys (TSK)
using the MSK as the authentication key or a key derivation key and
use the TSK for per-packet access enforcement.
When a peer moves from one authenticator to another, it is desirable
to avoid full EAP authentication. The full EAP exchange with another
run of the EAP method takes several round trips and significant time
to complete, causing delays in handoff times. Some EAP methods
specify the use of state from the initial authentication to optimize
Re-authentications by reducing the computational overhead, but
method-specific Re-authentication takes at least 2 roundtrips in most
cases (e.g., [8]). It is also important to note that many methods do
not offer support for Re-authentication. Thus, it is beneficial to
have efficient Re-authentication support in EAP rather than in
individual methods.
Key sharing across authenticators is sometimes used as a practical
solution to lower handoff times. In that case, compromise of an
authenticator results in compromise of EAP sessions established via
other authenticators.
In conclusion, there is a need to design an efficient EAP Re-
authentication mechanism that allows a fresh key to be established
between the peer and an authenticator without having to execute the
EAP method again. The EAP Re-authentication problem statement is
described in detail in [9].
This document specifies EAP Reauthentication Extensions (ERX) for
efficient re-authentication using EAP. The EAP Reauthentication
Protocol (ERP) based on ERX supports EAP method independent Re-
authentication for a peer that has valid, unexpired key material from
a previously performed EAP authentication. The protocol and the key
hierarchy required for EAP Reauthentication is described in this
document.
Narayanan & Dondeti Expires February 25, 2008 [Page 3]
Internet-Draft ERP August 2007
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
This document uses terminology defined in [2] and in [3]. In
addition, this document uses the following terms:
ER peer - An EAP peer that supports the EAP Re-authentication
protocol
ER Authenticator - An entity that supports the authenticator
functionality for EAP Reauthentication described in this document.
All references to "authenticator" in this document imply an ER
authenticator, unless specifically noted otherwise.
ER Server - An entity that performs the server portion of ERP
described here. This entity may or may not be an EAP server.
rRK - Re-authentication root Key, derived from the EMSK or DSRK.
rIK - Re-authentication Integrity Key, derived from the rRK.
rMSK - Re-authentication MSK. This is a per-authenticator key,
derived from the rRK.
3. ERP Overview
Figure 1 shows the protocol exchange. The first time the peer
attaches to an authenticator, it performs a full EAP exchange with
the EAP server; as a result an MSK is distributed to the
authenticator. The MSK is then used by the authenticator and the
peer to generate TSKs as needed. At the time of the initial EAP
exchange, the peer and the server derive a Re-authentication Root Key
(rRK). The rRK may be derived from the EMSK or from a Domain
Specific Root Key (DSRK). The rRK is only available to the peer and
the ER server and is never handed out to any other entity. Further,
a Re-authentication Integrity Key (rIK) is derived from the rRK; the
peer uses the rIK to provide proof of possession while performing an
ERP exchange at a later time. The rIK is also never handed out to
any entity and is only available to the peer and server.
At the time of the first EAP exchange, the peer may obtain a
server-id (either from the EAP method or via an out-of-band mechanism
from the server) for use in a subsequent exchange. The EAP Re-
authprotocol supports explicit bootstrapping using which a server ID
Narayanan & Dondeti Expires February 25, 2008 [Page 4]
Internet-Draft ERP August 2007
can be obtained by the peer. Alternatively, the peer may simply use
a key name to identify the full EAP session. Particularly, when the
ER state is duplicated among the different backend entities, a server
ID is not required. The server caches the rRK and rIK for the peer,
along with a key name.
Peer Authenticator Server
==== ============= ======
<--- EAP Request/ ------
Identity
----- EAP Response/ --->
Identity ---EAP Response/Identity-->
<------------ EAP Method exchange------------------->
<----MSK, EAP Success------
<---EAP Success---------
Peer Authenticator Server
==== ============= ======
[<-- EAP Request/ ------
Identity]
[<-- EAP Initiate/ ------
Reauth-Start]
---- EAP Initiate/ ----> ----EAP Initiate/ ---------->
Reauth/ Reauth/
[Bootstrap] [Bootstrap]
<--- EAP Finish/ ------> <---rMSK,EAP Finish/---------
Reauth/ Reauth/
[Bootstrap] [Bootstrap]
Figure 1: ERP Exchange
When the peer subsequently identifies a target authenticator that
supports EAP Reauthentication, it performs an ERP exchange, as shown
in Figure 1 as well; the exchange itself may happen when the peer
attaches to a new authenticator supporting EAP Reauthentication, or
prior to attachment. The peer initiates ERP by itself; it may also
Narayanan & Dondeti Expires February 25, 2008 [Page 5]
Internet-Draft ERP August 2007
do so in response to an EAP Request Identity or EAP Initiate Reauth-
Start message from the new authenticator. The EAP Initiate Reauth-
Start message allows the authenticator to initiate the ERP exchange.
It is plausible that the authenticator does not know whether the peer
supports ERP and whether it has performed a full EAP authentication
through another authenticator and hence the authenticator initiation
of the ERP exchange may require the authenticator to send both the
EAP Request Identity and EAP Initiate Reauth-Start messages.
ERX adds two new messages to EAP: EAP Initiate and EAP Finish
messages. The peer sends an EAP Initiate Re-auth message; it
includes peer-id and the server-id and/or a temporary NAI based on
the rIKname, and a sequence number for replay protection. The EAP
Initiate Re-auth message is integrity protected with the rIK. The
authenticator routes this message to the server indicated by the
server-id. If a server-id is not present, the message is routed
based on the rIKname when it is in the form of an NAI, and if rIK
name is also not present, the message is routed based on the peer-id.
The server uses the rIKname or the peer-id in that order to lookup
the rIK. If a server-id is present, the Authenticator MUST use that
identity in the AAA message so that AAA proxies route the message to
the correct server. If the server-id is not present, the
Authenticator uses NAI-based routing. The server, after verifying
proof of possession of the rIK, and freshness of the message, derives
a Re-authentication MSK (rMSK) from the rRK using the sequence number
as an input to the key derivation.
In response to the EAP Initiate Re-auth message, the server sends an
EAP Finish Re-auth message; this message is integrity protected with
the rIK. The server transports the rMSK along with this message to
the authenticator. The rMSK is transported in a manner similar to
that of the MSK along with the EAP Success message in a full EAP
exchange.
In an ERP bootstrap exchange, the peer may request the rRK lifetime
to be sent to it. If so, the ER server sends the lifetime along with
the EAP Finish Re-auth message.
The peer verifies the replay protection and the origin of the
message. It then uses the sequence number in the EAP Finish Re-auth
message to compute the rMSK. The lower layer security association
protocol is ready to be triggered after this point.
3.1. ERP with a Local ER Server
The defined ER extensions allow executing the ERP with a local ER
server that may be topologically closer to the authenticator. The
local ER server may be collocated with a local AAA server. The peer
Narayanan & Dondeti Expires February 25, 2008 [Page 6]
Internet-Draft ERP August 2007
may learn about the presence of a local ER server in the network and
the local domain (or ER server) name either via the lower layer or by
means of ERP bootstrapping. Figure 2 shows the full EAP and
subsequent local ERP exchange with a local ER server.
Peer Authenticator Local Server Home Server
==== ============= ========== ===========
<-- EAP Request/ -----
Identity
--- EAP Response/ --->
Identity --EAP Response/-->
Identity --EAP Response/Identity->
[DSRK Req, Domain Identity]
<------------------------ EAP Method exchange------------------>
<---MSK, DSRK, EAP Success--
<---MSK, EAP Success--
<---EAP Success---
Peer Authenticator Local Server
==== ============= ============
[<-- EAP Request/ ------
Identity]
[<-- EAP Initiate/ ------
Reauth-Start]
---- EAP Initiate/ ----> ----EAP Initiate/ ---------->
Reauth/ Reauth/
<--- EAP Finish/ ------> <---rMSK,EAP Finish/---------
Reauth/ Reauth/
Figure 2: Local ERP Exchange
As shown in Figure 2, 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
Narayanan & Dondeti Expires February 25, 2008 [Page 7]
Internet-Draft ERP August 2007
in the path between the authenticator and the home EAP server of the
peer). In that case, at the end of a full authentication exchange,
the DSRK may be provided to the local ER server. Alternatively, the
DSRK can be obtained at the time of an ERP bootstrap exchange with
the home server. The local ER server then computes a DS-rRK and a
DS-rIK (and the appropriate key names) from the DSRK as defined in
Section 4.1.1 and Section 4.1.3 below. The peer also derives the
DSRK, followed by the DS-rRK and the DS-rIK (and the appropriate key
names) following the EAP or ERP bootstrap exchange.
Subsequently, when the peer attaches to an authenticator within the
local ER domain, it may perform an ERP exchange with the local ER
server to obtain an rMSK for the new authenticator.
4. ER Key Hierarchy
We define a key hierarchy for ER, rooted at the rRK, and derived as a
result of a full EAP exchange. The rRK may be derived from an EMSK
or DSRK as specified in this document. For the purpose of rRK
derivation, this document derives a Usage Specific Root Key (USRK) or
a Domain Specific USRK (DS-USRK) in accordance with [3] for
Reauthentication. The USRK designated for Re-authentication is the
Re-authentication root key (rRK). A DS-USRK deisgnated for Re-
authentication is the DS-rRK available to a local ER server in a
particular domain. For simplicity, the keys are referred to without
the DS label in the rest of the document. However, the scope of the
various keys are limited to just the respective domains they are
derived for, in the case of the domain specific keys. Based on the
ER server with which the peer performs the ERP exchange, it knows the
corresponding keys that must be used.
The rRK is used to derive a rIK and one or more rMSKs. The figure
below shows the key hierarchy with the rRK, rIK and rMSKs.
rRK
|
+--------+--------+
| | |
rIK rMSK1 ...rMSKn
Figure 3: Re-authentication Key Hierarchy
Narayanan & Dondeti Expires February 25, 2008 [Page 8]
Internet-Draft ERP August 2007
4.1. Key Derivations and Properties
4.1.1. rRK Derivation
The rRK may be derived from the EMSK or DSRK. This section provides
the relevant key derivations for that purpose.
The rRK is derived using the prf+ operation defined in RFC4306 [4] as
follows.
rRK = prf+ (K, S), where,
K = EMSK or K = DSRK and
S = rRK Label
The rRK Label is an IANA-assigned ASCII string "EAP Re-authentication
Root Key" assigned from the Key Label name space in accordance with
[3]. This document specifies IANA registration for the rRK label
above.
The PRF used MAY be the same as that used by the EAP method - using
the PRF from the EAP method provides algorithm agility. Otherwise,
the default PRF used is HMAC-SHA-256.
Along with the rRK, a unique rRK name is derived to identify the rRK.
The rRK name is derived as follows.
rRK_name = prf-64 (rRK, "rRK Name")
where prf-64 is the first 64 bits from the output of the PRF. The
PRF is the same as that used in the derivation of the rRK.
4.1.2. rRK Properties
The rRK has the following properties. These properties apply to the
rRK regardless of the parent key used to derive it.
o The length of the rRK MUST at least be equal to the length of the
EMSK or DSRK derived by the corresponding EAP session.
o The rRK is to be used only as a root key for Re-authentication and
never used to directly protect any data.
o The rRK is only used for derivation of rIK and rMSK as specified
in this document.
Narayanan & Dondeti Expires February 25, 2008 [Page 9]
Internet-Draft ERP August 2007
o The rRK must remain on the peer and the server that derived it and
MUST NOT be transported to any other entity.
o The rRK is cryptographically separate from any other key derived
from its parent key.
o The lifetime of the rRK is never greater than that of its parent
key. The rRK is expired when the parent key expires and removed
from use at that time.
4.1.3. rIK Derivation
The Re-authentication Integrity Key (rIK) is used for integrity
protecting the ERP exchange. This serves as the proof of possession
of valid keying material from a previous full EAP exchange by the
peer to the server.
The rIK is derived from the rRK as follows.
rIK = prf+ (rRK, "Re-authentication Integrity Key")
The PRF used MAY be the same as that used by the EAP method - using
the PRF from the EAP method provides algorithm agility. Otherwise,
the default PRF used is HMAC-SHA-256.
The rIKname is derived as follows.
rIK_name = prf-64 (rRK, "rIKname")
where prf-64 is the first 64 bits from the output of the PRF. The
PRF is the same as that used in the derivation of the rIK.
4.1.4. rIK Properties
The rIK has the following properties.
o The length of the rIK MUST be equal to the length of the rRK.
o The rIK is only used for authentication of the ERP exchange as
specified in this document.
o The rIK MUST NOT be used to derive any other keys.
o The rIK must remain on the peer and the server and MUST NOT be
transported to any other entity.
o The rIK is cryptographically separate from any other keys derived
from the rRK.
Narayanan & Dondeti Expires February 25, 2008 [Page 10]
Internet-Draft ERP August 2007
o The lifetime of the rIK is never greater than that of its parent
key. The rIK is expired when the EMSK expires and removed from
use at that time.
4.1.5. rIK usage
The rIK is the key whose possession is demonstrated by the peer and
the ERP server to the other party. The peer demonstrates possession
of the rIK by computing the integrity checksum over the EAP Initiate
Re-auth message. When the peer uses the rIK for the first time, it
can choose the integrity algorithm to use with the rIK. The peer and
the server MUST use the same integrity algorithm with a given rIK for
all ERP messages protected with that key. The peer and the server
store the algorithm information after the first use and the same
algorithm for all subsequent uses of that rIK.
The rIK length may exceed the key length requirements of an integrity
algorithm. When using hash-based integrity algorithms, the key is
first hashed to reduce the size to the required key length[5]. When
using cipher-based integrity algorithms, the key is reduced in size
using the technique specified in [10]. Generalizing, the integrity
key is derived as follows: integrity key = Cipher-based-MAC(0^block-
size, rIK, rIK-length).
4.1.6. rMSK Derivation
The rMSK is derived at the peer and server and delivered to the
authenticator. The rMSK is derived following an EAP Re-auth protocol
exchange.
The rMSK is derived from the rRK as follows.
rMSK = prf+ (rRK, SEQ), where
The SEQ is the sequence number sent by the peer in the EAP Initiate
Re-auth message.
The PRF may be specified in the EAP Re-auth message. The default PRF
used is HMAC-SHA-256.
The rMSK name is derived as follows.
rMSK_name = prf-64 (rRK, "rMSK Name")
where prf-64 is the first 64 bits from the output of the PRF. The
PRF may be specified in the EAP Re-auth message.
Narayanan & Dondeti Expires February 25, 2008 [Page 11]
Internet-Draft ERP August 2007
4.1.7. rMSK Properties
The rMSK has the following properties:
o The length of the rMSK SHOULD be the same as that of the MSK
derived earlier in the EAP session at the time of the full EAP
exchange. The length of the rMSK MUST be at least 64 octets in
length.
o The rMSK is delivered to the authenticator and is used for the
same purposes that an MSK is used at an authenticator.
o The rMSK is cryptographically separate from any other keys derived
from the rRK.
o The lifetime of the rMSK is less than or equal to that of the rRK.
It MUST NOT be greater than the lifetime of the rRK.
o If a new rRK is derived, subsequent rMSKs must be derived from the
new rRK. Previously delivered rMSKs may still be used until the
expiry of the lifetime.
o A given rMSK MUST NOT be shared by multiple authenticators.
5. Protocol Description
ERP allows a peer and server to verify proof of possession of keying
material from an earlier EAP method run and establish a security
association between the peer and an authenticator. The authenticator
acts as a pass-through entity for the Re-auth protocol in a manner
similar to that described in RFC 3748 [2]. ERP is a single roundtrip
exchange between the peer and the server; it is independent of the
lower layer and the EAP method used during the full EAP exchange.
5.1. ERP Bootstrapping
The first time the peer attaches to an authenticator, it performs a
full EAP exchange, which results in the MSK being distributed to the
authenticator. The MSK is then used by the authenticator as defined
by specific lower layers. At the time of the initial EAP exchange,
the peer and the server also derive an EMSK. Next, the peer and the
server derive the rRK and the rIK as soon as the EMSK is available
with the anticipation that ERP may be used by the peer if it plans to
move to a new authenticator. The rIKname is also derived to serve as
the index to the rIK to process ERP messages.
We identify two types of bootstrapping for ERP: explicit and implicit
Narayanan & Dondeti Expires February 25, 2008 [Page 12]
Internet-Draft ERP August 2007
bootstrapping. There are at least two scenarios to consider for Re-
authentication. When the Re-auth messages are routed to the target
domain, they may or may not be routed to the server that holds the
rRK and the rIK. This is not an issue when there is a single ER
server in the domain or when the state is synchronized across all
servers in the domain. In that case, the peer does not need to know
the identity of the server that holds the Re-authentication keys.
There is also the case of the peer knowing the server id through
other means, say via the EAP method or through out of band
mechanisms. In those cases, ER bootstrapping is implicit. The peer
initiates an ERP exchange when it associates with a new
authenticator.
The peer may initiate an explicit ER bootstrapping exchange if the
server id is not available or if it is not known that the server id
is valid or when it is not known that the server state is
synchronized. In this case, the peer initiates the EAP Re-auth
exchange, with the bootstrapping flag turned on, immediately after
the full EAP authentication finishes. The following steps summarize
the process:
o The peer sends the EAP Initiate Re-auth message with the
bootstrapping flag turned on. It is RECOMMENDED that the
authenticator hold on to the state (e.g., called station id in
RADIUS) that allows all messages of a full EAP conversation to be
routed to the same server. The EAP Initiate Re-auth message
contains one or more TLVs containing identification information to
assist the authenticator further in routing the message to the
appropriate server -- in this case to the server that holds the
EMSK, rRK and rIK.
* It is mandatory to send the rIKname either by itself, or as
part of an NAI. The authenticator may use the NAI to route the
EAP Re-auth Bootstrap Initiate message.
* When the rIKname is not in the form of an NAI, the peer-id may
be included. The peer-id may be in the form of a pseudonym for
identity privacy.
o In addition to the identities, the message contains a sequence
number for replay protection, a crypto-suite, and an integrity
checksum. The crypto-suite indicates the authentication
algorithm. The integrity checksum indicates that the message
originated at the claimed entity, the peer indicated by the
peer-id, or the rIKname.
o The peer may additionally set the lifetime flag to request that
the rRK lifetime be sent to it.
Narayanan & Dondeti Expires February 25, 2008 [Page 13]
Internet-Draft ERP August 2007
o When an ERP capable authenticator receives EAP Initiate Re-auth
message from a peer, it looks for local EAP forwarding state
corresponding to the peer's lower layer address and forwards the
message accordingly. This forwarding is similar to that of
messages of an EAP conversation. It is RECOMMENDED that an ERP
capable authenticator store that forwarding information for a
finite amount of time after the EAP Success message has been sent
to the peer.
* In the absence of forwarding state, the authenticator parses
the message for the server-id. If that is present, the message
is forwarded via AAA to that server.
* If a server-id is not present, the authenticator parses the EAP
Initiate Re-auth message to locate the rIKname, and if the
rIKname is in the NAI form, uses that domain identity to
forward the message.
* Otherwise, it finds the peer-id and uses the realm portion of
the peer-id to route the EAP message to the appropriate server.
o Upon receipt of an EAP Initiate Re-auth message, the server
verifies whether the message is fresh or a replay by evaluating
whether the received sequence number is equal to or greater than
the expected sequence number for that rIK. Next, it verifies the
origin authentication of the message by looking up the rIK. If
any of the checks fail, the server sends an EAP Finish Re-auth
message with the relevant error value. This error MUST NOT have
any correlation to any EAP Success message that may have been
received by the authenticator and the peer earlier. If the EAP
Initiate Re-auth message is well-formed and valid, the server
prepares the EAP Finish Re-auth message. The bootstrap flag is
set to indicate that this is a bootstrapping exchange. The
message contains the following fields:
* one or more server identities so that the peer can reach a
server for Re-authentication through authenticators other than
the initial authenticator. It is plausible that no server-id
TLVs exist in the EAP Finish Re-auth message. In that case, it
is assumed that server side state is replicated in all the
servers in the corresponding domain.
* A sequence number for replay protection.
* The rIKname so that the peer can correctly identify the rIK to
verify the integrity and origin authentication of the Finish
message.
Narayanan & Dondeti Expires February 25, 2008 [Page 14]
Internet-Draft ERP August 2007
* If the lifetime flag was set in the EAP Initiate Re-auth
message, the ER server SHOULD include the rRK lifetime in the
EAP Finish Re-auth message.
* An authentication tag to prove that the EAP Finish Re-auth
message originates at a server that possesses the rIK
corresponding to the rIKname.
o In addition, the rMSK is sent along with the EAP Finish Re-auth
message, in a AAA attribute.
Since the ER bootstrapping exchange is typically done immediately
following the full EAP exchange, it is feasible that the process is
completed through the same entity that served as the EAP
authenticator for the full EAP exchange. In this case, the lower
layer may already have derived the TSKs based on the MSK received
earlier. The lower layer may then choose to ignore the rMSK that was
received with the ER bootstrapping exchange. Alternatively, the
lower layer may choose to generate a TSK from the rMSK. However, the
bootstrapping exchange may be carried out via a new authenticator, in
which case, the rMSK received is used by the lower layer.
5.1.1. ERP Bootstrapping with a Local ER Server
When a local ER server is present, it may be in the path of the full
EAP exchange performed by the peer. In this case, the local ER
server SHOULD include a request for DSRK and its domain or server
name along with the AAA message encapsulating the first EAP Response
message sent by the peer. If the EAP exchange is successful, the
server sends a DSRK (for the local ER server) along with the EAP
Success message. The local ER server MUST extract the DSRK, if
present, before forwarding the EAP Success message to the peer [11].
Note that the MSK (also present along with the EAP Success message)
is still extracted by the authenticator as usual.
If the peer performs an ERP bootstrapping exchange when a local ER
server is present, the local ER server MUST include the DSRK request
and its domain identity in the AAA message encapsulating the EAP
Initiate Re-auth message sent by the peer. If the exchange is
successful, the home ER server MUST include a DSRK along with the EAP
Finish Re-auth message. The local ER server MUST extract the DSRK,
if present, before forwarding the EAP Finish Re-auth message to the
peer.
When the server receives an EAP Initiate Re-auth message with the
bootstrap flag set along with a DSRK request, it SHOULD return the
domain or local ER server ID to which the DSRK was sent, in the EAP
Finish Re-auth message. The other processing rules for the ERP
Narayanan & Dondeti Expires February 25, 2008 [Page 15]
Internet-Draft ERP August 2007
bootstrapping exchange specified in Section 5.1 apply as well.
When the peer receives an EAP Finish Re-auth message with the
bootstrap flag set, if a local domain or server ID is present, it
MUST use that to derive the appropriate DSRK, DS-rRK and DS-rIK. If
not, the peer SHOULD derive the domain specific keys using the domain
identity it learnt via the lower layer. If the peer has no available
domain identity, it must assume that there is no local ER server
available.
The RADIUS attributes required to carry the DSRK request, local
domain identity and the DSRK itself along with the encapsulated EAP
messages are specified in [11].
5.2. EAP Re-auth Protocol
When a peer that has an active rRK and rIK identifies a new/target
authenticator that supports ERX, it may perform an ERP exchange with
the new authenticator supporting ERX. ERP is typically a peer-
initiated exchange, consisting of an EAP Initiate Re-auth and an EAP
Finish Re-auth message. The ERP exchange may be performed with a
local ER server (when one is present) or with the original EAP
server.
It is plausible for the network to trigger the EAP Re-authentication
process however. When an ERP capable authenticator sends an EAP
Request Identity the peer may in response initiate the EAP Re-
authentication exchange. Additionally, an ERP capable authenticator
may also send an EAP Initiate/Reauth-Start message to indicate
support for ERP. The peer may or may not wait for these messages to
arrive to initiate the EAP Initiate Re-auth message.
Notes on authenticator state machine:
If an authenticator that is waiting on an EAP Response after sending
an EAP Request packet to the peer receives an EAP Initiate Re-auth
packet from the peer, it should follow the EAP Re-authentication
exchange and determine Success or Failure of the exchange based on
the success or failure of the EAP Re-authentication exchange itself.
The authenticator SHOULD also cancel any retransmission timers
associated with the EAP Request packet. The same behavior applies
when the authenticator sends an EAP Initiate Reauth-Start message to
the peer and receives an EAP Initiate Re-auth packet from the peer as
well.
The EAP Initiate Reauth-Start message is sent by an ERP capable
authenticator; it is retransmitted as many times as the EAP Request
Identity message but has a different Identifier value. The EAP
Narayanan & Dondeti Expires February 25, 2008 [Page 16]
Internet-Draft ERP August 2007
Initiate Re-auth message from the peer may have originated before the
peer receives any of the two messages from the authenticator and thus
the Identifier value in the EAP Initiate Re-auth message is
independent of the Identifier value in the EAP Initiate Re-auth Start
and the EAP Request Identity messages.
Operational Considerations at the Peer:
ERP requires that the peer maintain retransmission timers for
reliable transport of EAP Re-authentication messages. The
reliability considerations of Section 4.3 of RFC 3748 apply with the
peer as the retransmitting entity.
The EAP Re-auth protocol has the following steps:
The peer sends an EAP Initiate Re-auth message including one or
more identity TLVs: the rIKname, and optionally the peer-id and/or
the server-id; also included are the peer's rIK sequence number,
and a crypto-suite indicating the cryptographic algorithms used.
The message is integrity protected with the rIK. When the peer is
performing ERP with a local ER server, it MUST use the
corresponding DS-rIK it shares with the local ER server. The peer
sets the lifetime flag to request the rRK lifetime from the
server. It may learn this to know when to trigger an EAP method
exchange.
The authenticator routes the EAP Initiate Re-auth message to the
server indicated by the server-id. If the server-id is not
present, the rIKname, if in the form of an NAI MUST be used to
route the message. If neither the server-id nor the rIKname in
the form of NAI are present, the peer-id MUST be used to forward
the message via AAA.
The server uses the rIKname to lookup the rIK. It first verifies
whether the sequence number is equal to or greater than the
expected sequence number. The server then proceeds to verify the
integrity of the message using the rIK, thereby verifying proof of
possession of that key by the peer. If the verifications fail,
the server sends an EAP Finish Re-auth message with the Result
flag set to '1' (Failure). Otherwise, it computes an rMSK from
the rRK using the sequence number as the additional input to the
key derivation.
The server then sends an EAP Finish Re-auth message containing the
rIK sequence number and the rIKname. The sequence number MUST be
same as the received sequence number. The local copy of the
sequence number is incremented by 1. The EAP Finish Re-auth
message is also integrity protected with the rIK. The server may
Narayanan & Dondeti Expires February 25, 2008 [Page 17]
Internet-Draft ERP August 2007
include the server-id with this message.
If the lifetime flag was set in the EAP Initiate Re-auth message,
the ER server SHOULD include the rRK lifetime in the EAP Finish
Re-auth message.
The server transports the rMSK along with this message 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
exchange.
The peer looks up the sequence number to verify whether it is
expecting a EAP Finish Re-auth message with that sequence number.
It then looks up the rIKname and verifies the integrity of the
message. This also verifies the proof of possession of the rIK at
the server. If the verifications fail, the peer logs an error and
stops the process; otherwise, it proceeds to the next step.
The peer uses the sequence number to compute the rMSK.
The lower layer security association protocol can be triggered at
this point.
5.2.1. Failure Handling
If the processing of the EAP Initiate Re-auth message results in a
failure, the ER server MUST send an EAP Finish Re-auth message with
the Result flag set to '1'. If the server has a valid rIK for the
peer, it MUST integrity protect the EAP Finish Re-auth failure
message.
The peer, upon receiving an EAP Finish Re-auth message with the
Result flag set to '1', MUST verify the sequence number and the
Authentication Tag to determine the validity of the message. If the
replay and integrity checks are successful, the peer MUST assume
failure of the exchange and terminate the ER state machine. If the
replay and/or integrity checks fail, it may mean that the server did
not have the rIK for the peer or that the failure message was sent by
an attacker. Hence, in this case, the peer SHOULD continue the ERP
exchange per the retransmission timers before declaring a failure.
5.3. New EAP Messages
Two new EAP Codes are defined for the purpose of ERP: EAP Initiate
and EAP Finish. The packet format for these messages follows the EAP
packet format defined in RFC3748 [2].
Narayanan & Dondeti Expires February 25, 2008 [Page 18]
Internet-Draft ERP August 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 4: EAP Packet
Code
5 Initiate
6 Finish
Two new code values are defined for the purpose of ERP. The
code values itself are TBD based on IANA assignment.
Identifier
The Identifier field is one octet. The Identifier field MUST
be the same if a Initiate Re-auth packet is retransmitted due
to a timeout while waiting for a Finish message. Any new (non-
retransmission) Initiate message MUST use a new Identifier
field.
The Identifier field of the Finish Re-auth message MUST match
that of the currently outstanding Initiate Re-auth message. A
Peer or Authenticator receiving a Finish Re-auth message whose
Identifier value does not match that of the currently
outstanding Initiate Re-auth message MUST silently discard the
packet.
In order to avoid confusion between new EAP Initiate Re-auth
messages and retransmissions, the peer must choose a an
Identifier value that is different from the previous Initiate
message, especially if that exchange has not finished. It is
RECOMMENDED that the authenticator clear EAP Re-auth state
after 300 seconds.
Type
This field indicates that this is an ERP exchange. Two type
values are defined in this document for this purpose - Re-auth
(assigned Type 1), Re-auth-Start (assigned Type 2).
Narayanan & Dondeti Expires February 25, 2008 [Page 19]
Internet-Draft ERP August 2007
Type-Data
The Type-Data field varies with the Type of Re-authentication
packet.
5.3.1. EAP Initiate Re-auth Packet
The EAP Initiate Re-auth packet contains the parameters shown in
Figure 5 :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|B|L| Reserved| SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto-Suite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: EAP Initiate Re-auth Packet
Type = 1.
Flags
'R' - The R flag is set to 0 and ignored upon reception.
'B' - The B flag is used as the bootstrapping flag. If the
flag is turned on, the message is a bootstrap message.
'L' - The L flag is used to request the rRK lifetime from the
server.
The rest of the 5 bits are set to 0 and ignored on reception.
SEQ: A 16-bit sequence number is used for replay protection. The
SEQ number field is initialized to zero every time a new rRK is
derived.
Narayanan & Dondeti Expires February 25, 2008 [Page 20]
Internet-Draft ERP August 2007
TVs or TLVs: In the TV payloads, there is a 1-octet type payload
and a value with type-specific length. In the TLV payloads, there
is a 1-octet type payload and a 1-octet length payload. The
length field indicates the length of the value expressed in number
of octets.
rIKname: This is carried in a TV payload. The Type is 1 and
the value is a 64-bit field computed as specified in Section
Section 4.1.3 and is used to identify the rIK with which the
ERP messages are protected.
rIKname as NAI: This is carried in a TLV payload. The Type is
2. The NAI is variable in length, not exceeding 256 octets.
If the rIK is derived from the EMSK, the realm part of the NAI
is the home domain identity and if the rIK is derived from a
DSRK, the realm part of the NAI is the domain identity used in
the derivation of the DSRK. The computed rIKname itself serves
as the username part of the NAI.
Peer-Id: This is a TLV payload. The Type is 3. The Peer-Id is
the NAI of the peer, and is variable in length, not exceeding
256 octets.
Server-Id: This is a TLV payload. The Type is 4. The
Server-Id is the FQDN of the server; it is variable in length,
not exceeding 256 octets. Other types of server IDs such as IP
addresses may be considered in future revisions of the draft.
ER capable authenticators SHOULD use this field to route the
EAP Initiate Re-auth Packet. If local policy dictates
otherwise, the packet may be routed based on the peer-Id.
Authenticator Identifier: This is a TLV payload. The Type is
TBD (see Section 5.5 for additional discussion). The server
sends the Authenticator Identifier so that the peer can verify
the identity seen at the lower layer, if channel binding is to
be supported.
Crypto Suite: This field indicates the integrity and if necessary
the encryption algorithm used for ERP. Key lengths and output
lengths are either indicated or are obvious from the crypto suite
name.
Authentication Tag: This field contains the integrity checksum
over the ERP packet. The length of the field is indicated by the
Crypto Suite.
Narayanan & Dondeti Expires February 25, 2008 [Page 21]
Internet-Draft ERP August 2007
5.3.1.1. Peer Operation
When an ER capable peer receives an EAP Request Identity message from
an Authenticator, it checks to see if it has valid EAP state from a
previous EAP authentication. If the peer has state from a previous
authentication, and if it knows that the Authenticator is ER capable,
it sends an EAP Initiate Re-auth message instead of an EAP Response
Identity message. The peer may, upon attachment to an authenticator
send an EAP Initiate Re-auth message in an unsolicited manner.
5.3.1.2. Authenticator Operation
If the Authenticator does not recognize the EAP Initiate Code, it
silently discards the EAP Initiate Re-auth message.
An ER capable Authenticator looks for the server ID in the EAP
Initiate Re-auth message to route the packet to the correct server.
This is the RECOMMENDED mode of operation.
The appropriate domain may be available as part of the rIKName.
The Authenticator sends the message just as it forwards other EAP
messages to the EAP server.
5.3.1.3. Server Operation
The server uses the following steps in processing EAP Re-
authentication messages:
The server uses the rIKname to lookup the rIK. It first verifies
whether the sequence number is equal to or greater than the
expected sequence number. The server then proceeds to verify the
integrity of the message using the rIK, thereby verifying proof of
possession of that key by the peer. If the verifications fail,
the server sends an EAP Finish Re-auth message with a Failure
indication. Otherwise, it computes an rMSK from the rRK using the
sequence number.
5.3.2. EAP Finish Re-auth Packet
The EAP Finish Re-auth packet contains the parameters shown in
Figure 6 :
Narayanan & Dondeti Expires February 25, 2008 [Page 22]
Internet-Draft ERP August 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type |R|B|L| Reserved | SEQ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto-Suite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: EAP Finish Re-auth Packet
Type = 1.
Flags
'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.
'B' - The B flag is used as the bootstrapping flag. If the
flag is turned on, the message is a bootstrap message.
'L' - The L flag is used to indicate the presence of the rRK
lifetime TLV.
The rest of the 5 bits are set to 0 and ignored on reception.
SEQ: A 16-bit sequence number is used for replay protection. The
SEQ number field is initialized to zero every time a new rRK is
derived.
TVs or TLVs: In the TV payloads, there is a 1-octet type payload
and a value with type-specific length. In the TLV payloads, there
is a 1-octet type payload and a 1-octet length payload. The
length field indicates the length of the value expressed in number
of octets.
rIKname: This is carried in a TV payload. The Type is 1 and
the value is a 64-bit field computed as specified in Section
Section 4.1.3 and is used to identify the rIK with which the
ERP messages are protected.
Narayanan & Dondeti Expires February 25, 2008 [Page 23]
Internet-Draft ERP August 2007
rIKname as NAI: This is carried in a TLV payload. The Type is
2. The NAI is variable in length, not exceeding 256 octets.
If the rIK is derived from the EMSK, the realm part of the NAI
is the home domain identity and if the rIK is derived from a
DSRK, the realm part of the NAI is the domain identity used in
the derivation of the DSRK.
Peer-Id: This is a TLV payload. The Type is 3. The Peer-Id is
the NAI of the peer, and is variable in length, not exceeding
256 octets.
Server-Id: This is a TLV payload. The Type is 4. The
Server-Id is the FQDN of the server; it is variable in length,
not exceeding 256 octets. Other types of server IDs such as IP
addresses may be considered in future revisions of the draft.
Authenticator Identifier: This is a TLV payload. The Type is
TBD (see Section 5.5 for additional discussion). The server
sends the Authenticator Identifier so that the peer can verify
the identity seen at the lower layer, if channel binding is to
be supported.
Crypto Suite: This field indicates the integrity and if necessary
the encryption algorithm used for ERP. Key lengths and output
lengths are either indicated or are obvious from the crypto suite
name.
Authentication Tag: This field contains the integrity checksum
over the ERP packet. The length of the field is indicated by the
Crypto Suite.
5.3.2.1. Server Operation
The server then sends an EAP Finish Re-auth message containing the
rIK sequence number, and the rIKname; this message is also integrity
protected with the rIK. The server may include one or more server-
ids with this message. The server-id is for the peer to use to send
future ERP messages.
The server transports the rMSK along with this message 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
exchange.
5.3.2.2. Authenticator Operation
The Authenticator Operation is similar to that in processing an EAP
success message. It extracts the rMSK just as it does an MSK from a
Narayanan & Dondeti Expires February 25, 2008 [Page 24]
Internet-Draft ERP August 2007
AAA message containing an EAP success packet [11].
5.3.2.3. Peer Operation
The peer uses the following steps in processing an EAP Finish Re-auth
message:
The peer first checks if the identifier in the EAP Finish Re-auth
message is the expected value.
The peer then checks to see if the sequence number in the received
message is the same as the sequence number in the EAP Initiate Re-
auth message; otherwise it logs an error.
Next, it uses the rIKname to lookup the appropriate rIK and
verifies the integrity of the message. If the verification
succeeds, it proceeds to the next step; otherwise, it logs an
error.
The peer then uses the sequence number and the peer-id to compute
the rMSK.
The lower layer security association protocol can be triggered at
this point.
5.3.3. EAP Initiate Re-auth-Start Packet
The EAP Initiate Re-auth packet contains the parameters shown in
Figure 7 :
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: EAP Initiate Re-auth-Start Packet
Type = 2.
Reserved, MUST be zero. Set to zero on transmission and ignored
on reception.
Narayanan & Dondeti Expires February 25, 2008 [Page 25]
Internet-Draft ERP August 2007
One or more TVs or TLVs are used to convey information to the
peer; for instance the authenticator may send domain identity to
the peer.
5.3.3.1. Authenticator Operation
The authenticator optionally sends the EAP Initiate Reauth-Start
message to indicate support for ERP to the peer and to initiate ERP
if the peer has already performed full EAP authentication and has
unexpired key material. The authenticator may include the domain
identity to allow the peer to learn it without lower layer support or
the ERP bootstrapping exchange.
The authenticator may re-transmit the EAP Initiate Reauth-Start
message a few times for reliable transport.
5.3.3.2. Peer Operation
The peer may send the EAP Initiate Re-auth message in response to the
EAP Initiate/Reauth-Start message from the authenticator. If the
peer does not recognize the Initiate code value, it silently discards
the message.
If the EAP Initiate Reauth-Start message contains the domain
identity, and if the peer does not already have the domain
information, the peer uses the domain identity to compute the DSRK
and uses the corresponding DS-rIK to send an EAP Initiate Re-auth
message in response.
5.3.4. TV and TLV Attributes
The TV attributes that may be present in the EAP Initiate or EAP
Finish messages are of the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: TV Attribute Format
The TLV attributes that may be present in the EAP Initiate or EAP
Finish messages are of the following format:
Narayanan & Dondeti Expires February 25, 2008 [Page 26]
Internet-Draft ERP August 2007
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: TLV Attribute Format
The following Types are defined in this document:
'1' - rIKname: TV Payload
'2' - rIKname as NAI: This is a TLV payload
'3' - Peer-Id: This is a TLV payload
'4' - Server-Id: This is a TLV payload
'5' - Domain Identity: This is a TLV payload
The TLV type range of 128-191 is reserved to carry channel binding
information in the EAP Initiate and Finish Re-auth messages.
Below are the current assignments (all of them are TLVs):
'128' - Called-Station-Id
'129' - Calling-Station-Id
'130' - NAS-Identifier
'131' - NAS-IP-Address
'132' - NAS-IPv6-Address
5.4. Replay Protection
For replay protection, ERP uses sequence numbers. The sequence
number is maintained per rIK and is initialized to zero in both
directions. In the first EAP Initiate Re-auth message, the peer uses
the sequence number zero or higher. Note that the when the sequence
number rotates, the rIK MUST be changed. The server expects a
sequence number of zero or higher. When the server receives an EAP
Initiate Re-auth message, it uses the same sequence number in the EAP
Finish Re-auth message. It increments the expected sequence number
by 1.
If the peer sends an EAP Initiate Re-auth message, but does not
Narayanan & Dondeti Expires February 25, 2008 [Page 27]
Internet-Draft ERP August 2007
receive a response, it retransmits the request (with no changes to
the message itself) a pre-configured number of times before giving
up. However, it is plausible that the server itself may have
responded to the message and it was lost in transit. Thus the peer
MUST increment the sequence number and use the new sequence number to
send subsequent EAP Re-authentication messages.
5.5. Channel Binding
ERP provides a protected facility to carry channel binding (CB)
information, according to the guidelines in Section 7.15 of [2]. The
TLV type range of 128-191 is reserved to carry CB information in the
EAP Initiate and Finish Re-auth messages. Called-Station-Id,
Calling-Station-Id, NAS-Identifier, NAS-IP-Address, and NAS-IPv6-
Address are some examples of channel binding information listed in
RFC 3748 and they are assigned values 128-132. Other values may be
added in future versions of this draft and the rest are IANA managed
based on IETF Consensus [6].
6. Security Considerations
This section provides an analysis of the protocol in accordance with
the AAA key management requirements specified in [12].
Cryptographic Algorithm Independence
The EAP Re-auth protocol satisfies this requirement. The
algorithm chosen by the peer for the PRF used in key derivation
as well as for the MAC generation is indicated in the EAP Re-
authentication Response message. If the chosen algorithms are
unacceptable, the EAP server returns an EAP Failure message in
response. Only when the specified algorithms are acceptable,
the server proceeds with derivation of keys and verification of
the proof of possession of relevant keying material by the
peer. A full blown negotiation of algorithms cannot be
provided in a single roundtrip protocol. Hence, while the
protocol provides algorithm agility, it does not provide true
negotiation.
Strong, fresh session keys
ERP results in the derivation of strong, fresh keys that are
unique for the given session. An rMSK is always derived on-
demand when the peer requires a key with a new authenticator.
Both the peer and the server contribute nonces that are used in
the rMSK derivation. Further, the compromise of one rMSK does
not result in the compromise of a different rMSK at any time.
Narayanan & Dondeti Expires February 25, 2008 [Page 28]
Internet-Draft ERP August 2007
Limit key scope
The scope of all the keys derived by ERP are well defined. The
rRK and rIK are never shared with any entity and always remain
on the peer and the server. The rMSK is provided only to the
authenticator through which the peer performs the ERP exchange.
No other authenticator is authorized to use that rMSK.
Replay detection mechanism
For replay protection of ERP messages, a sequence number
associated with the rIK is used. The sequence number is
maintained by the peer and the server, and initialized to zero
when the rIK is generated. The peer increments the sequence
number by one after it sends an ERP message. The server
increments the sequence number when it receives and responds to
the message.
Authenticate all parties
The EAP Re-auth protocol provides mutual authentication of the
peer and the server. Both parties need to possess the keying
material resulted from a previous EAP exchange in order to
successfully derive the required keys. Also, both the EAP Re-
authentication Response and the EAP Re-authentication
Information messages are integrity protected so that the peer
and the server can verify each other.
Keying material confidentiality
The peer and the server derive the keys independently using
parameters known to each entity. The rMSK is sent to the
authenticator via the AAA protocol. It is RECOMMENDED that the
AAA protocol be protected using IPsec or TLS so that the key
can be sent encrypted to the authenticator.
Confirm ciphersuite selection
The same ciphersuite used as a result of the EAP session to
which a particular ERP exchange corresponds is used after the
ERP exchange as well. The EAP method executed during the full
EAP exchange is responsible for confirming the ciphersuite
selection.
Prevent the domino effect
The compromise of one peer does not result in the compromise of
keying material held by any other peer in the system. Also,
Narayanan & Dondeti Expires February 25, 2008 [Page 29]
Internet-Draft ERP August 2007
the rMSK is meant for a single authenticator and is not shared
with any other authenticator. Hence, the compromise of one
authenticator does not lead to the compromise of sessions or
keys held by any other authenticator in the system. Hence, the
EAP Re-auth protocol allows prevention of the domino effect by
appropriately defining key scopes.
Bind key to its context
All the keys derived for ERP are bound to the appropriate
context using appropriate key labels. Also, the rMSK is bound
to the peer and server IDs.
In addition, a denial of service attack may be possible using the EAP
Iniaite/Re-auth message. The attacker sends a bogus EAP Initiate Re-
auth message, which may be carried by the authenticator in a RADIUS-
Access-Challenge to the server; in response to that the server may
send a RADIUS- Access-Reject. Note that such attacks may be
plausible with the EAP-Start capability of 802.11 and other similar
facilities in other link layers and where the peer can initiate EAP
authentication; an attacker may use such message to start an EAP
method run, which fails and may result in the server sending a
RADIUS-Access-Reject message. To mitigate the impact of such DoS
attacks, the authenticator must not tear down any link layer
connections as long as there is at least one active MSK and an active
RADIUS session (e.g., lifetime has not expired). It appears that
some implementations at the time of this writing already employ such
mitigation techniques.
7. IANA Considerations
This document requires IANA registration of two new EAP Codes: 5
(Initiate) and 6 (Finish). These values are in accordance with [2].
This document also requires IANA registration of two new Types
related to Initiate and one for Finish message : 1 (Re-auth, applies
to Initiate and Finish Codes), 2 (Re-auth-Start, applies to Initiate
Code only). Additional type values are IANA managed and assigned
based on IETF Consensus.
Next, a number of type values corresponding to the TLVs within EAP
Initiate and Finish messages. Those are as follows:
o rIKname: TV Payload. The Type is 1
o rIKname as NAI: This is a TLV payload. The Type is 2.
Narayanan & Dondeti Expires February 25, 2008 [Page 30]
Internet-Draft ERP August 2007
o Peer-Id: This is a TLV payload. The Type is 3.
o Server-Id: This is a TLV payload. The Type is 4.
o Domain Identity: This is a TLV payload. The Type is 5.
o The TLV type range of 128-191 is reserved to carry CB information
in the EAP Initiate and Finish Re-auth messages. Below are the
current assignments (all of them are TLVs):
* Called-Station-Id: 128
* Calling-Station-Id: 129
* NAS-Identifier: 130
* NAS-IP-Address: 131
* NAS-IPv6-Address: 132
Other values may be added in future versions of this draft and the
rest are IANA managed based on IETF Consensus.
o 192-255 is reserved for Experimental/Private use.
Further, this document registers a USRK label with a value "EAP Re-
authentication Root Key" in accordance with [3].
8. Acknowledgments
In writing this draft, we benefited from discussing the problem space
and the protocol itself with a number of folks including, Bernard
Aboba, Jari Arkko, Sam Hartman, Russ Housley, Joe Salowey, Jesse
Walker, Charles Clancy, Michaela Vanderveen, Kedar Gaonkar, Dan
Harkins and other participants of the HOKEY working group. The
credit for the idea to use EAP Initiate Re-auth-Start goes to Charles
Clancy.
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Narayanan & Dondeti Expires February 25, 2008 [Page 31]
Internet-Draft ERP August 2007
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[3] Salowey, J., "Specification for the Derivation of Root Keys
from an Extended Master Session Key (EMSK)",
draft-ietf-hokey-emsk-hierarchy-01 (work in progress),
June 2007.
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-07 (work in
progress), July 2007.
[7] Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-18 (work in
progress), February 2007.
9.2. Informative References
[8] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol
Method for 3rd Generation Authentication and Key Agreement
(EAP-AKA)", RFC 4187, January 2006.
[9] Clancy, C., "Handover Key Management and Re-authentication
Problem Statement", draft-ietf-hokey-reauth-ps-02 (work in
progress), July 2007.
[10] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The Advanced
Encryption Standard-Cipher-based Message Authentication Code-
Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006.
[11] Gaonkar, K. and L. Dondeti, "RADIUS attributes for Domain-
specific Key Request and Delivery",
draft-gaonkar-radext-erp-attrs-00 (work in progress),
July 2007.
[12] Housley, R. and B. Aboba, "Guidance for AAA Key Management",
draft-housley-aaa-key-mgmt-09 (work in progress),
February 2007.
Narayanan & Dondeti Expires February 25, 2008 [Page 32]
Internet-Draft ERP August 2007
Appendix A. Example ERP Exchange
0. Authenticator --> Peer: [EAP Request/Identity()]
1. Peer --> Authenticator: EAP Initiate/Re-auth(
SEQ, rIKname, [peer-Id],[ER-server-Id],
Crypto-suite, Auth-tag*)
1a. Authenticator --> Reauth-Server: AAA-Request{Authenticator-Id,
EAP Initiate/Re-auth(SEQ, rIKname, [peer-Id],
[ER-server-Id],Crypto-suite, Auth-tag*)
2. ER-Server --> Authenticator: AAA-Response{rMSK,
EAP Finish/Re-auth(SEQ, rIKname,[peer-Id],
[ER-server-Id],Crypto-suite,[CB-Info],
Auth-tag*)
2b. Authenticator --> Peer : EAP Finish/Re-auth(SEQ, rIKname,[peer-Id],
[ER-server-Id],Crypto-suite,[CB-Info],
Auth-tag*)
* Auth-tag computation is over the entire EAP Initiate/Finish message;
the code values for Initiate and Finish are different and thus
reflection attacks are mitigated.
Figure 10: ERP Exchange
Authors' Addresses
Vidya Narayanan
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-2483
Email: vidyan@qualcomm.com
Narayanan & Dondeti Expires February 25, 2008 [Page 33]
Internet-Draft ERP August 2007
Lakshminath Dondeti
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Narayanan & Dondeti Expires February 25, 2008 [Page 34]
Internet-Draft ERP August 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Narayanan & Dondeti Expires February 25, 2008 [Page 35]
