One document matched: draft-vidya-eap-er-02.txt
Differences from draft-vidya-eap-er-01.txt
Network Working Group V. Narayanan
Internet-Draft L. Dondeti
Intended status: Standards Track QUALCOMM, Inc.
Expires: July 23, 2007 January 19, 2007
EAP Extensions for Efficient Re-authentication
draft-vidya-eap-er-02
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 July 23, 2007.
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 the most
common deployment scenario, a peer and server authenticate each other
through an authenticator; the server sends the master session key
(MSK) to the authenticator so that the peer and the authenticator can
establish a security association for per-packet access enforcement.
It is desirable to not repeat the entire process of authentication
when the peer moves to another authenticator. This document
Narayanan & Dondeti Expires July 23, 2007 [Page 1]
Internet-Draft EAP-ER January 2007
specifies extensions to EAP keying hierarchy and an EAP method-
independent protocol to facilitate such efficient Re-authentication
between the peer and the server through an authenticator.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. EAP-ER Overview . . . . . . . . . . . . . . . . . . . . . . . 5
4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. EAP-ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . 8
5.1. Key Derivations and Properties . . . . . . . . . . . . . . 8
5.1.1. rRK Derivation . . . . . . . . . . . . . . . . . . . . 8
5.1.2. rRK Properties . . . . . . . . . . . . . . . . . . . . 9
5.1.3. rIK Derivation . . . . . . . . . . . . . . . . . . . . 10
5.1.4. rIK Properties . . . . . . . . . . . . . . . . . . . . 10
5.1.5. rMSK Derivation . . . . . . . . . . . . . . . . . . . 11
5.1.6. rMSK Properties . . . . . . . . . . . . . . . . . . . 11
6. Protocol Description . . . . . . . . . . . . . . . . . . . . . 12
6.1. EAP ER Bootstrapping . . . . . . . . . . . . . . . . . . . 12
6.2. EAP ER protocol . . . . . . . . . . . . . . . . . . . . . 15
6.3. New EAP Messages . . . . . . . . . . . . . . . . . . . . . 16
6.3.1. EAP Initiate Re-auth Packet . . . . . . . . . . . . . 18
6.3.2. EAP Finish Re-auth Packet . . . . . . . . . . . . . . 20
6.4. Replay protection . . . . . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Narayanan & Dondeti Expires July 23, 2007 [Page 2]
Internet-Draft EAP-ER January 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 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., [6]). 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.
One of the EAP lower layers, IEEE 802.11, provides a mechanism for
faster re-authentication in a limited setting, by introducing a two-
level key hierarchy. The EAP authenticator is collocated with what
is known as an R0 Key Holder (R0-KH); it receives the MSK from the
EAP server as usual. A pairwise master key (PMK-R0) is derived from
the second half (last 32 octets) of the MSK. Subsequently, the R0-KH
derives an R1-PMK to be handed out to the attachment point of the
peer. When the peer moves from one R1-KH to another, a new PMK-R1 is
generated by the R0-KH and handed out to the new R1-KH. The
transport protocol used between the R0-KH and the R1-KH is not
specified at the moment.
In some cases, a mobile may seldom move beyond the domain of the
R0-KH (the Extended Service Set, ESS in 802.11) and this model works
well. A full EAP authentication is repeated when the PMK-R0 expires.
However, in general cases mobiles may roam beyond the domain of R0-
KHs (or EAP authenticators), and the latency of full EAP
authentication remains an issue.
Narayanan & Dondeti Expires July 23, 2007 [Page 3]
Internet-Draft EAP-ER January 2007
Furthermore, in the 802.11r architecture, the R0-KH may actually be
located close to the edge, thereby creating a vulnerability: If the
R0-KH is compromised, all PMK-R1s derived from the corresponding PMK-
R0s will also be compromised.
Another consideration is that there needs to be a key transfer
protocol between the R0-KH and the R1-KH: in other words, there is
either a star configuration of security associations between each key
holder and a centralized entity that serves as the R0-KH, or if the
first authenticator is the default R0-KH, there will be a full-mesh
of security associations between all authenticators. Neither option
is desirable.
In other lower layers, key sharing across authenticators is sometimes
used as a practical solution to lower handoff times. In that case,
compromise of any authenticator results in compromise of several more
EAP sessions than for instance in case of 802.11r based systems.
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 elsewhere [7].
This document provides a means of performing EAP Efficient Re-
authentication. EAP-ER is a protocol that 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-ER is described in
this document. This document only specifies native EAP-based
transport for this protocol and hence, requires support for the
protocol on the authenticators as well. However, the protocol
specified in this document can be transported in an EAP method-like
fashion (using EAP Request/Response messages) to allow the operation
over legacy authenticators that do not support the new EAP-ER
messages. The details of such a transport is outside the scope of
this document.
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:
Narayanan & Dondeti Expires July 23, 2007 [Page 4]
Internet-Draft EAP-ER January 2007
EAP-ER peer - An EAP peer that supports the EAP-ER protocol
EAP-ER Authenticator - An EAP authenticator that also supports the
authenticator functionality for EAP-ER described in this document.
All references to "authenticator" in this document imply an EAP-ER
authenticator, unless specifically noted otherwise.
EAP-ER Server - An entity that performs the server portion of the
EAP-ER protocol described here. This entity may or may not be an
EAP server.
rRK - Re-authentication root Key, derived from the EMSK or as
specified in [8].
rIK - Re-authentication Integrity Key, derived from the rRK.
rMSK - Re-authentication MSK. This is a per-authenticator key,
derived from the rRK.
3. EAP-ER 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). As noted below, the rRK may be derived from the EMSK or by
other means, e.g., as specified in [8]. The rRK is only available to
the peer and EAP-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 EAP-ER 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-ER
protocol supports explicit bootstrapping using which a server ID can
be obtained by the peer at the end of a successful full EAP exchange.
Alternatively, the peer may simply use a key name to identify the
full EAP session. Particularly, when the EAP-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.
Narayanan & Dondeti Expires July 23, 2007 [Page 5]
Internet-Draft EAP-ER January 2007
Peer Authenticator Server
==== ============= ======
<-- EAP Request/ -----
Identity
--- EAP Response/ --->
Identity --EAP Response/Identity->
<-- full EAP exchange--> <---full EAP exchange--->
<---MSK, EAP Success----
Peer Authenticator Server
==== ============= ======
[<-- EAP Request/ -----
Identity]
--- EAP Initiate/ ---> --EAP Initiate/ --->
Reauth/ Reauth/
[Bootstrap] [Bootstrap]
<-- EAP Finish/ ---- <---rMSK,EAP Finish/--
Reauth/ Reauth/
[Bootstrap] [Bootstrap]
Figure 1: EAP-ER Exchange
When the peer subsequently identifies a target authenticator that
supports EAP-ER, it performs an EAP-ER exchange, as shown in the
figure above as well; the exchange itself may happen when the peer
attaches to a new authenticator supporting EAP-ER, or prior to
attachment. The peer may initiate the EAP-ER exchange by itself, or
in response to an EAP Request Identity from the new authenticator.
EAP-ER introduces two new 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 rIK name, 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 may be routed based on the peer-id or the temporary NAI or
both. The server uses the peer-id and/or the rIK name to lookup the
Narayanan & Dondeti Expires July 23, 2007 [Page 6]
Internet-Draft EAP-ER January 2007
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 and the peer-id as additional inputs.
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
the MSK transport along with the EAP Success message in a full EAP
exchange.
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, and other parameters (locally available to the peer and
hence not transported) to compute the rMSK. The lower layer TSK
generation mechanism is ready to be triggered after this point.
4. Design Goals
In general, the goals identified in [7] apply to this protocol.
Specifically, the following design goals are also considered.
o The protocol must be independent of the lower layer used to carry
EAP.
o The protocol must be EAP method independent.
o The protocol must satisfy the AAA key management requirements
specified in [9].
o The protocol should employ a simple and extensible key hierarchy.
o The protocol should not interfere with the currently defined fast
transition mechanisms in IEEE 802.11r.
o The protocol should be compatible with AAA protocols (RADIUS and
Diameter).
o The protocol should involve no more than one roundtrip to the EAP
or AAA server.
o The protocol must not preclude the use of the CAPWAP protocol.
Narayanan & Dondeti Expires July 23, 2007 [Page 7]
Internet-Draft EAP-ER January 2007
o It must be feasible to execute this protocol between a peer and a
target authenticator via a current authenticator, on lower layers
that allow it.
5. EAP-ER Key Hierarchy
We define a key hierarchy for EAP-ER, rooted at the rRK, and derived
as a result of a full EAP exchange. The rRK may be derived from an
EMSK as specified in this document. Alternately, the rRK may be
derived by other means, as identified in [8]. For the purpose of
EMSK-based rRK derivation, this document derives a Usage Specifc Root
Key (USRK) in accordance with [3] for EAP-ER. The USRK designated
for Re-authentication is the Re-authentication root key (rRK).
The rRK is used to derive a rIK and one or more rMSKs. The rRK and
rIK have the same lifetime as the EMSK. The figure below shows the
key hierarchy with the rRK, rIK and rMSKs.
rRK
|
+--------+--------+
| | |
rIK rMSK1 ...rMSKn
Figure 2: Re-authentication Key Hierarchy
5.1. Key Derivations and Properties
5.1.1. rRK Derivation
The rRK may be derived from the EMSK directly. This section provides
the relevant key derivations for that purpose. This derivation is
used when the EAP-ER server is collocated with the EAP server that
participated in the full EAP exchange with the peer. EAP-ER may also
be executed between the peer and a different EAP-ER server,
subsequent to the full EAP exchange with the EAP server. In that
case, the rRK is derived from a different key. Details on that model
are outside the scope of this document. An example of such an
alternate derivation is specifed in [8].
The rRK is derived from the EMSK using the prf+ operation defined in
RFC4306 [4] as follows.
rRK = prf+ (K, S), where,
Narayanan & Dondeti Expires July 23, 2007 [Page 8]
Internet-Draft EAP-ER January 2007
K = EMSK and
S = rRK Label
The rRK Label is an IANA-assigned ASCII string "EAP Re-authentication
Root Key" assigned from the USRK 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 = NDF-64( EAP Session-ID, rRK Label )
where NDF-64 is the first 64 bits from the output of the name
derivation function (NDF). The NDF is a hash function, also
indicated in the EAP Re-auth message. When it is not explicitly
specified, SHA-256 is the NDF. The EAP Session-ID is the session-id
of the full EAP exchange used to derive the EMSK used to derive the
rRK.
5.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
MSK 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.
o The rRK must remain on the peer and the server 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 the same as that of its parent key.
The rRK is expired when the parent key expires and removed from
Narayanan & Dondeti Expires July 23, 2007 [Page 9]
Internet-Draft EAP-ER January 2007
use at that time.
5.1.3. rIK Derivation
The Re-authentication Integrity Key (rIK) is used for integrity
protecting the EAP-ER 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 rIK name is derived as follows.
rIK_name = prf-64 (rRK, "rIK 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 rIK.
Unlike the rRK_name, the EAP session ID is not used to derive the
rIK_name. This is done in order to avoid any collisions with USRK
names. The key label used for USRKs is IANA registered, while the
string "rIK Name" is not. Given that a key is involved in the
derivation, we use a PRF in place of the NDF, a hash.
5.1.4. rIK Properties
The rIK has the following properties.
o The length of the rIK depends on the MAC algorithm used in
protecting the EAP-ER exchange. The MAC algorithm used may be
specified in the EAP ER message sent by the peer. The default MAC
algorithm is HMAC-SHA-256.
o The rIK is only used for authentication of the EAP-ER 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.
Narayanan & Dondeti Expires July 23, 2007 [Page 10]
Internet-Draft EAP-ER January 2007
o The rIK is cryptographically separate from any other keys derived
from the rRK.
o The lifetime of the rIK is the same as that of the EMSK. The rIK
is expired when the EMSK expires and removed from use at that
time.
5.1.5. rMSK Derivation
The rMSK is derived at the peer and server and delivered to the
authenticator. The rMSK is derived following an EAP-ER 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.
For the same reasons as in rIK_name, the rMSK name is also not
derived from the EAP Session ID.
5.1.6. rMSK Properties
The rMSK has the following properties:
o The length of the rMSK MUST be the same as that of the MSK derived
earlier in the EAP session at the time of the full EAP exchange.
This is so that lower layers can treat the rMSK the same as they
do the MSK.
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.
Narayanan & Dondeti Expires July 23, 2007 [Page 11]
Internet-Draft EAP-ER January 2007
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.
6. Protocol Description
The EAP-ER protocol results in a key shared between a peer and an
authenticator based on an EAP exchange between the peer and the EAP
server that previously occurred. Essentially, this protocol allows
key material based on an earlier authentication to be delivered to an
authenticator without another execution of an EAP method. Further,
this protocol finishes in a single roundtrip from the peer to the
server and satisfies the guidance for AAA key management of [9].
Next, it is independent of the lower layer, and the EAP method used
during the full EAP exchange. Finally, it is feasible to execute
this protocol between a peer and a target authenticator via a current
authenticator, on lower layers that allow it.
6.1. EAP ER 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 for the
same purpose 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 EAP-ER may be used
by the peer if it plans to move to a new authenticator. The rIK name
is also derived to serve as the index to the rIK to process EAP-ER
messages.
We identify two types of bootstrapping for EAP-ER: explicit and
implicit 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
EAP-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, EAP-ER bootstrapping is implicit. The
Narayanan & Dondeti Expires July 23, 2007 [Page 12]
Internet-Draft EAP-ER January 2007
peer initiates an EAP-ER exchange only when it moves from one
authenticator to another.
The peer may initiate an explicit EAP-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 PRF and the
authentication algorithm. The integrity checksum indicates that
the message originated at the claimed entity, the peer indicated
by the peer-id, or the rIK holder.
o When an EAP-ER 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 EAP-ER
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.
Narayanan & Dondeti Expires July 23, 2007 [Page 13]
Internet-Draft EAP-ER January 2007
* 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 name 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 on any EAP Success message that may have been
received by the authenticator and the peer earlier. If the
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.
* An authentication tag to prove that the EAP Finish Re-auth
message originates at a server that possesses the relevant rIK.
* An rMSK sent along with the EAP Finish Re-auth message, in a
AAA attribute.
Since the EAP-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 EAP-ER bootstrapping exchange. This must be
Narayanan & Dondeti Expires July 23, 2007 [Page 14]
Internet-Draft EAP-ER January 2007
negotiated at the lower layer to ensure appropriate action at the
peer and authenticator. However, the bootstrapping exchange may be
carried out via a new authenticator, in which case, the rMSK received
must be used to derive TSKs for the lower layer.
6.2. EAP ER protocol
When a peer that has an active rRK and rIK identifies a new/target
authenticator that supports EAP-ER, it may perform an EAP-ER exchange
either in advance or when it attaches to the new authenticator
supporting EAP-ER. EAP-ER is typically a peer-initiated exchange,
consisting of an EAP Initiate Re-auth and an EAP Finish Re-auth
message.
It is plausible for the network to trigger the EAP Re-authentication
process however. When an EAP-ER capable authenticator sends an EAP
Request Identity the peer may in response initiate the EAP Re-
authentication exchange.
Notes on authenticator state machine:
The authenticator state machine needs to be modified to consider the
EAP Re-authentication exchange as a "response" to the EAP Request
Identity and transfer the state machine to follow the EAP Re-
authentication exchange and determine Success or Failure of the
exchange based on whether the EAP Finish Re-auth message is a Success
or Failure. The authenticator MUST consider that it has received a
response to the EAP Request Identity and cancel the corresponding
retransmission timer.
Notes on Operational Considerations at the Peer:
EAP-ER 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-ER 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.
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 peer-id MUST be used to route the message if that is
Narayanan & Dondeti Expires July 23, 2007 [Page 15]
Internet-Draft EAP-ER January 2007
present. If neither the server-id nor the peer-id are present,
the rIKname MUST be in the form of an NAI and that is 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 a Failure
indication. 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 rIK name. 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
include the server-id with this 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 rIK name 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 key derivation processes can be triggered at this
point.
6.3. New EAP Messages
Two new EAP messages are defined for the purpose of EAP-ER: EAP
Initiate Re-auth and EAP Finish Re-auth. The packet format for these
messages follows the EAP packet format defined in RFC3748 [2].
Narayanan & Dondeti Expires July 23, 2007 [Page 16]
Internet-Draft EAP-ER January 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 3: EAP Re-authentication Packet
Code
5 Initiate
6 Finish
Two new code values are defined for the purpose of EAP-ER. 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 EAP-ER exchange. One type
is defined in this document for this purpose - Re-auth.
Narayanan & Dondeti Expires July 23, 2007 [Page 17]
Internet-Draft EAP-ER January 2007
Type-Data
The Type-Data field varies with the Type of Re-authentication
packet.
6.3.1. EAP Initiate Re-auth Packet
The EAP Re-authentication response packet contains the parameters
shown in Figure 4 :
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 | Flags | SEQ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto-Suite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: EAP Initiate Re-auth Packet
Flags: The rightmost bit is used as the bootstrapping flag. If
the flag is turned on, the message is a bootstrap message. All
other bits are set to zero on transmission and ignored on
reception.
SEQ: A 16-bit sequence number is used for replay protection. The
SEQ number field is initialized to zero.
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.
rIK name: 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 5.1.3 and is used to identify the rIK with which the
EAP ER messages are protected.
Narayanan & Dondeti Expires July 23, 2007 [Page 18]
Internet-Draft EAP-ER January 2007
rIK name as NAI: This is carried in a TLV payload. The Type is
2. The NAI is variable in length, not exceeding 256 octets.
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. The authenticator may use the Peer-Id to route the
EAP packet. However, the preferred field for this purpose is
the server-Id.
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.
EAP 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.
Crypto Suite: This field indicates the integrity and if necessary
the encryption algorithm used for EAP ER. 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 EAP ER packet. The length of the field is indicated by
the Crypto Suite.
6.3.1.1. Peer Operation
When an EAP 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
EAP 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.
6.3.1.2. Authenticator Operation
An EAP 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 Authenticator's local policy may dictate that the message be
routed based on the peer's NAI, also available in the EAP Initiate
Re-auth message.
The peer's domain may be available as part of the rIKName.
Narayanan & Dondeti Expires July 23, 2007 [Page 19]
Internet-Draft EAP-ER January 2007
The Authenticator sends the message just as it forwards other EAP
messages to the EAP server.
6.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.
The server then sends an EAP Finish Re-auth message containing the
rIK sequence number, and the rIK name; 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 EAP-ER 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.
6.3.2. EAP Finish Re-auth Packet
The EAP Finish 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 | Flags | SEQ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 or more TVs or TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto-Suite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: EAP Finish Re-auth Packet
Narayanan & Dondeti Expires July 23, 2007 [Page 20]
Internet-Draft EAP-ER January 2007
6.3.2.1. 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
AAA message containing an EAP success packet.
6.3.2.2. 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 rIK name 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 TSK derivation process can be triggered at this
point.
6.4. Replay protection
For replay protection, EAP ER uses sequence numbers. The sequence
number 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
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.
Narayanan & Dondeti Expires July 23, 2007 [Page 21]
Internet-Draft EAP-ER January 2007
7. Security Considerations
This section provides an analysis of the protocol in accordance with
the AAA key management requirements specified in [9].
Cryptographic Algorithm Independence
The EAP-ER 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
EAP-ER 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.
Limit key scope
The scope of all the keys derived by EAP-ER 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 EAP-ER
exchange. No other authenticator is authorized to use that
rMSK.
Replay detection mechanism
For replay protection of EAP ER 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 EAP ER Re-authentication
message. The server increments the sequence number when it
receives and responds to the message.
Narayanan & Dondeti Expires July 23, 2007 [Page 22]
Internet-Draft EAP-ER January 2007
Authenticate all parties
The EAP-ER 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 EAP-ER exchange corresponds is used after
the EAP-ER 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,
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-ER protocol allows prevention of the domino effect by
appropriately defining key scopes.
Bind key to its context
All the keys derived for EAP-ER are bound to the appropriate
context using appropriate key labels. Also, the rMSK is bound
to the peer and server IDs.
8. IANA Considerations
This document requires IANA registration of two new EAP Codes: 5
(Initiate) and 6 (Finish). This document also requires IANA
Narayanan & Dondeti Expires July 23, 2007 [Page 23]
Internet-Draft EAP-ER January 2007
registration of a new EAP Type - Re-auth. These values should be in
accordance with [2]. Further, this document registers a USRK label
with a value "EAP Re-authentication Root Key" in accordance with [3].
9. 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, and Jesse
Walker.
10. References
10.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.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
[3] Salowey, J., "Specification for the Derivation of Usage Specific
Root Keys (USRK) from an Extended Master Session Key (EMSK)",
draft-salowey-eap-emsk-deriv-01 (work in progress), June 2006.
[4] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005.
[5] Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-16 (work in
progress), January 2007.
10.2. Informative References
[6] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol
Method for 3rd Generation Authentication and Key Agreement (EAP-
AKA)", RFC 4187, January 2006.
[7] Clancy, C., "Handover Key Management and Re-authentication
Problem Statement", draft-ietf-hokey-reauth-ps-00 (work in
progress), January 2007.
[8] Dondeti, L. and V. Narayanan, "EAP Keying and Re-authentication
in Visited Domains", draft-dondeti-eap-vkh-00 (work in
progress), October 2006.
Narayanan & Dondeti Expires July 23, 2007 [Page 24]
Internet-Draft EAP-ER January 2007
[9] Housley, R. and B. Aboba, "Guidance for AAA Key Management",
draft-housley-aaa-key-mgmt-06 (work in progress), November 2006.
Authors' Addresses
Vidya Narayanan
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-2483
Email: vidyan@qualcomm.com
Lakshminath Dondeti
QUALCOMM, Inc.
5775 Morehouse Dr
San Diego, CA
USA
Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com
Narayanan & Dondeti Expires July 23, 2007 [Page 25]
Internet-Draft EAP-ER January 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 July 23, 2007 [Page 26]
| PAFTECH AB 2003-2026 | 2026-04-22 21:47:41 |