Individual Submission B. Faria, Ed. Internet-Draft Nokia Institute of Technology Intended status: Standards Track B. Patil Expires: May 3, 2012 G. Bajko Nokia October 31, 2011 Negotiation of security protocol for Mobile IPv6 operation draft-patil-mext-sec-negotiate-03 Abstract Mobile IPv6 has relied on IPsec and IKEv2 for securing the signaling and user traffic. A single security mechanism for Mobile IPv6 does not adequately address various deployment scenarios. The one-size- fits-all security approach is ill suited for Mobile IPv6, as different deployments have different security requirements. Multiple alternatives to securing signaling and user traffic have been proposed and are being considered for standardization. When multiple security protocols coexist for providing security for mobile IPv6 nodes, there is a need to negotiate the choice of security protocol between a mobile node and home agent a priori. This document proposes a method for negotiating the security protocol to be used between mobile IPv6 nodes. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on May 3, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Faria, et al. Expires May 3, 2012 [Page 1] Internet-Draft Security protocol negotiation October 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 4. Using the Home agent controller . . . . . . . . . . . . . . . . 4 5. Negotiation of security protocol . . . . . . . . . . . . . . . 5 5.1. Security Negotiation of Authentication Protocol for MIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 8. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Faria, et al. Expires May 3, 2012 [Page 2] Internet-Draft Security protocol negotiation October 2011 1. Introduction Mobile IPv6 has relied on IPsec and IKEv2 for securing the signaling and user traffic. A single security mechanism for Mobile IPv6 does not adequately address various deployment scenarios. The one-size- fits-all security approach is ill suited for Mobile IPv6, as different deployments need different security requirements. Multiple alternatives to securing signaling and user traffic have been proposed and are being considered for standardization. When multiple security protocols coexist for providing security for mobile IPv6 nodes, there is a need to negotiate the choice of security protocol between a mobile node and home agent a priori. This document proposes a method for negotiating the security protocol to be used between mobile IPv6 nodes based on the home agent controller (HAC) entity defined in [I-D.ietf-mext-mip6-tls]. Mobile IPv6 [RFC3775] security using IPsec and IKE is specified in [RFC3776] and [RFC4877]. A number of alternate security protocols for use by mobile IPv6 nodes have been proposed. Authentication protocol for Mobile IPv6 [RFC4285] is an example of one such. The use of such a mechanism is however restricted to networks with certain characteristics that are documented in the RFC. More recently, other security mechanisms for use in Mobile IPv6 deployments have been proposed. Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Node to Home Agent Communication [I-D.ietf-mext-mip6-tls] proposes a security solution that uses TLS between the mobile node (MN) and a home agent controller (HAC) to bootstrap Mobile IPv6 and the security protocol parameters between the MN and home agent (HA). Authorizing Mobile IPv6 Binding Update with Cryptographically Generated Addresses [I-D.laganier-mext-cga] proposes the use of CGA for securing the signaling between an MN and HA. 2. Requirements Language 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]. 2.1. Terminology The terminology used in this I-D is based on the Mobile IPv6 terminology defined in [RFC3775]. Faria, et al. Expires May 3, 2012 [Page 3] Internet-Draft Security protocol negotiation October 2011 Home Agent Controller (HAC) The home agent controller is a node responsible for bootstrapping Mobile IPv6 security associations between a mobile node and one or more home agents. The home agent controller also provides key distribution to both mobile nodes and home agents. Optionally, Mobile IPv6 bootstrapping can be done in addition to the security association bootstrapping between the mobile node and home agent controller. 3. Problem Statement Security for Mobile IPv6 signaling and user traffic can be achieved via the use of different mechanisms. At the present time the use of IPsec and IKEv2 is mandated and choice of any other security protocol does not exist. However the use of IPsec and IKE for providing security does not fit all deployments. Alternate security solutions have been proposed and could be used. The use of a security protocol by mobile IPv6 nodes should be driven by the needs and requirements of a specific deployment. An enterprise deployment of Mobile IPv6 will have a different set of security requirements as compared to a cellular operator offering mobile IPv6 service. When Mobile IPv6 hosts have the option of choosing from multiple security protocols, there is a need to negotiate the use of a specific protocol between a mobile node and home agent prior to operation. This problem is dealt with in the scope of this draft and solutions proposed. 4. Using the Home agent controller The home agent controller (HAC) is an entity that is defined in [I-D.ietf-mext-mip6-tls]. The HAC provides the MN with bootstrapping information of Mobile IPv6 such as assigned HA address, Home Network Prefix and MN IPv6 and/or IPv4 HoA. In addition, it assigns security parameters information to constitute the MN-HA security association. The HAC can generate IPSec SA information such as keys and SPI and provide it to the MN through the secure TLS secure connection without the use of IKEv2 for this purpose. The security association information is distributed by the HAC to the HA assigned to be used by the MN. In the proposed solution, the HAC is the central entity which plays the role of negotiating the security protocol to be used between a mobile node and the home agent. The HAC is aware of the capabilities and security protocols of various home agents that it is associated Faria, et al. Expires May 3, 2012 [Page 4] Internet-Draft Security protocol negotiation October 2011 with. An MN MUST contact the HAC to obtain the home agent and home address to use. The MN can also inform the HAC about the security protocols that it supports and can use for securing signaling and user traffic. Based on the security protocols the MN informed, the HAC will then assign the MN a valid home agent in addition to informing it of the security protocol to be used. Optionally, if the communication between the MN and the HA is to be protected by IPSec, the HAC may provide the MN and the assigned HA the relevant security parameters such as keys, SPI, ciphers etc. that constitutes an IPsec SA. The MN may be configured with the address of HACs or alternatively it may discover a HAC via DNS. This is dealt with in the [I-D.ietf-mext-mip6-tls] document. 5. Negotiation of security protocol The mobile node establishes a TLS connection with the home agent controller (HAC) and exchanges a set of messages via this secure TLS tunnel to bootstrap mobile IPv6 as well as negotiate the choice of security protocol. The security protocol information is exchanged using the Request-Response messaging within the TLS secure tunnel. The signaling flow diagram below illustrates this negotiation mechanism: MN HAC HA AAA | | | | |<===TLS connection====>|(1) | | | | | | |-Indicate capability-->|(2) | | | | | | | |<--Obtain profile, security-------->|(3) |<--Security protocol---|(4) | | | |--MN_ID, Sec----->|(5) | | | | | |<------Establish SA --------------------->|(6) | | | | | |<--------BU/BAck------------------------->| | | | | | | | | | Figure 1: Negotiation of security protocol for use between MN and HA 1. The MN establishes a TLS connection with the HAC and authenticates itself. Authentication details are described in [I-D.ietf-mext-mip6-tls]. All subsequent messaging between the Faria, et al. Expires May 3, 2012 [Page 5] Internet-Draft Security protocol negotiation October 2011 MN and HAC is within the secure TLS connection. 2. The MN signals the security protocols that it supports including ciphersuite and capabilities. 3. The HAC obtains the MNs profile and allowed security methods for the MN from the AAA server. The Home agent to be assigned to the MN is also informed by the AAA. The HAC chooses the security protocol to be used based on the capabilities of the MN as well as policy information from the AAA. 4. The HAC indicates the security protocol to be used by the MN. It also provides the MN with the security parameters such as encryption and integrity keys, SPI, and ciphers to be used for establishing the SA with the allocated HA. 5. The HAC also indicates to the assigned HA information about the MN and selected security protocol. Additionally security parameters required for establishing the SA are delivered to the HA. 6. The MN establishes the security association of the type indicated by the HAC. This could be an IPsec SA, or it could be the use of the SA defined in [I-D.ietf-mext-mip6-tls], the use of CGA or the use of Mobility Security Association as defined in [RFC4285]. 7. The MN performs registration with the HA. The BU/BAck are secured using the security protocol that has been chosen. 5.1. Security Negotiation of Authentication Protocol for MIPv6 This section describes the use of the proposed security negotiation protocol to negotiate the use of Authentication Protocol for MIPv6 as specified in [RFC4285]. That method can be applicable in network deployments where the home agent and home address is dynamically assigned to the mobile node and the security association is created via an out-of-band mechanism. That information is distribuited by the home agent controller via the TLS session established with the mobile node. The HAC fetches the security parameters that forms a mobility based security association from the AAA server and distribuite them to the mobile node and assigned home agent like security keys. The mobile node establishes a TLS connection with the home agent controller and exchange a set of messages via this secure TLS tunnel to bootstrap mobile IPv6. The MN indicates the Authentication Protocol for MIPv6 as a supported security protocol. The diagram below illustrates the negotiation of Authentication Protocol for Faria, et al. Expires May 3, 2012 [Page 6] Internet-Draft Security protocol negotiation October 2011 MIPv6 as the security protocol to be used: MN HAC HA AAA | | | | |<===TLS connection====>|(1) | | | | | | |---Indicate RFC4285--->|(2) | | | as security protocol | | | | |<--Obtain profile, security-------->|(3) |<---Set RFC4285 as --->|(4) | | | security protocol | | | | |--MN_ID, Sec----->|(5) | | | | | |<------Establish SA --------------------->|(6) | | | | | |<--------BU/BAck------------------------->| | | | | | | | | | Figure 2: Negotiation of Authentication Protocol for MIPv6 as the security protocol for use between MN and HA 1. The MN establishes a TLS session with the HAC and authenticates itself as described in [I-D.ietf-mext-mip6-tls]. All subsequent messaging between the MN and HAC is within the secure TLS connection 2. The MN indicates that it wants to use the Authentication Protocol for MIPv6 as the security protocol. It should also inform its capabilities based on the type of access network and the security services that it provides. 3. The HAC obtains the MNs profile along with its allowed security methods from the AAA server. The Home Agent to be assigned to the MN is also informed by the AAA. Based on the MN capabilities and policy information from the AAA, the HAC chooses the RFC4285 as the security protocol to be used. 4. The HAC indicates the security protocol to be used by the MN. The HAC also provides the information that composes a mobility security association between the MN and the HA like mobility SPI, keys, authentication algorithm and replay protection mechanism. 5. The HAC provides the assigned HA with information about the Authentication Protocol for MIPv6. It also provides security Faria, et al. Expires May 3, 2012 [Page 7] Internet-Draft Security protocol negotiation October 2011 parameters required for establishing the mobility security association. 6. The MN and HA establish the mobility security association just provided by the HAC. 7. The MN performs registration with the HA including the MN-HA mobility message authentication option with in the BU message. 6. IANA Considerations This document does not have any IANA requests at the present time. 7. Security Considerations The signaling between the mobile node and home agent controller is secured by TLS. All the messages between the MN and HAC are tunneled within the TLS connection and hence secured. The MN and Home agent (HA) are either colocated or have a secure messaging interface between them. There exists the potential to downgrade the choice of the security protocol between an MN and HA. However the HAC chooses the security protocol to be used based on the capabilities of the MN as well as policy information from an entity such as AAA. In case the MN is incapable of more robust secure mechanisms, the HAC may assign such a home agent with limited capabilities and connectivity. 8. Summary and Conclusion The choice of security protocols to be used in mobile IPv6 deployments increases the flexibility of the protocol and makes it viable for use in different deployment scenarios. This however does result in the need for negotiation of a security protocol to be used between the MN and HA. The capabilities of the MN and home agents available for use to an MN determine the security protocol that can be used. Use of a home agent controller provides Mobile IPv6 with a robust mechanism for bootstrapping as well negotiation the security protocol. 9. References 9.1. Normative References [I-D.ietf-mext-mip6-tls] Korhonen, J., Patil, B., Tschofenig, H., and D. Faria, et al. Expires May 3, 2012 [Page 8] Internet-Draft Security protocol negotiation October 2011 Kroeselberg, "Transport Layer Security-based Mobile IPv6 Security Framework for Mobile Node to Home Agent Communication", draft-ietf-mext-mip6-tls-02 (work in progress), October 2011. [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. [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006. [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. 9.2. Informative References [I-D.laganier-mext-cga] Laganier, J., "Authorizing Mobile IPv6 Binding Update with Cryptographically Generated Addresses", draft-laganier-mext-cga-01 (work in progress), October 2010. Authors' Addresses Bruno Faria (editor) Nokia Institute of Technology Av. Torquato Tapajos, 7200 - Km. 12 - Col Terra Nova Manaus, AM 69048-660 BRAZIL Email: bruno.faria@indt.org.br Faria, et al. Expires May 3, 2012 [Page 9] Internet-Draft Security protocol negotiation October 2011 Basavaraj Patil Nokia 6021 Connection drive Irving, TX 75039 USA Email: basavaraj.patil@nokia.com Gabor Bajko Nokia 323 Fairchild drive 6 Mountain view, CA 94043 USA Email: gabor.bajko@nokia.com Faria, et al. Expires May 3, 2012 [Page 10]