One document matched: draft-devarapalli-mip6-authprotocol-bootstrap-00.txt
MIP6 Working Group V. Devarapalli
Internet-Draft Nokia
Expires: August 30, 2006 A. Patel
K. Leung
Cisco
K. Chowdhury
Starent
February 26, 2006
Mobile IPv6 Bootstrapping for the Authentication Option Protocol
draft-devarapalli-mip6-authprotocol-bootstrap-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 August 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The current Mobile IPv6 bootstrapping mechanisms require the use of
IKEv2 between the mobile node and the home agent. If the Mobile IPv6
signaling messages are protected by the mobility option
authentication protocol, then the bootstrapping mechanism based on
Devarapalli, et al. Expires August 30, 2006 [Page 1]
Internet-Draft MIP6 Bootstrapping for Auth Protocol February 2006
IKEv2 cannot be used. This document describes bootstrapping
mechanisms for Mobile IPv6 when the mobility option authentication
protocol is used.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Home Address Configuration . . . . . . . . . . . . . . . . . . 3
3.1. Assigned Home Address . . . . . . . . . . . . . . . . . . 3
3.2. Home Address Auto-configuration . . . . . . . . . . . . . 4
3.3. Home Address Request Option . . . . . . . . . . . . . . . 4
3.4. Assigned Home Address Option . . . . . . . . . . . . . . . 5
4. Security Association Setup . . . . . . . . . . . . . . . . . . 6
4.1. Key Generation Mobility Options . . . . . . . . . . . . . 7
4.1.1. Key Generation Nonce Request . . . . . . . . . . . . . 7
4.1.2. Key Generation Nonce Reply . . . . . . . . . . . . . . 7
4.2. Key Generation Nonce Creation and Key Derivation . . . . . 9
5. Mobile Node's DNS Entry Update . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Devarapalli, et al. Expires August 30, 2006 [Page 2]
Internet-Draft MIP6 Bootstrapping for Auth Protocol February 2006
1. Introduction
The default mechanism for protecting Mobile IPv6 [2] signaling
messages is through IKEv2 and IPsec [7]. Mobile IPv6 signaling
messages can also be protected by using the mobility option
authentication protocol as described in [3]. This mechanism is not a
general authentication mechanism for Mobile IPv6, but is useful in
certain deployments as described in the applicability section of [3].
Mobile IPv6 bootstrap mechanisms enable a mobile node to dynamically
configure a home agent, acquire a home address and setup security
associations with the home agent. Such a mechanism is defined in
[8]. However, this mechanism uses IKEv2 to configure a home address
and setup IPsec security associations. This bootstrap mechanism
cannot be used if the mobility option authentication protocol is used
for protecting Mobile IPv6 signaling messages.
In this document we define a bootstrap mechanism that will work when
the mobility option authentication protocol is used. With this
mechanism a mobile node will be able to configure a home address and
dynamically setup security associations with the home agent which can
be used as specified in [3].
This document does not define a new home agent discovery mechanism.
Home agent discovery based in DNS lookup, as described in [8] should
be used by the mobile node to discover a home agent. A DHCPv6 based
mechanism as described in [11] can also be used to discover a home
agent.
2. Terminology
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 [1].
3. Home Address Configuration
3.1. Assigned Home Address
When the mobile node sends a Binding Update to a home agent protected
by the mobility message authentication option and does not have a
valid home address, it sets the home address to 0::0 in the Home
Address Option. The mobile node should include the Home Address
Request Option, described in Section 3.3, in the Binding Update. The
mobile node MUST also include the Mobile Node Identifier option [6].
The identity presented in the Mobile Node Identifier option is used
Devarapalli, et al. Expires August 30, 2006 [Page 3]
Internet-Draft MIP6 Bootstrapping for Auth Protocol February 2006
for identifying the mobile node.
When the home agent processes the Binding Update and notices the 0::0
home address and the Home Address Request option, it allocates a new
home address for the mobile node and responds with the home address
in the Binding Acknowledgement. The home address is carried in a new
mobility option, the Home Address option defined in Section 3.4.
For allocating a home address for a mobile node, the home agent could
either locally manage an address space and allocate a home address
from that address space, contact a DHCPv6 server on the home link for
the home address, or obtain the home address from a AAA server. If
the home agent is unable to allocate a home address for the mobile
node, it should reject the Binding Update and sent a Binding
Acknowledgement with the status code '144' (unable to allocate a home
address).
3.2. Home Address Auto-configuration
There may be a need for the mobile node to auto-configure a home
address instead of the home agent allocating a home address. For
example, the mobile node may want to use privacy extensions for
stateless address autoconfiguration as described in [9]. When the
mobile node sends a Binding Update it is not aware of the home prefix
to be able to configure a home address. Instead the mobile node
derives a 64-bit interface ID and sends it in the binding update.
The home agent combines the home prefix and interface ID from the
mobile node and constructs a 128-bit home address.
For sending the interface ID to the home agent, the mobile node sets
the home address field in the Home Address option to the 64-bit
interface ID. This mechanism assumes that the prefix length of the
home prefix is 64. This may not be a valid assumption in all
deployments. The auto-configuration mechanism described here will
fail if the prefix length is anything other than 64.
3.3. Home Address Request Option
This option is included by the mobile node in the Binding Update to
request for a new home address to be allocated. This option is only
valid in a Binding Update and has no alignment requirements.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Devarapalli, et al. Expires August 30, 2006 [Page 4]
Internet-Draft MIP6 Bootstrapping for Auth Protocol February 2006
Type
A 8-bit field indicating the type of the mobility option.
Length
A 8-bit field indicating the length of the option. Set to 0.
3.4. Assigned Home Address Option
This option is included by the home agent in the Binding
Acknowledgement to carry the newly allocated home address for the
mobile node. This option is valid only in a Binding Acknowledgement
and has an alignment requirement of 8n + 3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A 8-bit field indicating the type of the mobility option.
Length
A 8-bit field indicating the length of the option. Set to 17.
Prefix Length
A 8-bit field indicating the prefix length of the IPv6 prefix from
which the home address was allocated.
Home Address
Set to the home address allocated by the home agent.
Devarapalli, et al. Expires August 30, 2006 [Page 5]
Internet-Draft MIP6 Bootstrapping for Auth Protocol February 2006
4. Security Association Setup
[3] decribes how to protect Mobile IPv6 signaling messages using pre-
shared keys between the mobile and the home agent. It would be
useful to specify a mechanism that would dynamically create a shared
key between the mobile node and the home agent. In this document, we
describe a mechanism, similar to Mobile IPv4 key generation [4],
which allows the AAA server to generate a key that is delivered to
the home agent and also computed by the mobile node using the
information carried in the Binding Update and binding acknowledgement
messages.
The mechanism described here assumes that the mobile node depends on
an AAA infrastructure to obtain authorization for mobility service
and that there is a long lived AAA Security Association (SA) between
the mobile node and the AAA home (AAAH) server. This document
specifies extensions to Binding Update and binding acknowledgement
messages to derive a MN-HA SA from the AAA SA. Please refer to [4]
for a definition of security association when used in the context of
this document.
When the mobile node needs to send a Binding Update to its home agent
and realizes that it does not have a security association with the
home agent, it includes the Key Generation Nonce Request option,
illustrated in Section 4.1.1, in the Binding Update. The mobile node
MUST also include MN-AAA Mobility Message Authentication option as
described in section 5.2 of [3] and protect the Binding Update using
the MN-AAA SA.
When the home agent receives a Binding Update with the MN-AAA
Mobility Message Authentication and the Key Generation Nonce Request
options, it forwards this information to the AAAH server. The AAAH
server authenticates the Binding Update as described in [3]. The
AAAH server, when it processes the Key Generation Nonce Request
option, generates a 128 bit random value [12] to be used as the nonce
and derives a MN-HA SA. The AAAH server then sends this information
to the home agent. The AAA protocol extensions between the home
agent and the AAAH server are out of scope for this document.
The home agent then sends a Binding Acknowledgement to the mobile
node. The Binding Acknowledgement is protected by the MN-HA Mobility
Message Authentication option using the newly created MN-HA SA. The
home agent also includes the Key Generation Nonce Reply option,
illustrated in Section 4.1.2, with the information that was sent by
the AAAH. When the mobile node receives the Binding Acknowledgement,
it derives the MN-HA SA using the information present in the Key
Generation Nonce Reply option and authenticates the Binding
Acknowledgement with the newly created MN-HA SA.
Devarapalli, et al. Expires August 30, 2006 [Page 6]
Internet-Draft MIP6 Bootstrapping for Auth Protocol February 2006
The following sections describe new mobility options to carry the key
generation material, Key Generation Nonce creation and the actual
MN-HA SA derivation.
4.1. Key Generation Mobility Options
Two new mobility options are defined in this document for the purpose
of key generation.
4.1.1. Key Generation Nonce Request
The Key Generation Nonce Request is a new mobility option that is
included in the Binding Update when the mobile node does not have a
security association with its home agent. This option is valid only
in a Binding Update message and has an alignment requirement of 4n+2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile Node SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A 8-bit field indicating the type of the mobility option.
Length
A 8-bit field indicating the length of the option. Set to 4.
Mobile Node SPI
A 4-byte field set to the SPI that the mobile node will assign for
the security association created for use with binding
registration.
4.1.2. Key Generation Nonce Reply
The Key Generation Nonce Reply option is a new mobility option that
is used to carry the keying material for generating the MN-HA SA. It
is valid only in a binding acknowledgement. The MN-HA Key Generation
Nonce Reply option MUST appear before the MN-HA Mobility Message
Authentication Option. The alignment requirement for this option is
4n+2.
Devarapalli, et al. Expires August 30, 2006 [Page 7]
Internet-Draft MIP6 Bootstrapping for Auth Protocol February 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HA SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm Identifier | Replay Method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Generation Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
A 8-bit field indicating the type of the mobility option.
Length
A 8-bit field indicating the length of the option excluding the
Type and Length fields.
Lifetime
Indicates the duration of time (in seconds) for which the MN-HA SA
is valid.
AAA SPI
A 32-bit value indicating the SPI that the mobile node must use to
determine the transform to use for establishing the MN-HA SA.
HA SPI
The SPI that the home agent assigns for the MN-HA SA.
Algorithm Identifier
This field indicates the authentication algorithm to be used for
calculating the authentication data in subsequent Binding Updates.
For the different authentication algorithms, please refer to
"Transform Type 3 (Integrity Algorithm)" at
http://www.iana.org/assignments/ikev2-parameters.
Devarapalli, et al. Expires August 30, 2006 [Page 8]
Internet-Draft MIP6 Bootstrapping for Auth Protocol February 2006
Replay Method
This field contains the replay method to be used for subsequent
Binding Updates. For the different replay protection mechanisms,
please refer to [10].
Key Generation Nonce
A random value of at least 128 bits [12].
4.2. Key Generation Nonce Creation and Key Derivation
The section describes how the AAAH generates the Key Generation Nonce
and how the MN-HA SA is derived. The AAAH server generates a random
[12] value of 128 bits to be used as the Key Generation Nonce. The
AAAH server sends this nonce via the home agent through the Key
Generation Nonce Reply option.
The following example uses HMAC-SHA1 [5]. Other message
authentication codes or keyed hash functions MAY also be used. The
particular algorithm used is configured as part of the MN-AAA
Security Association between the MN and the AAAH server.
The AAAH server and the mobile node derive the new shared key for use
with the MN-HA SA as described below.
key = HMAC-SHA1 (MN-AAA key, {Key Generation Nonce ||
mobile node identifier))
The Key Generation Nonce is from the Key Generation Nonce Reply
option in the Binding Acknowledgement, and the mobile node identifier
is the identifier used by the mobile node in the MN Identifier option
in the Binding Update [6]. The MN-AAA key is the secret key stored
in the MN-AAA SA.
The mobile node then creates the MN-HA SA using the resulting key and
the other relevant information in the Key Generation Nonce Reply
option.
5. Mobile Node's DNS Entry Update
If the mobile node has a DNS entry that maps its FQDN to its home
address, the DNS entry becomes invalid if the mobile node bootstraps
a new home address. In order to be reachable at its new home
address, the DNS entry of the mobile node needs to be updated. This
document proposes to use the DNS update mechanism described in
section 6 of [8] to update the mobile node's FQDN with the newly
Devarapalli, et al. Expires August 30, 2006 [Page 9]
Internet-Draft MIP6 Bootstrapping for Auth Protocol February 2006
configured home address.
6. Security Considerations
The home agent is required by RFC 3775 [2] to check if a mobile node
is authorized to use a certain home address when it processes the
Binding Update from the mobile node. When the home agent allocates a
home address for a mobile node it should set up some authorization
state so that in the future it can verify if the mobile node is
allowed to a certain home address.
Security considerations regarding setting up the shared key between
the mobile node and the home agent are TBD.
7. IANA Considerations
This document defines four new mobility options, the Home Address
Request option, described in Section 3.3, the Home Address option,
described in Section 3.4, the Key Generation Nonce Request option,
described in Section 4.1.1 and the Key Generation Nonce Reply option,
described in Section 4.1.2. These four options should be allocated
from the same space used by the mobility options defined in [2].
This document also defines a new Binding Acknowledgement status code
to indicate that the home agent is unable to allocate a new home
address for the mobile node. A new Binding Acknowledgement status
code should be defined from the same space used by the Binding
Acknowledgement status codes in [2].
8. Acknowledgements
Some of the mechanisms described in this document appeared in the
early versions of [3]. Therefore we would like to thank the authors
of that document.
Most of the mechanisms described in this document are based on
solutions developed for Mobile IPv4 [10] [4]. We would like to
acknowledge the earlier work and thank the authors of respective
Mobile IPv4 documents.
9. References
Devarapalli, et al. Expires August 30, 2006 [Page 10]
Internet-Draft MIP6 Bootstrapping for Auth Protocol February 2006
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,
"Authentication Protocol for Mobile IPv6", RFC 4285,
January 2006.
[4] Perkins, C. and P. Calhoun, "Authentication, Authorization, and
Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957,
March 2005.
[5] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
9.2. Informative References
[6] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury,
"Mobile Node Identifier Option for Mobile IPv6 (MIPv6)",
RFC 4283, November 2005.
[7] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with
IKEv2 and the revised IPsec", draft-ietf-mip6-ikev2-ipsec-04
(work in progress), October 2005.
[8] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
draft-ietf-mip6-bootstrapping-split-01 (work in progress),
October 2005.
[9] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[10] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[11] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
the Integrated Scenario",
draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in
progress), October 2005.
[12] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
Devarapalli, et al. Expires August 30, 2006 [Page 11]
Internet-Draft MIP6 Bootstrapping for Auth Protocol February 2006
Authors' Addresses
Vijay Devarapalli
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
Email: vijay.devarapalli@nokia.com
Alpesh Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: alpesh@cisco.com
Kent Leung
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
Email: kleung@cisco.com
Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury, MA 01876
USA
Email: kchowdhury@starentnetworks.com
Devarapalli, et al. Expires August 30, 2006 [Page 12]
Internet-Draft MIP6 Bootstrapping for Auth Protocol February 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.
Devarapalli, et al. Expires August 30, 2006 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 02:53:54 |