One document matched: draft-vidya-eap-er-00.txt
Network Working Group V. Narayanan
Internet-Draft L. Dondeti
Expires: December 21, 2006 QUALCOMM, Inc.
June 19, 2006
EAP Extensions for Efficient Re-authentication
draft-vidya-eap-er-00
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 December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The extensible authentication protocol (EAP) is a generic framework
supporting multiple authentication methods. In the most common
deployment scenario, an EAP peer and server authenticate each other
through an authenticator; the server sends one of the session keys 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 in an EAP method
Narayanan & Dondeti Expires December 21, 2006 [Page 1]
Internet-Draft EAP-ER June 2006
independent manner. This document specifies extensions to EAP keying
hierarchy and the protocol itself to facilitate such efficient re-
authentication between the peer and the server through a new
authenticator.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. EAP-ER Overview . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. EAP-ER Key Hierarchy . . . . . . . . . . . . . . . . . . . . . 6
4.1. Rationale for using EMSK as the top level key . . . . . . 6
4.2. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. rRK Derivation and Properties . . . . . . . . . . . . 7
4.2.2. rIK Derivation and properties . . . . . . . . . . . . 8
4.2.3. rMSK Derivation and Properties . . . . . . . . . . . . 9
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10
5.1. EAP ER Bootstrapping . . . . . . . . . . . . . . . . . . . 10
5.2. Steps in the EAP ER protocol . . . . . . . . . . . . . . . 11
5.3. New EAP Messages . . . . . . . . . . . . . . . . . . . . . 12
5.3.1. EAP Re-authentication Response . . . . . . . . . . . . 13
5.3.2. EAP Re-authentication Information . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Narayanan & Dondeti Expires December 21, 2006 [Page 2]
Internet-Draft EAP-ER June 2006
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:
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, an EAP peer and 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 and use the TSK for per-packet access enforcement. EMSK
usage is defined in [1]. Its primary purpose is to derive usage
specific root keys (USRKs). Among the proposed use cases for USRKs
is efficient re-authentication between the peer and the server
through a different authenticator.
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 finish subsequent
authentications to finish in fewer roundtrips. However, most methods
do not offer this support. 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 to
avoid this problem 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), which of course receives the MSK
from the EAP server. 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 and this model works well. A full EAP authentication will
generally be 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 December 21, 2006 [Page 3]
Internet-Draft EAP-ER June 2006
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 the 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. This is
undesirable.
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
sessions than for instance in case of 802.11r based systems.
Thus, 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.
This document provides a means of performing EAP Efficient re-
authentication. Efficient Re-authentication is defined as a means of
performing EAP 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.
2. EAP-ER Overview
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 also derive an
EMSK. From the EMSK, a Re-authentication Root Key (rRK) is derived.
The rRK is only available to the peer and 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 receives the
server-id (either from the EAP method or via an out-of-band mechanism
from the server) for use in a subsequent exchange. The server caches
Narayanan & Dondeti Expires December 21, 2006 [Page 4]
Internet-Draft EAP-ER June 2006
the rRK and rIK for the peer, along with a key name.
When the peer subsequently identifies a target authenticator that
supports EAP-ER, it may perform an EAP-ER exchange; the exchange
itself may happen when the peer attaches to a new authenticator
supporting EAP-ER, or prior to attachment. In response to an EAP
Request Identity from the new authenticator, the peer sends an EAP
Re-authentication Response, including the peer-id, the server-id, a
sequence number, and a random nonce generated by the peer, PNonce.
The EAP Re-authentication Response is integrity protected with the
rIK. The authenticator routes this message to the server indicated
by the server-id. If AAA proxies are present, they need to parse the
server-id to route the message to the correct server. The server,
after verifying proof of possession using the rIK, and freshness of
the message, derives a Re-authentication MSK (rMSK) using the PNonce,
a random nonce from the AS, the ASNonce, and the peer-id, from the
rRK. The server then sends an EAP Re-authentication Information
message including the ASNonce; 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 regular EAP
exchange.
The peer uses the ASnonce and the other parameters (locally available
to the peer and hence not transported) to compute the rMSK. The
lower layer secure association protocol for TSK generation can be
triggered after this point.
3. Design Goals
The following are the design goals for the re-authentication
protocol.
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 [6].
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.
Narayanan & Dondeti Expires December 21, 2006 [Page 5]
Internet-Draft EAP-ER June 2006
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
server.
o The protocol must not preclude the use of the CAPWAP protocol.
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.
4. EAP-ER Key Hierarchy
We define a key hierarchy for EAP-ER, rooted at the EMSK derived as a
result of a full EAP exchange. This document derives a Usage Specifc
Root Key (USRK) in accordance with [1] for EAP-ER. The USRK
designated for re-authentication is the rRK.
The rRK is used to derive a rIK and rMSKs. The rRK and rIK are
derived by the peer when the EMSK is available, and have the same
lifetime as the EMSK. The derivation of the rRK and the rIK at the
server is typically triggered by the first EAP-ER message sent by the
peer following the corresponding full EAP session. The rMSK is
derived on-demand at both ends when an EAP-ER exchange is performed.
The figure above shows the key hierarchy with the rRK, rIK and rMSK.
4.1. Rationale for using EMSK as the top level key
For efficient re-authentication, the proposal is to reuse key
material from an earlier EAP authentication. The MSK and the EMSK
are the two keys derived during that process.
The MSK is delivered to the authenticator and used differently by
different lower layers. For instance, IKEv2 uses the MSK for entity
authentication alone, while lower layers like 802.11 and 802.16 use
it in the secure association protocol to derive TSKs. Also,
different lower layers use different parts of the MSK to derive other
keys from it. For example, IEEE 802.11 uses the first 256 bits of
the MSK for TSK derivation and 802.11's Task Group r (TGr) uses the
second 256 bits to derive PMKs-R1. IEEE 802.16 uses the first 320
bits of the MSK to derive TSKs.
Such disparate uses of the MSK at the lower layers makes it
infeasible to use the MSK for a lower layer agnostic EAP-ER purpose.
The EMSK, on the other hand, is currently kept at the peer and server
Narayanan & Dondeti Expires December 21, 2006 [Page 6]
Internet-Draft EAP-ER June 2006
and is never provided to any other entity. Hence, using the EMSK as
the top level key for performing EAP-ER provides the possibility of
making EAP-ER truly lower layer agnostic.
4.2. Key Derivation
4.2.1. rRK Derivation and Properties
The rRK is derived from the EMSK using the prf+ operation defined in
RFC4306 [2] as follows.
rRK = prf+ (K, S), where,
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 [1]. This document requests an IANA registration for the rRK
label specified above.
The PRF used is specified in the EAP Re-authentication Response. 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 prf-64 is the first 64 bits from the output of the name
derivation function (NDF). The NDF is a hash function, currently
specified as SHA-256. The EAP Session-ID is the session-id of the
full EAP exchange used to derive the EMSK used to derive the rRK. It
MUST be the most recent full EAP exchange that occurred between the
peer and the server.
The rRK has the following properties.
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.
Narayanan & Dondeti Expires December 21, 2006 [Page 7]
Internet-Draft EAP-ER June 2006
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 USRK derived
from the EMSK.
o The lifetime of the rRK is the same as that of the EMSK. The rRK
is expired when the EMSK expires and removed from use at that
time.
o If a new EMSK is derived due to a full EAP exchange, a new rRK
from that EMSK must be derived for the purpose of subsequent
EAP-ER exchanges. The new rRK MUST replace an existing rRK
derived from a previous EMSK.
4.2.2. rIK Derivation and properties
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 is the one specified in the EAP Re-authentication
Response. 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 used is HMAC-SHA-256.
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.
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 to be used is
specified in the EAP Re-authentication Request by the peer.
Narayanan & Dondeti Expires December 21, 2006 [Page 8]
Internet-Draft EAP-ER June 2006
o The rIK is only used for integrity protection 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.
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.
o If a new rRK is derived, a new rIK from that rRK must be derived
for the purpose of protecting subsequent EAP-ER exchanges. The
new rIK MUST replace an existing rIK derived from a previous rRK.
4.2.3. rMSK Derivation and Properties
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, S), where
S = PNonce || ASNonce || peer-id
where || denotes concatenation. The PNonce is a nonce sent by the
peer in the EAP Re-authentication Response message. The ASNonce is a
nonce sent by the server in the EAP Re-authentication Information
message. The peer-id is the ID of the peer exported by the EAP
method executed in the corresponding EAP session.
The PRF used is the one specified in the EAP Re-authentication
Response. 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 used is HMAC-SHA-256.
For the same reasons as in rIK_name, the rMSK name is also not
Narayanan & Dondeti Expires December 21, 2006 [Page 9]
Internet-Draft EAP-ER June 2006
derived from the EAP Session ID.
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 done so that lower layers can employ the secure
association protocol with the rMSK as they do with the MSK.
o The rRMSK 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
The EAP re-authentication protocol results in a key shared between an
EAP peer and a new/target EAP authenticator based on an EAP exchange
between the EAP peer and the EAP server that occurred via a previous
authenticator. Essentially, this protocol allows key material based
on an earlier authentication to be delivered to a new authenticator
without the execution of an EAP method. Further, this protocol
finishes in a single roundtrip to the EAP server and satisfies the
guidance for AAA key management of [6]. Next, it is independent of
the lower layer and EAP methods. 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.
5.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 to generate
TSKs as needed. At the time of the initial EAP exchange, the peer
and the server also derive an EMSK. From the EMSK, an rRK is
derived. The rRK is only available to the peer and server and is
never handed out to any other entity. Further, an rIK is derived
Narayanan & Dondeti Expires December 21, 2006 [Page 10]
Internet-Draft EAP-ER June 2006
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 receives the
server-id (either from the EAP method or via an out-of-band mechanism
from the server) to use in a subsequent exchange. The server caches
the rRK and rIK for the peer, along with a key name (EAP session ID
could potentially serve as the key name).
For replay protection of EAP ER messages, a sequence number
associated with the rIK is used. The sequence number is maintained
by the EAP 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.
The retransmission and sequence number maintenance semantics are
along the lines of the message-IDs and retransmission semantics of
the IKEv2 protocol [2].
5.2. Steps in the 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 advance EAP-ER
exchange or when it attaches to the new authenticator supporting
EAP-ER. The EAP-ER protocol has the following steps:
In response to an EAP Request Identity from the new authenticator,
the peer sends an EAP Re-authentication Response, including the
peer-id, the server-id, and a freshly generated random nonce,
called the PNonce, and the current value of the rIK sequence
number; the message is integrity protected with the rIK.
The authenticator routes the EAP Re-authentication Response
message to the server indicated by the server-id. If AAA proxies
are present, the proxy needs to parse the server-id to route the
message to the correct server.
The server uses the peer-id to lookup the rIK. It first verifies
whether the sequence number is falls within a window of acceptable
sequence numbers. If the window size is zero, the sequence number
must be 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 Failure message.
Otherwise, it computes an rMSK from the rRK using the PNonce, a
freshly generated random nonce, called the ASNonce and the peer-id
as additional inputs to the key derivation.
Narayanan & Dondeti Expires December 21, 2006 [Page 11]
Internet-Draft EAP-ER June 2006
The server then sends an EAP Re-authentication Information message
containing the sequence number, the ASNonce, and the rIK name;
this message is also 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 regular EAP exchange.
The peer looks up the sequence number to verify whether it is
expecting a EAP Re-authentication Information 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 of 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 ASnonce and other locally available parameters
(the peer-id and PNonce ) to compute the rMSK. The lower layer
secure association protocol can be triggered at this point.
5.3. New EAP Messages
Two new EAP messages are defined for the purpose of EAP-ER: EAP Re-
authentication Response and EAP Re-authentication Information. The
packet format for these messages follows the EAP packet format
defined in RFC3748 [3].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 1: EAP Re-authentication Packet
Code
5 Re-authentication
A new code value is defined for the purpose of EAP-ER. The
code value of 5 is TBD based on IANA assignment.
Identifier
Narayanan & Dondeti Expires December 21, 2006 [Page 12]
Internet-Draft EAP-ER June 2006
The Identifier field is one octet. The Identifier field MUST
be the same if a Re-authentication packet is retransmitted due
to a timeout while waiting for a response. Any new (non-
retransmission) Requests MUST modify the Identifier field.
The Identifier field of the Re-authentication Response MUST
match that of the currently outstanding Request. An
authenticator receiving a Re-authentication packet whose
Identifier value does not match that of the currently
outstanding Request MUST silently discard the packet.
In order to avoid confusion between new Requests and
retransmissions, the Identifier value chosen for each new
Request need only be different from the previous Request, but
need not be unique within the conversation. One way to achieve
this is to start the Identifier at an initial value and
increment it for each new Request. Initializing the first
Identifier with a random number rather than starting from zero
is recommended, since it makes sequence attacks somewhat more
difficult.
Since the Identifier space is unique to each session,
authenticators are not restricted to only 256 simultaneous
authentication conversations. Similarly, with re-
authentication, an EAP conversation might continue over a long
period of time, and is not limited to only 256 roundtrips.
Type
This field indicates the Type of EAP Re-authentication packet
and is one octet in size. A single Type MUST be specified for
each EAP Re-authentication packet. Two types are defined in
this document - Response and Information.
Type-Data
The Type-Data field varies with the Type of Re-authentication
packet.
5.3.1. EAP Re-authentication Response
The EAP Re-authentication response packet contains the parameters
shown in Figure Figure 2 :
Narayanan & Dondeti Expires December 21, 2006 [Page 13]
Internet-Draft EAP-ER June 2006
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 | Peer-Id Len | Peer-Id ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server-Id Len | Server-Id ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SEQ | rIK name ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PNonce ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto-Suite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EAP Re-authentication Response Packet
Peer-Id: There is a Peer-Id and the associated length field. The
Peer-Id is the NAI of the peer, and is variable in length, not
exceeding 256B. The Peer-Id can be used by the server to look up
the rIK. Alternatively the rIK name can be used for this purpose
also. 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: Similar to the Peer-Id, there is a server-Id and the
associated length field. EAP ER capable authenticators SHOULD use
this field to route the EAP Re-authentication Response Packet. If
local policy dictates otherwise, the packet may be routed based on
the peer-Id.
SEQ: A 16-octet sequence number is used for replay protection.
The SEQ number field is initialized to zero.
rIK name: This is a 64-octet field computed as specified in
Section Section 4.2.2 and is used to identify the rIK with which
the EAP ER messages are protected.
PNonce: This is a fresh random nonce generated by the peer; it is
to be used in rMSK derivation from the rRK. The nonce is variable
in size. There is no nonce length as everything else is of either
known size or associated with a length field. So, this field can
be unambiguously parsed.
Narayanan & Dondeti Expires December 21, 2006 [Page 14]
Internet-Draft EAP-ER June 2006
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.
5.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 already
authenticated to the network via another Authenticator. The peer can
identify the network, for instance, through NAIs advertised by the
Authenticator. If the peer has state from a previous authentication,
and if it knows that the Authenticator is EAP ER capable, it sends an
EAP re-authentication message instead of an EAP Response Identity
message.
The peer includes its identity and the identity of the server which
holds state from the previous authentication, the current value of
the rIK sequence number, the rIK name, and a freshly generated random
nonce in the message. The nonce MUST be at least half-the-size of
the rMSK. It then computes the integrity checksum over the EAP ER
packet, excluding the Auth tag field itself, and includes the value
in the Auth tag field.
5.3.1.2. Authenticator Operation
An EAP ER capable Authenticator looks for the server ID in the EAP
Re-authentication Response 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 Re-
authentication Response message.
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 can use the peer-id or the rIK name to lookup the rIK.
Narayanan & Dondeti Expires December 21, 2006 [Page 15]
Internet-Draft EAP-ER June 2006
It first verifies whether the sequence number is falls within a
window of acceptable sequence numbers. If the window size is
zero, the sequence number must be 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
Failure message.
If the EAP Re-authentication message is valid, the EAP server
computes an rMSK from the rRK using the PNonce, a freshly
generated random nonce, called the ASNonce, and the peer-id as
additional inputs to the key derivation.
The server prepares an EAP Re-authentication Information message
and sends it via AAA to the authenticator. The server includes
the rMSK in the AAA message that carries the EAP Re-authentication
Information message.
5.3.2. EAP Re-authentication Information
The EAP Re-authentication Information packet contains the parameters
shown in Figure Figure 3 :
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | SEQ | rIK name... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASNonce ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crypto-Suite | Authentication Tag ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: EAP Re-authentication Information Packet
The ASNonce is the only new field here, and hence that's described
below:
ASNonce: This is a fresh random nonce generated by the server; it is
to be used in rMSK derivation from the rRK. The nonce is variable in
size. There is no nonce length as everything else is of either known
size or associated with a length field. So, this field can be
unambiguously parsed.
Narayanan & Dondeti Expires December 21, 2006 [Page 16]
Internet-Draft EAP-ER June 2006
5.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.
5.3.2.2. Peer Operation
The peer uses the following steps in processing a EAP Re-
authentication Information message:
The peer checks to see if the sequence number in the received
message is the same as the sequence number in the EAP Re-
authentication Response it sent earlier. If the sequence number
verification succeeds, it proceeds to the next step; otherwise, it
logs an error.
The peer 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 ASNonce, the PNonce and other parameters to
compute the rMSK.
The lower layer secure association protocol can be triggered at
this point.
6. Security Considerations
This section provides an analysis of the protocol in accordance with
the AAA key management requirements specified in [6].
Cryptographic Algorithm Independence
The EAP-ER protocol satisfies this requirement. The algorithm
chosen by the peer for the PRF used in key derivaiton 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.
Narayanan & Dondeti Expires December 21, 2006 [Page 17]
Internet-Draft EAP-ER June 2006
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 EAP 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.
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.
Narayanan & Dondeti Expires December 21, 2006 [Page 18]
Internet-Draft EAP-ER June 2006
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.
7. IANA Considerations
This document requires IANA registration of a new EAP Code: 5 Re-
authentication. The new code value is defined for the purpose of
EAP-ER.
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, and Jesse
Walker. Note that this does not necessarily mean that they endorse
the protocol or verified the correctness of it.
9. References
9.1. Normative References
[1] Salowey, J., "Specification for the Derivation of Usage Specific
Root Keys (USRK) from an Extended Master Session Key (EMSK)",
Narayanan & Dondeti Expires December 21, 2006 [Page 19]
Internet-Draft EAP-ER June 2006
draft-salowey-eap-emsk-deriv-00 (work in progress), May 2006.
[2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005.
[3] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-13 (work in
progress), May 2006.
9.2. Informative References
[6] Housley, R. and B. Aboba, "Guidance for AAA Key Management",
draft-housley-aaa-key-mgmt-02 (work in progress), March 2006.
Narayanan & Dondeti Expires December 21, 2006 [Page 20]
Internet-Draft EAP-ER June 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 December 21, 2006 [Page 21]
Internet-Draft EAP-ER June 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Narayanan & Dondeti Expires December 21, 2006 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-23 08:26:33 |