Network Working Group M. Nakhjiri
Internet-Draft Motorola Labs
Expires: December 23, 2006 June 21, 2006
A Keying hierarchy for managing Wireless Handover security
draft-nakhjiri-hokey-hierarchy-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 23, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Problem of AAA-based key management for facilitating secure
handovers in a wireless mobile environment has been described in
[I-D.nakhjiri-aaa-hokey-ps]. The intention with this document is to
provide a starting point for developing a solution for that problem
by introducing a key hierarchy using EAP generated keys. An example
of how the channel binding problem can be solved is also added in an
appendix
Nakhjiri Expires December 23, 2006 [Page 1]
Internet-Draft Handover Keying Hierarchy Description June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Assumptions . . . . . . . . . . . . . . . . . 6
3. Key Hierarchy and Generation . . . . . . . . . . . . . . . . . 7
4. Architectural choices . . . . . . . . . . . . . . . . . . . . 11
5. messaging and AAA attributes . . . . . . . . . . . . . . . . . 13
5.1. Intra-ADC AN-handover . . . . . . . . . . . . . . . . . . 14
5.2. Inter-ADC AN-handover . . . . . . . . . . . . . . . . . . 14
6. Security report Card . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative references . . . . . . . . . . . . . . . . . . 17
Appendix A. Appendix A: channel binding . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Nakhjiri Expires December 23, 2006 [Page 2]
Internet-Draft Handover Keying Hierarchy Description June 2006
1. Introduction
Wireless networks deploy specific access nodes (AN) providing link
layer service to the peers. While the primary function of the AN is
provide network connectivity and operator policy enforcement on the
services rendered, it can do so only after the required
authentication and security procedures are successfully performed
(link security keys, LSKs are established between the peer and the
AN). This typically involves exchange of authentication signaling
between the peer and a backend AAA server through the AN, followed by
execution of a security association protocol (we call this link
security association protocol, LSAP). The LSAP can derive the LSKs
between the peer and the AN, but relies on a pre-existing trust,
defined in large part by a so called LSAP master key (LSAP_MK) (
[I-D.nakhjiri-aaa-hokey-ps]).
Provisioning of the peer and the AN with LSAP_MK is a challenge that
affects the design and scalability of the wireless network. It is
desired that LSAP_MK is unique for a peer-AN pair and is fresh for
each communication session. The Extensible Authentication Protocol
(EAP) framework, including [RFC3748] and the keying framework
[I-D.ietf-eap-keying] have been used to perform authentication and to
generate the EAP master keys (MSK and EMSK) at both backend server
and the peer. The EAP framework also allows transport of MSK to a
single intermediary called pass-through authenticator. The idea here
is to use the initial EAP authentication for generation of MSK and
EMSK and then build a key hierarchy to arrive at fresh LSAP_MKs that
are unique for the peer-AN pair and for the specific authenticated
session. The LSAP_MK would be delivered to the AN, while the peer
would be able to derive the LSAP_MK based on previously derived key
material. The peer and AN could then engage in a key management
schema (LSAP) to establish a secure link with the peer (sharing
LSKs).
The challenge with using the current EAP keying specification is
several fold: First the AN, through which the peer performs an EAP
authentication, needs to have a role in the EAP pass-through
authenticator architecture (as a authenticator port). From keying
perspective (the fact that the AN needs an LSAP_MK to run LSAP with
the peer) these two functions are almost orthogonal. Second EAP
keying recommends transport of MSK to the pass-through authenticator.
The role of an authenticator port in the key transport and keying is
not quite clear. The common wisdom from the SDOs that are further
along with implementation of EAP keying is that the AN would act as
an authenticator port. This would mean the current AN (authenticator
port) would be the entity receiving the MSK. This would mean the
current AN will need to act as a key holder for MSK and create an
LSAP_MK for use with the peer. As other ANs would require different
Nakhjiri Expires December 23, 2006 [Page 3]
Internet-Draft Handover Keying Hierarchy Description June 2006
LSAP-MKs with the same peer, this would require a cryptographic
separation between the LSAP_MKs and therefore the separation between
the storage of MSK and the LSAP_MK for each AN. However, the current
AN, since it is acting as an MSK holder still has visibility to the
LSAP-MK for all ANs for which it acts as an MSK holder. This is not
desirable in case the AN is under a threat of physically or logically
being hijacked. This would lead to a design where the MSK should
possibly be held by a key holder (or as called in PS draft an access
domain controller, ADC). The ADC would then create LSAP_MK for all
of the ANs in an access domain. The third problem with using EAP
keying is that a handover to an new ADC will require creation of a
new MSK at the new ADC, as using the same MSK at the new AN will
violate the principle of least privilege [I-D.housley-aaa-key-mgmt]
and can result in a so-called domino effect. Creating a new MSK at
the new ADC, on the other hand could require execution of another
round of lengthy EAP method authentication exchange, which could be
detrimental to handover performance, especially when real time
services are in active session.
Based on the discussion above, it would seem reasonable to have
multiple ANs grouped in an access domain controlled by an access
domain controller, ADC. Following an EAP authentication and creation
of MSK/EMSK, a handover root key could be generated and passed on to
the AAA server. The AAA server would then create ADC-specific master
keys (ADMSK) and forward the ADMSK to each ADC based on request or
proactively. Keying and authentication for handover between ANs
within an access domain will be handled by the managing ADC, while
the same for handovers between access domains can be handled through
the AAA server, but without requiring a full EAP authentication.
This can be accomplished if specific fast re-authentication keys can
be generated (from the handover root key) for the sole purpose of
authentication for handover between ADs and authorization for
handover keying within the new access domain. This key will of
course be kept hidden from each of the ADCs, while a new ADMSK will
be sent to the new ADC, which in turn can cache the ADMSK and derive
LSAP_MK for each of the ANs within its domain as needed. This
approach will have some practical problems as well.
First: the physical placement of the pass-through authenticator with
respect to AN versus ADC needs to be determined. The pros and cons
of each alternative are discussed later on in the draft. For now, we
suffice to say that pass-through authenticator, AN and ADC are
treated as three separate entities to not loose any generality.
Second, regardless of the physical placement of the authenticator
with respect to the AN, a design choice has to be made when it comes
to derivation of a handover root key:
Nakhjiri Expires December 23, 2006 [Page 4]
Internet-Draft Handover Keying Hierarchy Description June 2006
1. MSK as handover root key: If we use MSK as the root key, we need
to generate per-ADC keys from MSK and send those keys to each ADC
instead. When the ADC contains a pass-through authenticator,
this is in direct conflict with the existing deployments of EAP
keying specification.
2. AMSK as the handover root key: We can create an application
master key (AMSK) for handover from the EMSK as described in
[salowey-eap-emsk-deriv] . The per-ADC master keys (ADMSK) will
be generated from this AMSK and forwarded to each ADC. This is
also in conflict with existing deployment examples of EAP keying.
As one can see, we have introduced the term handover root key (HRK)
as the root key for handover keying in this draft. This naming is
introduced to reduce the dependency of a handover keying solution on
the choice of MSK versus AMSK (Note: HRK was referred to as XMSK in
[I-D.nakhjiri-aaa-hokey-ps]). The HRK may be either the MSK or the
AMSK, depending on the EAP WG or IETF decision on permissions and/or
requirements placed on MSK and EMSK from EAP methods. As seen above,
regardless of what key is used as HRK (MSK or an AMSK) is used as a
root key for handover keying, neither will result in a behavior that
is consistent with the current definition of authenticator in the EAP
keying documentation.
The preference here is to generate the HRK from the EMSK in the same
manner as an AMSK could be generated (HRK could be called handover
AMSK). Furthermore, without dueling much on the placement of the
pass-through authenticator, we introduced the key holder (KH) into
the ADC (shown in Figure 1) as an entity that can cache ADMSK and
generate LSAP_MKs as needed. In order for the ADC to be able to
receive the ADMSK from the AAA server, the ADC must also be able to
act as a AAA client with respect to the AAA server generating the
ADMSK. Transport of LSAP_MK from the ADMSK to the ANs may under hand
be done through a non-AAA protocol to be designed or determined later
on. The keys at each level (ADMSK or LSAP_MK) can be generated per
request or proactively (if all the required parameters are
available).
Nakhjiri Expires December 23, 2006 [Page 5]
Internet-Draft Handover Keying Hierarchy Description June 2006
(HRK,AAA_REAUTH_KEY)
<-------------------------------------------->
(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
This document intends to provide an example of how the various keys
in handover keying architecture shown in figure Figure 1 can be
generated. The document leaves the transport aspects of the key
distribution for future discussion. Some of our key binding ideas
may be self-evident through inclusion of various identifiers in the
expressions provided for generation of various keys, however, these
expression will need to examined more closely through further
discussions.
2. Terminology and Assumptions
Nakhjiri Expires December 23, 2006 [Page 6]
Internet-Draft Handover Keying Hierarchy Description June 2006
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].
HRK: Handover root key is a key that will be used as the root key to
solve the handover keying problem.
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 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.
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.
Link Secure Association Protocol (LSAP): 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). The LSAP
protocol uses LSAP_MK (below) 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 XMSK through one or more steps in ways to
be explored.
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.
ADC Identifier (ADCID): The identifier for the ADC serving the peer.
3. 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. From this EMSK, an AMSK designated for handover keying
application can be generated. We called this AMSK, the HRK.
HRK=HRK-PRF (EMSK, "AMSK for Handover" | EAP session ID | Key_ID |
Nakhjiri Expires December 23, 2006 [Page 7]
Internet-Draft Handover Keying Hierarchy Description June 2006
AAA server ID)
The HRK-PRF may be specified by any documentation (possibly
[I-D.ietf-eap-keying]) that governs the caching/ usage of EMSK. AP
session ID is supposed to be unique between peer and the server,
identified by the peer-ID and EAP server ID, respectively.
Note that the HRK is only known to the peer and the AAA server, but
not known to any of the ADCs. After its generation, the HRK will be
available at the AAA server and can be cached until expiration, but
will not be transported to any other entities. The HRK is then used
to the rest of keys within the handover key hierarchy:
AAA_REAUTH_KEY: This is a key that does not leave the AAA server and
is not exposed to any other entity in the network. AAA_REAUTH_KEY
can be used by the peer, to sign a ADC handover request (ADC-HO-
REQ) for handover to an area served by a new ADC or possibly to
perform a new fast authentication when the initial EAP session is
expired. Proof of possession of this key allows for a quick re-
authorization (typically called fast re-authentication) of the
peer in the either an inter-ADC handover, or session expiration,
without requiring a new EAP. Aside from the re-authorization, the
ADC-HO-REQ 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 proactively) 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.
AAA-REAUTH_KEY= HO-PRF (HRK, "Key for re-authentication to AAA
server" | EAP session ID | Key_ID )
ADMSK_i The key that is used as a root key for branch of key
hierarchy within each access domain. 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 as follows:
ADMSK_i= HO-PRF (HRK, "ADMSK generation" | EAP session ID | Key ID
| ADCID)
As seen, AAA_REAUTH_KEY and ADMSK are both generated at the AAA
server based using a HO_PRF that can be supported by the crypto-
engines at both MN and the AAA server.
Note that the peer may not have knowledge of the ADC identifier
Nakhjiri Expires December 23, 2006 [Page 8]
Internet-Draft Handover Keying Hierarchy Description June 2006
(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.
The AAA server now can send the ADMSK_i to the ith ADC through a
secure transport (possibly a secured AAA message). The AAA server
can delete the ADMSK_i after the transport to the ADC, if required
for compliance with principle of least privilege.
The ith ADC (ADCi) receives the ADMSKi. ADMSKi is meant to be a
temporary key (within the interval that the current EAP session is
valid) only known to the ADC_i and the peer. ADMSK_i is only cached
at the key holder of ADC i and at the peer and is not distributed to
any other entities. From this point on, we refer to this key as
ADMSK. The key holder of an ADC uses the ADMSK as 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:
LSAP_MKs: LSAP_MKs, as explained 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. The peer is able to perform the same calculation and
arrive at the same copy of LSAP_MKn prior to performing the LSAP.
ADC_REAUTH_KEY: To provide more flexibility in optimizing handover
keying delay, we can allow for externally-triggered requests (from
the peer through old or new ANs) to the ADC for generation of
LSAP_MK by provisioning an ADC_REAUTH_KEY at the ADC and at the
peer. A few uses cases for ADC_REAUTH_KEY can be envisioned:
1. Intra-ADC handover authorization (fast re-authentication to
ADC): The peer can use the ADC_REAUTH_KEY for the current ADC
to sign a request for authorization to a new AN (served by the
same ADC) and at the same time trigger the ADC to generate and
send the LSAP_MK for the new AN. This way intra-ADC handovers
can be easily handled at the ADC without involving lengthy
exchanges with the backend AAA servers.
2. Inter-ADC handover keying: If a new ADC (ADC_j) has been
provisioned with ADMSK_j through proactive provisioning using
the AAA infrastructure, the peer can using ADC_REAUTH_KEY for
the new ADC sign a request for authorization to move into the
access domain and thereby prepare to handover to ANs served by
that ADC. Especially if the new ADC (ADCj) is provisioned
with ADMSK_j before hand, the AAA interaction that is required
for inter-ADC handovers can be moved out of the timing
Nakhjiri Expires December 23, 2006 [Page 9]
Internet-Draft Handover Keying Hierarchy Description June 2006
critical path for handovers. The proactive provisioning of
the ADMSK_j can be part of a pre-authentication study.
3. Channel Binding: ADC_REAUTH_KEY and the authorization
signaling can help channel binding purposes. It is important
to note that both the peer and the ADC serving AN1 calculate
the LSAP_MK1 based on the peer-link-ID and AN-link-ID. The
peer uses an AN-link-ID advertised by the AN over the link,
while the ADC uses an AN-link-ID that is received from AN or
through pre-configuration. If those two copies of AN-link-ID
(received by peer and by ADC) do not match the LSAP_MKs will
not match either and LSK will fail. In the appendix we will
provide some hints on how this key can be used to provide
channel binding.
The ADC_REAUTH_KEY can be calculated as follows:
ADC_REAUTH_KEY= ADC-PRF (ADMSK_i, "Key for re-authentication to ADC"
| EAP session ID | Key_ID| ADCID )
LSAP_MKn for nth AN served by the KH of the ith ADC is generated as
follows:
LSAP_MKn = ADC-PRF (ADMSK_i, "LSAP master key generation" | EAP
Session ID | Key-ID | ANn-Device-Id)
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
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 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.
In the following we assume ADC i is the ADC 1 shown Figure 1) and the
first AN the peer is connecting to is AN1. So the ADC1 creates the
LSAP_MK1 for the (peer-AN1) interaction as follows:
As the mobile node hands off from AN1 to another AN (AN2), through
some method that we do not discuss at this point, the ADC is notified
Nakhjiri Expires December 23, 2006 [Page 10]
Internet-Draft Handover Keying Hierarchy Description June 2006
about the move and about the device ID of AN2. The ADC may require
proof of possession of the ADC_REAUTH_KEY from the peer. The key
holder of the ADC calculates the LSAP_MK2 for the AN2:
LSAP_MK2 = ADC-PRF (ADMSK-i, "LSAP master key generation" | EAP
Session ID | Key-ID | AN2-Device-Id)
and transports the LSAP_MK2 to AN2, which engages in LSAP with the
peer as described earlier.
The details of the signaling are to be explored later. For instance
the timing and triggers for various authorization messaging or keying
material transport needs to be fine-tuned based on the physical
conditions of the (peer-AN1), (peer-AN2) and (AN1, AN2) links.
For instance, authorization request for handover to AN2 and even
LSAP_MK2 transport may happen prior to or following a handover to
AN2. The former is for instance possible through the ADC1 encrypting
and signing the keying material for the AN2 through a (ADC1-AN2)
shared key and sending it to the AN1, which then can through a simple
context transfer move to the AN2, without much security requirements.
transfer.
Another example is if the AN or the peer could request LSAP_MKs for a
list of candidate ANs as part of the request to the key holder. The
ADC could then send signed (peer ID, AN-ID, encrypted(LSAP_MK))
triplets for each of the ANs.
4. 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.
The first choice to be made is to determine where the ADC function
needs to be located with respect to the AN. One important security
goal at hand, is prevention of domino effect, so that if the LSAP_MK
at one AN is compromised, the LSAP_MK at other ANs must not be
compromised as a result. Creation of LSAP_MKs from the ADMSK that is
at the higher level in the key hierarchy, partly serves this goal, by
providing cryptographic separation unless ADMSK is compromised.
However, to protect ADMSK from compromise, it is advised to follow
the principle of least privilege, i.e. ADMSK should not be made
available to a party unless absolutely needed. This would mean ADMSK
should not be made available to processing entities that otherwise
should only have access to LSAP_MK. This will leave two alternatives
when it comes to physical placement of the key holder with respect to
Nakhjiri Expires December 23, 2006 [Page 11]
Internet-Draft Handover Keying Hierarchy Description June 2006
the ANs.
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).
2. Integrated 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 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 backhaul 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.
The other choice to be made is the positioning of the ADC with
respect to EAP signaling and AN. The EAP signaling will physically
go through AN and EAP pass-through authenticator, so the pass-through
authenticator defines the path for EAP signaling. Hence by off-path
ADC we mean a scenario where ADC is not on the EAP signaling path and
contacts AAA server through a separate AAA channel.
1. Off-path ADC: According to the handover keying solution, the
ADMSK (and not the MSK) is sent to the ADC. This means ADC and
an EAP pass-through authenticator are logically different
entities and do not need to be collocated. This also means ADC
does not necessary have to be on the EAP signaling path. In the
off-path ADC arrangement, the pass-through authenticator can be
located at the serving AN, also acting as a AAA client when
encapsulating EAP packets into AAA messages. This is the most
generic arrangement, but the downside of this arrangement is that
Nakhjiri Expires December 23, 2006 [Page 12]
Internet-Draft Handover Keying Hierarchy Description June 2006
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.
+-+-+-+-+-+
| ADC |
| AAAC |-----+
+-+-+-+-+-+ \
| \
| \
V \
+-+-+-+-+ +-+-+-+-+-+ \ +-+-+-+-+-+
| | | Athr | +-| |
| EAP |--------| AAAC |------------| EAP/AAA |
| Peer | | AN | | Server |
+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 2: 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
entity as described above. In the integrated scenario, the pass-
through authenticator, AN and ADC will all be located in one
physical entity. In the standalone case, where ADC is disjunct
from the AN, a choice on placement of pass-through authenticator
in AN versus in ADC has to be made. 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.
5. messaging and AAA attributes
Design of messaging and message attributes to accomplish handover
keying will be based on requirements placed on security and
Nakhjiri Expires December 23, 2006 [Page 13]
Internet-Draft Handover Keying Hierarchy Description June 2006
performance of that process at a later date. For now, we provide
some examples to depict the type of issues involved in the design on
performance-optimized handover security signaling. The message
sequence diagrams are shown for a few different scenarios below. The
message names are chosen for maximum simplicity and need to be
enhanced later on.
5.1. Intra-ADC AN-handover
In this case, as the peer moves from coverage area of AN1 to coverage
area of AN2, it sends an handover authorization request to AN1 (using
the available link to AN1). The AN1 will send a KEY-REQ message to
the ADC to have the ADC proactively deliver the LSAP_MK2 to the AN2
as part of a KEY_REP message. The AN2 can optionally send a KEY-Conf
message to the AN1 to inform that it now has received LSAP_MK2
regarding the peer. This indication can be conveyed to the peer by
an HO-Auth-ack message from the AN1 to the peer, as shown in the
figure. Alternatively the same KEY-Conf message from the AN2 can be
encapsulated to the peer through AN1-peer link. The peer and AN2 can
now engage in an LSAP exchange to establish security associations
needed to secure the peer-AN2 link.
peer AN1 AN2 ADC
-------- -------- ------- ----------
| HO-Auth-REQ | | |
| ----------->| KEY-REQ | |
| | -------------------------> |
| | | KEY-REP |
| | KEY-Conf | <--------- |
| HO-Auth-ack | <-------- | |
| <-----------| | |
| LSAP |
| <----------------------------------- > |
Figure 3: Intra- ADC handover, peer-AN1 link up
5.2. Inter-ADC AN-handover
In this case the peer mobility pattern will bring the peer to the
coverage area of AN3, which is part of an access domain served by
ADC2. The KEY_REQ sent by the AN1 to the ADC1 is encapsulated in a
message to the AAA server. This is a case where a fast re-
authentication procedure with the AAA server is required. The need
for fast re-authentication may be indicated back to the peer, which
in turn will send a new authentication request out, but we leave the
details for later on. At this point we assume the KEY-REQ from the
ADC1 to the AAA server includes proper signatures to allow the AAA
server to authorize a handover to the domain controlled by ADC2.
Nakhjiri Expires December 23, 2006 [Page 14]
Internet-Draft Handover Keying Hierarchy Description June 2006
Following this successful authentication and authorization, the AAA
server sends the ADMSK2 to the ADC2 within a KEY_REP message. The
ADC2 informs the ADC1 and subsequently the AN1 and the peer of the
received authorization. The ADC2 will also calculate LSAP_MK3 for
the AN3 and send this key to AN3, which awaits the indication by the
peer to start an LSAP process.
peer AN1 ADC1 AN3 ADC2 AAA
----- ----- ----- ---- ----- -------
| HO-Auth-REQ | | | | |
| ----------->| KEY-REQ | | | |
| | ---------->| | | |
| | | KEY-REQ | |
| | |--------------------> |
| | | | KEY-REP |
| | | KEY-Conf | <------ |
| | KEY-Conf |<-------- | |
| HO-Auth-ack |<-----------| |KEY_REP| |
| <-----------| | |<---- | |
| LSAP |
| <---------------------------- > | | |
Figure 4: Inter- ADC handover, peer-AN1 link up
6. 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
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.
Nakhjiri Expires December 23, 2006 [Page 15]
Internet-Draft Handover Keying Hierarchy Description June 2006
Handover Vulnerabilities: The key hierarchy introduced here,
provides a hierarchy in authorization as well, e.g.
AAA_REAUTH_KEY versus ADC_REAUTH_KEY. 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.
7. 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.
8. IANA consideration
This document does not require any actions by IANA.
9. Acknowledgements
The author would like to thank Jari Arkko for useful suggestions on
generation of AMSK for handover key hierarchy and Mohan Parthasarathy
for providing feedback.
10. References
Nakhjiri Expires December 23, 2006 [Page 16]
Internet-Draft Handover Keying Hierarchy Description June 2006
10.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-13 (work in
progress), May 2006.
[I-D.nakhjiri-aaa-hokey-ps]
Nakhjiri, M., "AAA based Keying for Wireless Handovers:
Problem Statement", draft-nakhjiri-aaa-hokey-ps-02 (work
in progress), May 2006.
10.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.
[I-D.housley-aaa-key-mgmt]
Housley, R. and B. Aboba, "Guidance for AAA Key
Management", draft-housley-aaa-key-mgmt-02 (work in
progress), March 2006.
Appendix A. Appendix A: channel binding
Channel binding can be defined as a procedure through which the keys
generated for the channel (between party 1 and party 2) are bound the
parameters governing that channel. These parameters can be called
channel binding tuple (CBT) and typically can be listed as
CBT=(party 1 ID, party 2 ID,other information)
The field Other information may even include type of access
technology, if need be.
In a key hierarchy solution, channel binding needs to happen for keys
Nakhjiri Expires December 23, 2006 [Page 17]
Internet-Draft Handover Keying Hierarchy Description June 2006
at various levels of the key hierarchy. In context of link security
keying, the LSAP_MKs are used between a peer and AN to generate LSKs
to secure a link. Since the LSAP_MK is generated by KH of an ADC,
using peer-link-ID and AN-link-ID, in essence the channel binding for
LSAP_MK is accomplished during the generation of LSAP_MK. During the
LSAP exchange, the peer and AN will prove the possession of LSAP_MK.
However, it is more efficient to prevent the start of LSAP, if ADC
and peer can before generation of LSAP_MK verify that the AN is
providing the same identity to both peer and ADC (the so called lying
NAS problem).
As the channel binding need to happen at many level of key hierarchy,
it is not feasible to include channel binding information in EAP
layer signaling. It is neither desirable to have keying architecture
elements, such as AAA server or ADC to be pre-configured with channel
binding information for scalability reasons or the requirements on
statefulness. The statelessness (no requirements for pre-
configurations) is very desirable in roaming scenarios, where a
channel binding information in a foreign domain can simply not be
pre-configured in the home domain.
Here we are providing an example on how the identity presented by a
middle-entity in the keying architecture can be verified by both end
to prevent the so called lying NAS problem. The example is providing
verification of AN identity for both peer and ADC but can be extended
for use with AAA server even in roaming scenarios.
The solution is based on the premise that of sending two copies of
channel binding information to the key management entity (ADC in this
case): one directly from the AN to the ADC and one through the peer,
so that the ADC can compare the two and perform a check. Only after
a successful check, the peer and the AN can use LSAP_MK for LSAP
between the peer and the AN. The details are as follows:
The AN will sends AN-link-ID to the peer as part of link layer
association signaling. We call this ID, AN-to-peer-AN-ID.
The peer caches AN-to-peer-AN-ID as the AN-link-ID and builds the
channel binding tuple (CBT) using this ID.The peer now uses this CBT
(including AN-to-peer-ID) and calculates a peer-ANID-hash as follows:
peer-ANID-hash=KDF(ADC_REAUTH_KEY, channel binding info, "peer
hash").
The peer can now send an authorization-request towards the ADC to
request authorization for network entry through a AN (or handover to
a new AN). The format of this message depends on the access
technology used between the peer and the AN, however, the access
Nakhjiri Expires December 23, 2006 [Page 18]
Internet-Draft Handover Keying Hierarchy Description June 2006
technology messaging needs to include the peer-ANID-Hash described
above.
The AN now needs to forward the authorization request to the ADC.
The AN can include this request inside a message (defined by protocol
between AN and ADC) that also includes a request for LSAP_MK. We can
call this message AN-ADC-KEY-REQ. The AN will includes its
identifier (AN-link-ID) as part of this request. We call this
version of AN identifier AN-to-ADC-AN-ID. Providing integrity
protection for this identity is part of AN-ADC messaging protocol.
Our goal is to make sure AN-to-peer-AN-ID and AN-to-ADC-AN-ID are the
same.
The ADC after receiving AN-ADC-KEY-REQ message, by using the AN-to-
ADC-AN-ID from the AN calculate the channel binding tuple. Using the
channel binding tuple and the ADC_REAUTH_KEY, the ADC can calculate
its own hash signature (we call this signature ADC-ANID-hash):
ADC-ANID-hash=KDF(ADC_REAUTH_KEY, channel binding tuple, "server
hash")
If there is match between ADC-ANID-hash calculated by ADC and the
peer-ANID-hash reported by the peer, then not only the peer has
proved it holds the ADC_REAUTH_KEY, but also the ADC can make sure
the AN has reported the same identity to the peer.
To provide the same assurance to the peer, the ADC can sends a copy
of ADC-ANID-hash to the AN along with its response to the AN (AN-ADC-
KEY-RESP). The ADC can also include the LSAP_MK for the AN in this
message, since the ADC is now sure that AN is truthful.
The AN can now forward the ADC-ANID-hash inside its messaging to the
peer. The messaging can be one of the messages that are part of LSAP
to establish LSK between the peer and the AN.
The peer upon comparing ADC-ANID-hash and peer-ANID-hash, can
calculate LSAP_MK using the channel binding tuple that is now
confirmed and engage in LSAP messaging with the AN.
Note that the AN does not possess ADC-REAUTH_KEY and hence cannot
modify any of the signatures exchanged between ADC and peer.
Similar channel binding procedures can be used for all level of key
hierarchy as long as authorization keys are available. For instance
the same mechanism can be used to provide binding for keys between
the peer and the AAA server.
Nakhjiri Expires December 23, 2006 [Page 19]
Internet-Draft Handover Keying Hierarchy Description June 2006
Author's Address
Madjid Nakhjiri
Motorola Labs
Email: Madjid.nakhjiri@motorola.com
Nakhjiri Expires December 23, 2006 [Page 20]
Internet-Draft Handover Keying Hierarchy Description June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nakhjiri Expires December 23, 2006 [Page 21]