Internet DRAFT - draft-yegin-hmip-sa
draft-yegin-hmip-sa
MIPSHOP Working Group A. Yegin
Internet-Draft Samsung
Expires: January 29, 2007 K. Chowdhury
Starent Networks
July 28, 2006
HMIP Security Association
draft-yegin-hmip-sa-00
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 January 29, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a mechanism to dynamically generate a
security association between the mobile node and the mobility anchor
point to secure the HMIPv6 protocol messages. The mechanism relies
on generating a local security association based on the network
access authentication.
Yegin & Chowdhury Expires January 29, 2007 [Page 1]
Internet-Draft HMIP Security Association July 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. HMIP Security Association . . . . . . . . . . . . . . . . . . 4
2.1. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Key Distribution . . . . . . . . . . . . . . . . . . . . . 4
3. Using the SA . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Support for non-EAP-based Architectures . . . . . . . . . . . 6
5. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Yegin & Chowdhury Expires January 29, 2007 [Page 2]
Internet-Draft HMIP Security Association July 2006
1. Introduction
The current Hierarchical Mobile IPv6 (HMIP) protocol [RFC4140] lacks
a mechanism to secure the signaling between the mobile node (MN) and
the mobility anchor point (MAP). At the core of this problem is the
absence of a security association (SA) between the two nodes. When
the SA is present, it can be utilized along with IKEv2/IPsec
[I-D.ietf-mip6-ikev2-ipsec] or the mobility authentication option
[RFC4285] to provide authentication and integrity protection for the
protocol messages.
EAP [RFC3748] is used in various mobile and wireless network
architectures (e.g., WiFi, WiMAX, cdma2K). One important feature of
EAP is its ability to dynamically generate a secret key shared by the
EAP peer running on the MN and the authenticator running on the
network access server (NAS). This shared secret key (MSK -- master
session key [RFC3748]) can be utilized to derive another secret key
(HMIP-key) to be shared by the MN and the MAP in the access network.
This document describes how HMIP-key can be derived and used to
secure HMIP protocol messages.
Yegin & Chowdhury Expires January 29, 2007 [Page 3]
Internet-Draft HMIP Security Association July 2006
2. HMIP Security Association
HMIP security association (HMIP-SA) includes four parameters: The
peer identifier (HMIP-PID), the shared secret key (HMIP-key), the SPI
(HMIP-SPI), and the SA lifetime (HMIP-lifetime).
HMIP-PID of the MN is the Identity used during the EAP
authentication. HMIP-PID of the MAP is the IP address of the MAP.
HMIP-key is generated according to the following subsections.
HMIP-SPI value MUST be set to 1 upon initial EAP authentication with
the authenticator, increased by 1 for each subsequent EAP re-
authentication with the same authenticator, and set back to 1 after
wrapping around.
HMIP-lifetime is set to the lifetime of the MSK.
2.1. Key Derivation
The following formula is used to generate HMIP-key.
HMIP-key = HMAC-SHA1(MSK, "HMIPv6 key derivation" | MN-ID | MAP-
IPaddr)
MSK is the secret key generated by the EAP method execution and
shared by the MN and the NAS [RFC3748].
MN-ID is the Indetity presented by the MN during the EAP
authentication.
MAP-IPaddr is the IP address of the MAP used for HMIPv6 protocol
messaging.
2.2. Key Distribution
Since the EAP peer and HMIPv6 mobile node implementations reside on
the same MN, derivation and delivery of the HMIP-SA is internal to
that node. There is no additional protocol needed to carry the SA
parameters.
In case the MAP and the NAS are not colocated in a given architecture
or deployment, there needs to be a protocol to carry the SA
parameters from the NAS to the MAP. There is always a protocol used
for AAA purposes between the NAS and a service node like MAP in
architectures where such separation is supported. Whether it is
RADIUS, Diameter, or an architecture-specific proprietary protocol,
the details are outside the scope of this document.
Yegin & Chowdhury Expires January 29, 2007 [Page 4]
Internet-Draft HMIP Security Association July 2006
3. Using the SA
The dynamically generated SA can be directly used with either IKEv2/
IPsec [I-D.ietf-mip6-ikev2-ipsec] or the mobility authentication
option [RFC4285].
Yegin & Chowdhury Expires January 29, 2007 [Page 5]
Internet-Draft HMIP Security Association July 2006
4. Support for non-EAP-based Architectures
The same mechanism can be used with any architecture as long as there
is an equivalent of MSK shared between the MN and the NAS. Since
such a key would be architecture specific, it is hard to define it in
a generic but interoperable way in this document.[TBD: Give an
example from 3GPP.]
Yegin & Chowdhury Expires January 29, 2007 [Page 6]
Internet-Draft HMIP Security Association July 2006
5. Future Work
TBD: Cut another copy of the document for FMIPv6 security == s/HMIP/
FMIP + a bit of editing.
Yegin & Chowdhury Expires January 29, 2007 [Page 7]
Internet-Draft HMIP Security Association July 2006
6. Security Considerations
TBD.
Yegin & Chowdhury Expires January 29, 2007 [Page 8]
Internet-Draft HMIP Security Association July 2006
7. IANA Considerations
This document has no actions for IANA.
Yegin & Chowdhury Expires January 29, 2007 [Page 9]
Internet-Draft HMIP Security Association July 2006
8. References
8.1. Normative References
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L.
Bellier, "Hierarchical Mobile IPv6 Mobility Management
(HMIPv6)", RFC 4140, August 2005.
8.2. Informative References
[I-D.ietf-mip6-ikev2-ipsec]
Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec Architecture",
draft-ietf-mip6-ikev2-ipsec-06 (work in progress),
April 2006.
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Authentication Protocol for Mobile IPv6",
RFC 4285, January 2006.
Yegin & Chowdhury Expires January 29, 2007 [Page 10]
Internet-Draft HMIP Security Association July 2006
Authors' Addresses
Alper E. Yegin
Samsung Advanced Institute of Technology
Phone:
Email: alper01.yegin@partner.samsung.com
Kuntal Chowdhury
Starent Networks
Phone:
Email: kchowdhury@starentnetworks.com
Yegin & Chowdhury Expires January 29, 2007 [Page 11]
Internet-Draft HMIP Security Association July 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.
Yegin & Chowdhury Expires January 29, 2007 [Page 12]
