Mobile IP Working Group Alpesh Patel INTERNET DRAFT Kent Leung February 2004 Cisco System Inc. Haseeb Akhtar Mohamed Khalil Kuntal Chowdhury Nortel Networks Authentication Protocol for Mobile IPv6 draft-patel-mipv6-auth-protocol-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. Abstract This document defines new mobility options to enable authentication between mobility entities. These options can be used in addition to or in lieu of IPsec to authenticate mobility messages as defined in [1]. Expires 13 July, 2004 [Page 1] Internet Draft Authentication Protocol for MIPv6 14 February 2004 Table of Contents 1. Motivation......................................................2 2. Overview........................................................3 3. Terminology.....................................................3 3.1 General Terms..................................................3 4. Operational flow................................................4 5. Mobility message authentication option..........................4 6. Mobility message identification option..........................6 6.1 Processing considerations......................................7 6.1.1 Home Agent Considerations....................................7 6.1.2 Mobile Node Considerations...................................7 7. Encrypted Home KeyGen Token Option..............................7 7.1 Processing Considerations......................................9 7.1.1 Home Agent Considerations....................................9 7.1.2 Mobile Node Considerations..................................10 8. IANA Considerations............................................10 10. Intellectual Property Rights..................................10 11. Acknowledgements..............................................11 12. References....................................................11 13. Contact Information...........................................11 Full Copyright Statement..........................................12 1. Motivation The base specification of Mobile IPv6 [1] mandates IPsec support between MN and HA for authentication. Also, return routability messages passing via the HA (HoT/HoTi) and mobile prefix discovery messages must be protected using IPsec. While IPsec (ESP) may offer strong protection (depending on the algorithms used), use of IPsec may not be required/feasible in all cases where Mobile IPv6 may be used. For small handheld devices, the use of IPsec may be too taxing on battery and processor performance. Also depending on the model of home agent deployment (HA deployed by enterprise/service provider), MN may have to VPN back into the enterprise (which may impose dual IPsec requirement on MN). Also, having an authentication mechanism tied to the Mobile’s IP address does not permit the mobility entity to derive a dynamic address based on the configured prefix. If the MN’s address is dynamically configured based on a fixed prefix, IPsec will most likely not work as the IPsec SA’s are tied to the address. The mechanism described in this draft is not tied with mobility entity’s IP address and so does not mandate SA relationship with an IP address. Expires 13 July 2004 [Page 2] Internet Draft Authentication Protocol for MIPv6 14 February 2004 2. Overview This document presents a lightweight mechanism to authenticate the MN and HA based on a shared security association between MN and HA. As per the specification in the current MIPv6 draft [1], the return routability messages are protected by IPsec between MN and HA. Specifically, the Home KeyGen token sent by the CN to the MN (via) HA needs to be protected to secure the messages from an eves-dropper on the path between MN and HA. The extensions in this draft encrypts the Home KeyGen token from the HA to MN (based on the same MN/HA shared secret as used to authenticate the BU/BA messages). Thus, the integrity of the HoT message is preserved. This document introduces new mobility options to aid in authentication of the MN and to protect the integrity of return routability messages. 3. 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 RFC 2119 [2]. 3.1 General Terms MN Mobile Node HA Home Agent SA Security Association CN Correspondent Node IPsec IP Security protocol ESP Encapsulating security protocol BU Binding Update BA Binding Acknowledgement HoT Home Test Message (part of Return Routability test) SPI Security Parameter Index MH Mobility Header Expires 13 July 2004 [Page 3] Internet Draft Authentication Protocol for MIPv6 14 February 2004 4. Operational flow MN HA | BU to HA | (a) |---------------------------------------------------->| | (HoA option, NAI[optional], ID option, auth option) | | | | HA authenticates MN and | allocates Home Address | | | BA to MN | (b) |<----------------------------------------------------| | (HoA option, NAI[optional], ID option, auth option) | | | | | MN may use NAI option as defined in [5] to identify itself to the HA or some authentication infrastructure. 5. Mobility message authentication option This section defines the message authentication mobility option that may be used to secure Binding Update and Binding Acknowledgement messages. This extension can be used along with IPsec or preferably as an alternate mechanism to authenticate binding update and binding acknowledgement messages in absence of IPsec. This document also defines subtype numbers, which identify the mode of authentication and the peer entity to authenticate the message. One subtype number is specified in this document. It is expected that other subtypes will be defined by other documents in the future. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subtype | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | Authenticator . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type AUTH-OPTION-TYPE to be defined by IANA. An 8-bit identifier of the type mobility option. Expires 13 July 2004 [Page 4] Internet Draft Authentication Protocol for MIPv6 14 February 2004 Option Length 8-bit unsigned integer, representing the length in octets of the sub-type, SPI and authenticator, not including the Option Type and Option Length fields. Subtype A number assigned to identify the entity and/or mechanism to be used to authenticate the message. SPI Used to identify the particular security association to use to authenticate the message. Authenticator This field has the information to authenticate the relevant mobility entity. This protects the message beginning at the Mobility Header upto and including the SPI field. Alignment requirements 5.1 MN-HA authentication mobility option The format of the MN-HA authentication mobility option is as defined in section 5. This option uses the subtype value of 1. The MN-HA authentication mobility option is used to authenticate the binding update and binding acknowledgement messages based on the shared security association between MN and HA. Note that the security association may actually be between MN and the home domain but used by HA for authentication purpose. This must be the last option in a message with mobility header. The authenticator is calculated on the message starting from the mobility header till the SPI value of this option. Authenticator = First (96,HMAC_SHA1(MN-HA Shared key, Mobility Data)) Mobility Data = care-of address | home address | MH Data “MH Data” is the content of the Mobility Header till the SPI field of this extension. Expires 13 July 2004 [Page 5] Internet Draft Authentication Protocol for MIPv6 14 February 2004 The first 96 bits from the MAC result are used as the Authenticator field. 6. Mobility message identification option The identification option is used to prevent replay protection. The Identification field carries either timestamps or nonces for replay protection (support for timestamps is mandatory). This option can be used in binding update and binding acknowledgement messages. The default method for this purpose is the timestamp method; some other methods may be utilized as well. 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 implementers) and greater than the HA's time of day clock. The style of replay protection in effect between a mobile node and its home agent is part of the mobile security association. A mobile node and its home agent MUST agree on which method of replay protection will be used. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type IDENT-OPTION-TYPE to be defined by IANA. An 8-bit identifier of the type mobility option. Expires 13 July 2004 [Page 6] Internet Draft Authentication Protocol for MIPv6 14 February 2004 Option Length 8-bit unsigned integer, representing the length in octets of the Identification field. Identification The Identification field carries either timestamps or nonces for replay protection (support for timestamps is mandatory). Alignment requirements 6.1 Processing considerations 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. 6.1.1 Home Agent Considerations Timestamps: After successful authentication of Binding Update, the Home Agent must verify that the Identification field falls within the replay protection window. If Identification field is not within this window, HA MUST send a Binding Acknowledgement with error code MIPV6-ID- MISMATCH. In this case, HA must include the correct identification field in the Binding Acknowledgement message. Nonces: 6.1.2 Mobile Node Considerations Timestamps: If MN receives a Binding Acknowledgement with the code MIPV6-ID-MISMATCH, MN must adjust its timestamp and send subsequent Binding Update using the updated value. Nonces: 7. Encrypted Home KeyGen Token Option This option is inserted by the HA in the HoT message if MN and HA are using the authentication option defined in this document. If IPsec is used as per [1], this processing does not apply. Expires 13 July 2004 [Page 7] Internet Draft Authentication Protocol for MIPv6 14 February 2004 HA must use the Home KeyGen token from the HoT message and encrypt it as described below. The encrypted token is included in the HoT message. HA must set the Home KeyGen token in the HoT message to zero. Encrypting the Home KeyGen token provides similar level of security as provided by using IPsec for protecting the HoT messages. Encrypting the Home KeyGen token is as per password encryption as defined in [4], section 3.5. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Salt | String . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type KEYGEN-OPTION-TYPE to be defined by IANA. An 8-bit identifier of the type mobility option. Option Length 8-bit unsigned integer, representing the length in octets of the reserved, salt and String fields, not including the Option Type and Option Length fields. SPI The SPI corresponds to the SPI of the security associations between MN and HA. It is used to associate the right shared key to decrypt the Home KeyGen token. Salt The Salt field is two octets in length and is used to ensure the uniqueness of the encryption key used to encrypt each instance of the Home KeyGen Token option occurring in a given HoT message. The contents of each Salt field in a given HoT message MUST be unique. String The plaintext String field consists of three logical sub-fields: the Data-Length and token sub-fields (both of which are required), and the optional Padding sub-field. The Data-Length Expires 13 July 2004 [Page 8] Internet Draft Authentication Protocol for MIPv6 14 February 2004 sub-field is one octet in length and contains the length of the unencrypted token sub-field. The token sub-field contains the actual Home KeyGen token. If the combined length (in octets) of the unencrypted Data-Length and token sub-fields is not an even multiple of 16, then the Padding sub-field MUST be present. If it is present, the length of the Padding sub-field is variable, between 1 and 15 octets. The String field MUST be encrypted as follows, prior to transmission: Construct a plaintext version of the String field by concatenating the Data-Length and Token sub-fields. If necessary, pad the resulting string until its length (in octets) is an even multiple of 16. It is recommended that zero octets (0x00) be used for padding. Call this plaintext P. Call the shared secret (between MN and HA) S, the home init cookie (from the HoT message) R, and the contents of the Salt field A. Break P into 16 octet chunks p(1), p(2)...p(i), where i = len(P)/16. Call the ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. Intermediate values b(1), b(2)...c(i) are required. Encryption is performed in the following manner ('+' indicates concatenation): b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) . . . . . . b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + (i) The resulting encrypted String field will contain c(1)+c(2)+...+c(i). On receipt, the process is reversed to yield the plaintext String. Alignment requirements 7.1 Processing Considerations 7.1.1 Home Agent Considerations Home Agent must intercept the HoT message and if IPsec is not in use between MN and HA as described in [1] (for authentication/encryption of control messages), MUST encrypt the Home KeyGen token as described in section 7. Expires 13 July 2004 [Page 9] Internet Draft Authentication Protocol for MIPv6 14 February 2004 7.1.2 Mobile Node Considerations When MN receives a HoT message, if IPsec is not in use between MN and HA, MN must reverse the process as described in section 8 to retrieve the Home KeyGen token. 8. IANA Considerations The option types AUTH-OPTION-TYPE, IDENT-OPTION-TYPE and KEYGEN- OPTION-TYPE as defined in section 5, 6 and 7 respectively are new mobility options. IANA should record a value for these new mobility options. 9. Security Considerations This document proposes a new authentication option to authenticate the control message between MN and HA (as an alternative to IPsec). The new option provides for authentication of Binding Update and Binding Acknowledgement messages. It does not provide for encrypting these messages. In terms of protecting the return routability messages, this mechanism provides to encrypt the Home KeyGen token from CN to MN on the path between HA and MN. 10. Intellectual Property Rights The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights, which may cover technology that may be Expires 13 July 2004 [Page 10] Internet Draft Authentication Protocol for MIPv6 14 February 2004 required to practice this standard. Please address the information to the IETF Executive Director. 11. Acknowledgements 12. References [1] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), June 2003. [2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. [3] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [4] Zorn, et al., RADIUS Tunnel Authentication Attributes, RFC 2868, June 2000 13. Contact Information Questions and comments about this draft should be directed at the Mobile IPv6 working group: mip6@ietf.org Questions and comments about this draft may also be directed to the authors: Alpesh Patel Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134 USA Email: alpesh@cisco.com Phone: +1 408-853-9580 Kent Leung Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134 USA Expires 13 July 2004 [Page 11] Internet Draft Authentication Protocol for MIPv6 14 February 2004 Email: kleung@cisco.com Phone: +1 408-526-5030 Mohamed Khalil Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: mkhalil@nortelnetworks.com Phone: +1 972-685-0574 Haseeb Akhtar Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: haseebak@nortelnetworks.com Phone: +1 972-684-4732 Kuntal Chowdury Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: chowdury@nortelnetworks.com Phone: +1 972-685-7788 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Expires 13 July 2004 [Page 12] Internet Draft Authentication Protocol for MIPv6 14 February 2004 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Expires 13 July 2004 [Page 13]