INTERNET DRAFT Mohamed M. Khalil Category: Standards Track Nortel Networks Title: draft-mkhalil-mipv6-alloc-00.txt Haseeb Akhtar Date: Novemebr 2003 inCode Telecom Expires: May 2004 Secure and Dynamic Allocation of Home Address for MIPv6 draft-mkhalil-mipv6-alloc-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 30, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Static configuration of the MN's (Mobile Node) home address is a very cumbersome task and a provisioning nightmare for the Service Providers. With millions of subscribers, a typical Service Provider stands to incur considerable expenses in order to manually configure all of its MN's home address. The ability to dynamically and securely allocate MN's home address, therefore, can immensely aid in providing a cost-effective and efficient device management alternative to the Service Providers. This draft provides a simple method for dynamically allocating MN's home address in a secure manner. Khalil and Akhtar Expires April, 2004 [Page 1] Internet-Draft Secure and Dynamic Home Address for IPv6 November 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 2. Basic Operation. . . . . . . . . . . . . . . . . . . . . . 3 3. New Mobility Options . . . . . . . . . . . . . . . . . . . 3 3.1 MN-HA Authentication Option . . . . . . . . . . . . 4 3.2 Identification Option . . . . . . . . . . . . . . . 4 4. New Option for Prefix Discovery Messages . . . . . . . . . 5 5. Replay Protection Using Timestamp. . . . . . . . . . . . . 5 6. Mobile Node Operation. . . . . . . . . . . . . . . . . . . 6 7. Home Agent Operation . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Static configuration of the MN's (Mobile Node) home address is a very cumbersome task and a provisioning nightmare for the Service Providers. With millions of subscribers, a typical Service Provider stands to incur considerable expenses in order to manually configure all of its MN's home address. The ability to dynamically and securely allocate MN's home address, therefore, can immensely aid in providing a cost-effective and efficient device management alternative to the Service Providers. This draft provides a simple method for dynamically allocating MN's home address in a secure manner. The proposed method achieves this objective by adding two new mobility options in the Binding Update message. While in a foreign network, the MN MUST add these new mobility options while sending the very first Binding Update message to the HA (Home Agent). Khalil and Akhtar Expires April, 2004 [Page 2] Internet-Draft Secure and Dynamic Home Address for IPv6 November 2003 2. Basic Operation The following message flow shows the basic operation of the proposed method for dynamic and secure allocation of MN's home address. MN AR HA | | | (1)|<----Obtain a CoA---->| | | | | (2)|---------BU with new Mobility Options---------->| | (NAI=user@realm, home address option) | | | | (3)|<--------BA (with the new Mobility OPtions)-----| | home address is allocated by HA | | | | (4)|---------BU with IPSec------------------------->| | | | (5)|<--------BA wiht IPSec--------------------------| | | | (1) The MN obtains a Care-of Address using the methods described in [1]. (2) The MN now has a Care-of Address. It sends the Binding Update (BU) message to the HA with the new mobility options. Additionally, it also adds the NAI option as described in [4] so that the HA can authorize the user. (3) The HA allocates a home address to the MN or verifies the MN's home address (in the case where the MN has already been allocated a home address). The HA then returns the MN's home address in the BA (Binding Acknowledgement) message with the new mobility options. (4) The MN node now has a valid home address. It MAY initiate an IPSec session with the HA as described in [2]. (5) The HA returns the BA with the IPSec session as described in [2]. 3. New Mobility Options Two new mobility ooptions have been proposed. (a) MN-HA AUthentication option (b) Iedntification option. Khalil and Akhtar Expires April, 2004 [Page 3] Internet-Draft Secure and Dynamic Home Address for IPv6 November 2003 The following sections provide a brief description of these options. 3.1 MN-HA Authentication Option The MN-HA Authentication Option is used to authenticate MIPv6 messages Such as Binding Update and Binding Acknowledgment. The MN-HA Authentication Option should appear as the last option of the BU and BA messages. The alignment requirement is 8n + 2. The format of this option is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Authenticator | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Length A field contains the length of the authenticator in octets. SPI SPI (Security Parameter Index) is used to identify the SA (Security Association) between the MN and the HA. It is an integer between 0 (zero) and (2**32 - 1). Authenticator Authenticator field contains a cryptographic value which can be used to determine that the message has not been altered while it was in transit between the MN and HA. The authenticator is calculated as follows: Mobility Data = care-of address | HA address | Message Data Authenticator = First (96, HMAC_SHA1 (shared secret, Mobility Data)) 3.2 Identification Option The identification option is used to provide replay protection for the mobility messages. The default identification is based on the timestamp as defined in [3]. The alignment requirement is 8n + 6. The format of this option is as follows: Khalil and Akhtar Expires April, 2004 [Page 4] Internet-Draft Secure and Dynamic Home Address for IPv6 November 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TBD | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Identification 64 bits used for replay protection. 4.0 New Option for Prefix Discovery Messages MIPv6 provides a mechanism for the MN to collect prefix information from its home sub-network. This mechanism is based on using ICMP Mobile Prefix Solicitation Message and ICMP Mobile Prefix Advertisement message (also known as Prefix Discovery messages) [1]. This mechanism assumes that the authentication mechanism is provided by IPSec since the MN already has a home address [2]. If, however, the MN doesn't have a home address (that was statically configured beforehand), the alternative authentication mechanism proposed below MAY be used to acquire MN's home address. To authenticate these Prefix Discovery messages the MN-HA Authentication option MUST be included as a last option of the Prefix Discovery Messages (either Prefix Solicitation Message or Prefix Advertisement Message). The authenticator for these messages is calculated as follows: Mobility Data = care-of address | home agent address | ICMP Data Authenticator = First (96, HMAC_SHA1 (shared secret, Mobility Data)) 5.0 Replay Protection Using Timestamp The Identification field is used to let the HA verify that a Binding Update message has been generated recently by the MN, and it is not replayed by an attacker from some older registrations. The default method for this purpose is the timestamp method; some other methods may be utilized as well. Khalil and Akhtar Expires April, 2004 [Page 5] Internet-Draft Secure and Dynamic Home Address for IPv6 November 2003 If the MN uses 'timestamp' as a measure against replay protection, it SHOULD insert the current time of day. When the destination node receives the Binding Update, it will make sure that the 'timestamp' (as included by the sender) is close enough to its own time of the day. A default value of 500 milliseconds MAY be used as a reasonable offset (the time difference between the sender and the receiver). The low-order 32 bits of the identification option represents fractional seconds, the rest of the bits SHOULD be generated from a good source of randomness. For the identification field to be valid, the 'timestamp' contained in the Identification field MUST be close enough (as determined by the system implementors) and greater than the HA's time of day clock. 6.0 Mobile Node Operation MN MAY use the method proposed in this draft to acquire its home address dynamically in a secure manner. As soon as it attains the CoA (according to the procedures described in [1]), it MUST consturct a Binding Update message with the NAI option (as described in [4]), the MN-HA Authentication Option as described in section 3.1 and the Identification Option as described in section 3.2. It MUST also set the home address field of the Binding Update message to zero (0.0.0.0). Upon receiving the Binding Acknowledgment message from the HA, the MN MUST verify that the low-order 32 bits of the identification in the Identification option is identical to those sent in the Binding Update previously. It MAY then use the high-order bits of the identification in the Idenfication option for clock resynchronization. The home address returned by the HA in the home address field of the Binding Acknowledgement message will be the MN's home address for this session. 7.0 Home Agent Operation Upon receiving a Binding Update message with the NAI option [4], the HA MAY use this information to identify the user (for example, locate its record from the subcribers database). Khalil and Akhtar Expires April, 2004 [Page 6] Internet-Draft Secure and Dynamic Home Address for IPv6 November 2003 Upon receiving a Binding Update message with the MN-HA Authentication option, the HA MUST verify the authenticator value. If Authenticator is invalid, the HA MUST reject the Binding Update and SHOULD send a Binding Acknowledgment to the mobile node with status code VVV (invalid subscriber). The HA MUST then discard the Binding Update and SHOULD log the error as a security exception. If the Authenticator is propery validated, the HA MUST verify the Identification field contained in the Identification option. As mentioned in section 3.2, the default method for Identification is timestamp. The timestamp is considered to be valid if it is close enough to and greater than the HA's time of day clock. If the timestamp is valid, the HA MUST copy the entire Identification field into the Identification option of the Binding Acknowledgment message bound for the MN. If the timestamp is not valid, the HA MUST only copy the low-order 32 bits into the Binding Update message's Identification option, and supplies the high-order 32 bits from its own time of day. In the latter case, the HA MUST reject the Binding Update message and return back a status code of YYY (timestamp mismatch) in the Binding Acknowledgment message. If and when the HA receives a valid Binding Update message with the MN's home address field set to zero along with the NAI option it MUST allocate an unique IP address and process the registration procedure as stated in [1]. If and when the HA receives a valid Binding Update message with the MN's home address field set to a nonzero value along with the NAI option, it MUST verify the uniqueness of the home address. If the home address is unique, the HA MUST process the registration procedure as stated in [1]. If the home address is not unique it MUST reject the Binding Update message and MUST a return a Binding Acknowledgment message to the MN with an error status code ZZZ (home IP address not unique). References [1] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24.txt (work in progress), June 2003. [2] Arkko, J., Devarapalli, V., and F. Dupont, ""Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-06 (work in progress), June 2003. Khalil and Akhtar Expires April, 2004 [Page 7] Internet-Draft Secure and Dynamic Home Address for IPv6 November 2003 [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, January 2002. [4] Khalil, M., and H. Akhtar, "Mobile IP Network Access Identifier Extension for IPv6", draft-mkhalil-mipv6-NAI-00.txt (work in progress), October 2003. Addresses The working group can be contacted via the current chairs: Basavaraj Patil Nokia Corporation 6000 Connection Drive M/S M8-540 Irving, TX 75039 USA Phone: +1 972-894-6709 Fax : +1 972-894-5349 Email: Basavaraj.Patil@nokia.com Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone:+1 408 525 1404 E-Mail: gdommety@cisco.com Questions about this draft can be directed to the authors: Mohamed M Khalil Nortel Networks USA email: mkhalil@nortelnetworks.com Haseeb Akhtar inCode Telecom Group 9645 Scranton Road, Suite 110 San Diego, CA 92121 email:hakhtar@incodewireless.com Khalil and Akhtar Expires April, 2004 [Page 8]