idnits 2.17.1 draft-patil-mext-sec-negotiate-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2011) is 4554 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental draft: draft-ietf-mext-mip6-tls (ref. 'I-D.ietf-mext-mip6-tls') ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Downref: Normative reference to an Informational RFC: RFC 4285 Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Submission B. Faria, Ed. 3 Internet-Draft Nokia Institute of Technology 4 Intended status: Standards Track B. Patil 5 Expires: May 3, 2012 G. Bajko 6 Nokia 7 October 31, 2011 9 Negotiation of security protocol for Mobile IPv6 operation 10 draft-patil-mext-sec-negotiate-03 12 Abstract 14 Mobile IPv6 has relied on IPsec and IKEv2 for securing the signaling 15 and user traffic. A single security mechanism for Mobile IPv6 does 16 not adequately address various deployment scenarios. The one-size- 17 fits-all security approach is ill suited for Mobile IPv6, as 18 different deployments have different security requirements. Multiple 19 alternatives to securing signaling and user traffic have been 20 proposed and are being considered for standardization. When multiple 21 security protocols coexist for providing security for mobile IPv6 22 nodes, there is a need to negotiate the choice of security protocol 23 between a mobile node and home agent a priori. This document 24 proposes a method for negotiating the security protocol to be used 25 between mobile IPv6 nodes. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 3, 2012. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Using the Home agent controller . . . . . . . . . . . . . . . . 4 66 5. Negotiation of security protocol . . . . . . . . . . . . . . . 5 67 5.1. Security Negotiation of Authentication Protocol for 68 MIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 71 8. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 8 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1. Introduction 79 Mobile IPv6 has relied on IPsec and IKEv2 for securing the signaling 80 and user traffic. A single security mechanism for Mobile IPv6 does 81 not adequately address various deployment scenarios. The one-size- 82 fits-all security approach is ill suited for Mobile IPv6, as 83 different deployments need different security requirements. Multiple 84 alternatives to securing signaling and user traffic have been 85 proposed and are being considered for standardization. When multiple 86 security protocols coexist for providing security for mobile IPv6 87 nodes, there is a need to negotiate the choice of security protocol 88 between a mobile node and home agent a priori. This document 89 proposes a method for negotiating the security protocol to be used 90 between mobile IPv6 nodes based on the home agent controller (HAC) 91 entity defined in [I-D.ietf-mext-mip6-tls]. 93 Mobile IPv6 [RFC3775] security using IPsec and IKE is specified in 94 [RFC3776] and [RFC4877]. A number of alternate security protocols 95 for use by mobile IPv6 nodes have been proposed. Authentication 96 protocol for Mobile IPv6 [RFC4285] is an example of one such. The 97 use of such a mechanism is however restricted to networks with 98 certain characteristics that are documented in the RFC. 100 More recently, other security mechanisms for use in Mobile IPv6 101 deployments have been proposed. Transport Layer Security-based 102 Mobile IPv6 Security Framework for Mobile Node to Home Agent 103 Communication [I-D.ietf-mext-mip6-tls] proposes a security solution 104 that uses TLS between the mobile node (MN) and a home agent 105 controller (HAC) to bootstrap Mobile IPv6 and the security protocol 106 parameters between the MN and home agent (HA). Authorizing Mobile 107 IPv6 Binding Update with Cryptographically Generated Addresses 108 [I-D.laganier-mext-cga] proposes the use of CGA for securing the 109 signaling between an MN and HA. 111 2. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2.1. Terminology 119 The terminology used in this I-D is based on the Mobile IPv6 120 terminology defined in [RFC3775]. 122 Home Agent Controller (HAC) 124 The home agent controller is a node responsible for bootstrapping 125 Mobile IPv6 security associations between a mobile node and one or 126 more home agents. The home agent controller also provides key 127 distribution to both mobile nodes and home agents. Optionally, 128 Mobile IPv6 bootstrapping can be done in addition to the security 129 association bootstrapping between the mobile node and home agent 130 controller. 132 3. Problem Statement 134 Security for Mobile IPv6 signaling and user traffic can be achieved 135 via the use of different mechanisms. At the present time the use of 136 IPsec and IKEv2 is mandated and choice of any other security protocol 137 does not exist. However the use of IPsec and IKE for providing 138 security does not fit all deployments. Alternate security solutions 139 have been proposed and could be used. The use of a security protocol 140 by mobile IPv6 nodes should be driven by the needs and requirements 141 of a specific deployment. An enterprise deployment of Mobile IPv6 142 will have a different set of security requirements as compared to a 143 cellular operator offering mobile IPv6 service. 145 When Mobile IPv6 hosts have the option of choosing from multiple 146 security protocols, there is a need to negotiate the use of a 147 specific protocol between a mobile node and home agent prior to 148 operation. This problem is dealt with in the scope of this draft and 149 solutions proposed. 151 4. Using the Home agent controller 153 The home agent controller (HAC) is an entity that is defined in 154 [I-D.ietf-mext-mip6-tls]. The HAC provides the MN with bootstrapping 155 information of Mobile IPv6 such as assigned HA address, Home Network 156 Prefix and MN IPv6 and/or IPv4 HoA. In addition, it assigns security 157 parameters information to constitute the MN-HA security association. 158 The HAC can generate IPSec SA information such as keys and SPI and 159 provide it to the MN through the secure TLS secure connection without 160 the use of IKEv2 for this purpose. The security association 161 information is distributed by the HAC to the HA assigned to be used 162 by the MN. 164 In the proposed solution, the HAC is the central entity which plays 165 the role of negotiating the security protocol to be used between a 166 mobile node and the home agent. The HAC is aware of the capabilities 167 and security protocols of various home agents that it is associated 168 with. An MN MUST contact the HAC to obtain the home agent and home 169 address to use. The MN can also inform the HAC about the security 170 protocols that it supports and can use for securing signaling and 171 user traffic. Based on the security protocols the MN informed, the 172 HAC will then assign the MN a valid home agent in addition to 173 informing it of the security protocol to be used. Optionally, if the 174 communication between the MN and the HA is to be protected by IPSec, 175 the HAC may provide the MN and the assigned HA the relevant security 176 parameters such as keys, SPI, ciphers etc. that constitutes an IPsec 177 SA. The MN may be configured with the address of HACs or 178 alternatively it may discover a HAC via DNS. This is dealt with in 179 the [I-D.ietf-mext-mip6-tls] document. 181 5. Negotiation of security protocol 183 The mobile node establishes a TLS connection with the home agent 184 controller (HAC) and exchanges a set of messages via this secure TLS 185 tunnel to bootstrap mobile IPv6 as well as negotiate the choice of 186 security protocol. The security protocol information is exchanged 187 using the Request-Response messaging within the TLS secure tunnel. 188 The signaling flow diagram below illustrates this negotiation 189 mechanism: 191 MN HAC HA AAA 192 | | | | 193 |<===TLS connection====>|(1) | | 194 | | | | 195 |-Indicate capability-->|(2) | | 196 | | | | 197 | |<--Obtain profile, security-------->|(3) 198 |<--Security protocol---|(4) | | 199 | |--MN_ID, Sec----->|(5) | 200 | | | | 201 |<------Establish SA --------------------->|(6) | 202 | | | | 203 |<--------BU/BAck------------------------->| | 204 | | | | 205 | | | | 207 Figure 1: Negotiation of security protocol for use between MN and HA 209 1. The MN establishes a TLS connection with the HAC and 210 authenticates itself. Authentication details are described in 211 [I-D.ietf-mext-mip6-tls]. All subsequent messaging between the 212 MN and HAC is within the secure TLS connection. 214 2. The MN signals the security protocols that it supports including 215 ciphersuite and capabilities. 217 3. The HAC obtains the MNs profile and allowed security methods for 218 the MN from the AAA server. The Home agent to be assigned to the 219 MN is also informed by the AAA. The HAC chooses the security 220 protocol to be used based on the capabilities of the MN as well 221 as policy information from the AAA. 223 4. The HAC indicates the security protocol to be used by the MN. It 224 also provides the MN with the security parameters such as 225 encryption and integrity keys, SPI, and ciphers to be used for 226 establishing the SA with the allocated HA. 228 5. The HAC also indicates to the assigned HA information about the 229 MN and selected security protocol. Additionally security 230 parameters required for establishing the SA are delivered to the 231 HA. 233 6. The MN establishes the security association of the type indicated 234 by the HAC. This could be an IPsec SA, or it could be the use of 235 the SA defined in [I-D.ietf-mext-mip6-tls], the use of CGA or the 236 use of Mobility Security Association as defined in [RFC4285]. 238 7. The MN performs registration with the HA. The BU/BAck are 239 secured using the security protocol that has been chosen. 241 5.1. Security Negotiation of Authentication Protocol for MIPv6 243 This section describes the use of the proposed security negotiation 244 protocol to negotiate the use of Authentication Protocol for MIPv6 as 245 specified in [RFC4285]. That method can be applicable in network 246 deployments where the home agent and home address is dynamically 247 assigned to the mobile node and the security association is created 248 via an out-of-band mechanism. That information is distribuited by 249 the home agent controller via the TLS session established with the 250 mobile node. The HAC fetches the security parameters that forms a 251 mobility based security association from the AAA server and 252 distribuite them to the mobile node and assigned home agent like 253 security keys. 255 The mobile node establishes a TLS connection with the home agent 256 controller and exchange a set of messages via this secure TLS tunnel 257 to bootstrap mobile IPv6. The MN indicates the Authentication 258 Protocol for MIPv6 as a supported security protocol. The diagram 259 below illustrates the negotiation of Authentication Protocol for 260 MIPv6 as the security protocol to be used: 262 MN HAC HA AAA 263 | | | | 264 |<===TLS connection====>|(1) | | 265 | | | | 266 |---Indicate RFC4285--->|(2) | | 267 | as security protocol | | | 268 | |<--Obtain profile, security-------->|(3) 269 |<---Set RFC4285 as --->|(4) | | 270 | security protocol | | | 271 | |--MN_ID, Sec----->|(5) | 272 | | | | 273 |<------Establish SA --------------------->|(6) | 274 | | | | 275 |<--------BU/BAck------------------------->| | 276 | | | | 277 | | | | 279 Figure 2: Negotiation of Authentication Protocol for MIPv6 as the 280 security protocol for use between MN and HA 282 1. The MN establishes a TLS session with the HAC and authenticates 283 itself as described in [I-D.ietf-mext-mip6-tls]. All subsequent 284 messaging between the MN and HAC is within the secure TLS 285 connection 287 2. The MN indicates that it wants to use the Authentication Protocol 288 for MIPv6 as the security protocol. It should also inform its 289 capabilities based on the type of access network and the security 290 services that it provides. 292 3. The HAC obtains the MNs profile along with its allowed security 293 methods from the AAA server. The Home Agent to be assigned to 294 the MN is also informed by the AAA. Based on the MN capabilities 295 and policy information from the AAA, the HAC chooses the RFC4285 296 as the security protocol to be used. 298 4. The HAC indicates the security protocol to be used by the MN. 299 The HAC also provides the information that composes a mobility 300 security association between the MN and the HA like mobility SPI, 301 keys, authentication algorithm and replay protection mechanism. 303 5. The HAC provides the assigned HA with information about the 304 Authentication Protocol for MIPv6. It also provides security 305 parameters required for establishing the mobility security 306 association. 308 6. The MN and HA establish the mobility security association just 309 provided by the HAC. 311 7. The MN performs registration with the HA including the MN-HA 312 mobility message authentication option with in the BU message. 314 6. IANA Considerations 316 This document does not have any IANA requests at the present time. 318 7. Security Considerations 320 The signaling between the mobile node and home agent controller is 321 secured by TLS. All the messages between the MN and HAC are tunneled 322 within the TLS connection and hence secured. The MN and Home agent 323 (HA) are either colocated or have a secure messaging interface 324 between them. There exists the potential to downgrade the choice of 325 the security protocol between an MN and HA. However the HAC chooses 326 the security protocol to be used based on the capabilities of the MN 327 as well as policy information from an entity such as AAA. In case 328 the MN is incapable of more robust secure mechanisms, the HAC may 329 assign such a home agent with limited capabilities and connectivity. 331 8. Summary and Conclusion 333 The choice of security protocols to be used in mobile IPv6 334 deployments increases the flexibility of the protocol and makes it 335 viable for use in different deployment scenarios. This however does 336 result in the need for negotiation of a security protocol to be used 337 between the MN and HA. The capabilities of the MN and home agents 338 available for use to an MN determine the security protocol that can 339 be used. Use of a home agent controller provides Mobile IPv6 with a 340 robust mechanism for bootstrapping as well negotiation the security 341 protocol. 343 9. References 345 9.1. Normative References 347 [I-D.ietf-mext-mip6-tls] 348 Korhonen, J., Patil, B., Tschofenig, H., and D. 350 Kroeselberg, "Transport Layer Security-based Mobile IPv6 351 Security Framework for Mobile Node to Home Agent 352 Communication", draft-ietf-mext-mip6-tls-02 (work in 353 progress), October 2011. 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, March 1997. 358 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 359 in IPv6", RFC 3775, June 2004. 361 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 362 Protect Mobile IPv6 Signaling Between Mobile Nodes and 363 Home Agents", RFC 3776, June 2004. 365 [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 366 Chowdhury, "Authentication Protocol for Mobile IPv6", 367 RFC 4285, January 2006. 369 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 370 IKEv2 and the Revised IPsec Architecture", RFC 4877, 371 April 2007. 373 9.2. Informative References 375 [I-D.laganier-mext-cga] 376 Laganier, J., "Authorizing Mobile IPv6 Binding Update with 377 Cryptographically Generated Addresses", 378 draft-laganier-mext-cga-01 (work in progress), 379 October 2010. 381 Authors' Addresses 383 Bruno Faria (editor) 384 Nokia Institute of Technology 385 Av. Torquato Tapajos, 7200 - Km. 12 - Col Terra Nova 386 Manaus, AM 69048-660 387 BRAZIL 389 Email: bruno.faria@indt.org.br 390 Basavaraj Patil 391 Nokia 392 6021 Connection drive 393 Irving, TX 75039 394 USA 396 Email: basavaraj.patil@nokia.com 398 Gabor Bajko 399 Nokia 400 323 Fairchild drive 6 401 Mountain view, CA 94043 402 USA 404 Email: gabor.bajko@nokia.com