Network Working Group M. Nakhjiri
Internet-Draft Motorola Labs
Expires: September 4, 2006 March 3, 2006
A Keying hierarchy for managing Wireless Handover security
draft-nakhjiri-hokey-hierarchy-01
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 September 4, 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 September 4, 2006 [Page 1]
Internet-Draft Handover Keying Hierarchy Description March 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Assumptions . . . . . . . . . . . . . . . . . 5
3. Key Hierarchy and Generation . . . . . . . . . . . . . . . . . 6
4. Security report Card . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative references . . . . . . . . . . . . . . . . . . 12
Appendix A. Appendix A: channel binding . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Nakhjiri Expires September 4, 2006 [Page 2]
Internet-Draft Handover Keying Hierarchy Description March 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.
This typically involves exchange of authentication signaling between
the peer and a backend AAA server through the AN and provisioning of
keys for securing the link between the peer and the AN.
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 pass-through
authenticator and recommends this transport be done through a AAA
protocol. When the AN implements the authenticator and AAA client
function, it can then after receiving the MSK engage in a key
management schema with the peer to establish a secure link with the
peer.
The process described above may be sufficient in an environment where
the authentication, AAA client and AN are co-located and the peer
does not have move between different ANs. However, it will cause
difficulties when those conditions do not apply. If the MSK is
transported to an AN, when the peer moves to another AN, using the
same MSK at the new AN will violate the principle of least privilage
[I-D.housley-aaa-key-mgmt] and can result in a so-called domino
effect. Creating a new MSK at the new AN, on the other hand could
require performance of another round of lengthy EAP method
authentication exchange, which is detrimental to handover
performance, especially when real time services are in active
session.
As described in [I-D.nakhjiri-aaa-hokey-ps] an architecture deploying
a key holder, KH, (shown in Figure 1) that can act as a AAA client
and receive the master keys transmitted by the AAA server seems to
gain more acceptance in the industry due to its strength in
addressing this issue more effectively.
EAP working group is currently working on specification of
methodology [I-D.ietf-eap-keying] that allows the use of EAP method
generated master keys (MSK and EMSK) in assisting AAA-based key
management procedures. The notion of application master session key
(AMSK) has been recognized as a useful concept. While some basic
tenets about AMSK use has been discussed in IETF EAP WG, the process
of AMSK generation, caching and distribution is not yet standardized
Nakhjiri Expires September 4, 2006 [Page 3]
Internet-Draft Handover Keying Hierarchy Description March 2006
in IETF.
In the handover problem description document
[I-D.nakhjiri-aaa-hokey-ps] we tried to reduce the dependency of a
handover keying solution to the AMSK for that reason by introducing
the notion of XMSK as the master key that is pushed/pulled into each
key holder. Distinguishing between AMSK and XMSK serves two notions:
1) from one AMSK generated for handover, multiple XMSKs (one for each
key holder, KH) can be generated. This way the architecture is
capable of supporting Inter-KH handovers if need be. At the same
time it can comply with the concern that only the AMSK and not the
EMSK can be available at the AAA server, while the EMSK needs to stay
(or possibly deleted) at the EAP server. 2) The XMSK, created at the
AAA server for key holder and transported to the each KH, can be
deleted from AAA server cache, if required. The AMSK can on the
other stay at the AAA server for future use (such as XMSK generation
for other, not currently identified KHs).
Nakhjiri Expires September 4, 2006 [Page 4]
Internet-Draft Handover Keying Hierarchy Description March 2006
(HO-AMSK,HO-AAA-REAUTH-KEY)
<-------------------------------------------->
(XMSK,HO-KH-REAUTH-KEY)
<---------------------------->
LSK,LSAP-MK
<------------>
+-+-+-+-+-+LSK +-+-+-+ LSAP-MK1
| MN/ |-----| AN11|---+
|EAP Peer | +-+-+-+ | +-+-+-+
+-+-+-+-+-+ +-----|KH 1 |-+XMSK1
+-----+ | +-----+ |
| AN12|---|LSAP-MK2 ^
+-----+ | |
. | |
. | | +-+-+-+-+-+
+-+-+-+ | | |AAA/EAP |
| AN1n|---+ +--+--| Server |
+-+-+-+ | +---------+
|
+-+-+-+ +-----+ |
| AN21|---------|kH 2 |----+XMSK2
+-+-+-+ +-+-+-+ |
. . |
. . |
+-+-+-+ +-----+ |
| ANm1|---------|kH m |----+ XMSK3
+-+-+-+ +-+-+-+
. |
. |
+-+-+-+ |
| ANmk|-----------+
+-+-+-+
Figure 1: A keying architecture deploying key holders
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 September 4, 2006 [Page 5]
Internet-Draft Handover Keying Hierarchy Description March 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]
X-Master Session Key (XMSK): A key that will be used as the root key
to solve the handover keying problem.
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.
3. Key Hierarchy and Generation
Upon successful completion of the EAP authentiation 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 call this AMSK, the HO-AMSK
HO-AMSK=AMSK-PRF (EMSK, "AMSK for Handover" | EAP session ID | Key_ID
| AAA server ID)
EAP session ID is supposed to be unique between peer and the server,
identified by the peer-ID and EAP server ID, respectively.
The current assumption is that the EMSK cannot be exported from the
EAP layer down to the AAA layer, but the HO-AMSK can. Hence from
this point, we assume that the AAA server can maintain a cache of HO-
AMSK if it needs to. The HO-AMSK is then used to create further
keys:
HO-AAA-REAUTH-KEY= HO-PRF (HO-AMSK, "Key for re-authentication to AAA
server" | EAP session ID | Key_ID )
Nakhjiri Expires September 4, 2006 [Page 6]
Internet-Draft Handover Keying Hierarchy Description March 2006
KH-MK= HO-PRF (AMSK, "master Key for all key holders" | EAP session
ID | Key_ID )
HO-AAA-REAUTH-KEY is a key that can be used by the peer, if it needs
to indicate to the AAA server that it has moved to an area served by
a new key holder. The key allows for a quick re-authorization
process in the course of inter-KH handover, without requiring a new
EAP. Proof of possession of this key, authorizes the peer to receive
key generation services through a new key holder. Note that the peer
may not necessarily need to know that it has moved to a new key
holder; the AAA server can request proof of possession of this key
through a request. HO-AAA-REAUTH-KEY does not leave the AAA server
and is not exposed to any other entity in the network. The peer is
able to generate this key through knowledge of AMSK.
KH-MK is a key that does not leave the AAA server and is used by the
AAA server as a root key when generating XMSK for a key holder number
i:
XMSK for KH i= XMSKi= KH-i-MK=
HO-PRF (KH-MK, "XMSK generation" | EAP session ID | Key ID | Key
holder i ID)
Note that the peer may not have knowledge of the key holder
identifier, hence some sort of domain identifier corresponding to the
key holder needs to be used. Such domain identifiers can be
broadcast through the advertisements provided by the AN to the peer.
The AAA server now can send the XMSKi to the key holder i through a
secure transport (possibly a secured AAA message). The AAA server
can now delete the XMSKi, if required for compliance with principle
of least privilage.
The key holder i (KHi) receives the XMSKi. From this point on, we
refer to this key as XMSK or XMSK-current to comply with the
description provided in the handover keying problem description
[I-D.nakhjiri-aaa-hokey-ps]
The XMSK is meant to be cached at the key holder and not distributed
to any other entities. The key holder uses the XMSK as for all the
key generation activities within its domain (i.e. for all the ANs it
serves). In the following we assume key holder i is the key holder 1
shown Figure 1) and the first AN the peer is connecting to is AN1.
So the KH1 creates the LSAP-MK1 for the (peer-AN1) interaction as
follows:
LSAP-MK1 = LSAPMK-PRF (XMSK-i, "LSAP master key generation" | EAP
Nakhjiri Expires September 4, 2006 [Page 7]
Internet-Draft Handover Keying Hierarchy Description March 2006
Session ID | Key-ID | AN1-Device-Id)
The LSAP-MK1 is transported to the AN1 through a secure transport at
some point in conjunction to the handover
To maintain a level of integrity in the design, we provision another
authorization key (we call this HO-KH-REAUTH-KEY) so that the peer
can use this key to gain authorization from the key holder to
handover to another key. The KO-KH-REAUTH-KEY can be calculated as
follows:
HO-KH-REAUTH-KEY= HO-PRF (XMSK, "Key for re-authentication to key
holder" | EAP session ID | Key_ID )
The need for proof of possession of this key and the exact signaling
process through which this proof is presented to the key holder as
part of handover is to be tested later on. There a few possible uses
for this key:
1)HO-KH-REAUTH-KEY can help the peer to obtain authorization for
handover to another AN served by the same key holder and trigger the
key holder to send the LSAP-MK to that AN. This way lengthy
exchanges with the backend AAA servers (fast re-authentication) can
be eliminated in many cases.
2)HO-KH-REAUTH-KEY and the authorization signaling can help channel
binding purposes: It is important to note that both the peer and the
key holder 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 KH 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 key holder) 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.
Once the LSAP-MK1 is obtained by the AN1, the peer and AN1 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:
LSK-encryption=LSK-PRF (LSAP-MK1, "Link encryption key", EAP session
ID | Key ID | peer-link-ID | AN-link-ID | peer-nonce | AN1-nonce),
LSK-Authentication=LSK-PRF (LSAP-MK1, "Link authentication key", EAP
session ID | Key ID | peer-link-ID | AN1-link-ID | peer-nonce | AN-
nonce),
Nakhjiri Expires September 4, 2006 [Page 8]
Internet-Draft Handover Keying Hierarchy Description March 2006
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.
As the mobile node hands off from AN1 to another AN, through some
method that we do not discuss at this point, the key holder is
notified about the move and about the device ID of AN2. The Key
holder may require proof of possession of the HO-KH-REAUTH-KEY from
the peer. The key holder calculates the LSAP-MK2 for the AN2:
LSAP-MK2 = LSAPMK-PRF (XMSK-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 KH encrypting
and signing the keying material for the AN2 through a (KH-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
key holder could then send signed (peer ID, AN-ID,
encrypted(LSAP-MK)) triplets for each of the ANs.
Finally, As discussed in the problem statement draft, a key holder
seems to be a necessary part of the architecture. However, the
realization of this architecture can take various shapes. the
recommendation here is to use the following architecture to use EAP
keying framework.
Nakhjiri Expires September 4, 2006 [Page 9]
Internet-Draft Handover Keying Hierarchy Description March 2006
+-+-+-+-+-+
| Key Hldr|
| AAAC |-----+
+-+-+-+-+-+ \
| \
| \
V \
+-+-+-+-+ +-+-+-+-+-+ \ +-+-+-+-+-+
| | | Athr | +-| |
| EAP |--------| AAAC |------------| EAP/AAA |
| Peer | | AN | | Server |
+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 2: off-EAP-path key holder function
4. Security report Card
This section of the document provides a test of the provided key
hierarchy agains the security goals stated in the kandover 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 with the principle of least privilage 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, XMSK for each key holder is only
specific to that key holder, the same as LSAP-MK for each AN.
Key Naming: All keying material starting from XMSK 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. 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. HO-AAA-
REAUTH-KEY versus HO-KH-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-key holder and peer-AN authentication through
introduction of specific keys. AAA server-key holder, key
holder-AN authentication mechanisms are outside control of this
document.
Nakhjiri Expires September 4, 2006 [Page 10]
Internet-Draft Handover Keying Hierarchy Description March 2006
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.
5. 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, key holder) and (key holder, AN) may be subject to
security issues that are outside control of this docuemnt. Future
revisions of this document is to provide recommendations for the
transport mechanisms.
6. IANA consideration
This document does not require any actions by IANA.
7. Acknowledgements
The author would like to thank Jari Arrko for useful suggestions on
generation of AMSK for handover key hierarchy and Mohan Parthasarathy
for providing feedback.
8. References
8.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]
Nakhjiri Expires September 4, 2006 [Page 11]
Internet-Draft Handover Keying Hierarchy Description March 2006
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-09 (work in
progress), January 2006.
[I-D.nakhjiri-aaa-hokey-ps]
Nakhjiri, M., "AAA based Keying for Wireless Handovers:
Problem Statement", draft-nakhjiri-aaa-hokey-ps-01 (work
in progress), January 2006.
8.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-01 (work in
progress), November 2005.
[I-D.arkko-eap-service-identity-auth]
Arkko, J. and P. Eronen, "Authenticated Service
Information for the Extensible Authentication Protocol
(EAP)", draft-arkko-eap-service-identity-auth-04 (work in
progress), October 2005.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
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 September 4, 2006 [Page 12]
Internet-Draft Handover Keying Hierarchy Description March 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 a KH, 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 KH and
peer can before generation of LSAP-MK verify that the AN is providing
the same identity to both peer and KH (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 KH 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 arhictecture 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 KH 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 (KH in this
case) : one directly from the AN to the KH and one through the peer,
so that the KH 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(HO-KH-REAUTH-KEY, channel binding info, "peer
hash").
The peer can now send an authorization-request towards the KH 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 September 4, 2006 [Page 13]
Internet-Draft Handover Keying Hierarchy Description March 2006
technology messaging needs to include the peer-ANID-Hash described
above.
The AN now needs to forward the authorization request to the KH. The
AN can include this request inside a message (defined by protocol
between AN and KH) that also includes a request for LSAP-MK. We can
call this message AN-KH-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-KH-AN-ID. Providing integrity protection for this
identity is part of AN-KH messaging protocol. Our goal is to make
sure AN-to-peer-AN-ID and AN-to-KH-AN-ID are the same.
The KH after receiving AN-KH-KEY-REQ message, by using the AN-to-KH-
AN-ID from the AN calculate the channel binding tuple. Using the
channel binding tuple and the HO-KH-REAUTH-KEY, the KH can calculate
its own hash signature (we call this signature KH-ANID-hash):
KH-ANID-hash=KDF(HO-KH-REAUTH-KEY, channel binding tuple, "server
hash")
If there is match between KH-ANID-hash calculated by KH and the peer-
ANID-hash reported by the peer, then not only the peer has proved it
holds the HO-KH-REAUTH-KEY, but also the KH can make sure the AN has
reported the same identity to the peer.
To provide the same assurance to the peer, the KH can sends a copy of
KH-ANID-hash to the AN along with its response to the AN (AN-KH-KEY-
RESP). The KH can also include the LSAP-MK for the AN in this
message, since the KH is now sure that AN is truthful.
The AN can now forward the KH-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 KH-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 posess HO-KH-REAUTH-KEY and hence cannot
modify any of the signatures exchanged between KH 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 September 4, 2006 [Page 14]
Internet-Draft Handover Keying Hierarchy Description March 2006
Author's Address
Madjid Nakhjiri
Motorola Labs
Email: Madjid.nakhjiri@motorola.com
Nakhjiri Expires September 4, 2006 [Page 15]
Internet-Draft Handover Keying Hierarchy Description March 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 September 4, 2006 [Page 16]