Network Working Group A. Patel Internet-Draft K. Leung Expires: December 31, 2004 Cisco Systems M. Khalil H. Akhtar K. Chowdhury Nortel Networks July 2, 2004 Authentication Protocol for Mobile IPv6 draft-ietf-mip6-auth-protocol-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 December 31, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. 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 the base Mobile IPv6 specification. Patel, et al. Expires December 31, 2004 [Page 1] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 Table of Contents 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. General Terms . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Operational flow . . . . . . . . . . . . . . . . . . . . . . . 7 6. Mobility message authentication option . . . . . . . . . . . . 8 6.1 MN-HA authentication mobility option . . . . . . . . . . . 9 6.2 MN-AAA authentication mobility option . . . . . . . . . . 9 6.2.1 Processing considerations . . . . . . . . . . . . . . 10 7. Mobility message identification option . . . . . . . . . . . . 11 7.1 Processing considerations . . . . . . . . . . . . . . . . 12 7.1.1 Home Agent Considerations . . . . . . . . . . . . . . 12 7.1.2 Mobile Node Considerations . . . . . . . . . . . . . . 12 7.1.3 AAA server Considerations . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 11. Normative References . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 18 Patel, et al. Expires December 31, 2004 [Page 2] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 1. Motivation The base specification of Mobile IPv6 [RFC3775] 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). Moreover, IPsec/IKE based Mobile IPv6 over public wireless carrier's networks may pose serious capacity and scalability challenge. The multiple round trips to perform ISAKMP/IKE to establish IPsec SA may be too taxing on the wireless link, not to mention increase in setup latency during initial access and during handoffs. The use of manual IPsec SA in these large public network deployments suffer from scalability issue and involve provisioning nightmare. Also, having an authentication mechanism tied to the Mobile's home IP address does not permit the mobility entity to derive or acquire a dynamic home address based on the configured prefix. If the MN's home address is dynamically configured based on a fixed prefix or acquired during network access authentication (PPP, 802.1x etc.), IPsec will most likely not work as the IPsec SAs are tied to the address. The mechanism described in this draft is not tied with mobility entities home IP address and therefore does not mandate SA relationship with an IP address. Another important motivation for this proposed mechanism is to allow the MN to register with a Home Agent on a dynamically discovered Home Link. This sort of Dynamic Home Link assignments will allow the operators to leverage the true benefit of dynamic Home Agent assignment. For example the operator may assign a Home Link or Home Agent for the user that is closest to the subnet of attachment of the user. There may be various other reasons for opportunistic Home Agent assignment. The mechanisms described in the draft allows the MN to register with any Home Agent in the home network as long as the MN user shares security association with an entity in the home network such as a AAA server. Patel, et al. Expires December 31, 2004 [Page 3] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 2. Overview This document presents a lightweight mechanism to authenticate the MN at the HA or at the Home AAA based on a shared security association between the MN and the respective authenticating entity. This document introduces new mobility options to aid in authentication of the MN to the HA or AAA server. The confidentiality protection of the Mobile Prefix Discovery (MPD) and Return Routability (Home KeyGen token) messages is outside the scope of this document. Patel, et al. Expires December 31, 2004 [Page 4] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 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. Patel, et al. Expires December 31, 2004 [Page 5] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 4. General Terms MN Mobile Node HA Home Agent SA Security Association IPsec IP Security protocol ESP Encapsulating security protocol BU Binding Update BA Binding Acknowledgement SPI Security Parameter Index MH Mobility Header HAAA Home Authentication Authorization Accounting server CHAP CHallenge Authentication Protocol HoA Home Address AVP Attribute Value Pair AAA Authentication Authorization Accounting NAI Network Address Identifier Patel, et al. Expires December 31, 2004 [Page 6] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 5. Operational flow MN HA/HAAA | BU to HA | (a) |---------------------------------------------------->| | (HoA option, NAI[optional], ID option, auth option) | | | | HA/HAAA authenticates MN | | | | | BA to MN | (b) |<----------------------------------------------------| | (HoA option, NAI[optional], ID option, auth option) | | | | | MN may use NAI option as defined in [NAI] to identify itself to the HA while authenticating with the HA. The MN SHOULD use NAI option [NAI] while authenticating with the AAA infrastructure. Patel, et al. Expires December 31, 2004 [Page 7] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 6. 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. Two subtype numbers are 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. 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 Patel, et al. Expires December 31, 2004 [Page 8] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 Mobility Header upto and including the SPI field. Alignment requirements : MUST be aligned on an 8-octet boundary. 6.1 MN-HA authentication mobility option The format of the MN-HA authentication mobility option is as defined in section 6. 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 the MN and the HA. 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. The first 96 bits from the MAC result are used as the Authenticator field. 6.2 MN-AAA authentication mobility option The format of the MN-AAA authentication mobility option is as defined in section 6. This option uses the subtype value of 2. The MN-AAA authentication mobility option is used to authenticate the binding update and binding acknowledgement messages based on the shared security association between MN and HAAA. 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. The MN SHOULD use NAI option [NAI] to enable the Home Agent to make use of available AAA infrastructure which requires NAI. The MN MUST use either CHAP_SPI or HMAC_CHAP_SPI as defined in [3012bis] to indicate CHAP style authentication. The authenticator shall be calculated as follows: Patel, et al. Expires December 31, 2004 [Page 9] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 Authenticator = First (96, HMAC_SHA1 (MN-AAA Shared key, MAC_Mobility Data))). SPI = CHAP_SPI: MAC_Mobility Data = MD5 (care-of address | home address | MH Data). SPI = HMAC_CHAP_SPI: MAC_Mobility Data = HMAC_MD5 (care-of address | home address | MH Data). 6.2.1 Processing considerations The MN-AAA authentication mobility option MUST be verified by the AAA infrastructure that has the shared secret with the MN. The HA relays the authenticating information to the HAAA. The HA relies on the HAAA to admit or reject the home registration request from the MN. 6.2.1.1 Home Agent Considerations Upon receiving a BU from the MN the HA SHALL extract the MN-AAA authenticator and the SPI from the MN-AAA authentication mobility option and extract the NAI from the NAI option [NAI]. The HA SHALL include the extracted MN-AAA authenticator, SPI and the NAI in AAA specific AVPs while initiating the authentication procedure via AAA infrastructure. Patel, et al. Expires December 31, 2004 [Page 10] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 7. Mobility message identification option The identification option is used to prevent replay protection. The Identification field carries timestamp for replay protection. 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 and/or HAAA's time of day clock. The style of replay protection in effect between a mobile node and the HA and/or the HAAA is part of the mobile security association. A mobile node and the HA and/or the HAAA 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. Option Length: Patel, et al. Expires December 31, 2004 [Page 11] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 8-bit unsigned integer, representing the length in octets of the Identification field. Identification: The Identification field carries timestamp for replay protection. Alignment requirements : MUST be aligned on an 8-octet boundary. 7.1 Processing considerations The Identification field is used to let the HA and/or the HAAA 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. 7.1.1 Home Agent Considerations The HA processes this option only when MN-HA authentication mobility option is used in the BU. In this case: 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 but the authentication of the BU succeeds, HA MUST send a Binding Acknowledgement with error code "TBD by IANA" MIPV6-ID-MISMATCH. In this case, HA must include the correct identification field in the Binding Acknowledgement message. MN-HA Timestamp: If timestamp based replay check is successful and the authentication succeeds, the HA MUST include the received Identification value in the corresponding field of the Mobility message identification option in the BA. 7.1.2 Mobile Node Considerations The MN MUST process the Mobility message identification option. MN-HA Timestamp and MN-AAA Timestamp: The MN MUST set the Identification value in the Mobility message identification option in the BU message according to its own clock. If the 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. Patel, et al. Expires December 31, 2004 [Page 12] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 7.1.3 AAA server Considerations The HAAA processes this option only when MN-AAA authentication mobility option is used in the BU. In this case: After successful authentication of MN's credentials contained in the AVPs, the Home AAA server MUST verify that the Identification field falls within the replay protection window. If Identification field is not within this window, HAAA MUST reject the authentication and authorization request. Upon receiving the reject message from HAAA server, the HA MUST send a Binding Acknowledgement with error code "TBD by IANA" MIPV6-ID-MISMATCH. In this case, HA must include the correct identification field in the Mobility message identification option in the Binding Acknowledgement message. MN-AAA Timestamp: If timestamp based replay check is successful and the authentication and authorization succeeds, the HAAA does not include any updated Identification value in the accept message. In this case, the HA copies the Identification value from the BU into the corresponding field in the BA. If the replay check fails but authentication succeeds, in the reject message the HAAA MUST include the latest timestamp according to it's own clock. Patel, et al. Expires December 31, 2004 [Page 13] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 8. Security Considerations This document proposes new authentication options to authenticate the control message between MN, HA and/or HAAA (as an alternative to IPsec). The new options provide for authentication of Binding Update and Binding Acknowledgement messages Patel, et al. Expires December 31, 2004 [Page 14] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 9. IANA Considerations The option types AUTH-OPTION-TYPE, IDENT-OPTION-TYPE, as defined in section 6 and 7 respectively are new mobility options. The MIPV6-ID-MISMATCH error code also needs to be defined. IANA should record values for these new mobility options and the new error code. Patel, et al. Expires December 31, 2004 [Page 15] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 10. Acknowledgements TBD. 11 Normative References [3012bis] Perkins et. al., C., "Mobile IPv4 Challenge/Response Extensions (revised)", draft-ietf-mip4-rfc3012bis-01 (work in progress), April 2004. [NAI] Patel et. al., A., "Network Access Identifier Option for Mobile IPv6", draft-ietf-mipv6-nai-option-00.txt (work in progress), February 2004. [RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Authors' Addresses Alpesh Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-853-9580 EMail: alpesh@cisco.com Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-526-5030 EMail: kleung@cisco.com Patel, et al. Expires December 31, 2004 [Page 16] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 Mohamed Khalil Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US Phone: +1 972-685-0574 EMail: mkhalil@nortelnetworks.com Haseeb Akhtar Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US Phone: +1 972-684-4732 EMail: haseebak@nortelnetworks.com Kuntal Chowdhury Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US Phone: +1 972 685 7788 EMail: chowdury@nortelnetworks.com Patel, et al. Expires December 31, 2004 [Page 17] Internet-Draft Authentication Protocol for Mobile IPv6 July 2004 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 (2004). 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. Patel, et al. Expires December 31, 2004 [Page 18]