Network Working Group A. Patel Internet-Draft K. Leung Expires: June 23, 2005 Cisco Systems M. Khalil H. Akhtar Nortel Networks K. Chowdhury Starent Networks December 23, 2004 Authentication Protocol for Mobile IPv6 draft-ietf-mip6-auth-protocol-02.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 June 23, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract IPsec is specified as the sole means of securing all signaling messages between the Mobile Node and Home agent for Mobile IPv6. A flexible model for security between the mobile node and home agent is required from the perspective of deployment of the Mobile IPv6 Patel, et al. Expires June 23, 2005 [Page 1] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 protocol. One instance of such deployment need comes from networks that are built on 3GPP2 standards. This document proposes an alternate method for securing the signaling messages that are responsible for performing Registration of a mobile node at a home agent. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Operational flow . . . . . . . . . . . . . . . . . . . . . . . 6 5. Mobility message authentication option . . . . . . . . . . . . 7 5.1 MN-HA authentication mobility option . . . . . . . . . . . 8 5.1.1 Processing Considerations . . . . . . . . . . . . . . 9 5.2 MN-AAA authentication mobility option . . . . . . . . . . 9 5.2.1 Processing Considerations . . . . . . . . . . . . . . 10 5.3 Authentication Failure Detection at the Mobile Node . . . 10 6. Mobility message replay protection option . . . . . . . . . . 11 6.1 Timestamp option . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 A. Rationale for message identification option . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Patel, et al. Expires June 23, 2005 [Page 2] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 1. Introduction The base Mobile IPv6 specification [RFC3775] specifies the signaling messages, Binding Update (BU) and Binding Acknowledgement (BA), between the Mobile node and Home agent to be secured by the IPsec Security Associations (IPsec SAs) that are established between these two entities. This security model for Mobile IPv6 does not fit in very well for deployment scenarios which: 1. rely on the use of a Authentication, Authorization and Accounting (AAA) infrastructure for authenticating the subscriber 2. require dynamic assignment of home agent and home addresses 3. have constraints on the number of messages involved in setting up a IPsec SAs using protocols like IKEv1 4. include mobile nodes that do not support IKEv1 The conclusion drawn thereby is the need for a solution that does not necessarily require an IPsec SA for securing the signaling messages that deal with the Registration process of a mobile node with a home agent. This document proposes a solution for securing the Binding update and Binding acknowledgment messages between the Mobile node and Home agent using an authentication option which is included in these messages. Such a mechanism enables IPv6 mobility in hosts without having to establish an IPsec SA with its home agent. A mobile node can implement Mobile IPv6 without having to integrate it with the IPsec module, in which case the Binding update and Binding Acknowldegement messages (between MN-HA) are secured with the authentication option. It should be noted that it does not imply that the availability of such a solution deprecates the use of IPsec for securing Mobile IPv6 signaling between MNs and HAs. Home agents however have to implement and support registrations from mobile nodes that are secured via IPsec as well as with the authentication option. Patel, et al. Expires June 23, 2005 [Page 3] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 2. Overview This document presents a lightweight mechanism to authenticate the mobile node at the HA or at the Authentication, Authorization and Accounting (AAA) server in Home network (AAAH) based on a shared key based security association between the mobile node and the respective authenticating entity. This shared key based security association (shared-key based SA) may be statically provisioned or dynamically created. The term "security association" referred to in this document is understood to be a "shared-key based Mobile IPv6 authentication" security association. This document introduces new mobility options to aid in authentication of the mobile node to the HA or AAAH server. The confidentiality protection of Return Routability messages and authentication/integrity protection of Mobile Prefix Discovery (MPD) is outside the scope of this document. Patel, et al. Expires June 23, 2005 [Page 4] Internet-Draft Authentication Protocol for Mobile IPv6 December 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 June 23, 2005 [Page 5] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 4. Operational flow MN HA/AAAH | BU to HA | (a) |----------------------------------------------------->| | (including MN-ID option [optional], | | Message ID option [optional], authentication option)| | | | | | HA/AAAH authenticates MN | | | | | BA to MN | (b) |<-----------------------------------------------------| | (including MN-ID option [optional], | | Message ID option [optional], authentication option)| | | Mobile Node MAY use Mobile Node Identifier Option as defined in [MN_Ident] to identify itself while authenticating with the HA. The mobile node MUST use the Mobile Node Identifier option as defined in [MN_Ident] to identify itself while authenticating with the AAA infrastructure. MN MAY use Message Identifier option as defined in Section 6 for replay protection. Patel, et al. Expires June 23, 2005 [Page 6] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 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 option 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. Only one instance of an authentication option of a particular subtype can be present in the message. One message may contain multiple instances of authentication options with different subtype values. When a Binding Update or Binding Acknowledgement is received without an authentication option and the entity receiving it is configured to use authentication option or has the shared-key based security association for authentication option, the entity should silently discard the received message. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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, Security Parameter Index (SPI) and Authentication Data fields. Subtype: Patel, et al. Expires June 23, 2005 [Page 7] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 A number assigned to identify the entity and/or mechanism to be used to authenticate the message. SPI: Security Parameter Index Authentication Data: 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 : The alignment requirement for this option is 4n + 1 octets. 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-key based security association between the mobile node and the HA. The shared-key based security association between MN and HA as per this specification consists of a SPI, a key, an authentication algorithm and the replay protection mechanism in use. The SPI is a number in range [0-4294967296], where the range [0-255] is reserved. The key consists of an arbitrary value and is 16 octets in length. The authentication algorithm is HMAC_SHA1. The replay protection mechanism may use the Sequence number as specified in [RFC3775] or the option as defined in Section 6. This must be the last option in a message with mobility header if it is the only authentication option in the message. It must occur before the MN-AAA authentication option if both options are present in the message. The authentication data is calculated on the message starting from the mobility header till (including) the SPI value of this option. Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility Data)) Mobility Data = care-of address | home address | Mobility Header(MH) Data Patel, et al. Expires June 23, 2005 [Page 8] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 MH Data is the content of the Mobility Header till (including) the SPI field of this option. The first 96 bits from the MAC result are used as the Authentication Data field. 5.1.1 Processing Considerations MN MUST include this option in a BU if it has a shared-key based security association with the HA. The HA MUST include this option in the BA if IPsec is not used and it has a shared-key based security association with the mobile node. MN or HA receiving this option MUST verify the authentication data in the option. If authentication fails, HA MUST discard the BU and send BA with Status Code MIPV6-AUTH-FAIL, if the HA has a SA with the mobile node. 5.2 MN-AAA authentication mobility option The format of the MN-AAA authentication mobility option is as defined in Section 5. This option uses the subtype value of 2. The MN-AAA authentication mobility option is used to authenticate the Binding Update message based on the shared security association between MN and AAA server in Home network (AAAH). It is not used in Binding Acknowledgement message. The corresponding Binding Acknowledgement messages must be authenticated using the MN-HA authentication option. This must be the last option in a message with mobility header. If both Mobile-Home and Mobile-AAA authentication mobility options are present, the Mobile-Home Authentication Extension MUST appear prior to the Mobile-AAA Authentication option. The corresponding response MUST include the Mobile-Home Authentication Extension, and MUST NOT include the Mobile-AAA Authentication Extension. The mobile node MAY use Mobile Node Identifier option [MN_Ident] to enable the Home Agent to make use of available AAA infrastructure. The authentication data is calculated on the message starting from the mobility header till (including) the SPI value of this option. The authentication data shall be calculated as follows: Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data) hash_fn() is decided by the value of SPI field in the authentication option. The SPI field in the MN-AAA authentication option also defines how the mobility options in BU are mapped to AAA attributes Patel, et al. Expires June 23, 2005 [Page 9] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 for authentication. SPI = HMAC_SHA1_SPI: hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is authenticated by AAA using HMAC_SHA1 authentication. MAC_Mobility Data = SHA1(care-of address | home address | MH Data) MH Data is the content of the Mobility Header till (including) the SPI field of this option. 5.2.1 Processing Considerations The MN-AAA authentication mobility option MUST be verified by the AAA infrastructure that has the shared secret with the mobile node. The HA relays the authenticating information to the home AAA. The HA relies on the home AAA to admit or reject the Binding Update from the mobile node. 5.2.1.1 Home Agent Considerations Upon receiving a BU from the mobile node, the HA MUST extract the MN-AAA authentication data and the SPI from the MN-AAA authentication mobility option and extract the Mobile Node Identifier from the Mobile Node Identifier mobility option [MN_Ident] (if present). The HA MUST include the extracted MN-AAA authentication data, SPI and the Mobile Node Identifier in AAA specific Attribute-Value Pairs (AVPs) while initiating the authentication procedure via AAA infrastructure. 5.3 Authentication Failure Detection at the Mobile Node In case of authentication failure, the HA MUST send a Binding Acknowledgement with status code MIPV6-AUTH-FAIL to the mobile node, if an SA to be used between MN and HA for authentication exists. This MAY need administrative intervention to resolve the cause of the authentication failure. Upon receiving a Binding Acknowledgement with status code MIPV6-AUTH-FAIL, the mobile node SHOULD stop sending new Binding Updates to the responding HA. Patel, et al. Expires June 23, 2005 [Page 10] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 6. Mobility message replay protection option The Mobility message replay protection option MAY be used in a Binding Update/Binding Acknowledgement messages when authenticated using the mobility authentication option as described in Section 5. The Replay Protection option is used to let the home agent verify that a Binding Update has been freshly generated by the mobile node, not replayed by an attacker from some previous Binding Update. The Replay Protection option when included is used by the mobile node for matching BA with BU. The subtype field in the identification option specifies the style of replay protection used. This document specifies timestamps as one style of replay protection, as described in Section 6.1. The Identification field in the Replay Protection option in a new Binding Update MUST not be the same as in an immediately preceding Binding Update. The style of replay protection in effect between a mobile node and the HA is part of the shared-key based mobility security association. A mobile node and the HA MUST agree on which method of replay protection will be used (even though the security association may be dynamically derived. This can be done as part of policy at the HA). If the policy at HA mandates replay protection using this option (as opposed to the sequence number in Mobility Header in Binding Update) and the Binding Update from MN does not include this option, HA discards the BU and sets the Status Code in BA to MIPV6-MESG-ID-REQD. When mobility message identification option is used along with authentication option, the mobile node SHOULD set the Sequence Number in the mobility header in Binding Update to 0 and SHOULD ignore the Sequence Number in Mobility Header in BA. Appendix A provides details regarding why message identification option MAY be used when using the authentication option. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Patel, et al. Expires June 23, 2005 [Page 11] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 Option Type: MESG-ID-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 Subtype and Identification field. Subtype: 8-bit unsigned integer indicating the style of replay protection in use. Identification: The Identification field carries Subtype specific data for replay protection. Alignment requirements : This option does not have any specific alignment requirements. 6.1 Timestamp option The format of the timestamp mobility option is as defined in Section 6. This option uses the subtype value of 1. The Identification field carries timestamp for replay protection. The basic principle of timestamp replay protection is that the node generating a message inserts the current time of day, and the node receiving the message checks that this timestamp is sufficiently close to its own time of day. Unless specified differently in the shared-key based security association between the nodes, a default value of 7 seconds MAY be used to limit the time difference. This value SHOULD be greater than 3 seconds. Obviously the two nodes must have adequately synchronized time-of-day clocks. The mobile node MUST set the Identification field to a 64-bit value formatted as specified by the Network Time Protocol [RFC1305]. The low-order 32 bits of the NTP format represent fractional seconds, and those bits which are not available from a time source SHOULD be generated from a good source of randomness. Note, however, that when using timestamps, the 64-bit Identification used in a Binding Update from the mobile node MUST be greater than that used in any previous Binding Update. Patel, et al. Expires June 23, 2005 [Page 12] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 After successful authentication of Binding Update (either locally at the HA or when a success indication is received from the AAA server), the home agent MUST check the Identification field for validity. In order to be valid, the timestamp contained in the Identification field MUST be close enough to the home agent's time of day clock and the timestamp MUST be greater than all previously accepted timestamps for the requesting mobile node. If the timestamp is valid, the home agent copies the entire Identification field into the Identification field in the BA it returns to the mobile node. If the timestamp is not valid, the home agent copies only the low-order 32 bits into the BA, and supplies the high-order 32 bits from its own time of day. If the timestamp field is not valid but the authentication of the BU succeeds, HA MUST send a Binding Acknowledgement with status code MIPV6-ID-MISMATCH. HA does not create a binding cache entry if the timestamp check fails. If the mobile node receives a Binding Acknowledgement with the code MIPV6-ID-MISMATCH, the mobile node MUST authenticate the BA by processing the MN-HA authentication mobility option. If authentication succeeds, the mobile node MUST adjust its timestamp and send subsequent Binding Update using the updated value. Upon receiving a BA that does not contain the MIPV6-ID-MISMATCH status code, the mobile node MUST compare the Identification value in the BA to the Identification value it sent in the corresponding BU. If the values match, the mobile node proceeds to process the MN-HA authentication data in the BA. If the values do not match, the MN silently discards the BA. Patel, et al. Expires June 23, 2005 [Page 13] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 7. Security Considerations This document proposes new authentication options to authenticate the control message between MN, HA and/or home AAA (as an alternative to IPsec). The new options provide for authentication of Binding Update and Binding Acknowledgement messages. The MN-AAA authentication options provides for authentication with AAA infrastructure. It can be used to generate a per session key between MN and HA for subsequent authentication of BU/BA between MN and HA via the MN-HA authentication option. This memo also introduces an optional replay protection mechanism Section 6, to prevent replay attacks. The sequence number field in the Binding Update is not used if this mechanism is used. This memo defines the timestamp option to be used for message identification. Patel, et al. Expires June 23, 2005 [Page 14] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 8. IANA Considerations IANA services are required for this document. The values for new mobility options and status codes must be assigned from the Mobile IPv6 [RFC3775] numbering space. The values for Mobility Option types AUTH-OPTION-TYPE and MESG-ID-OPTION-TYPE, as defined in Section 5 and Section 6 need to be assigned. The suggested values are 8 for the AUTH-OPTION-TYPE and 9 for the MESG-ID-OPTION-TYPE Mobility Option. The values for status codes MIPV6-ID-MISMATCH, MIPv6-AUTH-FAIL and MIPV6-MESG-ID-REQD as defined in Section 6.1, Section 6 and Section 5.3 also need to be assigned. The suggested values are 144 for MIPV6-ID-MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for MIPV6-AUTH-FAIL. IANA should record values for these new Mobility Options and the new Status Codes. A new section for enumerating algorithms identified by specific SPIs within the range 0-255 is to be added to http://www.isi.edu/in-notes/iana/assignments/mobility-parameters The currently defined values are as follows: The value 0 should not be assigned. The value 3 is suggested for HMAC_SHA1_SPI as defined in section Section 5.2. The value 5 is reserved for use by 3GPP2. In addition, IANA needs to create a new namespace for the subtype field of the MN-HA and MN-AAA authentication mobility options under http://www.isi.edu/in-notes/iana/assignments/mobility-parameters The currently allocated values are as follows: MN-HA authentication mobility option Section 5.1 [1] MN-AAA authentication mobility option Section 5.2 [2] New values for this namespace can be allocated using Standards Action [RFC2434]. Patel, et al. Expires June 23, 2005 [Page 15] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 9. Acknowledgements The authors would like to thank Basavaraj Patil, Charlie Perkins Vijay Devarapalli and Jari Arkko for their thorough review and suggestions on the document. The authors would like to acknowledge the fact that a similar authentication method was considered in base protocol [RFC3775] at one time. 10 Normative References [MN_Ident] Patel et. al., A., "MN Identifier Option for Mobile IPv6", draft-ietf-mip6-mn-ident-option-01.txt (work in progress), December 2004. [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [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 Patel, et al. Expires June 23, 2005 [Page 16] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-526-5030 EMail: kleung@cisco.com 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 Starent Networks 2540 Coolwater Dr. Plano, TX 75025 US Phone: +1 214 550 1416 EMail: kchowdury@starentnetworks.com Patel, et al. Expires June 23, 2005 [Page 17] Internet-Draft Authentication Protocol for Mobile IPv6 December 2004 Appendix A. Rationale for message identification option Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility header to prevent replay attacks. There are two aspects that stand out in regards to using the Sequence Number to prevent replay attacks. Firstly, the specification states that HA should accept a BU with a Sequence Number greater than the Sequence Number from previous Binding Update. This implicitly assumes that the HA has some information regarding the Sequence Number from previous BU (even when the binding cache entry is not present). Secondly, the specification states that if the HA has no binding cache entry for the indicated home address, it MUST accept any Sequence Number value in a received Binding Update from this mobile node. With the mechanism defined in this draft, it is possible for the MN to register with a different home agent during each mobility session. Thus, it is unreasonable to expect each HA in the network to maintain state about the mobile node. Also, if the HA does not cache information regarding sequence number, as per the second point above, a replayed BU can cause a Home Agent to create a binding cache entry for the mobile node. Thus, when authentication option is used, Sequence Number does not provide protection against replay attack. One solution to this problem (when HA does not save state information for every MN) would be for the HA to reject the first BU and assign a (randomly generated) starting sequence number for the session and force the MN to send a fresh BU with the suggested sequence number. While this would work in most cases, it would require an additional round trip and this extra signalling and latency is not acceptable in certain deployments (3GPP2). Also, this rejection and using sequence number as a nonce in rejection is a new behavior that is not specified in [RFC3775]. Thus, this specification uses the message identification option to prevent replay attacks. Specifically, timestamps are used for message identification to prevent replay attacks as described in Section 6.1. It is important to note that as per Mobile IPv6 [RFC3775] this problem with sequence number exists. Since the base specification mandates the use of IPsec (and naturally that goes with IKE in most cases), the real replay protection is provided by IPsec/IKE. In case of BU/BA between MN and CN, the liveness proof is provided by the use of nonces which the CN generates. Patel, et al. Expires June 23, 2005 [Page 18] Internet-Draft Authentication Protocol for Mobile IPv6 December 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 June 23, 2005 [Page 19]