Network Working Group A. Muhanna Internet-Draft M. Khalil Intended status: Informational Nortel Expires: April 30, 2009 A. Yegin Samsung F. Xia Huawei USA October 27, 2008 Client MIP6 Binding Revocation Using Auth Option draft-muhanna-mext-revocation-using-authoption-00.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 April 30, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document describes the use of the Authentication Protocol in protecting binding revocation signaling messages between the home agent and the mobile node. The home agent uses this mechanism to revoke a client mobile IPv6 binding cache entry that was created Muhanna, et al. Expires April 30, 2009 [Page 1] Internet-Draft Client MIP6 Revocation Using Auth Option October 2008 using Client Mobile IPv6 protocol signaling with authentication protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 3 2.1. Conventions used in this document . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protecting Binding Revocation Signaling Using Authentication Protocol . . . . . . . . . . . . . . . . . . . 4 3.1. Integrity Protection for Binding Revocation Signaling . . 4 3.2. Replay Protection for Binding Revocation Signaling . . . . 4 4. Binding Revocation Processing . . . . . . . . . . . . . . . . 5 4.1. Home Agent Operation . . . . . . . . . . . . . . . . . . . 5 4.1.1. Home Agent Sending Binding Revocation Indication . . . 5 4.1.2. Home Agent Receiving Binding Revocation Acknowledgement . . . . . . . . . . . . . . . . . . . 6 4.2. Mobile Node Operation . . . . . . . . . . . . . . . . . . 6 4.2.1. Mobile Node Receiving Binding Revocation Indication . 6 4.2.2. MN Sending Binding Revocation Acknowledgement . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Muhanna, et al. Expires April 30, 2009 [Page 2] Internet-Draft Client MIP6 Revocation Using Auth Option October 2008 1. Introduction Binding Revocation for IPv6 Mobility [BCE-Revocation] describe how Binding Revocation signaling can be used to revoke a mobile node BCE that was created using Client Mobile IPv6 Protocol [RFC3775], Proxy Mobile IPv6 protocol [RFC5213], Dual Stack MIP6 protocol [ID-DSMIP6], or according to Multi Care-of Address protocol [ID-MCoA]. In all of these protocols, IPsec is the default and main protocol that is used to protect and secure the IP Mobility header and signaling. In addition, Binding Revocation for IPv6 Mobility as in [BCE-Revocation]requires the use of IPsec to protect and secure the Binding Revocation signaling between the home agent and the mobile node. On the other hand, Authentication Protocol for Mobile IPv6 [RFC4285] defined how the authentication protocol can be used to protect and secure the Client MIP6 signaling. In some systems the Authentication Protocol as specified in [RFC4285] has been used for providing Mobile IPv6 services. In this case, if the home agent needs to revoke a mobile node BCE, the home agent must have an IPsec SA with the mobile node to protect the binding revocation signaling messages according to [BCE-Revocation]. This is quite an impossible task because the mobile node BCE was created using a security association between the mobile node and the home agent based on Authentication Protocol. In order to allow such systems to leverage the benefits of Binding Revocation mechanism when Client Mobile IPv6 signaling is protected using Authentication Protocol, there is a need to define how the binding revocation signaling messages can be secured and protected using the Authentication Protocol. This document describe how Binding Revocation signaling messages (BRI and BRA) is secured and protected using the Authentication Protocol as in [RFC4285]. This document does not provide any new security features on the top of those identified and supported in [RFC4285]. Additionally, this document does not propose any modification to the format and structure of the BRI or BRA messages as described in [BCE-Revocation]. 2. Conventions & Terminology 2.1. Conventions used in this document 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 [RFC2119]. Muhanna, et al. Expires April 30, 2009 [Page 3] Internet-Draft Client MIP6 Revocation Using Auth Option October 2008 2.2. Terminology All the general mobility related terminology and abbreviations are to be interpreted as defined in Mobile IPv6 specification [RFC3775] and Authentication Protocol for Mobile IPv6 [RFC4285]. 3. Protecting Binding Revocation Signaling Using Authentication Protocol According to [RFC4285], the mobile node and its home agent will share a valid MN-HA security association after the exchange of the initial BU and BA messages. This active MN-HA SA which is based on MN-HA Mobility Message Authentication Option as described in [RFC4285] will be used to protect and secure the Binding Revocation messages between the home agent and the mobile node as described in this document. The following two subsections describe how the Authentication Protocol is used to provide integrity protection and replay protection to the BRI and BRA exchange using MN-HA Authentication and timestamp options. 3.1. Integrity Protection for Binding Revocation Signaling In order to provide an integrity protection to the BRI, the home agent MUST use the MN-HA SA that was used to protect the latest BU/BA messages between the mobile node and the home agent to build the MN-HA Mobility Message Authentication Option . The MN-HA Mobility Message Authentication Option MUST be the last mobility option in the BRI message in order to provide integrity protection to all of the BRI message content. The home agent MUST include MN-HA Mobility Message Authentication Option with the MN-HA SPI that index the MN-HA SA the mobile node and the home agent share to secure the Client Mobile IPv6 signaling of the current active binding cache entry. Similarly, when the mobile node send a BRA message, the mobile node MUST protect the BRA message using the MN-HA Mobility Message Authentication Option as the last mobility option in the BRA message. Additionally, If the timestamp option as described in [RFC4285] is included in the BRI or BRA message, the MN-HA Mobility Message Authentication Option must protect the Mobility Message Replay Protection Option too. 3.2. Replay Protection for Binding Revocation Signaling In order to protect the BRI and BRA messages against replay attack the home agent and the mobile node MUST include its current timestamp in the Mobility Message Replay Protection Option as described in Muhanna, et al. Expires April 30, 2009 [Page 4] Internet-Draft Client MIP6 Revocation Using Auth Option October 2008 [RFC4285]. The receiving node will use the included timestamp to make sure that the message has been sent not later than the allowed time interval. 4. Binding Revocation Processing The full details of the use of the Binding Revocation protocol is defined in [BCE-Revocation]. This document only specifies how to protect the BRI and BRA messages between the home agent and the mobile node using Authentication Protocol. If the Mobile Node Identifier Option for Mobile IPv6 as in [RFC4283] was used in the exchange of the Client MIP6 BU and BA signaling, the home agent MUST include this option in the BRI message sent to the mobile node. This option MUST be protected by the MN-HA Mobility Message Authentication Option. 4.1. Home Agent Operation 4.1.1. Home Agent Sending Binding Revocation Indication When an event requires the home agent to terminate a mobile node mobile IPv6 registration, e.g. for administrative reason, the home agent sends a Binding Revocation Indication message to the mobile node to inform the mobile node that its specified binding has been revoked and it will no longer be able to receive an IP connectivity via its binding with the home agent. To terminate a mobile node registration and its current binding with the home agent, the home agent sends a packet to the mobile node containing a Binding Revocation Indication, with the packet constructed as described in [BCE-Revocation] and this specification. The home agent MUST protect the BRI message using the Authentication Protocol as follows: o The home agent MUST include the Mobility Message Replay Protection Option in the BRI message after setting the timestamp field of this option to its current timestamp as specified in [RFC4285]. o The packet MUST contain a Home Address destination option, which contains the mobile node's registered home address for the binding being revoked. o The care-of address for the binding SHOULD be used as the Source Address in the packet's IPv6 header. Additionally, the home agent MUST include the mobile node current Care-of Address in the Alternate Care-of Address mobility option and then include the Muhanna, et al. Expires April 30, 2009 [Page 5] Internet-Draft Client MIP6 Revocation Using Auth Option October 2008 option in the Binding Revocation Indication. o The home Agent MUST construct the MN-HA Mobility Message Authentication Option using the currently active MN-HA SA as defined in [RFC4285] and ensure that this option is the last mobility option in the BRI message. 4.1.2. Home Agent Receiving Binding Revocation Acknowledgement When the home agent receives a packet carrying a BRA for an outstanding BRI message that belongs to a Mobile node that is secure using Authentication Protocol, the home SHOULD examine the BRA as follows: o The home agent MUST validate the authentication data of the MN-HA Mobility Message Authentication Option using the MN-HA SA that is indexed using the MN-HA SPI as defined in [RFC4285]. o If the validation of the MN-HA Mobility Message Authentication Option is successful, the home agent MUST validate the timestamp in the Mobility Message Replay Protection Option before accepting the BRA as a valid message. o If the validation of the MN-HA Mobility Message Authentication Option is NOT successful, the home agent MUST discard the BRA message and MAY log an event. 4.2. Mobile Node Operation 4.2.1. Mobile Node Receiving Binding Revocation Indication Upon receiving a packet carrying a Binding Revocation Indication that include the MN-HA Mobility Message Authentication Option, the mobile node MUST identify the MN-HA SA that it shares with the home agent and then validate the authentication data as in [RFC4285]. If the MN-HA Mobility Message Authentication Option validation is successful, the mobile node MUST validate the timestamp in the Mobility Message Replay Protection Option. If the MN-HA Mobility Message Authentication Option validation is successful, the mobile node MUST ensure that the Alternate Care-of Address option and the home destination option are included in the BRI and protected by the MN-HA Mobility Message Authentication Option. Muhanna, et al. Expires April 30, 2009 [Page 6] Internet-Draft Client MIP6 Revocation Using Auth Option October 2008 If the MN-HA Mobility Message Authentication Option validation is successful and the Alternate Care-of Address option is not included in the BRI message, the MN MUST send a BRA message with status code, Session Unknown. If the MN-HA Mobility Message Authentication Option validation is successful and the Home Destination Option is not included in the BRI message, the MN MUST send a BRA message with a status code, Session Unknown. If the MN-HA Mobility Message Authentication Option validation failed, the mobile node MUST discard the BRI message. 4.2.2. MN Sending Binding Revocation Acknowledgement When the mobile node receive a BRI message which successfully validated and the mobile node has an active BCE for the specified binding, the mobile node MUST send a BRA message with a status code 'SUCCESS' following [BCE-Revocation] and this specification. The mobile node MUST protect the BRA message using the Authentication Protocol as follows: o The mobile node MUST include the Mobility Message Replay Protection Option in the BRI message after setting the timestamp field of this option to its current timestamp as specified in [RFC4285]. o The home Agent MUST construct the MN-HA Mobility Message Authentication Option using the currently active MN-HA SA as defined in [RFC4285] and ensure that this option is the last mobility option in the BRI message. 5. IANA Considerations This document does not have any IANA requirements. 6. Security Considerations This document uses the same security mechanism as defined in the Authentication Protocol for Mobile IPv6 in [RFC4285]. However, this document require that the care-of address and the home address which have been assigned to the mobile node during the Client MIP6 registration MUST be included in the BRI message and protected by the MN-HA Mobility Message Authentication Option. Muhanna, et al. Expires April 30, 2009 [Page 7] Internet-Draft Client MIP6 Revocation Using Auth Option October 2008 7. Acknowledgements The author would like to thank the folks involved in the discussion on the MEXT mailing list on the topic of protecting Binding Revocation Messages using authentication protocol. 8. References 8.1. Normative References [BCE-Revocation] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", draft-ietf-mext-binding-revocation-01 (work in progress), August 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005. [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006. 8.2. Informative References [ID-DSMIP6] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and Routers", draft-ietf-mext-nemo-v4traversal-04 (work in progress), June 2008. [ID-MCoA] Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-08 (work in progress), May 2008. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. Muhanna, et al. Expires April 30, 2009 [Page 8] Internet-Draft Client MIP6 Revocation Using Auth Option October 2008 Authors' Addresses Ahmad Muhanna Nortel 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: amuhanna@nortel.com Mohamed Khalil Nortel 2221 Lakeside Blvd. Richardson, TX 75082 USA Email: mkhalil@nortel.com Alper E. Yegin Samsung Istanbul, Turkey Email: a.yegin@partner.samsung.com Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 USA Email: xiayangsong@huawei.com Muhanna, et al. Expires April 30, 2009 [Page 9] Internet-Draft Client MIP6 Revocation Using Auth Option October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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). Muhanna, et al. Expires April 30, 2009 [Page 10]