idnits 2.17.00 (12 Aug 2021) /tmp/idnits19910/draft-patil-mext-mip6issueswithipsec-04.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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 1762 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 11, 2011) is 3868 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-altman-tls-channel-bindings has been published as RFC 5929 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 3268 (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobility Extensions (MEXT) B. Patil 3 Internet-Draft Nokia 4 Intended status: Experimental C. Perkins 5 Expires: April 13, 2012 Tellabs 6 H. Tschofenig 7 Nokia Siemens Networks 8 D. Premec 9 Unaffiliated 10 October 11, 2011 12 Problems with the use of IPsec as the security protocol for Mobile IPv6 13 draft-patil-mext-mip6issueswithipsec-04.txt 15 Abstract 17 Mobile IPv6 as specified in RFC3775 relies on IPsec for securing the 18 signaling messages and user plane traffic between the mobile node and 19 home agent. An IPsec SA between the mobile node and the home agent 20 provides security for the mobility signaling. Use of IPsec for 21 securing the data traffic between the mobile node and home agent is 22 optional. This document analyses the implications of the design 23 decision to mandate IPsec as the default security protocol for Mobile 24 IPv6 and consequently Dual-stack Mobile IPv6 and recommends 25 revisiting this decision in view of the experience gained from 26 implementation and adoption in other standards bodies. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 13, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 64 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Problem statement . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 5 67 4.2. General issues with the use of IPsec for MIP6 security . . 7 68 4.3. Security Association Management . . . . . . . . . . . . . 9 69 4.4. Bootstrapping of Additional Mobile IPv6 Parameters . . . . 11 70 4.5. Protecting Traffic Between Mobile Node and Home Agent . . 12 71 5. Mobile Node to Home Agent Controller Communication . . . . . . 12 72 5.1. Request-response Message Framing over TLS-tunnel . . . . . 12 73 5.2. Request-response Message Content Encoding . . . . . . . . 13 74 5.3. Request-Response Message Exchange . . . . . . . . . . . . 13 75 5.4. Home Agent Controller Discovery . . . . . . . . . . . . . 14 76 5.5. Generic Request-Response Parameters . . . . . . . . . . . 14 77 5.5.1. Mobile Node Identifier . . . . . . . . . . . . . . . . 14 78 5.5.2. Authentication Method . . . . . . . . . . . . . . . . 15 79 5.5.3. Extensible Authentication Protocol Payload . . . . . . 15 80 5.5.4. Status Code . . . . . . . . . . . . . . . . . . . . . 15 81 5.5.5. Message Authenticator . . . . . . . . . . . . . . . . 15 82 5.5.6. Retry After . . . . . . . . . . . . . . . . . . . . . 16 83 5.5.7. End of Message Content . . . . . . . . . . . . . . . . 16 84 5.5.8. Random Values . . . . . . . . . . . . . . . . . . . . 16 85 5.6. Security Association Configuration Parameters . . . . . . 16 86 5.6.1. Security Parameter Index . . . . . . . . . . . . . . . 16 87 5.6.2. MN-HA Shared Keys . . . . . . . . . . . . . . . . . . 17 88 5.6.3. Security Association Validity Time . . . . . . . . . . 17 89 5.6.4. Security association scope (SAS) . . . . . . . . . . . 17 90 5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping . . 18 91 5.7. Mobile IPv6 Bootstrapping Parameters . . . . . . . . . . . 19 92 5.7.1. Home Agent Address . . . . . . . . . . . . . . . . . . 19 93 5.7.2. Home Addresses and Home Network Prefix . . . . . . . . 19 94 5.8. Authentication of the Mobile Node . . . . . . . . . . . . 19 95 5.9. Extensible Authentication Protocol Methods . . . . . . . . 22 96 6. Mobile Node to Home Agent communication . . . . . . . . . . . 23 97 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 23 98 6.2. Security Parameter Index . . . . . . . . . . . . . . . . . 24 99 6.3. Binding Management Message Formats . . . . . . . . . . . . 25 100 6.4. Reverse Tunneled User Data Packet Formats . . . . . . . . 26 101 7. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 27 102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 103 8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 27 104 8.2. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . 28 105 8.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 28 106 8.4. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 28 107 9. Security Considerations . . . . . . . . . . . . . . . . . . . 28 108 9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 29 109 9.2. Authentication and Key Exchange executed between the 110 MN and the HAC . . . . . . . . . . . . . . . . . . . . . . 29 111 9.3. Protection of MN and HA Communication . . . . . . . . . . 31 112 9.4. AAA Interworking . . . . . . . . . . . . . . . . . . . . . 33 113 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 114 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 115 11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 116 11.2. Informative References . . . . . . . . . . . . . . . . . . 34 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 119 1. Introduction 121 Mobile IPv6 as specified in [RFC3775] requires an IPsec security 122 association between the mobile node (MN) and home agent (HA). The 123 IPsec SA protects the mobility signaling messages between the MN and 124 HA. The user data may be optionally protected by the IPsec SA but is 125 not required. The use of IPsec by most hosts today is primarily as a 126 solution for enterprise connectivity through VPN applications. IPsec 127 has not evolved into a generic security protocol. 129 The use of IPsec and IKE (v1 and v2) with Mobile IPv6 are specified 130 in RFCs 3776 [RFC3776] and 4877 [RFC4877]. The Mobile IP and MIP6 131 working groups in the IETF chose to mandate IPsec as the default 132 security protocol for Mobile IPv6 based on various criteria and 133 lengthy discussions that occured between the years 2000 and 2004. 134 Implementation experience with Mobile IPv6 and the security variants 135 with which it has been specified in some SDOs indicates a need to 136 revisit the design choice for MIP6 signaling security. The analysis 137 and recommendation to revisit the security protocol architecture for 138 MIP6 should not be interpreted as a recommendation for Authentication 139 Protocol for Mobile IPv6 [RFC4285]. The objective is to highlight 140 the misfit of IPsec and IKEv2 as the security protocol for MIP6 and 141 hence the need for considering alternatives. A simpler security 142 architecture for securing the signaling and traffic between the MN 143 and HA can co-exist with the IPsec based solution as well. 145 The objective of Mobile IPv6 [RFC3775] is to enable IP mobility for 146 IPv6 hosts. The security aspect of the protocol is a critical 147 component for consideration in terms of deployment and operation on 148 large scales. If complexity of implementation were a consideration 149 then the current specification dealing with Mobile IPv6, i.e RFC3775 150 [RFC3775] and RFC5555 [RFC5555] would win high accolades. An 151 implementer spends 20% of his time on implementing the Mobile IPv6 152 protocol and 80% of the time integrating it with IPsec and IKEv2. 153 And even after that interoperability of the client with home agents 154 is not guaranteed. The IPsec/IKEv2 security architecture may work in 155 implementations wherein the OS, the IPsec/IKEv2 stack and mobile ipv6 156 client software are all implemented by a single entity. It just does 157 not work on open systems. 159 2. Terminology and Abbreviations 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 This document refers to [RFC3775][RFC4877] for terminology. 167 3. Background 169 IP mobility support in IPv6 was considered to be an integral feature 170 of the IPv6 stack based on the experience gained from developing 171 mobility support for IPv4. The design of Mobile IPv6 was worked on 172 by the Mobile IP WG in the late 90s and by the MIP6 WG until its 173 publication as [RFC3775] in 2004. 175 IPsec [RFC4301] was also intended to be a default component of the 176 IPv6 stack and was the preferred protocol choice for use by any other 177 IPv6 protocol that needed security. Rather than design security into 178 every protocol feature, the intent was to reuse a well-defined 179 security protocol to meet the security needs. Hence Mobile IPv6 has 180 been designed with a security architecture that relies on reusing 181 IPsec. 183 The Mobile IPv6 specification [RFC3775] was published along with the 184 companion specification "Using IPsec to Protect Mobile IPv6 Signaling 185 Between Mobile Nodes and Home Agents", [RFC3776]. The establishment 186 of the IPsec SA between the MN and HA as per RFC 3776 is based on the 187 use of IKE. The use of IKE in the context of Mobile IPv6 for IPsec 188 SA establishment did not gain traction because of factors such as 189 complexity of IKE and the IETF transitioning to IKEv2. The MIP6 WG 190 completed the specification, Mobile IPv6 Operation with IKEv2 and the 191 Revised IPsec Architecture [RFC4877] in April 2007. This [RFC4877] 192 is considered as the default security protocol solution for MIP6 and 193 updates [RFC3776]. 195 4. Problem statement 197 4.1. Problem Statement 199 Mobile IPv6 is encumbered by its reliance on IPsec [RFC4301] from an 200 implementation and deployment perspective. As a protocol solution 201 for host based mobility, MIP6 can be simpler without the IPsec 202 baggage. The issues with IPsec are even more exacerbated in the case 203 of dual-stack MIP6 [RFC5555]. 205 IPsec SAs between the MN and HA are established either manually or 206 via the use of IKEv2 [RFC4306]. Manual SA configuration is not a 207 scalable solution and hence MIP6 hosts and Home agents rely on IKEv2 208 for establishing dynamically IPsec SAs. As a result MIP6 depends on 209 the existence of IPsec and IKEv2 for successful operation. 211 IPsec is unable to provide security protection for MIP6 in a 212 transparent way, and numerous interactions between the host's 213 security subsystems and the MIP6 application are needed in the course 214 of the regular operation of the MIP6 application. Besides requiring 215 an extensive communications channel between the security subsystems 216 and the MIP6 application, those interactions often also require 217 modification of the MNs security subsystems code. The situation 218 today is such that the communications channel between the IPsec 219 subsystems and the MIP6 application is non existent and this is 220 generally true for most of the commercially available platforms. 221 Even if such a channel were to be available, there does not exist a 222 standardized protocol over that channel which would enable the MIP6 223 application to communicate with the security modules in a non- 224 implementation specific way. 226 Considering a third party application developer who would like to 227 provide a MIP6 application for a particular platform, the need for 228 numerous interactions with the IPsec subsystem and the unavailability 229 of the standardized communications channel through which such 230 interactions could take place is a major obstacle to the 231 implementation of the mobility protocol. Without such a 232 communication channel being available it is not possible to implement 233 a MIP6 application as a third party developer. 235 Even if the platform would provide such a communication interface for 236 the MIP6 daemon, this is still insufficient as the MIP6 protocol 237 standardized today [RFC3775] requires numerous changes to the host's 238 IPsec and IKEv2 implementation. This document enumerates various 239 implementation issues related to the interactions between the MIP6 240 application and the host's security subsystems. 242 An argument can be made that the MIP6 application itself should 243 provide the required changes to the IPsec subsystems of the platform 244 (maybe in the form of patches). While this is possible at least for 245 some open source platforms to provide modifications to the host's 246 IPsec implementation as well as the key management application(s), 247 this is still an issue for several reasons: 249 Target platform could be a commercial platform for which no source 250 code for the security modules (IPsec and IKEv2) is available. 251 If the MIP6 application were to patch the IPsec subsystems, then 252 multiple MIP6 applications from different developers would 253 implement it in different ways, which would inevitably lead to 254 variations and problems with interoperability at a minimum, for 255 instance when the user tries to install several MIP6 applications 256 it is difficult to determine which one is the best suited for his/ 257 her needs. 258 Key management daemons are usually provided as third party 259 software for which no source code may be available, even if the 260 platform itself is available as open source. 262 Even if the MIP6 application developer would be willing to provide 263 patches for the key management daemon to make it work with his 264 MIP6 application, how would the MIP6 application developer know 265 which of the several available key management daemons the user is 266 running? 267 Each application would be able to work only with a single key 268 management daemon, namely the one for which the MIP6 application 269 provides the patches. The user may be running another key 270 management daemon and may be unwilling to change its daemon to the 271 one that comes as part of the MIP6 application. 272 Patches for the IPsec part in the kernel and the key management 273 daemon would typically be valid only for the particular version of 274 the kernel and the key management daemon for which they were 275 written. This might prevent the user from upgrading the platform 276 or applying OS security patches that are provided as part of the 277 regular platform maintenance since this would in all probability 278 make the MIP6 application defunct. 279 Modifying the security subsystems by a third party is a security 280 issue and users are generally advised to refrain from allowing the 281 security subsystems to be modified in any way. 282 he developer may not have the knowledge or the time to modify the 283 platform's IKEv2 and IPsec subsystems, although it might be 284 perfectly capable to deliver the MIP6 application itself. 285 There could be copyright issues as well that would prevent 286 modifications of the platform's security subsystems or the 287 delivery of the modifications by the third party. 288 Even if the MIP6 application developer is able to come up with the 289 necessary patches for the security subsystem, it is not realistic 290 to expect the prospective user of MIPv6 to first patch the kernel 291 and the key management daemons before using the MIPv6 service. 293 The above discussion shows why it is unrealistic to expect that the 294 MIP6 application could provide the needed modifications to the IKEv2 295 and IPsec subsystems of the host. Section 6 presents a more 296 technical discussion of various implementation issues related to the 297 interworking between the MIP6 application and the IPsec/key 298 management modules. 300 The problem in a nutshell for MIP6 is the dependence on IPsec and 301 IKEv2 for successful operation. 303 4.2. General issues with the use of IPsec for MIP6 security 305 This section captures several issues with the use of IPsec by MIP6. 307 1. The design of Mobile IPv6 emphasized the reuse of IPv6 features 308 such as IPsec. IPsec for IPv4 was a bolt-on solution. With the 309 increasing need for security, IPv6 designers chose to 310 incorporate IPsec as a default feature. There existed an 311 assumption in the MIP6 working group that every IPv6 host would 312 have IPsec capability as a standard feature. While this is true 313 in many host implementations today, the existence of IPsec in 314 every IPv6 stack is not a given. Hence a host which needs to 315 implement Mobile IPv6 must ensure that IPsec and IKEv2 are also 316 available. As a result of this dependence, MIP6 is no longer a 317 standalone host-based mobility protocol. A good example of a 318 host based mobility protocol that works as a self-sufficient 319 module is Mobile IPv4 [RFC3344]. The security associated with 320 MIP4 signaling is integrated into the protocol itself. MIP4 has 321 been successfully deployed on a large scale in several networks. 322 2. IPsec use in most hosts is generally for the purpose of VPN 323 connectivity to enterprises. It has not evolved into a generic 324 security protocol that can be used by Mobile IPv6 easily. While 325 [RFC4877] does specify the details which enable only the MIP6 326 signaling to be encapsulated with IPsec, the general method of 327 IPsec usage has been such that all traffic between a host and 328 the IPsec gateway is carried via the tunnel. Selective 329 application of IPsec to protocols is not the norm. Use of IPsec 330 with Mobile IPv6 requires configuration which in many cases is 331 not easily achievable because of reasons such as enterprise 332 environments preventing changes to IPsec policies. 333 3. A MIP6 home agent is one end of the IPsec SA in a many-to-one 334 relationship. A MIP6 HA may support a very large number of 335 mobile nodes which could be in the hundreds of thousands to 336 millions. The ability to terminate a large number of IPsec SAs 337 (millions) requires signifiant hardware and platform capability. 338 The cost issues of such an HA are detrimental and hence act as a 339 barrier to deployment. 340 4. The implementation complexity of Mobile IPv6 is greatly 341 increased because of the interaction with IKEv2. The complexity 342 of the protocol implementation is even more so in the case of 343 Dual stack MIP6 [RFC5555] wherein NAT traversal scenarios are 344 considered. 345 5. IPsec and IKEv2 are not implemented or available by default in 346 every IPv6 or dual stack host. Mobile IPv6 support on such 347 devices is not an option. Many low-end cellular hosts have IP 348 stacks. The need for IPsec and IKEv2 in these devices is not 349 important whereas mobility support is needed in many cases. A 350 simpler security protocol than the use of IPsec/IKEv2 would make 351 MIP6 much more attractive to implement and deploy. 352 6. [RFC4877] which specifies the use of IKEv2 and IPsec with Mobile 353 IPv6 essentially results in a variant of IPsec which is specific 354 to Mobile IP. Hence this results in added complexity to 355 implementations. 357 7. Mobile IPv6 needs to be capable of being deployed in situations 358 where alternative security mechanisms are already well- 359 understood by the network administration. It should be possible 360 to enable Mobile IPv6 to work in situations where alternative 361 security mechanisms already supply the necessary authentication 362 and privacy. 363 8. IPsec has been successfully applied to VPN and other 364 infrastructure operations, but not for general end-to-end 365 applications. Thus, the granularity for selectors was 366 originally not at all sufficient for Mobile IPv6. 367 9. The way that the IPsec code sits in the usual kernel, and the 368 access mechanisms for the SA database, are not very convenient 369 for use by straightforward implementations of Mobile IPv6. 370 Unusual calling sequences and parameter passing seems to be 371 required on many platforms. 372 10. In certain environments the use of IPsec and IKEv2 for 373 establishing the SA is considered as an overhead. Bandwidth 374 constrained links such as cellular networks and air interfaces 375 which are in the licensed spectrum tend to be optimized for user 376 traffic. MIP6 signaling with the IPsec overhead and the IKEv2 377 messages are viewed negatively. It is more acceptable to have 378 signaling without IPsec encapsulation. 380 The issues listed above can be speculatively attributed as some of 381 the causes for MIP6 not being implemented widely. 383 4.3. Security Association Management 385 Once the MN has contacted the HAC and mutual authentication has taken 386 place between the MN and the HAC inside the TLS protected tunnel, the 387 HAC provisions the MN with all security related information inside 388 the TLS protected tunnel. This security related information 389 constitutes a security association (SA) between the MN and the HA. 390 The created SA MUST NOT be tied to the Care-of Address (CoA) of the 391 MN. 393 The HAC may proactively distribute the SA information to HAs under 394 its management, or the HA may query the SA information from the HAC 395 once the MN contacts the HA. If the HA queries for the SA 396 information from the HAC, then the HA MUST be able to query/index the 397 SA information from the HAC based on the Security Parameter Index 398 (SPI). 400 In certain situations, the HA may want the MN to re-establish the SA 401 even if the existing SA is still valid. The HA can indicate this to 402 the MN using a dedicated Status Code in a BA (value set to 403 REINIT_SA_WITH_HAC). As a result, the MN would contact the HAC prior 404 the SA times out, and the HAC would provision the MN and HAs with a 405 new SA information. 407 The SA contains at least the following information: 409 Mobility SPI: 411 This parameter is an SPI used by the MN and the HA to index the SA 412 between the MN and the HA. The HAC is responsible for assigning 413 SPIs to MNs. There is only one SPI for both binding management 414 messaging and possible user data protection. The same SPI is used 415 for both directions between the MN and the HA. The SPI values are 416 assigned by the HAC. The HAC MUST ensure uniqueness of the SPI 417 values across all MNs controlled by the HAC. 419 MN-HA shared key for ciphering: 421 This parameter is a key used for ciphering Mobile IPv6 traffic 422 between the MN and the HA. The HAC is responsible for generating 423 this key. The key generation algorithm is specific to the HAC 424 implementation. 426 MN-HA shared key for integrity protection: 428 This parameter is a key used for integrity protecting Mobile IPv6 429 traffic between the MN and the HA. This includes both binding 430 management messages and reverse tunneled user data traffic between 431 the MN and the HA. The HAC is responsible for generating this 432 key. The key generation algorithm is specific to the HAC 433 implementation. In case of combined algorithms a separate 434 integrity protection key is not needed and may be omitted. 436 Security association validity time: 438 This parameter represents the validity time for the security 439 association. The HAC is responsible for defining the lifetime 440 value based on its policies. The lifetime may be in the order of 441 hours or weeks. The MN MUST re-contact the HAC before the SA 442 validity time ends. 444 Security Association Scope: 446 This parameter defines whether the security association is applied 447 to Mobile IPv6 signaling messages only, or to both Mobile IPv6 448 signaling messages and data traffic. 450 Selected ciphersuite: 452 This parameter is the ciphersuite used to protect the traffic 453 between the MN and the HA. This includes both binding management 454 messages and reverse tunneled user data traffic between the MN and 455 the HA. The selected algorithms SHOULD be one of the mutually 456 supported ciphersuites of the negotiated TLS version between the 457 MN and the HAC. The HAC is responsible for choosing the mutually 458 supported ciphersuite that complies with the policy of the HAC. 459 Obviously, the HAs under HAC's management must have at least one 460 ciphersuite with the HAC in common and need to be aware of the 461 implemented ciphersuites. 463 Sequence number: 465 This parameter represents a monotonically increasing unsigned 466 sequence number used in all protected packets exchanged between 467 the MN and the HA. The initial sequence number MUST always be set 468 to 0 (zero). The sequence number may cycle to 0 (zero) when it 469 increases beyond its maximum defined value. 471 4.4. Bootstrapping of Additional Mobile IPv6 Parameters 473 When the MN contacts the HAC to distribute of the security related 474 information, the HAC may also provision the MN with various Mobile 475 IPv6 related bootstrapping information. Bootstrapping of the 476 following information SHOULD at least be possible: 478 Home Agent IP Address: 480 Concerns both IPv6 and IPv4 home agent addresses. 482 Home Address: 484 Concerns both IPv6 and IPv4 Home Addresses. 486 Home Link Prefix: 488 Concerns the IPv6 Home link prefix and the associated prefix 489 length. 491 The Mobile IPv6 related bootstrapping information is delivered from 492 the HAC to the MN over the same TLS protected tunnel as the security 493 related information. 495 4.5. Protecting Traffic Between Mobile Node and Home Agent 497 The same integrity and confidentiality algorithms MUST be used to 498 protect both binding management messages and reverse tunneled user 499 data traffic between the MN and the HA. Generally, all binding 500 management messages (BUs, BAs and so on) MUST be both integrity and 501 SHOULD be confidentially protected. The reverse tunneled user data 502 traffic SHOULD be equivalently protected. Generally, the rules 503 stated in [RFC3775] concerning the protection of the traffic between 504 the MN and the HA apply also in this specification. 506 5. Mobile Node to Home Agent Controller Communication 508 5.1. Request-response Message Framing over TLS-tunnel 510 The MN and the HAC communicate with each other using a simple lock- 511 step request-response protocol that is run directly on top of the 512 TLS-tunnel. We define only one message container framing for the 513 request messages and for the response messages. The message 514 containers are only meant to be exchanged on top of connection 515 oriented TLS-layer. Therefore, the end of message exchange is 516 determined by the other end closing the transport connection 517 (assuming the "application layer" has also indicated the completion 518 of the message exchange). The peer initiating the TLS-connection is 519 always sending "Requests" and the peer accepting the TLS-connection 520 is always sending "Responses". The format of the message container 521 is shown in Figure 1. 523 All data inside the Content portion of the message container MUST be 524 encoded using octets. Fragmentation of message containers is not 525 supported, which means one request or response at the "application 526 layer" MUST NOT exceed the maximum size allowed by the message 527 container format. 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Ver | Rsrvd | Identifier | Length | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Content portion.. ~ 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Figure 1: Request-Response Message Container 539 The three bit Ver field identifies the protocol version. The current 540 version is 0 i.e. all bits are set to value 0 (zero). 542 The Rsrvd field MUST be set to value 0 (zero), 544 The Identifier field is meant for matching requests and responses. 545 The valid Identifier values are between 1-255. The value 0 MUST NOT 546 be used. The first request for each communication session between 547 the MN and the HAC MUST have the Identifier values set to 1. 549 The Length field tells the length of the Content portion of the 550 container (i.e. Reserved octet, Identifier octet and Length field 551 are excluded). The Content portion length MUST always be at least 552 one octet up to 65535 octets. The value is in network order. 554 5.2. Request-response Message Content Encoding 556 The encoding of the message content is similar to HTTP header 557 encoding, and complies to the augmented Backus-Naur Form (BNF) 558 defined in Section 2.1 of [RFC2616]. All presented hexadecimal 559 numbers are in network byte order. From now on, we use TypeValue 560 header (TV-header) term to refer request-response message content 561 HTTP-like headers. 563 5.3. Request-Response Message Exchange 565 The message exchange between the MN and the HAC is a simple lock-step 566 request-response type as stated in Section 5.1. A request message 567 includes monotonically increasing Identifier value that is copied to 568 the corresponding response message. Each request MUST have a 569 different Identifier value and due the assumption of a reliable 570 connection oriented transport below the message container framing. 571 The number of request-response message exchanges MUST NOT exceed 255. 573 Each new communication session between the MN and the HAC MUST reset 574 the Identifier value to 1. The MN is also the peer that always sends 575 only request messages and the HAC only sends response messages. Once 576 the request-response message exchange completes, the HAC and the MN 577 MUST close the transport connection and the corresponding TLS-tunnel. 579 In a case of a HAC side error, the HAC MUST send a response back to a 580 MN with an appropriate status code and then close the transport 581 connection. 583 The first request message - MHAuth-Init - (i.e. the Identifier is 1) 584 MUST always contain at least the following parameters: 586 MN-Identity - See Section 5.5.1. 587 Authentication Method - See Section 5.5.2. 589 The first response message - MHAuth-Init - (i.e. the Identifier is 1) 590 MUST contain at minimum the following parameters: 592 Selected authentication Method - See Section 5.5.2. 594 The last request message from the MN side - MHAuth-Done - MUST 595 contain the following parameters: 597 Security Association Scope - See Section 5.6.4. 598 Proposed ciphersuites - See Section 5.6.5. 599 Message Authenticator - See Section 5.5.5. 601 The last response message - MHAuth-Done - that ends the request- 602 response message exchange MUST contain the following parameters: 604 Status Code - See Section 5.5.4. 605 Message Authenticator - See Section 5.5.5. 607 And in a case of successful authentication the following additional 608 parameters: 610 Selected ciphersuite - See Section 5.6.5. 611 Security Association Scope - See Section 5.6.4. 612 The rest of the security association data - See Section 5.6. 614 5.4. Home Agent Controller Discovery 616 All bootstrapping information, whether for setting up the SA or for 617 bootstrapping Mobile IPv6 specific information, is exchanged between 618 the MN and the HAC using the framing protocol defined in Section 5.1. 619 The IP address of the HAC MAY be statically configured to the MN or 620 dynamically discovered using for example DNS. In a case of DNS-based 621 HAC discovery, the MN either queries an A/AAAA or a SRV record for 622 the HAC IP address. The actual domain name used in queries is up to 623 the deployment to decide and out of scope of this specification. 625 5.5. Generic Request-Response Parameters 627 5.5.1. Mobile Node Identifier 629 An identifier that identifies a MN. The Mobile Node Identifier is in 630 form of a Network Access Identifier (NAI) [RFC4282]. 632 mn-id = "mn-id" ":" nai CRLF 633 nai = username 634 | "@" realm 635 | username "@" realm 636 ... 638 5.5.2. Authentication Method 640 The HAC is the peer that mandates the used authentication method. 641 The MN sends its proposal to the HAC but eventually the used 642 authentication method returned from the HAC defines the one to be 643 used. The MN MUST propose at least one authentication method and it 644 SHOULD propose more than one. The HAC MUST select exactly one 645 authentication method, or return an error and then close the 646 connection. 648 auth-method = "auth-method" ":" a-method *("," a-method) CRLF 649 a-method = 650 "psk" ; Pre-sharer key based authentication 651 | "eap" ; EAP-based authentication 653 5.5.3. Extensible Authentication Protocol Payload 655 Each Extensible Authentication Protocol (EAP) [RFC3748] message is 656 encoded string of hexadecimal numbers. The "eap-payload" is 657 completely transparent what EAP-method or EAP message is carried 658 inside it. The "eap-payload" can appear in both request and response 659 messages: 661 eap-payload = "eap-payload" ":" 1*(HEX HEX) CRLF 663 5.5.4. Status Code 665 The "status-code" MUST only be present in the response message that 666 ends the request-response message exchange. The "status-code" 667 follows the principles of HTTP and the definitions found in Section 668 10 of RFC 2616 also apply for these status codes listed below: 670 status-code = "status-code" ":" status-value CRLF 671 status-value = 672 "100" ; Continue 673 | "200" ; OK 674 | "400" ; Bad Request 675 | "401" ; Unauthorized 676 | "500" ; Internal Server Error 677 | "501" ; Not Implemented 678 | "503" ; Service Unavailable 679 | "504" ; Gateway Time-out 681 5.5.5. Message Authenticator 683 The "auth" header contains data used for authentication purposes. It 684 MUST be the last TV-header in the message and calculated over the 685 whole message till the start of the "msg-header": 687 msg-auth = "auth" ":" 1*(HEX HEX) CRLF 689 5.5.6. Retry After 691 reply-after = "retry-after" ":" rfc1123-date CRLF 693 5.5.7. End of Message Content 695 end-of-message = 2CRLF 697 5.5.8. Random Values 699 Random number generated by the MN or the HAC. The length of the 700 random number MUST be 32 octets (before TV-header encoding): 702 mn-rand = "mn-rand" ":" 32(HEX HEX) CRLF 703 hac-rand = "hac-rand" ":" 32(HEX HEX) CRLF 705 5.6. Security Association Configuration Parameters 707 During the Mobile IPv6 bootstrapping, the MN and the HAC negotiate a 708 single ciphersuite for protecting the traffic between the MN and the 709 HA. The allowed ciphersuites for this specification are a subset of 710 those in TLS v1.2 (see Annex A.5 of [RFC5246]) as per Section 5.6.5. 711 This might appear as a constraint as the HA and the HAC may have 712 implemented different ciphersuites. These two nodes are, however, 713 assumed to belong to the same administrative domain. In order to 714 avoid exchanging supported MN-HA ciphersuites in the MN-HAC protocol 715 and to reuse the TLS ciphersuite negotiation procedure we make this 716 simplifying assumption. The selected ciphersuite MUST provide 717 integrity and confidentially protection. 719 Section 5.6.5 provides the mapping from the TLS ciphersuites to the 720 integrity and encryption algorithms allowed for MN-HA protection. 721 This mapping mainly ignores the authentication algorithm part that is 722 not required within the context of this specification. For example, 723 [RFC3268] defines a number of AES based ciphersuites for TLS 724 including 'TLS_RSA_WITH_AES_128_CBC_SHA'. For this specification the 725 relevant part is 'AES_128_CBC_SHA'. 727 All the parameters described in the following sections apply only to 728 a request-response protocol response message to the MN. The MN has 729 no way affecting to the provisioning decision of the HAC. 731 5.6.1. Security Parameter Index 733 The 28-bit unsigned SPI number identifies the SA used between the MN 734 and the HA. The value 0 (zero) is reserved and MUST NOT be used. 736 Therefore, values ranging from 1 to 268435455 are valid. 738 The TV-header corresponding to the SPI number is: 740 mip6-spi = "mip6-spi" ":" 1*DIGIT CRLF 742 5.6.2. MN-HA Shared Keys 744 The MN-HA shared integrity (ikey) and encryption (ekey) keys are used 745 to protect the traffic between the MN and the HA. The length of 746 these keys depend on the selected ciphersuite. 748 The TV-headers that carry these two parameters are: 750 mip6-mn-to-ha-ikey = "mip6-mn-to-ha-ikey" ":" 1*(HEX HEX) CRLF 751 mip6-ha-to-mn-ikey = "mip6-ha-to-mn-ikey" ":" 1*(HEX HEX) CRLF 752 mip6-mn-to-ha-ekey = "mip6-mn-to-ha-ekey" ":" 1*(HEX HEX) CRLF 753 mip6-ha-to-mn-ekey = "mip6-ha-to-mn-ekey" ":" 1*(HEX HEX) CRLF 755 5.6.3. Security Association Validity Time 757 The end of the SA validity time is encoded using the "rfc1123-date" 758 format, as defined in Section 3.3.1 of [RFC2616]. 760 The TV-header corresponding to the SA validity time value is: 762 mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date 763 CRLF 765 5.6.4. Security association scope (SAS) 767 The SA is applied either to Mobile IPv6 signaling messages only, or 768 to both Mobile IPv6 signaling messages and data traffic. This 769 parameter MUST be agreed between the MN and HA prior to using the SA. 770 Otherwise the receiving side would not be aware of whether the SA 771 applies to data traffic and could not decide how to act when 772 receiving unprotected packets of PType 1 (see Section 6.4). 774 mip6-sas = "mip6-sas" ":" 1DIGIT CRLF 776 where a value of "0" indicates that the SA does not protect data 777 traffic and a value of "1" indicates that all data traffic MUST be 778 protected by the SA. If the mip6-sas value of an SA is set to 1, any 779 packet with PType = 0 MUST be silently discarded when received. 781 The HAC is the peer that mandates the used security association 782 scope. The MN sends its proposal to the HAC but eventually the 783 security association scope returned from the HAC defines the used 784 scope. 786 5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping 788 The ciphersuite negotiation between HAC and MN uses a subset of the 789 TLS 1.2 ciphersuites and follows the TLS 1.2 numeric representation 790 defined in Annex A.5 of [RFC5246]. The TV-headers corresponding to 791 the selected ciphersuite and ciphersuite list are: 793 mip6-ciphersuite = "mip6-ciphersuite" ":" csuite CRLF 794 csuite = "{" suite "}" 795 suite = 796 "00" "," "02" ; CipherSuite NULL_SHA = {0x00,0x02} 797 | "00" "," "3B" ; CipherSuite NULL_SHA256 = {0x00,0x3B} 798 | "00" "," "0A" ; CipherSuite 3DES_EDE_CBC_SHA = {0x00,0x0A} 799 | "00" "," "2F" ; CipherSuite AES_128_CBC_SHA = {0x00,0x2F} 800 | "00" "," "3C" ; CipherSuite AES_128_CBC_SHA256 = {0x00,0x3C} 801 mip6-suitelist = "mip6-suitelist" ":" csuite *("," csuite) CRLF 803 All other Ciphersuite values are reserved and subject to future 804 specifications. 806 The following integrity algorithms MUST be supported by all 807 implementations: 808 HMAC-SHA1-96 [RFC2404] AES-XCBC-MAC-96 [RFC3566] 810 The binding management messages between the MN and HA MUST be 811 integrity protected. Implementations MUST NOT use a NULL integrity 812 algorithm. 814 The following encryption algorithms MUST be supported: 815 NULL [RFC2410] TripleDES-CBC [RFC2451] AES-CBC with 128-bit keys [RFC3602] 817 Traffic between MN and HA MAY be encrypted. Any integrity-only 818 CipherSuite makes use of the NULL encryption algorithm. 820 Note: In the present version, this document does not consider 821 combined algorithms. The following table provides the mapping of 822 each ciphersuite to a combination of integrity and encryption 823 algorithms that are part of the negotiated SA between MN and HA. 825 +-------------------+-----------------+--------------------------+|Ciphersuite |Integ. Algorithm |Encr. Algorithm | 826 +-------------------+-----------------+--------------------------+|NULL_SHA |HMAC-SHA1-96 |NULL ||NULL_SHA256 |AES-XCBC-MAC-96 |NULL ||3DES_EDE_CBC_SHA |HMAC-SHA1-96 |TripleDES-CBC ||AES_128_CBC_SHA |HMAC-SHA1-96 |AES-CBC with 128-bit keys ||AES_128_CBC_SHA256 |AES-XCBC-MAC-96 |AES-CBC with 128-bit keys | 827 +-------------------+----------------+---------------------------+ 829 Ciphersuite-to-Algorithm Mapping 831 5.7. Mobile IPv6 Bootstrapping Parameters 833 In parallel with the SA bootstrapping, the HAC SHOULD provision the 834 MN with relevant Mobile IPv6 related bootstrapping information. 836 The following generic BNFs are used to form IP addresses and 837 prefixes. They are used in subsequent sections. 839 ip6-addr = 7( word ":" ) word CRLF 840 word = 1*4HEX 841 ip6-prefix = ip6-addr "/" 1*2DIGIT 842 ip4-addr = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 844 5.7.1. Home Agent Address 846 The HAC MAY provision the MN with an IPv4 or an IPv6 address of a HA, 847 or both. 849 mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr CRLF 850 mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr CRLF 852 5.7.2. Home Addresses and Home Network Prefix 854 The HAC MAY provision the MN with an IPv4 or an IPv6 home address, or 855 both. The HAC MAY also provision the MN with its home network 856 prefix. 858 mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr CRLF 859 mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr CRLF 860 mip6-hnp-ip6 = "mip6-ip6-hnp" ":" ip6-prefix CRLF 862 5.8. Authentication of the Mobile Node 864 This section describes the basic operation required for the MN-HAC 865 mutual authentication and the channel binding. The authentication 866 protocol described as part of this section is a simple exchange that 867 follows the GPSK exchange used by EAP-GPSK [RFC5433]. It is secured 868 by the TLS tunnel and is cryptographically bound to the TLS tunnel 869 through channel binding based on [RFC5056] and on the channel binding 870 type 'tls-server-endpoint' described in 871 [I-D.altman-tls-channel-bindings]. As a result of the channel 872 binding type, this method can only be used with TLS ciphersuites that 873 use server certificates and the Certificate handshake message. For 874 example, TLS ciphersuites based on PSK or anonymous authentication 875 cannot be used. 877 The authentication exchange MUST be performed through the encrypted 878 TLS tunnel. It performs mutual authentication between the MN and the 879 HAC based on a pre-shared key (PSK) or based on an EAP-method (see 880 Section 5.9). The PSK protocol is described in this section. It 881 consists of the message exchanges (MHAuth-Init, MHAuth-Mid, MHAuth- 882 Done) in which both sides exchange nonces and their identities, and 883 compute and exchange a message authenticator 'auth' over the 884 previously exchanged values, keyed with the pre-shared key. The 885 MHAuth-Done messages are used to deal with error situations. Key 886 binding with the TLS tunnel is ensured by channel binding of the type 887 "tls-server-endpoint" as described by 888 [I-D.altman-tls-channel-bindings] where the hash of the TLS server 889 certificate serves as input to the 'auth' calculation of the MHAuth 890 messages. 892 Note: The authentication exchange is based on the GPSK exchange used 893 by EAP-GPSK. In comparison to GPSK, it does not support exchanging 894 an encrypted container (it always runs through an already protected 895 TLS tunnel). Furthermore, the initial request of the authentication 896 exchange (MHAuth-Init) is sent by the MN (client side) and is 897 comparable to EAP-Response/Identity, which reverses the roles of 898 request and response messages compared to EAP-GPSK. Figure 2 shows a 899 successful protocol exchange. 901 MN HAC 902 | | 903 | Request/MHAuth-Init (...) | 904 |------------------------------------------------------>| 905 | | 906 | Response/MHAuth-Init (...) | 907 |<------------------------------------------------------| 908 | | 909 | Request/MHAuth-Done (...) | 910 |------------------------------------------------------>| 911 | | 912 | Response/MHAuth-Done (...) | 913 |<------------------------------------------------------| 914 | | 916 Figure 2: Authentication of the Mobile Node Using Shared Secrets 918 1) Request/MHAuth-Init: (MN -> HAC) 919 mn-id, mn-rand, auth-method=psk 921 2) Response/MHAuth-Init: (MN <- HAC) 922 [mn-rand, hac-rand, auth-method=psk, [status],] auth 924 3) Request/MHAuth-Done: (MN -> HAC) 925 mn-rand, hac-rand, sa-scope, ciphersuite-list, auth 927 4) Response/MHAuth-Done: (MN <- HAC) 928 [sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand, 929 hac-rand, status, auth 931 Where: 933 auth = HMAC-SHA256(PSK, msg-octets | CB-octets) 935 The length "mn-rand", "hac-rand" is 32 octets. Note that "|" 936 indicates concatenation and optional parameters are shown in square 937 brackets [..]. The square brackets can be nested. 939 The shared secret PSK can be variable length. 'msg-octets' includes 940 all payload parameters of the respective message to be signed except 941 the 'auth' payload. CB-octets is the channel binding input to the 942 auth calculation that is the "TLS-server-endpoint" channel binding 943 type. The content and algorithm (only required for the "TLS-server- 944 endpoint" type) are the same as described in 945 [I-D.altman-tls-channel-bindings]. 947 The MN starts by selecting a random number 'mn-rand' and choosing a 948 list of supported authentication methods coded in 'auth-method'. The 949 MN sends its identity 'mn-id', 'mn-rand' and 'auth-method' to the HAC 950 in MHAuth-Init. The decision of which authentication method to offer 951 and which to pick is policy- and implementation-dependent and, 952 therefore, outside the scope of this document. 954 In MHAuth-Done, the HAC sends a random number 'hac-rand' and the 955 selected ciphersuite. The selection MUST be one of the MN-supported 956 ciphersuites as received in 'ciphersuite-list'. Furthermore, it 957 repeats the received parameters of the MHAuth-Init message 'mn-rand'. 958 It computes a message authenticator 'auth' over all the transmitted 959 parameters except 'auth' itself. The HAC calculates 'auth' over all 960 parameters and appends it to the message. 962 The MN verifies the received MAC and the consistency of the 963 identities, nonces, and ciphersuite parameters transmitted in MHAuth- 964 Auth. In case of successful verification, the MN computes a MAC over 965 the session parameter and returns it to the HAC in MHAuth-Done. The 966 HAC verifies the received MAC and the consistency of the identities, 967 nonces, and ciphersuite parameters transmitted in MHAuth-Init. If 968 the verification is successful, MHAuth-Done is prepared and sent by 969 the HAC to confirm successful completion of the exchange. 971 5.9. Extensible Authentication Protocol Methods 973 Basic operation required for the MN-HAC mutual authentication using 974 EAP-based methods. 976 MN HAC 977 | | 978 | Request/MHAuth-Init (...) | 979 |------------------------------------------------------>| 980 | | 981 | Response/MHAuth-Init (..., | 982 | eap-payload=EAP-Request/Identity) | 983 |<------------------------------------------------------| 984 | | 985 | Request/MHAuth-Mid (eap-payload= | 986 | EAP-Response/Identity) | 987 |------------------------------------------------------>| 988 | | 989 | Response/MHAuth-Mid (eap-payload=EAP-Request/...) | 990 |<------------------------------------------------------| 991 | | 992 : : 993 : ..EAP-method specific exchanges.. : 994 : : 995 | | 996 | Request/MHAuth-Done (eap-payload=EAP-Response/..., | 997 | ..., auth) | 998 |------------------------------------------------------>| 999 | | 1000 | Response/MHAuth-Done (eap-payload=EAP-Success, | 1001 | ..., auth) | 1002 |<------------------------------------------------------| 1003 | | 1005 Figure 3: Authentication of the Mobile Node Using EAP 1007 1) Request/MHAuth-Init: (MN -> HAC) 1008 mn-id, mn-rand, auth-method=eap 1010 2) Response/MHAuth-Init: (MN <- HAC) 1011 [auth-method=eap, eap, [status,]] auth 1013 3) Request/MHAuth-Mid: (MN -> HAC) 1014 eap, auth 1016 4) Response/MHAuth-Mid: (MN <- HAC) 1017 eap, auth 1019 MHAuth-Mid exchange is repeated as many times as needed by the 1020 used EAP-method. 1022 5) Request/MHAuth-Done: (MN -> HAC) 1023 sa-scope, ciphersuite-list, eap, auth 1025 6) Response/MHAuth-Done: (MN <- HAC) 1026 [sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap, 1027 status, auth 1029 Where: 1031 auth = HMAC-SHA256(shared-key, msg-octets | CB-octets) 1033 In MHAuth-Init and MHAuth-Mid messages, shared-key is set to "1". If 1034 the EAP-method is key-deriving and creates a shared MSK key as a side 1035 effect of Authentication shared-key MUST be the MSK in all MHAuth- 1036 Done messages. This MSK MUST NOT be used for any other purpose. In 1037 case the EAP method does not generate an MSK key, shared-key is set 1038 to "1". 1040 'msg-octets' includes all payload parameters of the respective 1041 message to be signed except the 'auth' payload. CB-octets is the 1042 channel binding input to the AUTH calculation that is the "TLS- 1043 server-endpoint" channel binding type. The content and algorithm 1044 (only required for the "TLS-server-endpoint" type) are the same as 1045 described in [I-D.altman-tls-channel-bindings]. 1047 6. Mobile Node to Home Agent communication 1049 6.1. General 1051 The following sections describe the packet formats used for the 1052 traffic between the MN and the HA. This traffic includes binding 1053 management messages (for example, BU and BA messages), reverse 1054 tunneled and encrypted user data, and reverse tunneled plain text 1055 user data. This specification defines a generic packet format, where 1056 everything is encapsulated inside UDP. See Section 6.3 and 1057 Section 6.4 for detailed illustrations of the corresponding packet 1058 formats. 1060 The Mobile IPv6 service port number (HALTSEC), where the HA expects 1061 to receive UDP packets, is reserved by IANA. The same port number is 1062 used for both binding management messages and user data packets. The 1063 reason for multiplexing data and control messages over the same port 1064 number is due to the possibility of Network Address and Port 1065 Translators located along the path between the MN and the HA. The 1066 Mobile IPv6 service MAY use any ephemeral port number as the UDP 1067 source port, and MUST use the Mobile IPv6 service port number 1068 (HALTSEC) as the UDP destination port. 1070 The encapsulating UDP header is immediately followed by a 4-bit 1071 Packet Type (PType) field that defines whether the packet contains an 1072 encrypted mobility management message or a, an encrypted user data 1073 packet, or a plain text user data packet. 1075 The Packet Type field is followed by a 28-bit SPI value, which 1076 identifies the correct SA concerning the encrypted packet. For any 1077 packet that is neither integrity protected nor encrypted (i.e. no SA 1078 is applied by the originator) the SPI MUST be set to 0 (zero). ). 1079 Mobility management messages MUST always be at least integrity 1080 protected. Hence, mobility management messages MUST NOT be sent with 1081 a SPI value of 0 (zero). 1083 There is always only one SPI per MN-HA mobility session and the same 1084 SPI is used for all types of protected packets independent of the 1085 direction. 1087 The SPI value is followed by a 32-bit Sequence Number value that is 1088 used to identify retransmissions of encrypted messages. Each 1089 endpoint in the security association maintains two "current" Sequence 1090 Numbers: the next one to be used for a packet it initiates and the 1091 next one it expects to see in a packet from the other end. If the MN 1092 and the HA ends initiate very different numbers of messages, the 1093 Sequence Numbers in the two directions can be very different. In a 1094 case encryption is not used, the Sequence Number MUST be set to 0 1095 (zero). Note that the HA SHOULD initiate a re-establishement of the 1096 SA before any of the Sequence Number cycle. 1098 Finally, the Sequence Number field is followed by the data portion, 1099 whose content is identified by the Packet Type. The data portion may 1100 be protected. 1102 6.2. Security Parameter Index 1104 The SPI is a 32-bit field, where the first 4 bits indicate the Packet 1105 Type (PType) of the UDP encapsulated packet. The SPI value itself 1106 consists of the remaining 28-bit of the SPI field. The SPI field is 1107 treated as one 32-bit field during the integrity protection 1108 calculation. 1110 0 1 2 3 1111 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 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | PType | SPI | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 Figure 4: Security Parameter Index with Packet Type 1118 A SPI value of 0 (zero) indicates a plaintext packet. If the packet 1119 is integrity protected or both integrity protected and encrypted, the 1120 SPI value MUST be different from 0. 1122 6.3. Binding Management Message Formats 1124 The binding management messages that are only meant to be exchanged 1125 between the MN and the HA MUST be integrity protected and MAY be 1126 encrypted. They MUST use the packet format shown in Figure 5. All 1127 packets that are specific to the Mobile IPv6 protocol and contain a 1128 Mobility Header (as defined in Section 6.1.1. of RFC 3775) SHOULD use 1129 the packet format shown in Figure 5. (This means that some Mobile 1130 IPv6 mobility management messages, such as the HoTI message, as 1131 treated as data packets and using encapsulation described in 1132 Section 6.4). 1134 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |: UDP header (src-port=Xp,dst-port=Yp) :| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------|PType=8| SPI | ^Int.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-| Sequence Number | |ered+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----| Payload Data* (variable) | | ^: : | || | |Conf.+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-| | Padding (0-255 bytes) | |ered*+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || | Pad Length | Next Header | v v+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------| Integrity Check Value-ICV (variable) |: :| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 Figure 5: UDP Encapsulated Binding Management Message Format 1138 The PType value 8 (eight) identifies that the UDP encapsulated packet 1139 contains a RFC 3775 defined Mobility Header and other relevant IPv6 1140 extension headers. Note, there is no additional IP header inside the 1141 encapsulated part. The Next Header field MUST be set to value of the 1142 first encapsulated header. The encapsulated headers follow the 1143 natural IPv6 and Mobile IPv6 extension header alignment and 1144 formatting rules. 1146 The Padding, Pad Length, Next Header and ICV fields follow the rules 1147 of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this 1148 document. For a SPI value of 0 (zero) that indicates an unprotected 1149 packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT 1150 be present. 1152 The source and destination IP addresses of the outer IP header (i.e. 1153 the src-addr and the dst-addr in Figure 5) use the current care-of 1154 address of the MN and the HA address. 1156 6.4. Reverse Tunneled User Data Packet Formats 1158 There are two types of reverse tunneled user data packets between the 1159 MN and the HA. Those that are integrity protected and encrypted and 1160 those that are plaintext. The MN or the HA decide whether to apply 1161 integrity protection and encryption to a packet or to send it in 1162 plaintext based on the mip6-sas value in the SA. If the mip6-sas is 1163 set to 1 the originator MUST NOT send any plaintext packet, and the 1164 receiver MUST silently discard any packet with the PType set to 0 1165 (unprotected). It is RECOMMENDED to apply confidentiality and 1166 integrity protection of user data traffic. The reverse tunneled IPv4 1167 or IPv6 user data packets are encapsulated as-is inside the 'Payload 1168 Data' shown in Figure 6. and Figure 7. 1170 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+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |: IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) :| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |: UDP header (src-port=Xp,dst-port=Yp) :| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|PType=1| SPI | ^Int.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-| Sequence Number | |ered+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----| Payload Data* (variable) | | ^: : | || | |Conf.+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-| | Padding (0-255 bytes) | |ered*+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | || | Pad Length | Next Header | v v+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------| Integrity Check Value-ICV (variable) |: :| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1172 Figure 6: UDP Encapsulated Protected User Data Packet Format 1174 The PType value 1 (one) identifies that the UDP encapsulated packet 1175 contains an encrypted tunneled IPv4/IPv6 user data packet. The Next 1176 Header field header MUST be set to value corresponding the tunneled 1177 IP packet (e.g., 41 for IPv6). 1179 The Padding, Pad Length, Next Header and ICV fields follow the rules 1180 of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this 1181 document. For a SPI value of 0 (zero) that indicates an unprotected 1182 packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT 1183 be present. 1185 The source and destination IP addresses of the outer IP header (i.e., 1186 the src-addr and the dst-addr in Figure 6) use the current care-of 1187 address of the MN and the HA address. The ESP protected inner IP 1188 header, which is not shown in Figure 6, uses the home address of the 1189 MN and the correspondent node (CN) address. 1191 0 1 2 3 1192 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 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | | 1195 : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : 1196 | | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | | 1199 : UDP header (src-port=Xp,dst-port=Yp) : 1200 | | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 |PType=0| 0 | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | 0 | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | | 1207 : Payload Data (plain IPv4 or IPv6 Packet) : 1208 | | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 Figure 7: UDP Encapsulated Non-Protected User Data Packet Format 1213 The PType value 0 (zero) identifies that the UDP encapsulated packet 1214 contains a plaintext tunneled IPv4/IPv6 user data packet. Also the 1215 SPI and the Sequence Number fields MUST be set to 0 (zero). 1217 The source and destination IP addresses of the outer IP header (i.e., 1218 the src-addr and the dst-addr in Figure 7) use the current care-of 1219 address of the MN and the HA address. The plain text inner IP header 1220 uses the home address of the MN and the CN address. 1222 7. Route Optimization 1224 The treatment of MN-CN route optimization is outside the scope of 1225 this document. 1227 8. IANA Considerations 1229 8.1. New Registry: Packet Type 1231 IANA is requested to create a new registry for the Packet Type as 1232 described in Section 6.1. 1234 Packet Type | Value 1235 ----------------------------------+---------------------------------- 1236 non-encrypted IP packet | 0 1237 encrypted IP packet | 1 1238 mobility header | 8 1240 Following the allocation policies from [RFC5226] new values for the 1241 Packet Type AVP MUST be assigned based on the "RFC Required" policy. 1243 8.2. HTTP Headers 1245 A number of HTTP headers with their respective parameters are 1246 reserved. See Section 5.6 and Section 5.7 for a list of header names 1247 and their parameters. 1249 8.3. Status Codes 1251 A new Status Code (to be used in BA messages) is reserved for the 1252 cases where the HA wants to indicate to the MN that it needs to re- 1253 establish the SA information with the HAC. The Result Code is 1254 reserved from the 0-127 code space: 1256 REINIT_SA_WITH_HAC TBD1 1258 8.4. Port Numbers 1260 A new port number (HALTSEC) for UDP packets is reserved from the PORT 1261 NUMBERS registry. 1263 HALTSEC TBD2 1265 9. Security Considerations 1267 This document describes and uses a number of building blocks that 1268 introduce security mechanisms and need to interwork in a secure 1269 manner. 1271 The following building blocks are considered from a security point of 1272 view: 1274 1. Discovery of the HAC 1275 2. Authentication and MN-HA SA establishment executed between the MN 1276 and the HAC (PSK or EAP-based) through a TLS tunnel 1277 3. Protection of MN-HA communication 1278 4. AAA Interworking 1280 9.1. Discovery of the HAC 1282 No dynamic procedure for discovering the HAC by the MN is described 1283 in this document. As such, no specific security considerations apply 1284 to the scope of this document. 1286 9.2. Authentication and Key Exchange executed between the MN and the 1287 HAC 1289 This document describes a simple authentication and MN-HA SA 1290 negotiation exchange over TLS. The TLS procedures remain unchanged; 1291 however, channel binding is provided. 1293 Authentication: Server-side certificate based authentication MUST be 1294 performed using TLS 1.2 [RFC5246]. 1296 The client-side authentication may depend on the specific 1297 deployment and is therefore not mandated. Note that TLS-PSK 1298 [RFC4279] cannot be used in conjunction with the methods described 1299 in section 5.8 and 5.9 of this document due to the limitations of 1300 the channel binding type used. 1302 Through the protected TLS tunnel, an additional authentication 1303 exchange is performed that provides client-side or mutual 1304 authentication and exchanges SA parameters and optional 1305 configuration data to be used in the subsequent protection of 1306 MN-HA communication. The additional authentication exchange can 1307 either be PSK-based (section 5.8) or EAP-based (section 5.9). 1308 Both exchanges are always performed within the protected TLS 1309 tunnel and MUST NOT be used as standalone protocols. 1311 The simple PSK-based authentication exchange provides mutual 1312 authentication and follows the GPSK exchange used by EAP-GPSK 1313 [RFC5433] and has similar properties, although some features of 1314 GPSK like the exchange of a protected container are not supported. 1316 The EAP-based authentication exchange simply defines message 1317 containers to allow carrying the EAP packets between the MN and 1318 the HAC. In principle, any EAP method can be used. However, it 1319 is strongly recommended to use only EAP methods that provide 1320 mutual authentication and that derive keys including an MSK key in 1321 compliance with [RFC3748]. 1323 Both exchanges use channel binding with the TLS tunnel. The 1324 channel binding type 'TLS-server-endpoint' as per 1325 [I-D.altman-tls-channel-bindings] MUST be used. 1327 Dictionary Attacks: All messages of the authentication exchanges 1328 specified in this document are protected by TLS. However, any 1329 implementation SHOULD assume that the properties of the 1330 authentication exchange are the same as for GPSK [RFC5433] in case 1331 the PSK-based method as per section 5.8. is used, and are the same 1332 as those of the underlying EAP method in case the EAP-based 1333 exchange as per section 5.9 is used. 1335 Replay Protection: The underlying TLS protection provides protection 1336 against replays. 1338 Key Derivation and Key Strength: For TLS, the TLS specific 1339 considerations apply unchanged. For the authentication exchanges 1340 defined in this document, no key derivation step is performed as 1341 the MN-HA keys are generated by the HAC and are distributed to the 1342 MN through the secure TLS connection. 1344 Key Control: No joint key control for MN-HA keys is provided by this 1345 version of the specification. 1347 Lifetime: The TLS-protected authentication exchange between the MN 1348 and the HAC is only to bootstrap keys and other parameters for 1349 usage with MN-HA security. The SAs that contain the keys have an 1350 associated lifetime. The usage of Transport Layer Security (TLS) 1351 Session Resumption without Server-Side State, described in 1352 [RFC5077], provides the ability for the MN to minimize the latency 1353 of future exchanges towards the HA without having to keep state at 1354 the HA itself. 1356 Denial of Service Resistance: The level of resistance against denial 1357 of service attacks SHOULD be considered the same as for common TLS 1358 operation, as TLS is used unchanged. For the PSK-based 1359 authentication exchange, no additional factors are known. For the 1360 EAP-based authentication exchange, any considerations regarding 1361 denial-of-service resistance specific to the chosen EAP method are 1362 expected to be applicable and need to be be taken into account. 1364 Session Independence: Each individual TLS protocol run is 1365 independent from any previous exchange based on the security 1366 properties of the TLS handshake protocol. However, several PSK or 1367 EAP-based authentication exchanges can be performed across the 1368 same TLS connection. 1370 Fragmentation: TLS runs on top of TCP and no fragmentation specific 1371 considerations apply to the MN-HAC authentication exchanges. 1373 Channel Binding: Both the PSK and the EAP-based exchanges use 1374 channel binding with the TLS tunnel. The channel binding type 1375 'TLS-server-endpoint' as per [I-D.altman-tls-channel-bindings] 1376 MUST be used. 1378 Fast Reconnect: This protocol provides session resumption as part of 1379 TLS and optionally the support for [RFC5077]. No fast reconnect 1380 is supported for the PSK-based authentication exchange. For the 1381 EAP-based authentication exchange, availability of fast reconnect 1382 depends on the EAP method used. 1384 Identity Protection: Based on the security properties of the TLS 1385 tunnel, passive user identity protection is provided. An attacker 1386 acting as man-in-the-middle in the TLS connection would be able to 1387 observe the MN identity value sent in MHAuth-Init messages. 1389 Protected Ciphersuite Negotiation: This protocol provides 1390 ciphersuite negotiation based on TLS. 1392 Confidentiality: Confidentiality protection of payloads exchanged 1393 between the MN and the HAC are protected with the TLS Record 1394 Layer. TLS ciphersuites with confidentiality and integrity 1395 protection MUST be negotiated and used in order to exchange 1396 security sensitive material inside the TLS connection. 1398 Cryptographic Binding: No cryptographic bindings are provided by 1399 this protocol specified in this document. 1401 Perfect Forward Secrecy: Perfect forward secrecy is provided with 1402 appropriate TLS ciphersuites. 1404 Key confirmation: Key confirmation of the keys established with TLS 1405 is provided by the TLS Record Layer when the keys are used to 1406 protect the subsequent TLS exchange. 1408 9.3. Protection of MN and HA Communication 1410 Authentication: Data origin authentication is provided for the 1411 communication between the MN and the HA. The chosen level of 1412 security of this authentication depends on the selected 1413 ciphersuite. Entity authentication is offered by the MN to HAC 1414 protocol exchange. 1416 Dictionary Attacks: The concept of dictionary attacks is not 1417 applicable to the MN-HA communication as the keying material used 1418 for this communication is randomly created by the HAC and its 1419 length depends on the chosen cryptographic algorithms. 1421 Replay Protection: Replay protection for the communication between 1422 the MN and the HA is provided based on sequence numbers and 1423 follows the design of IPsec ESP. 1425 Key Derivation and Key Strength: The strength of the keying material 1426 established for the communication between the MN and the HA is 1427 selected based on the negotiated ciphersuite (based on the MN-HAC 1428 exchange) and the key created by the HAC. The randomness 1429 requirements for security described in RFC 4086 [RFC4086] are 1430 applicable to the key generation by the HAC. 1432 Key Control: The keying material established during the MN-HAC 1433 protocol exchange for subsequent protection of the MN-HA 1434 communication is created by the HA and therefore no joint key 1435 control is provided for it. 1437 Key Naming: For the MN-HA communication the security associations 1438 are indexed with the help of the SPI and additionally based on the 1439 direction (in-bound communication or out-bound communication). 1441 Lifetime: The lifetime of the MN-HA security associations is based 1442 on the value in the mip6-sa-validity-end HTTP header field 1443 exchanged during the MN-HAC exchange. The HAC controls the SA 1444 lifetime. 1446 Denial of Service Resistance: For the communication between the MN 1447 and the HA there are no heavy cryptographic operations (such as 1448 public key computations). As such, there are no DoS concerns. 1450 Session Independence: Sessions are independent from each other when 1451 new keys are created by via the MN-HAC protocol. A new MN-HAC 1452 protocol run produces fresh and unique keying material for 1453 protection of the MN-HA communication. 1455 Fragmentation: There is no additional fragmentation support provided 1456 beyond what is offered by the network layer. 1458 Channel Binding: Channel binding is not applicable to the MN-HA 1459 communication. 1461 Fast Reconnect: The concept of fast reconnect is not applicable to 1462 the MN-HA communication. 1464 Identity Protection: User identities SHOULD NOT be exchanged between 1465 the MN and the HA. In a case binding management messages contain 1466 the user identity, the messages SHOULD be confidentity protected. 1468 Protected Ciphersuite Negotiation: The MN-HAC protocol provides 1469 protected ciphersuite negotiation through a secure TLS connection. 1471 Confidentiality: Confidentiality protection of payloads exchanged 1472 between the MN and the HAC (for Mobile IPv6 signaling and 1473 optionally for the data traffic) is provided utilizing algorithms 1474 negotiated during the MN-HAC exchange. 1476 Cryptographic Binding: No cryptographic bindings are provided by 1477 this protocol specified in this document. 1479 Perfect Forward Secrecy: Perfect forward secrecy is provided when 1480 the MN bootstraps new keying material with the help of the MN-HAC 1481 protocol (assuming that a proper TLS ciphersuite is used). 1483 Key confirmation: Key confirmation of the MN-HA keying material 1484 conveyed from the HAC to the MN is provided when the first packets 1485 are exchanged between the MN and the HA (in both directions as two 1486 different keys are used). 1488 9.4. AAA Interworking 1490 The AAA backend infrastructure interworking is not defined in this 1491 document and therefore out-of-scope. 1493 10. Acknowledgements 1495 The authors would like to thank Pasi Eronen, Domagoj Premec, and 1496 Christian Bauer for their comments. 1498 11. References 1500 11.1. Normative References 1502 [I-D.altman-tls-channel-bindings] 1503 Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1504 for TLS", draft-altman-tls-channel-bindings-10 (work in 1505 progress), March 2010. 1507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1508 Requirement Levels", BCP 14, RFC 2119, March 1997. 1510 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1511 ESP and AH", RFC 2404, November 1998. 1513 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 1514 Its Use With IPsec", RFC 2410, November 1998. 1516 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 1517 Algorithms", RFC 2451, November 1998. 1519 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1520 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1521 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1523 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 1524 and Its Use With IPsec", RFC 3566, September 2003. 1526 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1527 Algorithm and Its Use with IPsec", RFC 3602, 1528 September 2003. 1530 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1531 in IPv6", RFC 3775, June 2004. 1533 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1534 Network Access Identifier", RFC 4282, December 2005. 1536 [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1537 Chowdhury, "Authentication Protocol for Mobile IPv6", 1538 RFC 4285, January 2006. 1540 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1541 Channels", RFC 5056, November 2007. 1543 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1544 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1545 May 2008. 1547 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1548 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1550 11.2. Informative References 1552 [RFC3268] Chown, P., "Advanced Encryption Standard (AES) 1553 Ciphersuites for Transport Layer Security (TLS)", 1554 RFC 3268, June 2002. 1556 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1557 August 2002. 1559 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1560 Levkowetz, "Extensible Authentication Protocol (EAP)", 1561 RFC 3748, June 2004. 1563 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1564 Protect Mobile IPv6 Signaling Between Mobile Nodes and 1565 Home Agents", RFC 3776, June 2004. 1567 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1568 Requirements for Security", BCP 106, RFC 4086, June 2005. 1570 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1571 for Transport Layer Security (TLS)", RFC 4279, 1572 December 2005. 1574 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1575 Internet Protocol", RFC 4301, December 2005. 1577 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1578 RFC 4303, December 2005. 1580 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1581 RFC 4306, December 2005. 1583 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1584 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1585 April 2007. 1587 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1588 "Transport Layer Security (TLS) Session Resumption without 1589 Server-Side State", RFC 5077, January 2008. 1591 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 1592 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 1593 RFC 5433, February 2009. 1595 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1596 Routers", RFC 5555, June 2009. 1598 Authors' Addresses 1600 Basavaraj Patil 1601 Nokia 1602 6021 Connection Drive 1603 Irving, TX 75039 1604 USA 1606 Email: basavaraj.patil@nokia.com 1608 Charles Perkins 1609 Tellabs 1610 3590 N. 1st Street, Suite 300 1611 San Jose, CA 95134 1612 USA 1614 Email: charles.perkins@tellabs.com 1616 Hannes Tschofenig 1617 Nokia Siemens Networks 1618 Linnoitustie 6 1619 Espoo 02600 1620 Finland 1622 Phone: +358 (50) 4871445 1623 Email: Hannes.Tschofenig@gmx.net 1624 URI: http://www.tschofenig.priv.at 1626 Domagoj Premec 1627 Unaffiliated 1628 Heinzelova 70a 1629 Zagreb 10000 1630 Croatia 1632 Email: domagoj.premec@gmail.com