Internet DRAFT - draft-nakhjiri-eap-ho
draft-nakhjiri-eap-ho
Internet Draft Madjid Nakhjiri
draft-nakhjiri-eap-ho-00.txt Motorola Labs
Category: Internet draft June 2005
Expires: December 2005
EAP keying and handover support
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 3, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The current EAP documentation set, such as [EAP3748], [EAPKEY6], and
[RADEAP3579] provide a powerful framework for performing combined
authentication and key management using an EAP server and an AAA
Nakhjiri et. al. EAP keying and handover support [Page 1]
infrastructure. The framework competently deals with many issues
related to network-access control and link security setup. However,
when it comes to deploying these specifications for mobile wireless
environments, where a peer is required to perform fast and/or
heterogeneous handovers, the current framework can be extended with
more clear guidelines and possibly specifications in ways that
prevent interoperability or security issues. This draft intends to
explore some of the complications in deploying the EAP framework for
handovers and analyze a few solution alternatives.
Further threat analysis of each alternative or providing trade-off
guidelines for support of handover may be part of the future
revisions of this document.
Conventions used in this document
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.
Table of Contents
1. Introduction...................................................3
2. Terminology and Assumptions....................................4
3. Key derivation overview........................................5
3.1 Key transport timing issues................................7
3.2 Channel binding issues.....................................7
3.3 Life times.................................................8
4. Key distribution architecture alternatives.....................9
4.1 AAA server-based...........................................9
4.1.1 Initial EAP authentication and key distribution 9
4.1.2 Handover 10
4.1.3 Pros and Cons 12
4.2 Local Key distribution Center.............................13
4.2.1 Initial authentication 14
4.2.2 Handover 16
4.2.3 Pros and Cons 17
4.3 EAP Proxy approach (multi-hop peer-NAS link)..............17
4.3.1 Initial authentication 18
4.3.2 Handover 19
4.3.3 Pros and Cons 19
4.4 AAA-proxy approach........................................20
4.4.1 Handover procedure 20
5. Security considerations.......................................21
6. References....................................................21
Nakhjiri et. al. EAP keying and handover support [Page 2]
1. Introduction
EAP key management framework [EAPKEY6] defines a 3 phase procedure
for performing EAP-based authentication and key management. These
phases are discovery, authentication and secure association protocol
(SAP) phases:
EAP peer Authenticator Auth. Server
-------- ------------ --------
|<----------------------------->| |
| discovery phase | |
|<----------------------------->|<---------------------------->|
| EAP auth (phase 1a) | AAA pass-through (optional) |
| | |
| |<---------------------------->|
| | AAA-Key transport |
| | (optional; phase 1b) |
|<----------------------------->| |
| Secure association protocol | |
| (including a nonce exchange) | |
Figure 1: 3 phases of EAP authentication and key management.
. In the discovery phase, the peer locates the authenticators.
This phase is considered out of scope of [EAPKEY6], however, it
may have an impact on some of proposals discussed in this
document as explained later.
. During the EAP authentication phase, as part of an EAP-method,
EAP master key (MSK) and extended master key (EMSK) are
established between the EAP server and EAP peer. Furthermore, a
AAA key can be established between the peer and EAP server. In
cases where authenticator is separate from the EAP server, the
AAA-key is transported to the authenticator. The AAA-key or a
derivate key, called Pair-wise master key (PMK) residing at the
authenticator and the peer can be used for the next phase
. During the Secure association phase the peer and the
authenticator engage in an exchange, by which they prove the
possession of AAA-key (or PMK) and at the same time use this key
as a medium term secret to establish short term so called
transient session keys (TSK). In order to assure that the
transient session keys are fresh and to avoid the domino effect
possibly caused by attacks on weak session keys (leading to
compromise of AAA key or PMK), the secure association protocol
typically includes a nonce exchange between the authenticator
and the peer every time new (or refreshed) session keys are
required. The secure association protocol (SAP) phase is also
considered out of scope for [EAPKEY6].
Nakhjiri et. al. EAP keying and handover support [Page 3]
In networks offering mobility services, network attachment is
typically provided by a point of presence (PoP), sometimes called a
base station (BS) or an access point (AP). From this point on, for
convenience we call the PoP, a BS. An exact definition of BS is
provided in the terminology section.
In a wireless environment, a peer can attach to the network through a
BS after going through an EAP authentication procedure with the
backend authentication server and then a secure association procedure
with the BS.
A mobile wireless peer may need change its serving BS due to its
geographical/ topological mobility.
For simplicity at this point we assume that the mobility scenario
does not require roaming between different AAA domains. Mobility
enabled security architectures should be designed in a way that full
EAP authentication exchanges should not be required during handovers.
In other words if the new BS for the peer is itself served by the
same AAA infrastructure as the old BS and if the master keying
material (MSK, EMSK and/ or AAA key) established during the EAP
authentication phase through the initial BS is still valid, the EAP
authentication phase (at least in large part) should be skipped for
the new BS. This way only security association establishment
procedures between the peer and new BS are required, which means a
substantial reduction in the latency involved in handover security
procedures. The problem however is that the security association
protocols typically use a nonce-in the clear-exchange along with the
keying material derived from full EAP authentication process. If the
derivation of temporary session keys is based on the AAA-key
directly, it would require that AAA-key must be shared with each BS.
Once the AAA-key is shared with one BS, that BS is able to derive the
session keys between the peer and its neighboring BSs pair, as long
as the BS can hear the over the air security association exchange.
This would lead to a security compromise. For that reason we propose
to use a slightly modified key derivation mechanism (as suggested in
previous versions of [EAPEXT]).
2. Terminology and Assumptions
In this document we refer to a network point of attachment as base
station (as defined below). For simplicity in presentation of the
different problems and solution approaches, we assume that a mobile
peer does not roam outside a single administrative domain consisting
of a AAA infrastructure where all the AAA entities trust each other.
We also assume that the functionality of EAP authentication server
Nakhjiri et. al. EAP keying and handover support [Page 4]
resides at the AAA server. The functionality of an EAP authenticator
or a AAA NAS may or may not reside at a direct point of attachment.
Base Station (BS)
A network point of presence with layer-2/1 MAC/PHY capability
towards the peer (acts as an AP), and layer-3 capability (IP)
towards the backend infrastructure.
EAP-method
The EAP-based authentication method that is used during a full EAP
authentication between the peer and the EAP server.
EMSK (Extended Master Session Key)
The Keying material that is derived between the EAP peer and
server and exported by the EAP method. The EMSK is never shared
with a third party. Derivation of EMSK is EAP-method dependent.
MSK (Master Session Key)
The Keying material that is derived between the EAP peer and
server and is exported by the EAP method. Derivation of MSK is
EAP-method dependent.
Home AAA server (AAAH)
The AAAH is a AAA server that operates in the home network. The
home network is the network that holds the user record.
3. Key derivation overview
As mentioned earlier, to avoid the security issues related to the
key-sharing between the BSs, the initial master keying materials,
such as AAA-key not be shared directly with each BS. Instead we
suggest using a key specific to each point of attachment, we call BS
master key (BSMSK). The key derivation example can be as follows
AAA-Key = MSK (0,63)
AMSK = KDF (EMSK, "EAP AAA-Key derivation for multiple attachments",
length)
BSMSK-A = prf (AMSK (0, 63),"EAP AAA-Key derivation for multiple
attachments", AAA-Key, BS-A-Id, Peer-Id, length)
BSMSK-B = prf (AMSK (0, 63),"EAP AAA-Key derivation for multiple
attachments", AAA-Key, BS-B-Id, Peer-Id, length)
Where:
Peer-Id = Peer link address
Nakhjiri et. al. EAP keying and handover support [Page 5]
BS-A-Id = AP/BS A link address
BS-B-Id = AP/BS B link address
prf = HMAC-SHA1
KDF = can be defined according to the security policies
length = length of derived key material
As mentioned earlier the derivation of MSK and EMSK is method
dependent. For example for EAP-TLS, MSK and EMSK are derived as
follows
MSK = TLS-PRF-64(TMS, "client EAP encryption", client.random ||
server.random)
EMSK = second 64 octets of:
TLS-PRF-128(TMS, "client EAP encryption", client.random ||
server.random)
Where:
TLS-PRF-X= TLS PRF function defined in [RFC2246] computed to X
octets
client.random = Nonce generated by the TLS client.
server.random = Nonce generated by the TLS server.
As shown from above, following the initial EAP authentication, the
AAA key and BSMSK can be derived and the BSMSK is transported over to
the BS to which the peer is attached to. Once the peer and the BS
receive notification about the completion of the EAP authentication
process and the transport of BSMSK to the BS, they can engage in a
security association protocol, as described below.
The security association protocol is typically controlled by the
standard body defining the wireless link between the peer and the
base station. In the following we provide a generic example of a
security association protocol for illustration purposes:
. After receiving the EAP success and receiving the BSMSK from the
infrastructure, the BS sends a SAP-request to the peer,
including a BSrandom (an unrepeated random nonce generated by
the BS) and BS-ID (an identifier according to the specification
of the L2 link between the peer and the BS).
. The peer calculates BSMSK for the BS-ID, generates an MSrandom
(an unrepeated random nonce generated by the MS) and calculates
temporary session encryption keys (TSEK) and authentication keys
(TSAK). The peer then generates a SAP-Response for the BS,
including MSrandom, BSrandom, MSID, BSID and an HMAC signature
using the calculated TSAK.
. The BS calculates the TSAK, TSEK based on the received
information from SAP-response from the peer, confirms the HMAC
Nakhjiri et. al. EAP keying and handover support [Page 6]
signature from the peer and if there is a match, it sends a SAP-
confirm message back to the peer, including an HMAC of its own.
The process above can include authenticated negotiations of TSEK and
TSAK life times as well. The TSEK and TSAK for BS-A can for example
be calculated as follows:
TSEK-A = KDF (BSMSK-A,"Temporary Session Encryption Key derivation",
BS-A-Id, Peer-Id, BSrandom, MSrandom, length),
TSAK-A = KDF (BSMSK-A,"Temporary Session Message Authentication Key
derivation", BS-A-Id, Peer-Id, BSrandom, MSrandom, length)
The problem that this draft is tackling is how to lay out the
authentication architecture so that the BSMSK delivered to the BS in
time for security association protocol procedures. In the following
we discuss various alternatives for this architecture. However, first
we like to point a few issues that will possibly be common to most of
the alternatives suggested below.
3.1 Key transport timing issues
One issue with the framework defined in [EAPKEY6] is that, when a AAA
client (EAP authenticator) acts as a pass-through, the timing of the
EAP success sent to the authenticator relative to the timing of the
AAA message carrying the BSMSK (in [EAPKEY6]: AAA-key) is not clear:
. If the authenticator simply forwards the EAP success, received
from the EAP server, to the peer without waiting for reception
of the BSMSK from the EAP server, the subsequent security
association protocol may fail, due to race conditions.
. If on the other hand, the authenticator waits with forwarding of
the EAP-Success to the peer, until it has received the BSMSK
from the server, then the authenticator is not really acting as
a pass-through.
One simple solution to this problem is for the AAA/ EAP server to
simply wait until it has successfully transmitted the BSMSK or AAA
key to the authenticator and then send an EAP-Success to the
authenticator. However, as we see below, some of the solutions
proposed in this document assume that the BSMSK is transported from
some entity other than the EAP server to the authenticator. In that
case, more specific triggering/ notification procedures need to be
used to prevent such race conditions.
3.2 Channel binding issues
Nakhjiri et. al. EAP keying and handover support [Page 7]
The EAP key management framework recommends the AAA-key scope to be
defined by peer ID and authenticator ID, assuming that the peer ID is
conveyed securely to the authenticator and the authenticator ID is
conveyed securely to the peer. Beside the fact that the secure
exchange of IDs may have practical implications, it seems that the
binding needs to be known to the AAA server as well. Typically the
peer may only know the authenticator ID that the authenticator uses
over the link layer between the peer and the authenticator and this
ID may be different from the ID (e.g. NAS ID or NAS IP) that the
authenticator uses when communicating with the EAP/ AAA server.
Extending the framework to distribute BSMSKs would require definition
of scope for BSMSK. We recommend the BSMSK scope be defined between
the peer and the BS, based on identifiers that are used over the
peer-BS communication link. However, this may mean that these
identifiers have to be transferred in a protected manner to whichever
entity (AAA server/ LKDC/ EAP proxy) that is to generate BSMSK and
define its scope. Using AAA protocols for this purpose would require
specific channel-binding-attributes.
It is not clear whether it is practical to inform the AAA servers
about the BSMSKs and their scope, even in cases where the BSMSKs are
generated outside the AAA/ EAP servers.
3.3 Life times
The life time of BSMSK may need to be defined based on the link layer
technology operator authorization policies. However, the life time of
a BSMSK cannot be longer than that of the AAA-key, from which the
BSMSK is derived. When the AAA server is not responsible for
generation of BSMSK, the AAA server cannot be responsible for
enforcement of BSMSK lifetime, either. In such cases, generic BSMSK
life time policies may be stored at the AAA server and conveyed to
the BS as well as the entity responsible for generation/ distribution
of BSMSK in out-of-band manners. The key distribution entity would
then be responsible for life time management and enforcement as well.
The life time of AAA-key itself should be negotiated and communicated
properly. It is stated that the root service SA, that is established
as a result of the EAP-authentication and AAA-key transport, defines
the AAA-key lifetime. However, [EAPKEY6] states that ææEAP does not
support negotiation of key life time of exported or derived keysÆÆ.
Furthermore, it is stated that ææto support the method-independence,
key management of the exported or derived keys SHOULD NOT be provided
within EAP methodsÆÆ. Except defining the maximum allowed life time
for all the exported keys through the ææsession-timeoutÆÆ attribute,
method-independent mechanisms for negotiation of AAA-key life time
are not defined. Furthermore, a AAA attribute is required to transfer
the key life time information to the authenticator.
Nakhjiri et. al. EAP keying and handover support [Page 8]
4. Key distribution architecture alternatives
4.1 AAA server-based
This alternative assumes that the BS acts as the Authenticator during
the initial EAP authentication process (as shown in figure below),
but does not receive the AAA-key from the authentication server.
Instead the server calculates the BSMSK and sends it to the serving
BS over a AAA protocol.
|Pre-EAP: Long term credentials |
|< ----------------------------------------- > |
| No pre-EAP trust | Pre-EAP shared key |
|< ----------------->|<----------------------> |
| |
+-+-+-+-+ L2 +-+-+-+-+-+ AAA +-+-+-+-+
| EAP |----------| BS |---------------|EAP AS |
| Peer | | EAP Athr| BSMSK |AAAH |
| | | NAS |< -------------| |
+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+
Figure 2a: Pre-existing trust relationships in a AAA-based key
distribution model
4.1.1 Initial EAP authentication and key distribution
The initial EAP authentication is performed between the EAP peer and
the authentication server, using the BS (authenticator) as a pass-
through.
. Once the EAP authentication process between the EAP peer and
Authentication server is complete, the server sends the BSMSK to
the serving BS over a AAA message. The exact RADIUS/ Diameter
attribute that carries the BSMSK over to the authenticator is to
be defined.
. Our recommendation is that, the authentication server waits with
sending an EAP-Success to the authenticator until after the
BSMSK is complete.
. The authenticator forwards the EAP-Success to the EAP peer and
either initiates the Security association protocol or waits for
the peer for that initiation.
Nakhjiri et. al. EAP keying and handover support [Page 9]
EAP peer BS/ Authenticator Auth. Server
-------- ------------- ----------
| | |
|<----------------------------->|<--------------------------->|
| EAP auth (pass through) | |
| |<--------------------------->|
| | BSMSK-Key transport |
| |<--------------------------- |
| | EAP success |
|<----------------------------- | |
| EAP Success | |
|<----------------------------->| |
| Secure association protocol | |
Figure 2b: combined EAP authentication and key management during
network entry
4.1.2 Handover
As the peer determines the need for handover to a new BS, it can
send a handover request to the new BS directly. The new BS then
needs to inquire the proper keying material (BSMSK-N) from the
Authentication server to start security association establishment
with the peer. The main issue with this approach is that it
inserts the BSMSK-fetch procedure in the handover timing critical
path. Instead we recommend that the peer engages the current
(serving) BS to start the handover security procedures as shown in
the following figure.
EAP peer old BS new BS Auth. Server
-------- -------- -------- ------------
| | | |
| HO-Key-request | RADIUS Access Request |
|------------------>|---------------------------------------->|
| | RADIUS Access Accept (E[BSMSK-N]) |
| |<----------------------------------------|
| | CTXP | |
| |(E[BSMSK-N]) | |
| |<--------- > | |
| | HO-Key-Ack | |
| HO-Key-Confirm |<---------- | |
|< ---------------- | | |
| Secure association protocol | |
|<-----------------------------> | |
| | | |
Figure 2c: key material acquisition during handover
Nakhjiri et. al. EAP keying and handover support [Page 10]
. As the peer determines the need for handover to a new BS, or
when it discovers a new BS (or a set of candidate BSs) as part
of its scanning process, it can send a HO-Key-request to serving
(old) BS to request the authentication server to create a BSMSK-
N for the new BS. This message needs to include MSID and BSID
for the new BS. If more than one new BS is involved, the
messaging described hereon should support inclusion of
information for more than one BS.
. The old BS creates a AAA request (format TBD, e.g. RADIUS Access
Request, or a RADIUS Authorization-only request) and includes
the MSID and BSID for the BSs included in the message attributes
(TBD) from the peer. The BS may also include additional BSIDs to
this list based on its own databases on its neighbor BSs.
. The authentication server looks up the entries for the peer
based on the received MSID. If the server can verify that peer
has performed the initial EAP authentication, created the keying
material (MSK, EMSK, AAA-key), it check the validity of the
keying material (life time not expired). The authentication
server then examines the received BSIDs. If the server has
security associations with BSs listed, or determines that it can
establish security associations with these BSs, the server
generates the BSMSK for any BS, whose BSID is included in the
request. The reason for the latter restriction, is that the
BSMSK for each BS must be encrypted with an encryption key
(called AAA-BS key) that is only shared by the AAA server and
that BS. This way the old serving BS, that receives the BSMSK,
cannot extract the BSMSK for any other BSs. E[BSMSK] denotes an
encrypted BSMSK. Once, the authentication server received
confirmation about establishment of security association with
the new BS (acquired AAA-BS key), the AAA server sends the
(BSID, E[BSMSK]) pairs (in a TBD attribute) for each BSID in a
AAA response (RADIUS Access Accept) to the old BS. The (BSID,
E[BSMSK]) should also be signed by the AAA server by a key
recognizable by the target BS. The BSMSK information may include
life time information as well.
. The old BS sends the signed (BSID, E[BSMSK]) pair to any BS that
it can communicate with, possibly using a context transfer
process (CXTP).
. Once the CXTP is complete, the new BS receives the (BSID,
E[BSMSK]), verifies the AAA server signature and decrypts the
BSMSK, it is ready to engage in a security association procedure
with the peer as the peer arrives. The new BS sends a HO-Key-Ack
to the old BS. The new BS may opt to send HO-Key-Ack simply
before verification of the keying material (due to timing
constraints).
. Upon receiving the HO-key-Ack from the new BS, the old BS sends
a HO-Key-confirm message to the peer.
. The peer can start the signaling of security association
protocol with the new BS at this point.
Nakhjiri et. al. EAP keying and handover support [Page 11]
It should be noted that the process described above assumes that
server-initiated messaging is not supported. If server-initiated
messaging is supported (Diameter), the authentication server can
simply send the BSMSK to the new BS, without the need for going
through the old BS.
4.1.3 Pros and Cons
This method has the following advantages:
. Transport of EAP signaling over the link layer (EAP over L2
methods, such as EAPOL, PKMV2) and between the BS and AAA server
(EAP over RADIUS or Diameter) is well defined.
. The AAA-key does not leave the EAP/ AAA server or the peer. Only
BSMSK that is bound to a specific (peer, BS) pair is shared with
entities outside the initial authentication exchange. In case a
BS is compromised, only the BSMSK for that BS is compromised.
. Proactive and timely BSMSK acquisition signaling can reduce the
delays related to handover security establishment significantly.
. The AAA server can directly define BSMSK life time and send this
information to the BS.
. The AAA server is fully aware of the BSMSK key scope.
The disadvantages of a AAA-based approach are as follow
. Since the AAA server must create BSMSK for every new BS, to
which the peer intends to connect to, the AAA server needs to be
involved in every handover and this may increase the load on AAA
server significantly.
. The AAA server must store information on both AAA-key and BSMSK.
. Acquisition of BSMSK in conjunction to handover requires
accurate timing with other handover signaling. This typically is
a tricky process. We suggested a procedure through which the new
BS can acquire its keys through the old BS and based on a
trigger provided by the mobile peer. In cases the old and new BS
do not have a direct line of communication/ trust relationship,
or the peer cannot provide adequate triggers, this may not be
possible. That means the new BS needs to directly acquire the
BSMSK for the peer from the server. Two approaches comes to
mind: 1) The new BS can receive BSMSK regarding peers long in
advance. The AAA server can deliver the BSMSK to several BSs at
once. Since it is not practical for the AAA server to maintain
groupings of BSs, it is possible that the serving BS during the
initial authentication, requests BSMSKs for a number of
neighbors. This can be potentially inefficient since the peer
may never move to some BSs. 2) the new BS can directly place a
request with the AAA server based on a trigger that it receives
from the peer. Such triggers are only available when the peer is
in the coverage area of the new BS and this is typically does
Nakhjiri et. al. EAP keying and handover support [Page 12]
not allow enough time for the roundtrip to the AAA server for
acquisition of the BSMSK.
. The AAA server must be aware of the identifiers the peer and the
BS use over the L2 link (peer-ID and BS-ID). This may require
additional complexity to the AAA infrastructure data base, in
case the peer and BS are using other types of identity (such as
NAI or IP addresses) towards the AAA server. For peers capable
of multiple technologies and thereby multiple L2 identifiers,
this problem may become even more complicated.
4.2 Local Key distribution Center
According to this alternative, the peer will perform an EAP
authentication through a BS acting as EAP authenticator and AAA NAS.
The peer and EAP/AAA server both generate the EAP MSK/EMSK and AAA-
key as described previously. However, the EAP key management
procedure is modified slightly:
+-+-+-+-+-+ AAA-key
| LKDC |<-------
+-+-+-+-+-+ \
| \
|BSMSK \
V \
+-+-+-+-+ L2 +-+-+-+-+-+ AAA --+-+-+-+-+
| EAP |----------| BS |---------------|EAP AS |
| Peer | | EAP Athr| |AAAH |
| | | NAS | | |
+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+
Figure 3a: Key distribution architecture using LKDC
. The EAP server forwards the AAA-key to a local key distribution
center (LKDC) instead of to the BS/ authenticator.
. The EAP server is no longer involved in generation of BSMSK from
the AAA-key.
. The LKDC will instead calculate the BSMSK from the received AAA-
key and send the BSMSK over a secure link to the BS/
authenticator. Each BS receives its keying material from only
one LKDC (or two for failover support). The BS can be configured
with the identity of the LKDC for which it receives its keying
material from and the trust relationship that it needs to use
when communicating with LKDC.
. To simplify the AAA server architecture, it is not required of
the AAA server to store the LKDC-BS mappings. This information
can be provided during the EAP key management procedure, but
using AAA signaling. The AAA server is however required to have
a trust relationship and security association with the LKDC so
Nakhjiri et. al. EAP keying and handover support [Page 13]
it can communicate with the LKDC securely (to send the AAA-key
for instance).
. Also note that the LKDCs may have trust relationship with
different AAA servers if required to support roaming.
- AAA1- AAA2
/ | \/
/ | /\
/ | / \
/ |/ \
LKDC1 LKDC2 LKDC3
/ | \ / \ /| \
/ | \ / \ / | \
NAS1 NAS2 NAS3
Figure 3b: Relationships between LKDC and other AAA entities
An important note is due: the LKDC is an off-path entity for EAP
authentication process. The serving BS still acts as an EAP
authenticator during EAP authentication and as a AAA NAS for access
control procedures, which means that the BS needs to have a direct
security association (such as RADIUS shared secret) with the AAA
server. The LKDC only comes in the process when it is time for
distribution of BSMSK to the BSs as described below.
4.2.1 Initial authentication
The initial authentication is performed as follows:
. The EAP peer starts the EAP authentication with the EAP server
through the serving BS that acts as an EAP authenticator and AAA
client.
. Once the EAP authentication is complete, the BS and the peer
receive EAP success indications.
. The EAP server now needs to send the AAA-key to the LKDC (not to
the authenticator) over a secure link. However the EAP server
needs to know the address and identity of the LKDC first. There
are two alternatives solutions for this problem:
. In a Diameter infrastructure or a RADIUS infrastructure where
server-initiated messaging is possible, the NAS simply needs to
include the identity of the LKDC in a AAA message (TBD message)
while the EAP authentication for the peer is being completed.
When the server completes the authentication, it can proactively
send the AAA-key to the LKDC.
. In a typical RADIUS infrastructure, where server-initiated
messaging is not possible, the LKDC can acquire the AAA-key from
the RADIUS server based on a request-accept exchange, started by
the LKDC (as shown the figure above). The trigger for this
process can be provided by the NAS (shown as ææEAP Success
notificationÆÆ in the figure).
Nakhjiri et. al. EAP keying and handover support [Page 14]
EAP peer BS/Authen AAA server LKDC
-------- ----------- ------------ ----------
| | | |
|<------------------->|<------------->| |
|EAP auth | AAA pass-thru | |
| | | |
|<------------------- |<------------- | |
| EAP success | EAP success | |
| |----------------------------------> |
| | EAP Success notification |
| | | <---------------- |
| | | AAA-Key request |
| | | ----------------> |
| | | AAA-Key transport |
| |<--------------------------------- |
| <------------------ | BSMSK transport |
|SAP trigger/1 st msg | | |
|<------------------> | | |
| SA protocol | | |
Figure 3c: EAP authentication and key distribution using LKDC
Channel binding and key scope issues
Since the AAA-key is not known to the authenticator, it should not
be bound to the authenticator either. The AAA-key scope in this
case should be defined by (peer ID, LKDC ID) pair, rather than
(peer ID, authenticator ID) pair. The identifiers are as
understood by AAA infrastructure. However, the peer does not and
need not know the identifier of the LKDC, since the peer does not
have any direct contact with the LKDC. If the peer is required to
store the scope for the AAA-key, it needs to receive the LKDC ID
from the EAP/ AAA server. In that case the LKDC ID needs to be
communicated with EAP signaling (since the peer has no AAA
functionality) to the peer and possibly through secure EAP method
signaling.
The AAA server controls the scope of AAA-key and hence needs to
know the LKDC ID through signaling from NAS. The AAA messaging and
attributes for this purpose needs to be defined.
The BSMSK scope on the other hand should be defined by (peer ID,
BS ID, LKDC ID) triplets. The LKDC ID and BS ID needs to be send
to the peer in an authenticated manner within the EAP method or as
part of secure association protocol signaling. The alternative
would be to base the BSMSK scope on (peer ID, BS ID) pairs to
allow the use of link-specific methods. The suitability of each
method needs to be further studied.
In either case, it is not practical for the EAP server/ AAA server
to store information on BSMSK, so this information will be stored
at the LKDC.
Nakhjiri et. al. EAP keying and handover support [Page 15]
4.2.2 Handover
An example of a handover signaling is shown below.
. To expedite the handover process, we suggest that the peer sends
a trigger for new BSMSK acquisition to the old BS, which in turn
forwards the request to the LKDC.
. If the new BS is within the region controlled by LKDC (which
also means the LKDC and new BS have a trust relationship and
encryption/ authentication keys established), the LKDC can
simply send the BSMSK-N for the new BS directly to the new BS.
. If the new BS is outside the LKDC control, the old LKDC must
locate the new LKDC for the new BS and if an ææold LKDC-new LKDCÆÆ
trust relationship exists, send the AAA key and related
information (e.g. life time) over the new LKDC. The new LKDC
will then calculate the new BSMSK for the new BS and holds the
AAA-key for future use. All this assumes that the old LKDC can
locate the new LKDC based on the new BS information provided by
the old BS. This is not an unreasonable assumption given that
the LKDC is aware of mobility topology and should be aware of
its neighbor LKDCs.
. If the old LKDC cannot find the new LKDC, or the new LKDC and
old LKDC do share a trust relationship, or sharing AAA-key is
against AAA policies, the BSMSK request needs to be referred to
the AAA server (procedure not included here).
. Once the new BS receives the BSMSK (in encrypted form) and
extract the key, it can send a notification to the old BS, which
in turn forwards a similar notification to the peer.
. Upon receiving the notification, the peer can engage in security
association procedure with the new BS. Note that the peer may
not be able to wait for such notifications. In such cases the
delay associated with the new BS response to the security
association procedure initiated by the peer cannot be predicted
easily.
EAP peer old BS new BS LKDC
-------- -------- -------- ------------
| | | |
| HO-Key-request | BSMSK Request |
|------------------>|------------------------------------>|
| | | BSMSK (E[BSMSK-N]) |
| | BSMSK-Ack |<----------------------|
| HO-Key-Confirm |< -----------| |
|< ---------------- | | |
| Secure association protocol | |
|<-----------------------------> | |
| | | |
Figure 3d: Handover key distribution using LKDC
Nakhjiri et. al. EAP keying and handover support [Page 16]
4.2.3 Pros and Cons
The advantages of this model are as follows:
. The AAA/ EAP server is off-loaded from having to generate BS-
specific keys for a large number of BSs and being involved in
every inter-BS handover.
. The AAA-key is not revealed to possibly physically insecure BSs.
. The initial EAP authentication is performed in a typical way
with the first hop network device (BS) acting as an EAP
authenticator as well as a AAA client. This would mean EAP can
be run over the L2 link directly.
. It is possible to co-locate LKDCs with mobility management
entities or make the LKDCs aware of the mobility patterns or BS-
neighbor lists. This way the LKDC can proactively send BSMSKs to
BSs in the vicinity of the serving BS.
. When the BSMSK acquisition is performed based on requests by old
or new BS, the BS-LKDC roundtrip can be expected to be much
shorter than the BS-AAA server roundtrip.
Disadvantages
. The need for secure backhaul communication protocol between the
BS and the LKDC.
. Depending on the implementation, the AAA server may not be able
to enforce control over the usage of AAA-key by LKDC. For
instance, the lifetime of BSMSK based on the parent AAA-key is
not controlled directly by the AAA server. This control may be
enforced by including life time information in the calculation
of BSMSK or by separate authorization signaling performed with
the NAS using a AAA protocol.
. The timing of EAP-success and acquisition of BSMSK by BS from
LKDC may create race conditions for start of secure association
protocol. Specific triggers may be required for this process.
. Inter-LKDC handovers may still require consultation to the AAA-
server.
4.3 EAP Proxy approach (multi-hop peer-NAS link)
In this approach, the EAP authenticator and AAA client (NAS)
functionality does not reside at the same physical box as the BS.
Instead the BS simply acts as an ææEAP proxyÆÆ forwarding EAP messaging
from the peer to the NAS. On the peer side, the BS must encapsulate
the EAP messaging inside the link layer protocol, while on the NAS
side, the BS must encapsulate the EAP messaging into the protocol
between BS and NAS (possibly a deployment specific protocol). The EAP
will run between the peer and the server transparent to the existence
of the EAP proxy.
Nakhjiri et. al. EAP keying and handover support [Page 17]
4.3.1 Initial authentication
. Initial authentication is performed in a manner similar to the
AAA-based approach described earlier. However, in order to allow
for control of AAA-key and BSMSK scope and life time, the NAS
may have to obtain and include two sets of identifiers for peer
and BS as AAA protocol attributes or EAP attributes. The two
sets of identifiers are: L2 ID, (such as MAC address) for peer
and BS, and ID as specified at the AAA server database (NAI or
other ID).
. Once the authentication is complete, the AAA server sends the
AAA-key to the NAS, which in turn calculates the BSMSK for the
BS and sends it over to the BS.
. The AAA server will send an EAP success towards the peer. The
AAA server should send the EAP success after it transmitted the
AAA-key to the NAS. Ideally the EAP peer should receive the EAP
success as a trigger to start the Secure association protocol.
This in turn means the NAS should wait until it creates the
BSMSK for the BS before passing the EAP success along to the BS
for forwarding the peer. However, this may not always be
possible, so the peer may have to wait for a more explicit
trigger for start of secure association protocol. The timing of
EAP success should be further studied.
EAP peer BS/ EAP Proxy NAS Auth. Server
------- ------------- --- ----------
| | | |
|<----------------->|<----------->|<------------------->|
| EAP auth/L2 | EAP/TBD | EAP/AAA pass-thru |
| | pass-thru | |
| | |<------------------- |
| | | AAA-Key transport |
| | |<------------------- |
| | | EAP Success |
| |<------------| |
| | BSMSK trans.| |
|<--------------------------------| |
| EAP success | |
|< ------------ > | | |
| SA protocol | | |
Figure 4a: EAP authentication and key management using an EAP proxy.
Channel Binding and key scope issues
Again, the scope of the BSMSK and AAA-keys should be different.
The AAA-key scope should be based on (peer ID, NAS ID) pair. The
peer may need to receive the NAS ID from the authentication server
in a secure manner and as part of EAP signaling. The BSMSK scope
Nakhjiri et. al. EAP keying and handover support [Page 18]
should be based on (peer ID, BS ID, NAS ID) triplets. The
authentication server should not be kept aware of the BSMSK scope.
4.3.2 Handover
The new BS needs to acquire its BSMSK from a NAS that holds the AAA
key in manner similar to that of the LKDC approach.
No EAP signaling is required during handover. No signaling with the
AAA server is required as long as both BS are served by the same NAS,
or two NASes that can share AAA-keys (as explained for LKDC
approach). When the two BSs do not share an LKDC, the same
complications as those described for LKDC case will arise and very
similar approaches can be used to resolve the issues.
EAP peer old BS new BS NAS
-------- -------- -------- ------------
| | | |
| HO-Key-request | BSMSK Request |
|------------------>|------------------------------------>|
| | | BSMSK (E[BSMSK-N]) |
| | BSMSK-Ack |<----------------------|
| HO-Key-Confirm |< -----------| |
|< ---------------- | | |
| Secure association protocol | |
|<-----------------------------> | |
| | | |
Figure 4b: Handover key distribution with EAP proxy approach.
4.3.3 Pros and Cons
Advantages
. The AAA/ EAP server is off loaded from having to generate BS-
specific keys for a large number of BSs and being involved in
every inter-BS handover.
. The AAA-key is not revealed to possibly physically insecure BSs.
. No EAP authenticator or AAA client functionality is required
from the BS.
Disadvantages
. The BS has to perform EAP encapsulation protocol translation
from EAP over L2 to EAP over a TBD protocol. Since the TBD
protocol is being used instead of a AAA protocol to carry EAP
messaging, the TBD protocol must provide security mechanisms
equivalent to those provided by the AAA protocol. Furthermore,
the TBD protocol may be deployment- or access technology
specific, and this can cause interoperability issues for NASes
that need to support BS from different manufacturers/ operators
or access technologies.
. The AAA server cannot become aware of the existence or identity
of the BS, as the BS simply acts as a proxy behind the EAP
Nakhjiri et. al. EAP keying and handover support [Page 19]
authenticator, unless the BS information is explicitly provided
to the AAA server by the NAS.
. The AAA server may not be able to control the binding, scope or
life time of BSMSKs.
. The timing of EAP-success and acquisition of BSMSK by BS from
EAP proxy may create race conditions for start of secure
association protocol. Specific triggers may be required for this
process.
4.4 AAA-proxy approach
The final approach is to use a AAA proxy between the AAA server and
the authenticator. The AAA server will send the AAA-key to the AAA
proxy (instead of to the authenticator). The function of AAA proxy
for creation of BSMSK for each base station during initial
authentication and handover is as described for LKDC in the previous
step.
EAP BS/EAP Auth AAA Authentication
peer /NAS proxy Server
---- ---------- ------- ----------
| | | |
|<------------->|<---------------->|<------------------->|
| EAP auth (phase 1a) AAA pass-through |
| | | |
| | |<------------------- |
| | | AAA-key trans |
| |<---------------- | |
| | BSMSK transport | |
| |----------------> | |
| | BSMSK confirm | ------------------> |
| | | key trans. confirm |
|<------------- |<---------------- |<------------------- |
| | | EAP Success |
|<------------->| | |
| Secure assoc.| | |
| protocol | | |
Figure 5a: EAP authentication and key management using AAA proxies.
Channel binding and scope issues
The issues are similar to those described earlier.
4.4.1 Handover procedure
Nakhjiri et. al. EAP keying and handover support [Page 20]
As seen in the figure below, the AAA proxy function during handover
is exactly the same as the LKDC.
EAP peer old BS new BS AAA proxy
-------- -------- -------- ------------
| | | |
| HO-Key-request | BSMSK Request |
|------------------>|------------------------------------>|
| | | BSMSK (E[BSMSK-N]) |
| | BSMSK-Ack |<----------------------|
| HO-Key-Confirm |< -----------| |
|< ---------------- | | |
| Secure association protocol | |
|<-----------------------------> | |
| | | |
Figure 5b: Handover key distribution with AAA proxies.
The AAA proxy will have to have key generation and distribution
capabilities in addition to the traditional functionalities defined
for AAA proxies. The list of pros and cons is otherwise similar to
that for LKDC approach.
5. Security considerations
Most of the security issues are discussed while providing each of
the solution alternatives. Among the most important issues are:
. Transport of AAA-key or BSMSK through AAA protocols is not well-
specified yet. AAA messages and attributes need to be
investigated for this purpose.
. Definition of scope, naming, and life time for AAA-key and BSMSK
needs to be investigated further.
. Synchronization between EAP-Success and AAA messaging that
carries keying material needs to be examined further.
6. References
[EAPKEY6] B. Aboba, Et. Al., ææExtensible Authentication Protocol
(EAP) Key Management FrameworkÆÆ, Internet Draft, IETF, draft-ietf-
eap-keying-06 (work in progress), April 2005.
[EAPKEY5] B. Aboba, Et. Al., ææExtensible Authentication Protocol
(EAP) Key Management FrameworkÆÆ, Internet Draft, IETF work in
progress, draft-ietf-eap-keying-05, February 2005.
Nakhjiri et. al. EAP keying and handover support [Page 21]
[EAPEXT], B. Aboba, ææExtensible Authentication Protocol (EAP) Key
Management ExtensionsÆÆ, Internet Draft, IETF work in progress, draft-
aboba-eap-keying-extens-00, April 2005.
[EAP3748], B. Aboba, Et. Al., ææExtensible Authentication Protocol
(EAP)ÆÆ, RFC 3748, IETF, June 2004.
[RADEAP3579], B. Aboba, P. Calhoun, ææRADIUS (Remote Authentication
Dial In User Service) Support For Extensible Authentication Protocol
(EAP)ÆÆ, RFC 3579, IETF, September 2003.
[MOBTERM3753], J. Manner, M. Kojo, ææMobility Related TerminologyÆÆ,
RFC 3753, IETF, June 2004.
Acknowledgments
.
Author's Addresses
Madjid Nakhjiri
Motorola Labs
Contact Email: Madjid.Nakhjiri@motorola.com
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.
Nakhjiri et. al. EAP keying and handover support [Page 22]
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 (2005). 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.
This Internet-Draft will expire January 2006.
Nakhjiri et. al. EAP keying and handover support [Page 23]
