Network Working Group M. Nakhjiri
Internet-Draft Huawei USA
Expires: July 19, 2007 January 15, 2007
A Keying hierarchy for managing Wireless Handover security
draft-nakhjiri-hokey-hierarchy-03
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 19, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Nakhjiri Expires July 19, 2007 [Page 1]
Internet-Draft A Handover Keying Hierarchy Description January 2007
Abstract
The Problem of AAA-based key management for facilitating secure
handovers in a wireless mobile environment as well as for optimizing
re-authentications has been described in [I-D.nakhjiri-aaa-hokey-ps]
and [I-D.clancy-hokey-reauth-ps]. This document provides a solution
for the problems described in those drafts. Specifically an EAP
initiated key hierarchy to significantly reduce handover and re-
authentication latency is defined. A number of architectural and
protocol trade-offs are also presented. Signaling messages,
extensions and attributes for deploying the handover key hierarchy
are shown in proactive and reactive modes. Document also proposes a
method to solve channel binding problem.
Table of Contents
1. Introduction and Problem statement . . . . . . . . . . . . . . 3
1.1. Deploying ANs and Access gateways . . . . . . . . . . . . 3
1.2. Choice of root keys . . . . . . . . . . . . . . . . . . . 4
1.3. purpose of this document . . . . . . . . . . . . . . . . . 5
2. Terminology, Assumptions and new concepts . . . . . . . . . . 5
3. Proposed architecture . . . . . . . . . . . . . . . . . . . . 7
4. Key Hierarchy and Generation . . . . . . . . . . . . . . . . . 9
5. Architecture and messaging . . . . . . . . . . . . . . . . . . 12
5.1. Inter-ADC AN-handover and fast AAA re-authentication . . . 12
5.1.1. Proactive signaling . . . . . . . . . . . . . . . . . 13
5.1.2. Reactive signaling . . . . . . . . . . . . . . . . . . 15
5.2. Intra-ADC AN-handover . . . . . . . . . . . . . . . . . . 15
5.3. channel binding . . . . . . . . . . . . . . . . . . . . . 16
5.3.1. channel binding between peer and ADC . . . . . . . . . 17
5.3.2. channel binding between peer and AN . . . . . . . . . 18
5.4. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.5. New Extensions . . . . . . . . . . . . . . . . . . . . . . 19
6. backward compatibility with EAP . . . . . . . . . . . . . . . 19
7. Security report Card . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative references . . . . . . . . . . . . . . . . . . 22
Appendix A. Appendix A: Architectural choices . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Nakhjiri Expires July 19, 2007 [Page 2]
Internet-Draft A Handover Keying Hierarchy Description January 2007
1. Introduction and Problem statement
It is becoming more and more common to use the Extensible
Authentication Protocol (EAP) framework ([RFC3748] ) for access
control authentication and bootstrapping the wireless link security.
This is done by performing an EAP method [RFC3748] that is capable of
generating EAP master keys, MSK and EMSK, ([I-D.ietf-eap-keying]),
which are, in turn, used to bootstrap the so called temporary session
keys, TSK) for the wireless link. The typically deployed model is
one where EAP authentication is performed between the peer and a
backend server, without involving much intelligence from the edge of
the network. At the edge, the model only uses a logical entity
called pass-through authenticator, which only takes part in changing
the form of encapsulation of the EAP, but is otherwise passive until
the very end, where the keying material for establishment of TSKs are
generated from EAP master keys and are transported to this pass-
through authenticator.
Deploying this model creates a number of issues that are partly
listed in the problem statement drafts ([I-D.nakhjiri-aaa-hokey-ps]
and [I-D.clancy-hokey-reauth-ps]); for instance, the model does
suffers from the inherent lack of support for fast re-authentications
in EAP when peer's session is expiring. Another issue is the way the
keying material derived from the initial EAP authentication, and
distributed to the pass-through authenticators does not readily allow
for optimized handovers without breaking security principles.
Developing mechanisms for fast re-authentications although solving
the problem in cases of session expiry, may not be adequate for
solving handover latency problems, since many times a round trip to
the AAA/EAP server may simply be too time consuming and therefore
development of a key hierarchy that readily allows for handovers may
be more efficient.
This part of the document intends to elaborate on several more
detailed problems that are involved with use of EAP framework in a
wireless mobile environment:
1.1. Deploying ANs and Access gateways
Wireless Networks today deploy specific access nodes (AN) for
providing link layer connectivity and other services such as policy
control etc to the wireless peers. There are several reasons for the
access service operators to wish to manage groups of ANs in clusters
managed by a single gateway (e.g. Access Service Node gateway,
ASN-GW in WiMAX architecture). In such cases, it is the gateway
rather than the individual ANs that performs many mobility (Mobile IP
foreign agent), AAA (AAA client), and EAP (pass-through
authenticator) functions. This creates several problems
Nakhjiri Expires July 19, 2007 [Page 3]
Internet-Draft A Handover Keying Hierarchy Description January 2007
EAP signaling
The EAP model recognizes the pass-through authenticator as the
entity that terminates the link with the peer and starts the AAA
signaling with the backend server (to carry EAP over the backend).
In the wireless architectures, the AN is the entity that ends the
physical link with the peer, but it is not the AAA client and
therefore not responsible for encapsulation of EAP in AAA
protocol. This means there is an AN-Authenticator link that is
underspecified according to the EAP model. As we see later, this
link can cause problem when it comes to distribution of key
material for MN-AN TSK generation. To get around this problem, we
call a domain of ANs managed by a gateway, an Access Domain and
refer to the gateway as Access Domain controller. The access
domain controller (ADC) may or may not be on the path of every EAP
authentication, involving a peer, an AN, and an EAP server. This
means the ADC and pass-through authenticator may be logically and
physically separate and the pass-through authenticator could be
located in an AN.
key transport
The EAP model also specifies the transport of EAP MSK from the EAP
server to the pass-through authenticator. However, since the
pass-through authenticator and AAA function is typically deployed
in the gateway rather than in the AN, this means it is the gateway
and not the AN that receives keying material (MSK) from the AAA
server. The other reason for doing so is that only gateway to
gateway handovers would lead to a need for a new MSK and thereby a
new EAP authentication (if the current keying model to be
deployed).
key generation
The introduction of the gateway, that is separate from the ANs,
would potentially mean that two level of keys needs to be
introduced in the hierarchy, one key at gateway (ADC) level
(called ADMSK) and one key at AN level (called LSAP_MK).
Supplying the peer and the AN with fresh and unique LSAP_MK to
perform the exchange needed to secure their links is also a
challenge.
1.2. Choice of root keys
The decision on whether to use EAP MSK or EMSK as the root key for
the entire handover keying and re-authentication solution. While
cryptographically each might have similar characteristics, there will
be different impacts on the backward compatibility with the existing
Nakhjiri Expires July 19, 2007 [Page 4]
Internet-Draft A Handover Keying Hierarchy Description January 2007
deployments. Choice of MSK as root means that new specifications
define a new usage for MSK and transport behavior, while choice of
EMSK means new specification for EMSK usage (e.g.
[I-D.salowey-eap-emsk-deriv]) must be produced.
1.3. purpose of this document
This document intends to provide a solution for the problems of re-
authentication and handover keying described earlier. The main
portion of the solution revolves around creation of a new keying
architecture based on the master keys established as part of a
previously valid EAP, while staying independent of the EAP signaling
framework restrictions. A number of architectural choices are
presented to deal with EAP limitations. A new channel binding
problem is presented. Some problems remain partially or completely
unsolved. Example is the transport of generated keys from the ADC to
AN. Signaling required for exchange of parameters related to key
derivation is still work under progress and in some cases requires
extensions to non-IETF signaling mechanisms.
2. Terminology, Assumptions and new concepts
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 [RFC2119].
For a complete description of the terminology, the reader is referred
to [I-D.nakhjiri-aaa-hokey-ps].
Access Domain/ADC
As mentioned earlier, the existence of both an AN and a gateway on
the path of EAP signaling creates issues: the AN terminates the
peer link, while the gateway acts as a AAA client and receives the
master keys for MN-AN TSK generation. As mentioned this may lead
to the need for proprietary AN-gateway protocols to carry EAP.
Furthermore as mentioned before the pass-through authenticator is
the entity that receives the MSK from the EAP server. To get
around both these problem, we introduce a new logical entity
called Access Domain Controller (ADC) managing a so called domain
of ANs. The ADC would be the entity that receives any keying
materials directly coming from the EAP/ AAA server and thereby
managing the mobility and keying needs of the domain of ANs.
However, as far as the EAP signaling goes, since EAP signaling is
potentially only important during initial EAP authentication, it
is possible to simply allow the gateway (ADC) to be outside the
initial EAP signaling (between peer, AN and EAP server), since the
existence of both AN and the gateway (acting as the ADC) on the
Nakhjiri Expires July 19, 2007 [Page 5]
Internet-Draft A Handover Keying Hierarchy Description January 2007
path allows for either to act as the pass-through authenticator.
This means the ADC and pass-through authenticator may be logically
and physically separate and the pass-through authenticator could
be located in an AN. There is also a possibility where both AN,
ADC and pass-through authenticator can all be collocated. An
appendix for this document discusses the trade offs around
HRK:
Handover root key is a key that will be used as the root key to
solve the handover keying problem. The HRK can be the same as
MSK, a key generated from MSK, or can be a usage specific root key
(USRK) derived from EMSK specifically for support of re-
authentication and handover. HRK is generated using a so-called
HRK_PRF in a manner that preserves cryptographic separation
between EMSK, HRK and other USRKs and thus needs to comply with
the requirements in [I-D.salowey-eap-emsk-deriv]
HO_PRF:
The PRF that is used by the MN and the AAA server for generating
handover-related keys to be generated at the AAA server level.
The HO_PRF needs not to comply with the requirements specified for
USRK, and only needs to be supported by the crypto-engines at both
MN and the AAA server. The HO_PRF can be access technology
agnostic and can be pre-configured based on MN and AAA
capabilities to avoid cipher suite negotiations, if desired.
ADC_PRF:
The PRF that is used at the key holder (KH) of the ADC and the MN
for generating lower level keys at are to be generated at the KH
of ADC.
AAA_RK
AAA Re-authentication key. A key derived at the AAA server and at
the peer from the HRK and is used for fast re-authentication to
the AAA server and handover authorization between the peer and the
AAA server.
ADMSK
Access Domain Master Session Key: A key derived at he AAA server
and at the peer from the HRK for a specific ADC. AAA server
transports ADMSK to the ADC through secure AAA protocol transport.
ADC_RK
ADC Reauthentication key. A key generated at the peer and the ADC
from ADMSK for the purpose of local fast re-authentication to the
ADC and possibly handover authorization.
Link Secure Association Protocol (LSAP):
Nakhjiri Expires July 19, 2007 [Page 6]
Internet-Draft A Handover Keying Hierarchy Description January 2007
The term Link Secure Association Protocol refers to the process
used between the peer and the AN to generate and manage the
security associations used to protect the peer-AN link (layer 2 or
layer 3). EAP documentation [I-D.ietf-eap-keying] uses the term
SAP for the protocol between the peer and authenticator. We use
the term LSAP intentionally to refer to cases, where the AN may be
separate from the pass-through authenticator. The actual details
of the LSAP protocol exchanges may be the same as those for SAP,
but the LSAP protocol uses LSAP_MK (see below) rather than MSK or
the so called PMK as a root key and arrives at LSKs.
LSAP Master key (LSAP_MK):
The master key used by the peer and the AN during LSAP run to
arrive at LSKs between the peer and the AN. LSAP_MK is derived
from ADMSK through one or more steps in ways to be explored. This
proposal also assumes that LSAP_MK is securely delivered from ADC
to the AN, while the peer is able to generate the LSAP_MK.
Link Session Keys (LSK):
The keys derived upon completion of LSAP and used to secure the
access link between the peer and the AN. In a special case, where
the AN and the authenticator are co-located and use the same
identifiers. EAP documentation uses the term TSK to refer to MN-
authenticator temporary keys, we use LSK to distinguish a case
where the AN may not be the pass-through authenticator, otherwise
the LSK and TSK can be the same.
ADC Identifier (ADCID):
The identifier for the ADC serving the peer. This ID must
unequivocally and uniquely identify the ADC to both the peer, the
EAP server (and the ANs being served by the ADC, when applicable).
3. Proposed architecture
The picture below describes the assumed physical architecture for the
access network, including gateways performing ADC function for groups
of ANs and ANs providing link connectivity to the peers. It also
shows the keys that would be shared between various entities as the
MN would move from one AN to the next. There may or may not be
restrictions on the overlapping life times for the keys such as ADMSK
and LSKs depending on the network policy. This picture does not show
the placement of the pass-through authenticator. Our believe is that
positioning of pass-through authenticator is important for the
initial EAP authentication and not for the following keying process.
Our choice is to have AN and ADC as separate entities as shown in the
picture. Furthermore, we assume that the pass-through authenticator
function is located within the AN, and the ADC is off the EAP
Nakhjiri Expires July 19, 2007 [Page 7]
Internet-Draft A Handover Keying Hierarchy Description January 2007
signaling path. This along with the choice of EMSK for derivation of
HRK creates the least conflict with existing EAP specifications and
deployments. A discussion around placement of pass-through
authenticator, AN and ADC is provided in an appendix.
(HRK,AAA_RK)
<-------------------------------------------->
(ADMSK,KH_REAUTH_KEY)
<---------------------------->
LSK,LSAP_MK
<------------>
+-+-+-+-+-+LSK +-+-+-+ LSAP_MK11
| MN/ |-----| AN11|---+
|EAP Peer | +-+-+-+ | +-+-+-+
+-+-+-+-+-+ +-----|ADC1 |-+ADMSK1
+-+-+-+ | +-+-+-+ |
| AN12|---|LSAP_MK12 ^
+-+-+-+ | |
. | |
. | | +-+-+-+-+-+
+-+-+-+ | | | AAA/EAP|
| AN1n|---+LSAP_MK1n +-+-+| Server |
+-+-+-+ | +-+-+-+-+-+
| HRK
+-+-+-+ +-+-+-+ |
| AN21|---------|ADC2 |-+ADMSK2
+-+-+-+ +-+-+-+ |
. . |
. . |
+-+-+-+ +-----+ |
| ANm1|---------|ADCm |-+ ADMSKm
+-+-+-+ +-+-+-+
. |
. |
+-+-+-+ |
| ANmk|-------------+
+-+-+-+
Figure 1: A keying architecture deploying ADCs
Keying (LSAP_MK generation) and authentication for handover between
ANs within an access domain will be handled by the managing ADC,
without the need for referring to the AAA server for re-
authentication or key management. Only the handovers between access
domains can be handled through the AAA server, since as the picture
shows, per-ADC master keys (ADMSK) needs to be generated from the HRK
Nakhjiri Expires July 19, 2007 [Page 8]
Internet-Draft A Handover Keying Hierarchy Description January 2007
at the AAA server and forwarded to each ADC. Depending on the
network policy, a peer re-authentication may or may not be required
for a new ADMSK fetch as part of ADC handovers. This methodology
reduces or in many cases eliminates the need for AAA-server referrals
from the handover procedure. Still the key hierarchy presented here
provides a method for fast re-authentication that can be used for
session lifetime extension or re-authentication in conjunction with
ADC handovers (depending on network policy). This is done by
creating specific re-authentication keys (AAA_RK) from the HRK and
using these keys with minimal signaling with the AAA server. The
same method (using an ADC re-authentication key) can be used if re-
authentication with the ADCs are required for intra-ADC handovers.
4. Key Hierarchy and Generation
Upon successful completion of the EAP authentication method, the EAP
server generates the EAP MSK and EMSK as defined by the method that
was executed. As mentioned before, one can choose either MSK or EMSK
for the handover keying problem. Our choice here is to use the EMSK.
From this EMSK, an USRK designated for handover keying application
can be generated. We called this USRK, the HRK.
Based on the user profiles, the AAA server authorizes the user (peer)
for the handover keying and fast re-authentication service and
request generation of the HRK from the EAP layer key holder that
holds the EMSK. The HRK is then delivered to the AAA layer (seen as
AAA server in this document). The HRK is stored at the AAA server
database, where it is fetched for each ADMSK derivation. The ADMSK
for each ADC is kept hidden from other ADCs.
EMSK
|
HRK
_________________|___________________......______
| | | |
AAA-_RK ADMSK1 ADMSK2 ADMSKm
_____|__________________________
| | |
ADC_RK LSAP_MK1 LSAP_MK2
Figure 2: A keying hierarchy to support handover and re-
authentications
HRK=HRK-PRF (EMSK, "Handover Root key derivation" | EAP session ID |
Key_ID | AAA server ID)
Nakhjiri Expires July 19, 2007 [Page 9]
Internet-Draft A Handover Keying Hierarchy Description January 2007
Since HRK is generated as an USRK from the EMSK, the HRK-PRF may be
based on a network policy decision or decision specifically for the
handover process (see [I-D.salowey-eap-emsk-deriv] for details). EAP
session ID is supposed to be unique between peer and the server,
identified by the peer-ID and EAP server ID, respectively, but is an
optional field depending on whether it is produced by the executed
method.
Note that the HRK is only known to the peer and the AAA server, and
will be available until expiration, but is not transported to any of
the ADCs or ANs. The HRK is then used for generation of keys within
the next level of the handover key hierarchy, namely the AAA_RK and
ADMSK_I as described below. Note that these keys are generated using
HO_PRF that is supported by the crypto-engines at MN and AAA server.
The HO_PRF does not have to be the same as HRK_PRF as explained
earlier.
1. AAA_RK=HO-PRF (HRK, "Key for re-authentication to AAA server" |
EAP session ID | Key_ID )
2. ADMSK_i= HO-PRF (HRK, "ADMSK generation" | EAP session ID | Key
ID | ADCID)
AAA_RK: AAA Re-authentication key is a key that does not leave the
AAA server and is not exposed to any other entity in the network.
AAA_RK can be used by the peer, to sign a ADC handover request
(HRQ) for handover to an area served by a new ADC or possibly to
perform a new fast authentication (FRQ) when the initial EAP
session is expired. Proof of possession of this key allows for a
quick re-authorization of the peer without requiring a new EAP.
Aside from the re-authorization, the HRQ can serve as a trigger
for the AAA server to create an ADMSK for the new ADC. Depending
on the timing of this message (if done pro actively) the delay
related to handover keying can be significantly reduced. Note
that the peer may not necessarily need to know that it has moved
to a new ADC; the AAA server can (through the new AN or new ADC)
request proof of possession of this key through a request. The
peer is able to generate this key through knowledge of HRK.
ADMSK_i ADMSK_i is the key that is used as a root key for branch of
key hierarchy within each access domain and only known to MN and
ADC_i. Once the AAA server knows which ADC (ADC number i: ADC_i)
is going to serve the MN, it creates a ADC master session key for
that specific key holder (ADMSK_i) using the HRK. Note that the
peer may not have knowledge of the ADC identifier (ADCID). To
allow to peer to be able to calculate the ADMSK_i, the ADC
identifier should be provided to the peer through some means. We
are suggesting that the ADCID be provided through broadcast
advertisements provided by the ANs serving the area.
Nakhjiri Expires July 19, 2007 [Page 10]
Internet-Draft A Handover Keying Hierarchy Description January 2007
The AAA server now can send the ADMSK_i to the ith ADC through a
secure transport (possibly through securing the AAA message with a
permanent security association between the AAA server and the ADC).
The AAA server can delete the ADMSK_i cache after the transport to
the ADC, if required for compliance with principle of least
privilege.
The ith ADC (ADCi) receives the ADMSKi. ADMSKi (called ADMSK from
this point on) and caches it in its key holder for all the key
generation activities within its domain (i.e. For all the ANs it
serves). Particularly, the KH of the ADC generates two types of
keys:
1. ADC_RK= ADC-PRF (ADMSK_i, "Key for re-authentication to ADC" |
EAP session ID | Key_ID| ADCID )
2. LSAP_MKn = ADC-PRF (ADMSK_i, "LSAP master key generation" | EAP
Session ID | Key-ID | ANn-Device-Id)
LSAP_MKs: LSAP_MKs, as explained earlier and in
[I-D.nakhjiri-aaa-hokey-ps] serve as master keys for performing
Link Security Association Protocol (LSAP) exchanges between the
peer and the AN to establish Link Session Keys (LSKs). LSAP_MKn
for AN number n is generated at the KH of the serving ADC using
ADMSK and is sent to and only to the ANn. Transport of LSAP_MK
from the ADC to the ANs may be done through a non-AAA protocol to
be designed or determined later on. The peer is able to calculate
the LSAP_MKn as long as AN identifier is available.
ADC_RK: This will be the shared secret that is used for
authenticating the signaling between the peer and ADC. The
authentication may be needed if fast re-authentication as part of
intra-ADC handovers are required, or to trigger proactive inter-
ADC handovers, or for channel binding purposes as follows:
1. A request signed using ADC_RK can trigger generation of
LSAP_MKs for intra-ADC handovers without the need for
interaction to AAA server.
2. A proactive request signed using ADC_RK to a new ADC can
trigger LSAP_MK generation for inter-ADC handovers (as long as
ADMSK is available at the new ADC) and thereby improving
handover latency.
3. Channel Binding: ADC_RK and the authorization signaling can
help channel binding purposes (confirming AN_link_ID at both
peer and ADC).
Once the LSAP_MKn is obtained by the ANn, the peer and ANn can engage
in an LSAP exchange to arrive at the LSKs. The exact process of LSAP
is dictated by the SDO governing the specification of the
Nakhjiri Expires July 19, 2007 [Page 11]
Internet-Draft A Handover Keying Hierarchy Description January 2007
communications link between the peer and ANs. So the following is
simply an example for creation of link session keys for encryption
and message authentication:
LSKE=LSK-PRF (LSAP_MKn, "Link data encryption key", EAP session ID
| Key ID | peer-link-ID | ANn-link-ID | peer-nonce | ANn-nonce),
LSKA=LSK-PRF (LSAP_MKn, "Link data authentication key", EAP
session ID | Key ID | peer-link-ID | ANn-link-ID | peer-nonce |
ANn-nonce),
Where the nonces are exchanged as part of an LSAP exchange between
the peer and AN1. The link IDs are the identifiers through which the
peer and the AN recognize each other over the wireless link.
5. Architecture and messaging
In this section we attempt to describe how the earlier proposed key
hierarchy can be used for improving the latency involved in handover
and re-authentication.
As mentioned earlier, the preferred architecture model is the model
that is most widely deployed today in wireless networks, i.e. a
network, where physically disjoint ADCs are managing groups of ANs
within an access domain. and ADCs.
Placement of ADC versus the authenticator for the initial EAP is also
rather important. However, once the initial authentication is
complete, as long as both the peer and the backend server generating
the HRK have the ADC identifier to create the ADCID, the positioning
of ADC with respect to EAP pass-through authenticator is immaterial.
In the following we will discuss more details on the signaling
required for handover keying and re-authentication. As the timing of
handover triggers and the path the signaling can take depends on the
physical conditions of the physical links between peer and previous
versus new ANs (peer-AN1, peer-AN2 and AN1-AN2 links), various
combination of the proactive/ reactive requests versus pull/ push key
transports can be envisioned.
5.1. Inter-ADC AN-handover and fast AAA re-authentication
Figure below shows a scenario where the peer changes its point of
attachment from AN1 (under control of ADC1) to AN3 (under control of
ADC2). Since this involves a change of ADCs, an ADMSK2 needs to be
generated. As described earlier, the knowledge of both HRK and
ADCID_2 is required for generation of ADMSKs. First, this means the
ADMSK2 for ADC2 must be generated at the AAA server. Although a re-
Nakhjiri Expires July 19, 2007 [Page 12]
Internet-Draft A Handover Keying Hierarchy Description January 2007
authentication of the peer in conjunction to ADC handover is a matter
of network policy and not necessarily required, we show how AAA_RK
can be used during handover messaging to achieve a fast re-
authentication with the AAA server. Second, the ADCID_2 needs to be
communicated to both the peer and the AAA server:
The peer can receive the ADCID_2 through beacon advertisements
broadcast by the AN3 or possibly neighbor advertisements by the
AN1.
The AAA server can receive the ADCID_2, when it receives a
handover and key request (HKRQ). Note, HKRQ is a new AAA command
. This request can either be made reactively (after peer's
handover into AN3 area) from ADC2 or pro actively (while the peer
is still in AN1 area) from ADC1.
5.1.1. Proactive signaling
Here, we consider a case where the peer tries to perform a proactive
handover request, while still being attached to AN1. This can be
considered to provide more optimized performance than a reactive
request. It is however important to note that for the proactive
keying to be optimized, the AAA server must receive the ADCID2 either
from the peer or ADC1 at the time of key request. In the following
we can assume that the ADC2 has:
The peer starts by sending a handover request (HRQ) to the AN1,
while including the AN3_ID as a request to attach to AN3. The
peer does not know whether this is an intra- or inter-ADC
handover, therefore the peer signs the HRQ with both ADC_RK and
AAA_RK. The former is included inside an ADC_REAUTH_Extension,
while the latter is included inside a AAA_REAUTH_Extension. If
the peer has received the ADC2_ID for the ADC2 (managing the AN3)
somehow (e.g. Through beacon advertisement by AN3), the MN
includes the ADC2_ID inside an NEW_ADC_Extension.
If the ADC recognizes AN3_ID as one of its own (intra-ADC
handover), the ADC1 verifies the signature in
ADC_REAUTH_Extension, using ADC_RK, and ignoring the
AAA_REAUTH_Extension, the ADC1 would create an LSAP_MK3 for AN3.
However, in this scenario AN3 is not served by the ADC1. Not
finding AN3 in its AN_list, or finding a NEW_ADC_Extension, means
the ADC needs to forward the request from the peer as an HKRQ to
the AAA server and includes the AAA_REAUTH_Extension inside a
HKRQ_Authorization_AVP. ADC1 extracts ADCID_2 either from its own
database, or from the peer's HRQ message NEW_ADC_Extension and
includes it inside an ADC_ID_AVP to the AAA server. The ADC1
protects the HKRQ with whatever security mechanism available
within the AAA infrastructure between AAA server and its clients.
Nakhjiri Expires July 19, 2007 [Page 13]
Internet-Draft A Handover Keying Hierarchy Description January 2007
The AAA server, upon receiving the HKRQ from the ADC1, verifies
the signature within HKRQ_Authorization_AVP (using AAA_RK). Using
the included ADCID_2 included in ADC_ID_AVP of the HKRQ, the AAA
server calculates an ADMSK2 for the ADC2. The AAA server encrypts
the ADMSK2 for the ADC2 with a AAA_ADC2_key and includes the
wrapped key inside an ADC_KEY_AVP and sends it along an HKRP
command to the ADC1. The AAA server needs to include other
information regarding the MN session (as required by ADC2 for
LSAP_MK and ADC_RK derivations) inside this AVP. The ADC_KEY_AVP,
may set an "ADMSK flag" to indicate that this indeed is an ADMSK
and not an MSK to show that the server is using a handover key
hierarchy rather than a legacy MSK.
The ADC1 extracts the ADC_KEY_AVP from the HKRP, initiates a
context transfer process (CTXP, see RFC 4067) )with the ADC2,
delivering the wrapped key to the ADC2.
The ADC2 receiving the information from the AAA server, calculates
the LSAP_MK3 for AN3 and initiates a transfer of this key to AN3
(AN_KEY message)..
Once the completion of CTXP is confirmed at the ADC1, ADC1 sends
an handover request reply (HRP) to the peer. If the ADC1 had not
received a NEW_ADC_Extension from the peer (peer did not know
ADCID_2), the ADC1 includes ADCID_2 inside this extension and send
it along HRP to the peer.
The peer calculates LSAP_MK3 an starts an LSAP exchange with AN3
to establish link security.
The proactive keying process is shown in the figure below. It should
be noted that the reactive keying, i.e. When the peer requests the
key directly from AN3 and ADC2 is much simpler and no context
transfer process or interaction with ADC1 is required and ADCID_2 is
readily available.
Nakhjiri Expires July 19, 2007 [Page 14]
Internet-Draft A Handover Keying Hierarchy Description January 2007
peer AN1 ADC1 AN3 ADC2 AAA
----- ----- ----- ---- ----- -------
| HRQ | | | | |
| ----------->| HRQ | | | |
| | ---------->| | | |
| | | HKRQ | |
| | |--------------------> |
| | | | HKRP |
| | |<-------------------- |
| | | CTP | |
| | HRP |<--------> | |
| HRP |<-----------| | | |
| <-----------| | | | |
| LSAP | | | |
| <---------------------------- > | | |
Figure 3: Proactive Inter- ADC handover, peer-AN1 link up
5.1.2. Reactive signaling
It should be noted that the reactive keying, i.e. When the peer
requests the key directly from AN3 and ADC2 is much simpler and no
context transfer process or interaction with ADC1 is required and
ADCID_2 is readily available.
peer AN1 AN3 ADC1 ADC2 AAA
----- --- ----- --- ----- -------
| HRQ | | |
| ----------->| HRQ | |
| | ---------->| |
| | | HKRQ |
| | |--------------------> |
| | | HKRP |
| | |<-------------------- |
| | | |
| | HRP | |
| HRP |<-----------| |
| <-----------| | |
| LSAP | | |
| <--------- >| | |
Figure 4: Reactive Inter- ADC handover, peer-AN3 link up
5.2. Intra-ADC AN-handover
Intra-ADC handovers are simply handled by the ADC without referral to
AAA server and this is the benefit of the assumed architecture
including ADCs and ANs.
Nakhjiri Expires July 19, 2007 [Page 15]
Internet-Draft A Handover Keying Hierarchy Description January 2007
As the peer moves from AN1 area to AN2, it sends an HRQ to AN2
(reactive handover) including the ADC_REAUTH_Extension.
AN2 forwards HRQ to ADC2.
ADC2 after verifying the signature (using ADC_RK) within the
ADC_REAUTH_Extension and if successful, ADC2 creates an LSAP_MK2 for
AN2 and sends it to AN2.
AN2 starts LSAP process with the peer.
Above, we described a reactive handover procedure this time. As
mentioned before, proactive handover keying through AN1 is possible
in cases where peer-AN1 is still available. The LSAP_MK2 for AN2 can
be delivered from ADC2 either directly or through a secure AN1-AN2
context transfer.
Alternatively, the AN1 can send a list of neighbor ANs to the ADC and
request for an LSAP_MK push from ADC to those ANs. The LSAP_MK can
be delivered as signed triplets of (peer ID,AN-ID,
encrypted(LSAP_MK)) for each of the ANs.
5.3. channel binding
This section proposes a new method independent channel binding
procedure that does not add any roundtrips to the handover keying
signaling.
Channel binding can be defined as a procedure through which the keys
generated for the between party 1 and party 2 are bound to the
parameters governing that channel between party 1 and party 2. This
is important both for limiting the scope of the key. The channel can
defined by a set of parameters, that we notify as channel binding
Tuple (CBT). CBT can simply be represented as follows:
CBT=(party 1 ID, party 2 ID, other channel data)
The field "Other channel data" can for instance include type of
access technology.
In cases where party 1 and party 2 use a trust third party to
establish a shared key, without having had a prior trust
relationship, it is important that the CBT is also checked by the
third party, so neither party lies about its identity to the other
peer.
In the wireless handover and re-authentication key hierarchy
presented in this document, party 1 is always the peer, while party 2
Nakhjiri Expires July 19, 2007 [Page 16]
Internet-Draft A Handover Keying Hierarchy Description January 2007
is either the AN (for LSAP_MK and LSK) or ADC (for ADMSK and ADC_RK).
When generating the ADMSK to shared between peer and ADC it is
important to make sure that the ADC reports the same identity to the
peer and to the AAA server. When generating LSAP_MK to be shared
between peer and AN, it is important to make sure that the AN reports
the same identity to both peer and ADC.
5.3.1. channel binding between peer and ADC
The idea presented here for channel binding is simple:
Lets assume the ADC were to lie about its identity to the peer and
present itself as ADC_DID (down link ID), while presenting itself as
ADC_UID (up link ID) to the AAA server. If the AAA server could
receive two copies of the ADC_ID, one through the peer and one
through the ADC itself, then the AAA server could uncover this lie.
To realize this, we suggest the following procedure
DCBT: The peer forms a DCBT (down link CBT) based on the ADC_DID
received from the beacon advertisement
DCBT=(peer_ID, ADC_DID, other data).
Note that this precludes the proactive handover requests, where
the peer does not know ADC_ID. In such cases the channel binding
might have to happen following the HKRQ and HKRP exchange.
The peer builds a Peer_CBT_Extension and adds this extension to
the HRQ sent towards ADC. Note that the this extension either
needs to include its own MIC or needs to be included the
calculation of the MIC for the HRQ and thus the peer uses AAA_RK
for the calculation of this signature.
DCBT_Authenticator= HMAC_SHAX (AAA_RK, DCBT)
UCBT After receiving the peer HRQ, when the ADC is ready to send an
HKRQ to the AAA server, the ADC creates its own version of the
CBT, that we call up link CBT (UCBT) based on ADC_UID
UCBT=(peer_ID, ADC_UID, other data)
The UCBT can be protected separately by the ADC-AAA trust
relationship, or undergo the security provided to the HKRP (AAA
messaging).However, separate protection of UCBT is preferred as it is
carried as a AAA AVP.
The ADC includes DCBT and UCBT inside separate AAA AVPs within HKRQ,
as Peer_CBT_AVP and ADC_CBT_AVP.
The AAA server can simply verify that the DCBT and UCBT in fact
include the same ADC_ID (ADC_DID and ADC_UID are the same). The AAA
Nakhjiri Expires July 19, 2007 [Page 17]
Internet-Draft A Handover Keying Hierarchy Description January 2007
server can create a notification of the successful channel binding
procedure for the peer by adding an additional AVP to the HKRP back
to the ADC. The AVP can be called CBT_Confirm_AVP and include a MIC
using AAA_RK again. The HKRP also includes the ADMSK for the ADC.
The ADC must extract the information from CBT_Confirm_AVP inside a
CBT_Confirm_extension inside the HRP message to the peer.
If the peer receives the CBT_Confirm_AVP from the ADC and can verify
the AAA server signature, the peer can calculate the ADMSK using the
ADC_DID and install the ADMSK. Otherwise the peer considers the
handover request as denied.
As we can see the channel binding procedure for ADMSK does not add
any additional round trip to the messaging.
5.3.2. channel binding between peer and AN
The same methodology can be applied for binding the LSAP_MK to the
peer and AN.
D_AN_CBT: The peer forms a D_AN_CBT (down link CBT) based on the
AN_DID received from the beacon advertisement
D_AN_CBT=(peer_ID, AN_DID, other data).
The peer builds a Peer_AN_CBT_Extension and adds this extension to
the HRQ sent towards AN. Note that the this extension either
needs to include its own MIC or needs to be included the
calculation of the MIC for the HRQ and thus the peer uses ADC_RK
for the calculation of this signature.
D_AN_CBT_Authenticator= HMAC_SHAX (ADC_RK, D_AN_CBT)
U_AN_CBT In this case the U_AN_CBT may not be needed, since the ADC
typically has a list of the ANs that is serving and knows the
AN_ID. Thus upon receiving the HRQ, the ADC verifies the MIC in
the Peer_AN_CBT_Extension and then verifies that AN_DID indeed
matches ADC copy of AN_ID. If there is a match, the ADC creates
an AN_CBT_Confirm_extension (signed with ADC_RK) inside the HRP
message to the peer.
If the peer receives the AN_CBT_Confirm_AVP from the AN and can
verify the ADC signature, the peer can calculate the LSAP_MK using
the AN_DID and install the LSAP_MK. Otherwise the peer considers
the handover request as denied.
As we can see the channel binding procedure for LSAP_MK does not
add any additional round trip to the messaging either.
5.4. New AVPs
Nakhjiri Expires July 19, 2007 [Page 18]
Internet-Draft A Handover Keying Hierarchy Description January 2007
ADC_ID_AVP: details TBD
HKRQ Authorization_AVP: details TBD
ADC_KEY_AVP: details TBD
This AVP SHOULD include an indication that the server is
requesting the peer to use the handover keying hierarchy ADMSK
rather than the EAP keying MSK for keying. This indication can be
done by setting an "ADMSK flag".
Peer_CBT_AVP: details TBD
ADC_CBT_AVP: details TBD
5.5. New Extensions
New_ADC_Extension: format TBD
This extension SHOULD include indications that the peer supports a
handover keying hierarchy rather than a legacy EAP keying hierarchy.
AAA_REAUTH_Extension: format TBD
ADC_REAUTH_Extension: format TBD
Peer_CBT_Extension
Peer_AN_CBT_Extension
6. backward compatibility with EAP
For simplicity we call a peer or server that supports handover keying
"hokey-compliant". The same entity is "hokey incompliant" even if it
supports EAP keying. Hokey-compliant" peere and servere can use
handover root key (HRK) to generate per-ADC keys (ADMSK). A "hokey
compliant" server transports the ADMSK to the ADC (potentially an
authenticator). On the other hand, hokey-incompliant (legacy) peers
and servers use MSK instead of both HRK and ADMSK. Authenticators
may not require much change to comply with the new key hierarchy,
unless they act as an ADC and are responsible for a domain of ANs,
unless a "hokey compliant" ADC and AAA server need to deal with a
"hokey non-compliant" peer. While running the EAP method, the
authenticator does not (and does not need to) have a knowledge of
whether the server and the peer are hokey-compliant. However, the
peer and the server Should be able to indication their compliances to
each other and possibly negotiate their preference. In other words,
a "hokey compliant peer needs to identify the AAA server that it is
Nakhjiri Expires July 19, 2007 [Page 19]
Internet-Draft A Handover Keying Hierarchy Description January 2007
requesting a hokey key hierarchy and not a legacy key hierarchy and
vice versa. We consider two major cases:
1. During the initial EAP authentication: During the initial EAP
authentication, an indication for handover keying hierarchy is
more difficult to achieve in a EAP method independent fashion.
Using a new EAP method type just for indicating key variant may
be excessive, especially since sequencing EAP methods cannot be
achieved unless after a method is completed. For those reasons,
it may be more practical, to simply negotiate "hokey compliance"
(i.e. Use of handover keying hierarchy) after EAP Success
indication. Once the peer receives an EAP Success, it can send a
"Key Request" message (indicating her "hokey compliance" to the
server, if the peer knows the ADC, the ADC_ID can also be
included as mentioned before (this also implies ADC "hokey
compliance"). The server replies with "Key Response" along with
ADMSK wrapped in ADC_KEY_AVP and an "ADMSK-flag" set or with MSK,
depending on its "hokey compliance". Alternatively the same can
be achieved by EAP signaling and possibly a new EAP method type.
However, the signaling needs to be initiated by the AAA server,
possibly piggybacking on the EAP Success, the EAP Request/Hokey
(the new EAP method type), to which the peer responds with EAP
Response/Hokey. Regardless, of whether Hokey or EAP signaling is
used, the PRF for HRK and ADMSK can be negotiated if needed.
2. During a handover: The process during a handover can be much more
straightforward by using hokey signaling (HRQ and HRP), without
involving EAP signaling, especially in cases where the
authenticator and ADC are not collocated. This is explained in
the previous sections of this document. The peer and the server
can perform a fast re-authentication using the keys derived from
HRK, instead of performing a full EAP authentication.
There is however an issue with not using EAP and that is the lower
layers, especially on the peer side needs to define encapsulation
mechanisms for carrying hokey signaling. This is however minimal
work, especially in cases, where the lower layer is already capable
of carrying EAP.
7. Security report Card
This section of the document provides a test of the provided key
hierarchy against the security goals stated in the handover keying
problem statement draft [I-D.nakhjiri-aaa-hokey-ps]
Key Context and scope, prevention of domino effect: The context
and scope for each key is defined. The entire purpose of the
hierarchy is to abide by the principle of least privilege to
prevent the domino effect. Master keys are deleted after
transport. Keys generated at each level of the hierarchy are
Nakhjiri Expires July 19, 2007 [Page 20]
Internet-Draft A Handover Keying Hierarchy Description January 2007
unique to entities. For instance, ADMSK for each ADC is only
specific to that ADC, the same as LSAP_MK for each AN.
Key Naming: All keying material starting from ADMSK and the
derivatives are uniquely named, using the identity of the parties
sharing the key.
Key Freshness: Use of EAP session ID should provide adequate level
of freshness, in cases where the identity of an entity within the
architecture is not known to the peer and in case of LSAP_MK
generation. Generation of link level keys (LSKs) is outside
control of IETF. Still, the examples provided in this document,
use peer and AN nonces for that purpose.
Handover Vulnerabilities: The key hierarchy introduced here,
provides a hierarchy in authorization as well, e.g. AAA_RK versus
ADC_RK. This way, the entity that generates the keys is making
the authorization decisions.
Authentication of all the parties: The hierarchy allows for peer-
AAA server, peer-ADC and peer-AN authentication through
introduction of specific keys. AAA server-ADC, ADC-AN
authentication mechanisms are outside control of this document.
Channel binding: The keys introduced in this document are named in
a way that allows for proper binding. Exact signaling procedures
for channel binding are to be investigated.
EAP method independence: The key hierarchy in this document stems
from the EAP method generated keys (MSK and EMSK). As long as the
method is capable of creating EMSKs, this hierarchy is method
independent.
8. Security Considerations
This document discusses branching a key hierarchy from root keys
provided by the EAP key management in order for providing keying
solutions for wireless mobile networks. Key caching and non-
transport requirements (i.e. Storing a key at the origin without
transporting it) are discussed throughout the document. However, the
solution relies on the secure (encrypted and authenticated) transport
of keys. Such secure transport of keying material between pairs such
as (AAA server, ADC) and (ADC, AN) may be subject to security issues
that are outside control of this document. Future revisions of this
document is to provide recommendations for the transport mechanisms.
9. IANA consideration
This document defines a number of new AAA AVPs that need to be
standardized by IANA. It may also require a number of new Diameter
command codes, if Diameter is used. In that case, allocation of new
command codes needs to be done through IANA as well.
Nakhjiri Expires July 19, 2007 [Page 21]
Internet-Draft A Handover Keying Hierarchy Description January 2007
10. Acknowledgements
The author would like to thank Jari Arkko for useful suggestions on
generation of USRK for handover key hierarchy and Mohan Parthasarathy
for providing feedback.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-16 (work in
progress), January 2007.
[I-D.nakhjiri-aaa-hokey-ps]
Nakhjiri, M., "AAA based Keying for Wireless Handovers:
Problem Statement", draft-nakhjiri-aaa-hokey-ps-03 (work
in progress), June 2006.
[I-D.clancy-hokey-reauth-ps]
Clancy, C., "Handover Key Management and Re-authentication
Problem Statement", draft-clancy-hokey-reauth-ps-01 (work
in progress), January 2007.
[I-D.salowey-eap-emsk-deriv]
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.
11.2. Informative references
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
Nakhjiri Expires July 19, 2007 [Page 22]
Internet-Draft A Handover Keying Hierarchy Description January 2007
[I-D.housley-aaa-key-mgmt]
Housley, R. and B. Aboba, "Guidance for AAA Key
Management", draft-housley-aaa-key-mgmt-06 (work in
progress), November 2006.
Appendix A. Appendix A: Architectural choices
We now come to the point where we need to make decisions on physical
placements of various functional elements of EAP and handover keying
with respect to the physical entities in a typical wireless network.
AN versus ADC: The first choice to make is whether AN and ADC can be
physically collocated or should they be in separate entities. One
important security goal is prevention of domino effect, which
requires that LSAP_MK and ADMSK are cryptographically separate
(compromise of LSAP_MK at one AN does not lead to compromise of
the LSAP_MK at other ANs or the compromise of ADMSK at the ADC
managing those ANs), but also must not be compromised as a result.
The other security goal is the principal of least privilege, which
means an AN function should only have access to LSAP_MK not to
ADMSK. The other goal is simply related to mobility performance,
i.e. Whether it is advantage to have an AN with ADC function to
act as an anchor for future mobility of the peer within the
session or have a centralized ADC. When AN and ADC (especially
key holder function) functions reside inside the same physical
location, care must be taken that
1. Standalone ADC: ADC located within an entity that physically
disjunct from the AN. This way, one ADC can sit on a more
central (hopefully physically safer location within the
network) and through back-haul links serve multiple ANs.
Having the same designated ADC within the domain will make the
system design more robust. For instance when IPsec tunnels
are needed to protect AAA or other signaling, such tunnels can
be set up with the same ADC off the handover timing critical
path. The handover design may be more efficient this way as
well. For instance by knowing the identity of the ADC, the AN
and the peer will be able to perform fast handover procedures
easier (e.g. ADCID can be broadcast to peers for the purpose
of key generation, or the key requests can always be sent to
the same entity). Furthermore, this does not require
anchoring the ADC function from the initial AN through which
the peer authenticated to the EAP server.
2. Integrated AN-ADC: According to this alternative the ADC is
located within the AN. This would require that the ADMSK and
ADC may possibly have to be located inside a trusted platform
in the memory location that is not accessible to processing
entity handling LSAP and over the air encryption/ decryption.
The downside of this alternative are three: First: The initial
Nakhjiri Expires July 19, 2007 [Page 23]
Internet-Draft A Handover Keying Hierarchy Description January 2007
AN that also acts as a pass-through authenticator and receives
ADMSK needs to act as the ADC for the domain. This will make
the design of the topology of the wireless network rather
dynamic and the optimizations described for a static ADC
cannot be achieved as easily, since any AN can at any time act
as ADC for the domain. Second: Depending on the topology and
arrangement of the ANs having to go back to an anchor AN for
retrieving LSAP_MK can be detrimental to handover and back
haul performance for wide area wireless network. Third: A
compromise of the initial AN and thereby compromise of the
ADMSK will put the rest of the ANs within that domain at
potential risk until the peer session expires.
ADC versus Pass-through Authenticator The other choice to be made is
the positioning of the ADC with respect to EAP signaling and AN.
The EAP signaling will have to physically go through AN. It does
however not have to go through the ADC, depending on whether the
ADC is part of the pass-through authenticator function or not.
Furthermore, according to the handover keying solution, the ADMSK
is sent to the ADC. However EAP Keying only defines the transport
of MSK to the pass-through authenticator. From the keying
standpoint, this makes the ADC and pass-through authenticator
separate logical entities and creates a choice.
1. Off-path ADC: In the off-path ADC arrangement, the ADC is off
the EAP signaling path. The pass-through authenticator can
simply be located at the serving AN, also acting as a AAA
client when encapsulating EAP packets into AAA messages. The
transport of ADMSK to ADC from the AAA server is done through
a AAA server-ADC AAA channel and this means the initial AN
does not have an anchoring responsibilities. This is the most
generic arrangement. This arrangement in case EMSK is chosen
for HRK derivation creates a least conflict with the design of
legacy EAP pass-through authenticators. But the downside of
this arrangement is that ADC identifier (ADCID) must be
provided and proven to both peer, AN and AAA server (the one
creating ADMSK for the ADC). As mentioned earlier, the ADCID
can be provided to the peer to advertisements by the AN (such
as beacons), while the ADCID can be provided to the AAA server
through AAA signaling (AAA attribute). The other downside is
it requires AAA functionality within the AN and it requires
the AAA server to deal with two different AAA clients as part
of security provisioning and authentication. Specific channel
binding issues might arise in this case.
Nakhjiri Expires July 19, 2007 [Page 24]
Internet-Draft A Handover Keying Hierarchy Description January 2007
+-+-+-+-+-+
| ADC |
| AAAC |-----+
+-+-+-+-+-+ \
| \
| \
V \
+-+-+-+-+ +-+-+-+-+-+ \ +-+-+-+-+-+
| | | Athr | +-| |
| EAP |--------| AAAC |------------| EAP/AAA |
| Peer | | AN | | Server |
+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 5: off-EAP-path ADC function
2. On-path ADC: In this case the ADC is located on the EAP
signaling path, i.e. Either integrated with an AN or as an
standalone ADC entity as described previously. In this case,
one needs to decide on whether the pass-through authenticator
function needs to be placed inside the AN or inside the ADC.
Placing the pass-through authenticator in the AN is
acceptable, as long as the AN is able to encapsulate the EAP
signaling into AAA signaling and the ADC is able to act as a
AAA proxy for AAA signaling. Note that this alternative will
imply that the master keys from the AAA server are not sent to
the authenticator as it is common in IEEE 802.1x style
implementations. Placing the pass-through authenticator in
the ADC will possibly require specific considerations in the
transfer of EAP signaling from the peer over the AN and the
ADC to the EAP server. In the integrated AN-ADC scenario, the
pass-through authenticator, AN and ADC will all be located in
one physical entity.
Author's Address
Madjid Nakhjiri
Huawei USA
Email: mnakhjiri@huawei.com
Nakhjiri Expires July 19, 2007 [Page 25]
Internet-Draft A Handover Keying Hierarchy Description 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).
Nakhjiri Expires July 19, 2007 [Page 26]