MIPSHOP H. Deng
Internet-Draft Hitachi (China)
Intended status: Standards Track Z. Cao
Expires: April 4, 2007 Peking University
Y. Ma
Hitachi (China)
Oct 2006
Handover Key Hierarchy for Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)
draft-deng-mipshop-hmip-hhokey-00.txt
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 April 4, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Deng, et al. Expires April 4, 2007 [Page 1]
Internet-Draft Handover Key Hierarchy for HMIPv6 Oct 2006
Abstract
The Hierarchy Mobile IPv6 document introduces the Mobile Anchor
Point, which improve the performance of IPv6 in terms of handover
speed. This document specifies a proactive key distribution method
(push mode) within the same MAP, while the use of the handover keying
hierarchy among different MAPs is in a reactive mode (pull mode).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Push within MAP . . . . . . . . . . . . . . . . . . . . . 5
3.2. Pull across MAP . . . . . . . . . . . . . . . . . . . . . 5
4. Architecture Considerations . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Deng, et al. Expires April 4, 2007 [Page 2]
Internet-Draft Handover Key Hierarchy for HMIPv6 Oct 2006
1. Introduction
The Hierarchy Mobile IPv6 (HMIPv6) document [I-D.hmipv6] introduces
the Mobile Anchor Point, which improve the performance of IPv6 in
terms of handover speed. The MAP is essentially a local Home Agent,
and it is located at any level in a hierarchical network of routers.
The MN only needs to send one Binding Update message to its MAP
before any traffics form HA and CNs are re-routed to its new place,
hence significantly improving handover performance.
Unfortunately, the HMIPv6 document does not specifies a framework for
authenticating the MN to the networks. Extensible Authentication
Protocol (EAP) is suitable do this job for HMIPv6. When the MN is in
the visit network, it performs EAP exchanges with the local AAA
Server which delegates the authentication service of the home AAA
server. The Access Router and / or the MAP act as a pass-through
authenticator. Although EAP Keying framework [I-D.ietf-eap-keying]
provides guidelines for generation of the keying meterials, the
handover keying problem is not solved until we have the Handover Key
Problem Statement document [I.D.aaa-hokey-ps] and a handover keying
hierarchy document [I-D.hokey-hierarchy].
According to the handover keying document, the HMIPv6 architecture is
suitable to take advantage of the handover keying hierarchy. The MAP
resembles the Access Domain Controller (ADC), while the AR is a kind
of the Access Node.
Currently use of handover key hierarchy engages in a reactive manner
in which the Access Node pulls the corresponding key from its
upstream key holders (e.g. the ADC). But we argue that in an
administrative domain, it is suitable and proper to use the handover
key hierarchy in a proactive manner. In this document, we define a
proactive key distribution method (push mode) within the same MAP,
while the use of the handover keying hierarchy among different MAPs
is in a reactive mode (pull mode).
Deng, et al. Expires April 4, 2007 [Page 3]
Internet-Draft Handover Key Hierarchy for HMIPv6 Oct 2006
2. Terminology
The keywords "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 [RFC2119].
The following new terminology and abbreviations are introduced in
this document and all the other general mobility related terms as
defined in [I-D.ietf-eap-keying] and [I.D.aaa-hokey-ps]
Push mode
The proactive mode of key distribution in which the upstream key
holder distributes the keys for downstream key holders under its
control in advance.
Pull mode
The reactive mode of key distribution in which the downstream key
holder requests the corresponding key from its upstream key holder
when they are in need of this key.
Deng, et al. Expires April 4, 2007 [Page 4]
Internet-Draft Handover Key Hierarchy for HMIPv6 Oct 2006
3. Protocol Overview
The key management within one MAP domain utilizes the push model,
while key mananagemtn across different MAPs make use of the pull
mode. The protocol operations are decribed in the following two
subsections.
3.1. Push within MAP
The handover within one MAP is decribed in Figure 1. The MN was
originally authenticated to AR1 with a full EAP exchange. Then the
AAA server pushes the corresponding key to the MAP. According to its
configuration, the MAP pushes the keys to the ARs within its
administrative domain. When the MN attaches to another AR (e.g. AR2
in Figure 1), the MN and AR2 assert their knowledge of the
corresponding LSAP_MK by exchanges of the Secure Association Protocol
(SAP), after which they arrive at the consensus of the LSK.
MN AR1 AR2 MAP AAA
| | | | |
|<---EAP---->|<---------------RADIUS----------------->|
|<=============== EAP Authentication=================>|
| | | KeyPush | |
| | |<------------| |
| | | KeyPush | |
| |<-------------------------| |
| | | | |
| Attach to AR2 | | |
|------------------------>| | |
| | | | |
| | | | |
|<======= SAP =======>| | |
| | | | |
Figure 1: Handover within MAP
3.2. Pull across MAP
With our protocol, the handover across different MAPs utilizes the
pull mode. The protocol operations are described in Figure 2, which
is similar to [I-D.hokey-hierarchy]. For simplicity, we omit the ANs
in Figure 2.
According to [I-D.hokey-hierarchy], the HoReq sent by MN and HokeyReq
sent by the MAP is authenticated by the AAA_REAUTH_KEY. The AAA
Deng, et al. Expires April 4, 2007 [Page 5]
Internet-Draft Handover Key Hierarchy for HMIPv6 Oct 2006
server will validate the authentication payload upon receiving the
HokeyReq message. If the validation is successful, the AAA sends out
the HokeyRep message to the new MAP (e.g. MAP2), and MAP2 confirms
its receipt of the handover key by sending out a HokeyConf message to
MAP1. MAP1 will also make the MN convinced of the handover by
sending HoAck message to the MN. Finally, the MN and MAP2 finish the
SAP exchanges and establish the communication following up.
MN MAP1 MAP2 AAA
| HoReq | | |
|------------->| HokeyReq |
| |---------------------------->|
| | | HokeyRep |
| | HokeyConf |<-------------|
| HoAck |<-------------| |
|<-------------| | |
| | | |
| | | |
|<========== SAP ==========>| |
| | | |
Figure 2: Handover across MAP
Deng, et al. Expires April 4, 2007 [Page 6]
Internet-Draft Handover Key Hierarchy for HMIPv6 Oct 2006
4. Architecture Considerations
As specified in [I-D.hokey-hierarchy], the ADC may locate off-path or
on-path with respect to the EAP signalling. The MAP undergoes the
same story of the ADC with no exception.
o Off-path MAP: The MAP does not necessarily have to be on the EAP
signaling path. In the off-path MAP arrangement, the EAP
authenticator can be located at the serving AN. One downside of
this arrangement is that 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. The
other downside is that there MAY be additional considerations on
the key distribution protocol between the MAP and AN.
+-+-+-+-+-+
| MAP |---+
+-+-+-+-+-+ \
| \
| \
V \
+-+-+-+-+ +-+-+-+-+-+ \ +-+-+-+-+-+
| | | | +---| |
| MN |--------| AN |-------------| EAP/AAA |
| | | | | Server |
+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Off-path MAP
o On-path MAP: The MAP is located on the path of EAP signaling. In
the integrated scenario, the pass- through authenticator, AN and
MAP MAY be located in one physical entity. In the standalone
case, where MAP is disjunct from the AN, a choice on placement of
pass-through authenticator in AN versus in MAP 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 MAP is able to act as a AAA proxy for AAA
signaling.
Deng, et al. Expires April 4, 2007 [Page 7]
Internet-Draft Handover Key Hierarchy for HMIPv6 Oct 2006
5. Security Considerations
Both the key lifetime, key scope in the hierarchy MUST comply with
EAP keying framework [I-D.ietf-eap-keying].
Deng, et al. Expires April 4, 2007 [Page 8]
Internet-Draft Handover Key Hierarchy for HMIPv6 Oct 2006
6. IANA Considerations
This specification does not request the creation of any new parameter
registries, nor does it require any other IANA assignments.
Deng, et al. Expires April 4, 2007 [Page 9]
Internet-Draft Handover Key Hierarchy for HMIPv6 Oct 2006
7. Acknowledgement
TBD.
Deng, et al. Expires April 4, 2007 [Page 10]
Internet-Draft Handover Key Hierarchy for HMIPv6 Oct 2006
8. References
8.1. Normative References
[I-D.hmipv6]
Soliman, H., Castelluccia, C., ElMalki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", June 2006,
<draft-soliman-mipshop-4140bis-00.txt>.
[I.D.aaa-hokey-ps]
Nakhjiri, M., Parthasarathy, M., and al. et, "AAA based
Keying for Wireless Handovers: Problem Statement",
May 2005, <draft-nakhjiri-aaa-hokey-ps-02.txt (work in
progress)>.
8.2. Informative References
[I-D.hokey-hierarchy]
Nakhjiri, M., "A Keying hierarchy for managing Wireless
Handover security", June 2006,
<draft-nakhjiri-hokey-hierarchy-02 (work in progress)>.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", <draft-ietf-eap-keying-13.txt (work
in progress)>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Deng, et al. Expires April 4, 2007 [Page 11]
Internet-Draft Handover Key Hierarchy for HMIPv6 Oct 2006
Authors' Addresses
Hui Deng
Hitachi (China)
Beijing Fortune Bldg. 1701
5 Dong San Huan Bei-Lu
Chao Yang District
Beijing 100004
China
Email: hdeng@hitachi.cn
Zhen Cao
Peking University
No.1 Science Building Room 1534
5 Yi He Yuan Lu
Hai Dian District
Beijing 100871
China
Email: caozhen@pku.edu.cn
Yuanchen Ma
Hitachi (China)
Beijing Fortune Bldg. 1701
5 Dong San Huan Bei-Lu
Chao Yang District
Beijing 100004
China
Email: ycma@hitachi.cn
Deng, et al. Expires April 4, 2007 [Page 12]
Internet-Draft Handover Key Hierarchy for HMIPv6 Oct 2006
Full 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.
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.
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).
Deng, et al. Expires April 4, 2007 [Page 13]