MIP6 Working Group V. Devarapalli Internet-Draft Azaire Networks Intended status: Informational A. Patel Expires: September 2, 2007 K. Leung Cisco K. Chowdhury Starent March 1, 2007 Mobile IPv6 Bootstrapping for the Authentication Option Protocol draft-devarapalli-mip6-authprotocol-bootstrap-02.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 September 2, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). 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 September 2, 2007 [Page 1] Internet-Draft MIP6 Bootstrapping for Auth Protocol March 2007 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 . . . . . . . . . . . . . . 8 4.2. Key Generation Nonce Creation and Key Derivation . . . . . 9 5. Mobile Node's DNS Entry Update . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Devarapalli, et al. Expires September 2, 2007 [Page 2] Internet-Draft MIP6 Bootstrapping for Auth Protocol March 2007 1. Introduction The default mechanism for protecting Mobile IPv6 [2] signaling messages is through IKEv2 and IPsec [6]. 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 [7]. 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 [7] should be used by the mobile node to discover a home agent. A DHCPv6 based mechanism as described in [10] 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 [5]. The identity presented in the Mobile Node Identifier option is used Devarapalli, et al. Expires September 2, 2007 [Page 3] Internet-Draft MIP6 Bootstrapping for Auth Protocol March 2007 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 [8]. 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 September 2, 2007 [Page 4] Internet-Draft MIP6 Bootstrapping for Auth Protocol March 2007 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 September 2, 2007 [Page 5] Internet-Draft MIP6 Bootstrapping for Auth Protocol March 2007 4. Security Association Setup RFC 4285 [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 [11] 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 September 2, 2007 [Page 6] Internet-Draft MIP6 Bootstrapping for Auth Protocol March 2007 The following figure illustrates the security association setup mechanism. MN HA AAA Infrastructure | | | | | | |-----Binding Update------>| | | (MN-ID option) | | | (MN-AAA auth option) | | | (Key Gen Nonce req) | | | |--------AAA message------>| | | (MN-AAA auth option) | | | (Key Gen Nonce req) | | | | | |<------AAA message--------| | | (Nonce) | | | (MN-HA SA) | | | | |<----Binding Ack----------| | | (MN-HA auth option) | | | (Key Gen Nonce reply) | | | | | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Devarapalli, et al. Expires September 2, 2007 [Page 7] Internet-Draft MIP6 Bootstrapping for Auth Protocol March 2007 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. 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. Devarapalli, et al. Expires September 2, 2007 [Page 8] Internet-Draft MIP6 Bootstrapping for Auth Protocol March 2007 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. Replay Method This field contains the replay method to be used for subsequent Binding Updates. For the different replay protection mechanisms, please refer to [9]. Key Generation Nonce A random value of at least 128 bits [11]. 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 [11] 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 [12]. Other message authentication codes or keyed hash functions MAY also be used. The particular algorithm used is configured as part of the MN-AAA Devarapalli, et al. Expires September 2, 2007 [Page 9] Internet-Draft MIP6 Bootstrapping for Auth Protocol March 2007 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 [5]. 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 [7] to update the mobile node's FQDN with the newly 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, Devarapalli, et al. Expires September 2, 2007 [Page 10] Internet-Draft MIP6 Bootstrapping for Auth Protocol March 2007 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 [9] [4]. We would like to acknowledge the earlier work and thank the authors of respective Mobile IPv4 documents. 9. References 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. 9.2. Informative References [4] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005. [5] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005. [6] Dupont, F. and V. Devarapalli, "Mobile IPv6 Operation with Devarapalli, et al. Expires September 2, 2007 [Page 11] Internet-Draft MIP6 Bootstrapping for Auth Protocol March 2007 IKEv2 and the revised IPsec Architecture", draft-ietf-mip6-ikev2-ipsec-08 (work in progress), December 2006. [7] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario", draft-ietf-mip6-bootstrapping-split-04 (work in progress), December 2006. [8] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. [9] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [10] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the Integrated Scenario", draft-ietf-mip6-bootstrapping-integrated-dhc-02 (work in progress), February 2007. [11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [12] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. Authors' Addresses Vijay Devarapalli Azaire Networks 3121 Jay Street Santa Clara, CA 95054 USA Email: vijay.devarapalli@azairenet.com Alpesh Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 USA Email: alpesh@cisco.com Devarapalli, et al. Expires September 2, 2007 [Page 12] Internet-Draft MIP6 Bootstrapping for Auth Protocol March 2007 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 September 2, 2007 [Page 13] Internet-Draft MIP6 Bootstrapping for Auth Protocol March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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). Devarapalli, et al. Expires September 2, 2007 [Page 14]