idnits 2.17.1 draft-korhonen-mext-mip6-altsec-06.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3775, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3775, updated by this document, for RFC5378 checks: 1996-01-29) -- 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 19, 2010) is 4931 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** 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) == Outdated reference: A later version (-04) exists of draft-patil-mext-mip6issueswithipsec-03 -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 5 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) J. Korhonen, Ed. 3 Internet-Draft Nokia Siemens Networks 4 Updates: 3775 (if approved) B. Patil 5 Intended status: Experimental Nokia 6 Expires: April 22, 2011 H. Tschofenig 7 D. Kroeselberg 8 Nokia Siemens Networks 9 October 19, 2010 11 Transport Layer Security-based Mobile IPv6 Security Framework for Mobile 12 Node to Home Agent Communication 13 draft-korhonen-mext-mip6-altsec-06.txt 15 Abstract 17 Mobile IPv6 signaling between the mobile node and home agent is 18 secured using IPsec. The security association between a mobile node 19 and the home agent is established using IKEv1 or IKEv2. The security 20 model specified for Mobile IPv6, which relies on IKE/IPsec, requires 21 interaction between the Mobile IPv6 protocol part of the IP stack and 22 the IKE/IPsec part of the IP stack. The IPsec/IKEv2 based security 23 architectures makes implementation and deployment of the protocol 24 infeasible for numerous reasons. This document proposes an alternate 25 security framework, which relies on Transport Layer Security for 26 establishing keying material and other bootstrapping parameters 27 required to protect Mobile IPv6 signaling and data traffic between 28 the mobile node and home agent. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 22, 2011. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 65 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. TLS-based Security Establishment . . . . . . . . . . . . . . . 6 67 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.3. Security Association Management . . . . . . . . . . . . . 8 70 4.4. Bootstrapping of Additional Mobile IPv6 Parameters . . . . 10 71 4.5. Protecting Traffic Between Mobile Node and Home Agent . . 11 72 5. Mobile Node to Home Agent Controller Communication . . . . . . 11 73 5.1. Request-response Message Framing over TLS-tunnel . . . . . 11 74 5.2. Request-response Message Content Encoding . . . . . . . . 12 75 5.3. Request-Response Message Exchange . . . . . . . . . . . . 12 76 5.4. Home Agent Controller Discovery . . . . . . . . . . . . . 13 77 5.5. Generic Request-Response Parameters . . . . . . . . . . . 13 78 5.5.1. Mobile Node Identifier . . . . . . . . . . . . . . . . 13 79 5.5.2. Authentication Method . . . . . . . . . . . . . . . . 14 80 5.5.3. Extensible Authentication Protocol Payload . . . . . . 14 81 5.5.4. Status Code . . . . . . . . . . . . . . . . . . . . . 14 82 5.5.5. Message Authenticator . . . . . . . . . . . . . . . . 15 83 5.5.6. Retry After . . . . . . . . . . . . . . . . . . . . . 15 84 5.5.7. End of Message Content . . . . . . . . . . . . . . . . 15 85 5.5.8. Random Values . . . . . . . . . . . . . . . . . . . . 15 86 5.6. Security Association Configuration Parameters . . . . . . 15 87 5.6.1. Security Parameter Index . . . . . . . . . . . . . . . 16 88 5.6.2. MN-HA Shared Keys . . . . . . . . . . . . . . . . . . 16 89 5.6.3. Security Association Validity Time . . . . . . . . . . 16 90 5.6.4. Security association scope (SAS) . . . . . . . . . . . 16 91 5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping . . 17 92 5.7. Mobile IPv6 Bootstrapping Parameters . . . . . . . . . . . 18 93 5.7.1. Home Agent Address . . . . . . . . . . . . . . . . . . 18 94 5.7.2. Mobile IPv6 Service Port Number . . . . . . . . . . . 18 95 5.7.3. Home Addresses and Home Network Prefix . . . . . . . . 19 96 5.7.4. DNS Server . . . . . . . . . . . . . . . . . . . . . . 19 97 5.8. Authentication of the Mobile Node . . . . . . . . . . . . 19 98 5.9. Extensible Authentication Protocol Methods . . . . . . . . 21 99 6. Mobile Node to Home Agent communication . . . . . . . . . . . 23 100 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 6.2. Security Parameter Index . . . . . . . . . . . . . . . . . 24 102 6.3. Binding Management Message Formats . . . . . . . . . . . . 25 103 6.4. Reverse Tunneled User Data Packet Formats . . . . . . . . 27 104 7. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 28 105 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 106 8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 29 107 8.2. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . 29 108 8.3. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 29 109 8.4. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 29 110 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 111 9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 30 112 9.2. Authentication and Key Exchange executed between the 113 MN and the HAC . . . . . . . . . . . . . . . . . . . . . . 30 114 9.3. Protection of MN and HA Communication . . . . . . . . . . 32 115 9.4. AAA Interworking . . . . . . . . . . . . . . . . . . . . . 34 116 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 117 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 118 11.1. Normative References . . . . . . . . . . . . . . . . . . . 35 119 11.2. Informative References . . . . . . . . . . . . . . . . . . 35 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 122 1. Introduction 124 Mobile IPv6 [RFC3775] signaling, and optionally user traffic, between 125 a mobile node (MN) and home agent (HA) are secured by IPsec 126 [RFC4301]. The current Mobile IPv6 security architecture is 127 specified in [RFC3776] and [RFC4877]. This security model requires a 128 tight coupling between the Mobile IPv6 protocol part and the IKE(v2)/ 129 IPsec part of the IP stack. Implementation experience has shown that 130 the use of IKE(v2)/IPsec with Mobile IPv6 is fairly complex. The 131 issues with the IKE(v2)/IPsec based security architecture are 132 documented in [I-D.patil-mext-mip6issueswithipsec]. 134 This document proposes an alternate security framework for Mobile 135 IPv6. Transport Layer Security (TLS) [RFC5246] is widely implemented 136 in almost all major operating systems and extensively used. Instead 137 of using IKEv2, the security framework proposed in this document is 138 based on TLS protected messages to exchange keys and bootstrapping 139 parameters between the Mobile Node and a new functional entity called 140 as the Home Agent Controller (HAC). The Mobile IPv6 signaling 141 between the mobile node and home agent is subsequently secured using 142 the resulting keys and negotiated cipher suite. The HAC can be co- 143 located with the HA, or can be an independent entity. For the latter 144 case, communication between HAC and HA is not defined by this 145 document. The Diameter protocol can be used between the HA and HAC 146 when the two entities are not collocated. 148 The primary advantage of using TLS based establishment of Mobile IP6 149 security associations compared to IKEv2 is the ease of implementation 150 while providing equivalent level of security. For the protection of 151 Mobile IPv6 signaling messages a solution is provided that decouples 152 Mobile IPv6 protection from regular IPsec operation to reduce 153 complexity in Mobile IP client implementations. 155 The security framework proposed in this document is not intended to 156 replace the currently specified architecture which relies on IPsec 157 and IKEv2. It provides an alternative solution which is more optimal 158 for certain deployment scenarios. 160 2. Terminology and Abbreviations 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 Home Agent Controller (HAC): 168 The home agent controller is a node responsible for bootstrapping 169 Mobile IPv6 security associations between a mobile node and one or 170 more home agents. The home agent controller also provides key 171 distribution to both mobile nodes and home agents. Optionally, 172 Mobile IPv6 bootstrapping can be done in addition to the security 173 association bootstrapping between the mobile node and home agent 174 controller. 176 Binding Management Messages: 178 Mobile IPv6 signaling messages between a mobile node and a home 179 agent, correspondent node or mobility access point to manage the 180 bindings are referred to as binding management messages. Binding 181 Updates and Binding Acknowledgement messages are examples of 182 binding management messages. 184 3. Background 186 Work on the design and specification of Mobile IPv6 has been done 187 since the late 90s. The security architecture of Mobile IPv6 was 188 based on the understanding that IPsec is an inherent and integral 189 part of the IPv6 stack and any protocol that needs security should 190 use IPsec unless there is a good reason not to. As a result of this 191 mindset the Mobile IP6 protocol relied on the use of IPsec for 192 security between the MN and HA. It should be noted that Mobile IPv4 193 [RFC3344] for example does not use IPsec for security and instead has 194 specified its own security solution. Mobile IPv4 has been 195 implemented and deployed on a reasonably large scale and the security 196 model has proven itself to be sound. 198 Mobile IPv6 standardization was completed in 2005 along with the 199 security architecture using IKE/IPsec specified in RFC 3776 200 [RFC3776]. With the transition to IKEv2 [RFC5996], Mobile IP6 201 security has also been updated to rely on the use of IKEv2 [RFC4877]. 202 Recent implementation exercises of Mobile IPv6 and Dual-stack Mobile 203 IPv6 [RFC5555] have identified the complexity of using IPsec and 204 IKEv2 in conjunction with Mobile IPv6. At an abstract level it can 205 be said that implementing Mobile IPv6 with IPsec and IKEv2 is 206 possible only with modifications to the IPsec and IKEv2 components. 207 The original design intent was to reuse IPsec without having to 208 modify them. The current security model requires an IPsec/IKEv2 209 implementation that is specific to Mobile IPv6. 211 This document proposes a security framework based on TLS protected 212 establishment of Mobile IPv6 security associations with reduced 213 implementation complexity, while maintaining an equivalent (to IKEv2/ 214 IPsec) level of security. 216 4. TLS-based Security Establishment 218 4.1. Overview 220 The security architecture proposed in this document relies on a 221 secure TLS session established between the MN and the HAC for 222 authentication and security association establishment. 223 Authentication of the HAC is done via standard TLS operation where 224 the HAC uses a TLS server certificate as credentials. MN 225 authentication is done by the HAC via signaling messages that are 226 secured by the TLS connection. This can either be MN-only 227 authentication within the server-authenticated TLS channel, or mutual 228 authentication between the MN and HAC. Upon successful completion of 229 authentication, the HAC generates keys which are delivered to the MN 230 through the secure TLS channel. The same keys are also provided to 231 the assigned HA. The HAC also provides the MN with MIP6 232 bootstrapping information such as the address of the HA, the Home 233 network prefix, and the IPv6 and/or IPv4 HoA. 235 The MN and HA use security associations based on the keys and SPIs 236 generated by the HAC and delivered to the MN and HA. Figure 1 below 237 is an illustration of the process: 239 MN HAC HA 240 -- --- -- 241 | | | 242 | /-------------------------\ | | 243 |/ \| | 244 |\ TLS session setup /| | 245 | \-------------------------/ | | 246 | | | 247 | /-------------------------\ | | 248 |/ MN Authentication \| | 249 |\ /| | 250 | \-------------------------/ | | 251 | | | 252 | /-------------------------\ | | 253 |/ HAC provisions the MN \| | 254 |\ keys, SPI and MIP6 parms /| | 255 | \-------------------------/ | | 256 | |--MNID, keys, SPI->| 257 | | | 258 | /--------------------------------------------\ | 259 |/ MN-HA SA established; Secures \ | 260 |\ signaling and optionally user traffic / | 261 | \--------------------------------------------/ | 262 | | 263 |------------BU(encrypted)----------------------->| 264 | | 265 |<---------BAck(encrypted)------------------------| 267 Figure 1: High level architecture 269 4.2. Architecture 271 The TLS-based security architecture is shown in Figure 2. The 272 signaling message exchange between the MN and the HAC is protected by 273 TLS. It should be noted that a HAC, a AAA server and a HA are 274 logically separate entities and can be collocated in all possible 275 combinations. There MUST be a strong trust relationship between the 276 HA and the HAC, and the communication between them MUST be both 277 integrity and confidentially protected. 279 +------+ +------+ +------+ 280 |Mobile| TLS |Home | AAA | AAA | 281 | Node |<----------->|Agent |<---------->|Server| 282 | | |Contrl| | | 283 +------+ +------+ +------+ 284 ^ ^ ^ 285 | | | 286 | BU/BA/../ | e.g. AAA | AAA 287 | (Data) | | 288 | v | 289 | +---------+ | 290 | | MIPv6 | | 291 +--------------->| Home |<-------------+ 292 | Agent(s)| 293 +---------+ 295 Figure 2: TLS-based Security Architecture Overview 297 4.3. Security Association Management 299 Once the MN has contacted the HAC and mutual authentication has taken 300 place between the MN and the HAC, the HAC securely provisions the MN 301 with all security related information inside the TLS protected 302 tunnel. This security related information constitutes a security 303 association (SA) between the MN and the HA. The created SA MUST NOT 304 be tied to the Care-of Address (CoA) of the MN. 306 The HAC may proactively distribute the SA information to HAs, or the 307 HA may query the SA information from the HAC once the MN contacts the 308 HA. If the HA requests SA information from the HAC, then the HA MUST 309 be able to query/index the SA information from the HAC based on the 310 Security Parameter Index (SPI) identifying the correct security 311 association between the MN and the HA. 313 The HA may want the MN to re-establish the SA even if the existing SA 314 is still valid. The HA can indicate this to the MN using a dedicated 315 Status Code in a BA (value set to REINIT_SA_WITH_HAC). As a result, 316 the MN SHOULD contact the HAC prior to the SA timing out, and the HAC 317 would provision the MN and HAs with a new SA to be used subsequently. 319 The SA established between MN and HAC SHALL contain at least the 320 following information: 322 Mobility SPI: 324 This parameter is an SPI used by the MN and the HA to index the SA 325 between the MN and the HA. The HAC is responsible for assigning 326 SPIs to MNs. There is only one SPI for both binding management 327 messaging and possible user data protection. The same SPI is used 328 for both directions between the MN and the HA. The SPI values are 329 assigned by the HAC. The HAC MUST ensure uniqueness of the SPI 330 values across all MNs controlled by the HAC. 332 MN-HA keys for ciphering: 334 A pair of symmetric keys (MN -> HA, HA -> MN) used for ciphering 335 Mobile IPv6 traffic between the MN and the HA. The HAC is 336 responsible for generating these keys. The key generation 337 algorithm is specific to the HAC implementation. 339 MN-HA shared key for integrity protection: 341 A pair of symmetric keys (MN -> HA, HA -> MN) used for integrity 342 protecting Mobile IPv6 traffic between the MN and the HA. This 343 includes both binding management messages and reverse tunneled 344 user data traffic between the MN and the HA. The HAC is 345 responsible for generating these keys. The key generation 346 algorithm is specific to the HAC implementation. In case of 347 combined algorithms a separate integrity protection key is not 348 needed and may be omitted, i.e., the encryption keys SHALL be 349 used. 351 Security association validity time: 353 This parameter represents the validity time for the security 354 association. The HAC is responsible for defining the lifetime 355 value based on its policies. The lifetime may be in the order of 356 hours or weeks. The MN MUST re-contact the HAC before the SA 357 validity time ends. 359 Security Association Scope: 361 This parameter defines whether the security association is applied 362 to Mobile IPv6 signaling messages only, or to both Mobile IPv6 363 signaling messages and data traffic. 365 Selected ciphersuite: 367 This parameter is the ciphersuite used to protect the traffic 368 between the MN and the HA. This includes both binding management 369 messages and reverse tunneled user data traffic between the MN and 370 the HA. The selected algorithms SHOULD be one of the mutually 371 supported ciphersuites of the negotiated TLS version between the 372 MN and the HAC. The HAC is responsible for choosing the mutually 373 supported ciphersuite that complies with the policy of the HAC. 374 Obviously, the HAs under HAC's management must have at least one 375 ciphersuite with the HAC in common and need to be aware of the 376 implemented ciphersuites. The selected ciphersuite is the same 377 for both directions (MN -> HA and HA -> MN). 379 Sequence numbers: 381 A monotonically increasing unsigned sequence number used in all 382 protected packets exchanged between the MN and the HA in the same 383 direction. Sequence numbers are maintained per direction, so each 384 SA includes two independent sequence numbers (MN -> HA, HA -> MN). 385 The initial sequence number for each direction MUST always be set 386 to 0 (zero). Sequence numbers cycle to 0 (zero) when increasing 387 beyond their maximum defined value. 389 4.4. Bootstrapping of Additional Mobile IPv6 Parameters 391 When the MN contacts the HAC to distribute of the security related 392 information, the HAC may also provision the MN with various Mobile 393 IPv6 related bootstrapping information. Bootstrapping of the 394 following information SHOULD at least be possible: 396 Home Agent IP Address: 398 Concerns both IPv6 and IPv4 home agent addresses. 400 Mobile IPv6 Service Port Number: 402 The port number where the HA is listening to UDP [RFC0768] 403 packets. 405 Home Address: 407 Concerns both IPv6 and IPv4 Home Addresses. 409 Home Link Prefix: 411 Concerns the IPv6 Home link prefix and the associated prefix 412 length. 413 DNS Server Address: 415 The address of a DNS server that can be reached via the HA. DNS 416 queries in certain cases cannot be routed to the DNS servers 417 assigned by the access network to which the MN is attached and 418 hence an additional DNS server address which is reachable via the 419 HA needs to be configured. 421 The Mobile IPv6 related bootstrapping information is delivered from 422 the HAC to the MN over the same TLS protected tunnel as the security 423 related information. 425 4.5. Protecting Traffic Between Mobile Node and Home Agent 427 The same integrity and confidentiality algorithms MUST be used to 428 protect both binding management messages and reverse tunneled user 429 data traffic between the MN and the HA. Generally, all binding 430 management messages (BUs, BAs and so on) MUST be integrity protected 431 and SHOULD be confidentially protected. The reverse tunneled user 432 data traffic SHOULD be equivalently protected. Generally, the 433 requirements stated in [RFC3775] concerning the protection of the 434 traffic between the MN and the HA also apply to the mechanisms 435 defined by this specification. 437 5. Mobile Node to Home Agent Controller Communication 439 5.1. Request-response Message Framing over TLS-tunnel 441 The MN and the HAC communicate with each other using a simple lock- 442 step request-response protocol that is run inside the protected TLS- 443 tunnel. A generic message container framing for the request messages 444 and for the response messages is defined. The message containers are 445 only meant to be exchanged on top of connection oriented TLS-layer. 446 Therefore, the end of message exchange is determined by the other end 447 closing the transport connection (assuming the "application layer" 448 has also indicated the completion of the message exchange). The peer 449 initiating the TLS-connection is always sending "Requests" and the 450 peer accepting the TLS-connection is always sending "Responses". The 451 format of the message container is shown in Figure 3. 453 All data inside the Content portion of the message container MUST be 454 encoded using octets. Fragmentation of message containers is not 455 supported, which means one request or response at the "application 456 layer" MUST NOT exceed the maximum size allowed by the message 457 container format. 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Ver | Rsrvd | Identifier | Length | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Content portion.. ~ 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 Figure 3: Request-Response Message Container 469 The three bit Ver field identifies the protocol version. The current 470 version is 0 i.e. all bits are set to value 0 (zero). 472 The Rsrvd field MUST be set to value 0 (zero), 474 The Identifier field is meant for matching requests and responses. 475 The valid Identifier values are between 1-255. The value 0 MUST NOT 476 be used. The first request for each communication session between 477 the MN and the HAC MUST have the Identifier values set to 1. 479 The Length field tells the length of the Content portion of the 480 container (i.e. Reserved octet, Identifier octet and Length field 481 are excluded). The Content portion length MUST always be at least 482 one octet up to 65535 octets. The value is in network order. 484 5.2. Request-response Message Content Encoding 486 The encoding of the message content is similar to HTTP header 487 encoding, and complies to the augmented Backus-Naur Form (BNF) 488 defined in Section 2.1 of [RFC2616]. All presented hexadecimal 489 numbers are in network byte order. From now on, we use TypeValue 490 header (TV-header) term to refer request-response message content 491 HTTP-like headers. 493 5.3. Request-Response Message Exchange 495 The message exchange between the MN and the HAC is a simple lock-step 496 request-response type as stated in Section 5.1. A request message 497 includes monotonically increasing Identifier value that is copied to 498 the corresponding response message. Each request MUST have a 499 different Identifier value. Hence, a reliable connection oriented 500 transport below the message container framing is assumed. The number 501 of request-response message exchanges MUST NOT exceed 255. 503 Each new communication session between the MN and the HAC MUST reset 504 the Identifier value to 1. The MN is also the peer that always sends 505 only request messages and the HAC only sends response messages. Once 506 the request-response message exchange completes, the HAC and the MN 507 MUST close the transport connection and the corresponding TLS-tunnel. 509 In a case of a HAC side error, the HAC MUST send a response back to a 510 MN with an appropriate status code and then close the transport 511 connection. 513 The first request message - MHAuth-Init - (i.e. the Identifier is 1) 514 MUST always contain at least the following parameters: 516 MN-Identity - See Section 5.5.1. 517 Authentication Method - See Section 5.5.2. 519 The first response message - MHAuth-Init - (i.e. the Identifier is 1) 520 MUST contain at minimum the following parameters: 522 Selected authentication Method - See Section 5.5.2. 524 The last request message from the MN side - MHAuth-Done - MUST 525 contain the following parameters: 527 Security Association Scope - See Section 5.6.4. 528 Proposed ciphersuites - See Section 5.6.5. 529 Message Authenticator - See Section 5.5.5. 531 The last response message - MHAuth-Done - that ends the request- 532 response message exchange MUST contain the following parameters: 534 Status Code - See Section 5.5.4. 535 Message Authenticator - See Section 5.5.5. 537 And in a case of successful authentication the following additional 538 parameters: 540 Selected ciphersuite - See Section 5.6.5. 541 Security Association Scope - See Section 5.6.4. 542 The rest of the security association data - See Section 5.6. 544 5.4. Home Agent Controller Discovery 546 All bootstrapping information, whether for setting up the SA or for 547 bootstrapping Mobile IPv6 specific information, is exchanged between 548 the MN and the HAC using the framing protocol defined in Section 5.1. 549 The IP address of the HAC MAY be statically configured to the MN or 550 may be dynamically discovered using DNS. In a case of DNS-based HAC 551 discovery, the MN either queries an A/AAAA or a SRV record for the 552 HAC IP address. The actual domain name used in queries is up to the 553 deployment to decide and out of scope of this specification. 555 5.5. Generic Request-Response Parameters 557 5.5.1. Mobile Node Identifier 559 An identifier that identifies a MN. The Mobile Node Identifier is in 560 form of a Network Access Identifier (NAI) [RFC4282]. 562 mn-id = "mn-id" ":" nai CRLF 563 nai = username 564 | "@" realm 565 | username "@" realm 566 ... 568 5.5.2. Authentication Method 570 The HAC is the peer that mandates the authentication method. The MN 571 sends its authentication method proposal to the HAC. The HAC, upon 572 receipt of the MN proposal returns the selected authentication 573 method. The MN MUST propose at least one authentication method. The 574 HAC MUST select exactly one authentication method, or return an error 575 and then close the connection. 577 auth-method = "auth-method" ":" a-method *("," a-method) CRLF 578 a-method = 579 "psk" ; Pre-shared key based authentication 580 | "eap" ; EAP-based authentication 582 5.5.3. Extensible Authentication Protocol Payload 584 Each Extensible Authentication Protocol (EAP) [RFC3748] message is an 585 encoded string of hexadecimal numbers. The "eap-payload" is 586 completely transparent what EAP-method or EAP message is carried 587 inside it. The "eap-payload" can appear in both request and response 588 messages: 590 eap-payload = "eap-payload" ":" 1*(HEX HEX) CRLF 592 5.5.4. Status Code 594 The "status-code" MUST only be present in the response message that 595 ends the request-response message exchange. The "status-code" 596 follows the principles of HTTP and the definitions found in Section 597 10 of RFC 2616 also apply for these status codes listed below: 599 status-code = "status-code" ":" status-value CRLF 600 status-value = 601 "100" ; Continue 602 | "200" ; OK 603 | "400" ; Bad Request 604 | "401" ; Unauthorized 605 | "500" ; Internal Server Error 606 | "501" ; Not Implemented 607 | "503" ; Service Unavailable 608 | "504" ; Gateway Time-out 610 5.5.5. Message Authenticator 612 The "auth" header contains data used for authentication purposes. It 613 MUST be the last TV-header in the message and calculated over the 614 whole message till the start of the "msg-header": 616 msg-auth = "auth" ":" 1*(HEX HEX) CRLF 618 5.5.6. Retry After 620 retry-after = "retry-after" ":" rfc1123-date CRLF 622 5.5.7. End of Message Content 624 end-of-message = 2CRLF 626 5.5.8. Random Values 628 Random numbers generated by the MN and the HAC, respectively. The 629 length of the random number MUST be 32 octets (before TV-header 630 encoding): 632 mn-rand = "mn-rand" ":" 32(HEX HEX) CRLF 633 hac-rand = "hac-rand" ":" 32(HEX HEX) CRLF 635 5.6. Security Association Configuration Parameters 637 During the Mobile IPv6 bootstrapping, the MN and the HAC negotiate a 638 single ciphersuite for protecting the traffic between the MN and the 639 HA. The allowed ciphersuites for this specification are a subset of 640 those in TLS v1.2 (see Annex A.5 of [RFC5246]) as per Section 5.6.5. 641 This might appear as a constraint as the HA and the HAC may have 642 implemented different ciphersuites. These two nodes are, however, 643 assumed to belong to the same administrative domain. In order to 644 avoid exchanging supported MN-HA ciphersuites in the MN-HAC protocol 645 and to reuse the TLS ciphersuite negotiation procedure we make this 646 simplifying assumption. The selected ciphersuite MUST provide 647 integrity and confidentiality protection. 649 Section 5.6.5 provides the mapping from the TLS ciphersuites to the 650 integrity and encryption algorithms allowed for MN-HA protection. 651 This mapping mainly ignores the authentication algorithm part that is 652 not required within the context of this specification. For example, 653 [RFC5246] defines a number of AES based ciphersuites for TLS 654 including 'TLS_RSA_WITH_AES_128_CBC_SHA'. For this specification the 655 relevant part is 'AES_128_CBC_SHA'. 657 All the parameters described in the following sections apply only to 658 a request-response protocol response message to the MN. The MN has 659 no way affecting to the provisioning decision of the HAC. 661 5.6.1. Security Parameter Index 663 The 28-bit unsigned SPI number identifies the SA used between the MN 664 and the HA. The value 0 (zero) is reserved and MUST NOT be used. 665 Therefore, values ranging from 1 to 268435455 are valid. 667 The TV-header corresponding to the SPI number is: 669 mip6-spi = "mip6-spi" ":" 1*DIGIT CRLF 671 5.6.2. MN-HA Shared Keys 673 The MN-HA shared integrity (ikey) and encryption (ekey) keys are used 674 to protect the traffic between the MN and the HA. The length of 675 these keys depend on the selected ciphersuite. 677 The TV-headers that carry these two parameters are: 679 mip6-mn-to-ha-ikey = "mip6-mn-to-ha-ikey" ":" 1*(HEX HEX) CRLF 680 mip6-ha-to-mn-ikey = "mip6-ha-to-mn-ikey" ":" 1*(HEX HEX) CRLF 681 mip6-mn-to-ha-ekey = "mip6-mn-to-ha-ekey" ":" 1*(HEX HEX) CRLF 682 mip6-ha-to-mn-ekey = "mip6-ha-to-mn-ekey" ":" 1*(HEX HEX) CRLF 684 5.6.3. Security Association Validity Time 686 The end of the SA validity time is encoded using the "rfc1123-date" 687 format, as defined in Section 3.3.1 of [RFC2616]. 689 The TV-header corresponding to the SA validity time value is: 691 mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date 692 CRLF 694 5.6.4. Security association scope (SAS) 696 The SA is applied either to Mobile IPv6 signaling messages only, or 697 to both Mobile IPv6 signaling messages and data traffic. This policy 698 MUST be agreed between the MN and HA prior to using the SA. 699 Otherwise the receiving side would not be aware of whether the SA 700 applies to data traffic and could not decide how to act when 701 receiving unprotected packets of PType 1 (see Section 6.4). 703 mip6-sas = "mip6-sas" ":" 1DIGIT CRLF 705 where a value of "0" indicates that the SA does not protect data 706 traffic and a value of "1" indicates that all data traffic MUST be 707 protected by the SA. If the mip6-sas value of an SA is set to 1, any 708 packet received with a PType value that does not match the mip6-sas 709 value of the SA MUST be silently discarded. 711 The HAC is the peer that mandates the used security association 712 scope. The MN sends its proposal to the HAC but eventually the 713 security association scope returned from the HAC defines the used 714 scope. 716 5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping 718 The ciphersuite negotiation between HAC and MN uses a subset of the 719 TLS 1.2 ciphersuites and follows the TLS 1.2 numeric representation 720 defined in Annex A.5 of [RFC5246]. The TV-headers corresponding to 721 the selected ciphersuite and ciphersuite list are: 723 mip6-ciphersuite = "mip6-ciphersuite" ":" csuite CRLF 724 csuite = "{" suite "}" 725 suite = 726 "00" "," "02" ; CipherSuite NULL_SHA = {0x00,0x02} 727 | "00" "," "3B" ; CipherSuite NULL_SHA256 = {0x00,0x3B} 728 | "00" "," "0A" ; CipherSuite 3DES_EDE_CBC_SHA = {0x00,0x0A} 729 | "00" "," "2F" ; CipherSuite AES_128_CBC_SHA = {0x00,0x2F} 730 | "00" "," "3C" ; CipherSuite AES_128_CBC_SHA256 = {0x00,0x3C} 731 mip6-suitelist = "mip6-suitelist" ":" csuite *("," csuite) CRLF 733 All other Ciphersuite values are reserved. 735 The following integrity algorithms MUST be supported by all 736 implementations: 738 HMAC-SHA1-96 [RFC2404] 739 AES-XCBC-MAC-96 [RFC3566] 741 The binding management messages between the MN and HA MUST be 742 integrity protected. Implementations MUST NOT use a NULL integrity 743 algorithm. 745 The following encryption algorithms MUST be supported: 747 NULL [RFC2410] 748 TripleDES-CBC [RFC2451] 749 AES-CBC with 128-bit keys [RFC3602] 751 Traffic between MN and HA MAY be encrypted. Any integrity-only 752 CipherSuite makes use of the NULL encryption algorithm. 754 Note: In the present version, this document does not consider 755 combined algorithms. The following table provides the mapping of 756 each ciphersuite to a combination of integrity and encryption 757 algorithms that are part of the negotiated SA between MN and HA. 759 +-------------------+-----------------+--------------------------+ 760 |Ciphersuite |Integ. Algorithm |Encr. Algorithm | 761 +-------------------+-----------------+--------------------------+ 762 |NULL_SHA |HMAC-SHA1-96 |NULL | 763 |NULL_SHA256 |AES-XCBC-MAC-96 |NULL | 764 |3DES_EDE_CBC_SHA |HMAC-SHA1-96 |TripleDES-CBC | 765 |AES_128_CBC_SHA |HMAC-SHA1-96 |AES-CBC with 128-bit keys | 766 |AES_128_CBC_SHA256 |AES-XCBC-MAC-96 |AES-CBC with 128-bit keys | 767 +-------------------+----------------+---------------------------+ 769 Ciphersuite-to-Algorithm Mapping 771 5.7. Mobile IPv6 Bootstrapping Parameters 773 In parallel with the SA bootstrapping, the HAC SHOULD provision the 774 MN with relevant Mobile IPv6 related bootstrapping information. 776 The following generic BNFs are used to form IP addresses and 777 prefixes. They are used in subsequent sections. 779 ip6-addr = 7( word ":" ) word CRLF 780 word = 1*4HEX 781 ip6-prefix = ip6-addr "/" 1*2DIGIT 782 ip4-addr = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 783 ip4-subnet = ip4-addr "/" 1*2DIGIT 785 5.7.1. Home Agent Address 787 The HAC MAY provision the MN with an IPv4 or an IPv6 address of a HA, 788 or both. 790 mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr CRLF 791 mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr CRLF 793 5.7.2. Mobile IPv6 Service Port Number 795 The HAC SHOULD provision the MN with an UDP port number, where the HA 796 expects to receive UDP packets. If this parameter is not present, 797 then the IANA reserved port number (HALTSEC) MUST be used instead. 799 mip6-port = "mip6-port" ":" 1*5DIGIT CRLF 801 5.7.3. Home Addresses and Home Network Prefix 803 The HAC MAY provision the MN with an IPv4 or an IPv6 home address, or 804 both. The HAC MAY also provision the MN with its home network 805 prefix. 807 mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr CRLF 808 mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr CRLF 809 mip6-ip6-hnp = "mip6-ip6-hnp" ":" ip6-prefix CRLF 810 mip6-ip4-hnp = "mip6-ip4-hnp" ":" ip4-subnet CRLF 812 5.7.4. DNS Server 814 The HAC may also provide the MN with DNS server configuration 815 options. These DNS servers are reachable via the home agent. 817 dns-ip6 = "dns-ip6" ":" ip6-addr CRLF 818 dns-ip4 = "dns-ip4" ":" ip4-addr CRLF 820 5.8. Authentication of the Mobile Node 822 This section describes the basic operation required for the MN-HAC 823 mutual authentication and the channel binding. The authentication 824 protocol described as part of this section is a simple exchange that 825 follows the GPSK exchange used by EAP-GPSK [RFC5433]. It is secured 826 by the TLS tunnel and is cryptographically bound to the TLS tunnel 827 through channel binding based on [RFC5056] and on the channel binding 828 type 'tls-server-endpoint' described in [RFC5929]. As a result of 829 the channel binding type, this method can only be used with TLS 830 ciphersuites that use server certificates and the Certificate 831 handshake message. For example, TLS ciphersuites based on PSK or 832 anonymous authentication cannot be used. 834 The authentication exchange MUST be performed through the encrypted 835 TLS tunnel. It performs mutual authentication between the MN and the 836 HAC based on a pre-shared key (PSK) or based on an EAP-method (see 837 Section 5.9). The PSK protocol is described in this section. It 838 consists of the message exchanges (MHAuth-Init, MHAuth-Mid, MHAuth- 839 Done) in which both sides exchange nonces and their identities, and 840 compute and exchange a message authenticator 'auth' over the 841 previously exchanged values, keyed with the pre-shared key. The 842 MHAuth-Done messages are used to deal with error situations. Key 843 binding with the TLS tunnel is ensured by channel binding of the type 844 "tls-server-endpoint" as described by [RFC5929] where the hash of the 845 TLS server certificate serves as input to the 'auth' calculation of 846 the MHAuth messages. 848 Note: The authentication exchange is based on the GPSK exchange used 849 by EAP-GPSK. In comparison to GPSK, it does not support exchanging 850 an encrypted container (it always runs through an already protected 851 TLS tunnel). Furthermore, the initial request of the authentication 852 exchange (MHAuth-Init) is sent by the MN (client side) and is 853 comparable to EAP-Response/Identity, which reverses the roles of 854 request and response messages compared to EAP-GPSK. Figure 4 shows a 855 successful protocol exchange. 857 MN HAC 858 | | 859 | Request/MHAuth-Init (...) | 860 |------------------------------------------------------>| 861 | | 862 | Response/MHAuth-Init (...) | 863 |<------------------------------------------------------| 864 | | 865 | Request/MHAuth-Done (...) | 866 |------------------------------------------------------>| 867 | | 868 | Response/MHAuth-Done (...) | 869 |<------------------------------------------------------| 870 | | 872 Figure 4: Authentication of the Mobile Node Using Shared Secrets 874 1) Request/MHAuth-Init: (MN -> HAC) 875 mn-id, mn-rand, auth-method=psk 877 2) Response/MHAuth-Init: (MN <- HAC) 878 [mn-rand, hac-rand, auth-method=psk, [status],] auth 880 3) Request/MHAuth-Done: (MN -> HAC) 881 mn-rand, hac-rand, sa-scope, ciphersuite-list, auth 883 4) Response/MHAuth-Done: (MN <- HAC) 884 [sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand, 885 hac-rand, status, auth 887 Where: 889 auth = HMAC-SHA256(PSK, msg-octets | CB-octets) 891 The length "mn-rand", "hac-rand" is 32 octets. Note that "|" 892 indicates concatenation and optional parameters are shown in square 893 brackets [..]. The square brackets can be nested. 895 The shared secret PSK can be variable length. 'msg-octets' includes 896 all payload parameters of the respective message to be signed except 897 the 'auth' payload. CB-octets is the channel binding input to the 898 auth calculation that is the "TLS-server-endpoint" channel binding 899 type. The content and algorithm (only required for the "TLS-server- 900 endpoint" type) are the same as described in [RFC5929]. 902 The MN starts by selecting a random number 'mn-rand' and choosing a 903 list of supported authentication methods coded in 'auth-method'. The 904 MN sends its identity 'mn-id', 'mn-rand' and 'auth-method' to the HAC 905 in MHAuth-Init. The decision of which authentication method to offer 906 and which to pick is policy- and implementation-dependent and, 907 therefore, outside the scope of this document. 909 In MHAuth-Done, the HAC sends a random number 'hac-rand' and the 910 selected ciphersuite. The selection MUST be one of the MN-supported 911 ciphersuites as received in 'ciphersuite-list'. Furthermore, it 912 repeats the received parameters of the MHAuth-Init message 'mn-rand'. 913 It computes a message authenticator 'auth' over all the transmitted 914 parameters except 'auth' itself. The HAC calculates 'auth' over all 915 parameters and appends it to the message. 917 The MN verifies the received MAC and the consistency of the 918 identities, nonces, and ciphersuite parameters transmitted in MHAuth- 919 Auth. In case of successful verification, the MN computes a MAC over 920 the session parameter and returns it to the HAC in MHAuth-Done. The 921 HAC verifies the received MAC and the consistency of the identities, 922 nonces, and ciphersuite parameters transmitted in MHAuth-Init. If 923 the verification is successful, MHAuth-Done is prepared and sent by 924 the HAC to confirm successful completion of the exchange. 926 5.9. Extensible Authentication Protocol Methods 928 Basic operation required for the MN-HAC mutual authentication using 929 EAP-based methods. 931 MN HAC 932 | | 933 | Request/MHAuth-Init (...) | 934 |------------------------------------------------------>| 935 | | 936 | Response/MHAuth-Init (..., | 937 | eap-payload=EAP-Request/Identity) | 938 |<------------------------------------------------------| 939 | | 940 | Request/MHAuth-Mid (eap-payload= | 941 | EAP-Response/Identity) | 942 |------------------------------------------------------>| 943 | | 944 | Response/MHAuth-Mid (eap-payload=EAP-Request/...) | 945 |<------------------------------------------------------| 946 | | 947 : : 948 : ..EAP-method specific exchanges.. : 949 : : 950 | | 951 | Request/MHAuth-Done (eap-payload=EAP-Response/..., | 952 | ..., auth) | 953 |------------------------------------------------------>| 954 | | 955 | Response/MHAuth-Done (eap-payload=EAP-Success, | 956 | ..., auth) | 957 |<------------------------------------------------------| 958 | | 960 Figure 5: Authentication of the Mobile Node Using EAP 962 1) Request/MHAuth-Init: (MN -> HAC) 963 mn-id, mn-rand, auth-method=eap 965 2) Response/MHAuth-Init: (MN <- HAC) 966 [auth-method=eap, eap, [status,]] auth 968 3) Request/MHAuth-Mid: (MN -> HAC) 969 eap, auth 971 4) Response/MHAuth-Mid: (MN <- HAC) 972 eap, auth 974 MHAuth-Mid exchange is repeated as many times as needed by the 975 used EAP-method. 977 5) Request/MHAuth-Done: (MN -> HAC) 978 sa-scope, ciphersuite-list, eap, auth 980 6) Response/MHAuth-Done: (MN <- HAC) 981 [sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap, 982 status, auth 984 Where: 986 auth = HMAC-SHA256(shared-key, msg-octets | CB-octets) 988 In MHAuth-Init and MHAuth-Mid messages, shared-key is set to "1". If 989 the EAP-method is key-deriving and creates a shared MSK key as a side 990 effect of Authentication shared-key MUST be the MSK in all MHAuth- 991 Done messages. This MSK MUST NOT be used for any other purpose. In 992 case the EAP method does not generate an MSK key, shared-key is set 993 to "1". 995 'msg-octets' includes all payload parameters of the respective 996 message to be signed except the 'auth' payload. CB-octets is the 997 channel binding input to the AUTH calculation that is the "TLS- 998 server-endpoint" channel binding type. The content and algorithm 999 (only required for the "TLS-server-endpoint" type) are the same as 1000 described in [RFC5929]. 1002 6. Mobile Node to Home Agent communication 1004 6.1. General 1006 The following sections describe the packet formats used for the 1007 traffic between the MN and the HA. This traffic includes binding 1008 management messages (for example, BU and BA messages), reverse 1009 tunneled and encrypted user data, and reverse tunneled plain text 1010 user data. This specification defines a generic packet format, where 1011 everything is encapsulated inside UDP. See Section 6.3 and 1012 Section 6.4 for detailed illustrations of the corresponding packet 1013 formats. 1015 The Mobile IPv6 service port number is where the HA expects to 1016 receive UDP packets. The same port number is used for both binding 1017 management messages and user data packets. The reason for 1018 multiplexing data and control messages over the same port number is 1019 due to the possibility of Network Address and Port Translators 1020 located along the path between the MN and the HA. The Mobile IPv6 1021 service MAY use any ephemeral port number as the UDP source port, and 1022 MUST use the Mobile IPv6 service port number as the UDP destination 1023 port. The Mobile IPv6 service port is either dynamically assigned to 1024 the MN during the bootstrapping phase (i.e. the mip6-port parameter) 1025 or in absence of the bootstrapping parameter the IANA reserved port 1026 (HALTSEC) MUST be used. 1028 The encapsulating UDP header is immediately followed by a 4-bit 1029 Packet Type (PType) field that defines whether the packet contains an 1030 encrypted mobility management message or a, an encrypted user data 1031 packet, or a plain text user data packet. 1033 The Packet Type field is followed by a 28-bit SPI value, which 1034 identifies the correct SA concerning the encrypted packet. For any 1035 packet that is neither integrity protected nor encrypted (i.e. no SA 1036 is applied by the originator) the SPI MUST be set to 0 (zero). 1037 Mobility management messages MUST always be at least integrity 1038 protected. Hence, mobility management messages MUST NOT be sent with 1039 a SPI value of 0 (zero). 1041 There is always only one SPI per MN-HA mobility session and the same 1042 SPI is used for all types of protected packets independent of the 1043 direction. 1045 The SPI value is followed by a 32-bit Sequence Number value that is 1046 used to identify retransmissions of encrypted messages. Each 1047 endpoint in the security association maintains two "current" Sequence 1048 Numbers: the next one to be used for a packet it initiates and the 1049 next one it expects to see in a packet from the other end. If the MN 1050 and the HA ends initiate very different numbers of messages, the 1051 Sequence Numbers in the two directions can be very different. In a 1052 case encryption is not used, the Sequence Number MUST be set to 0 1053 (zero). Note that the HA SHOULD initiate a re-establishement of the 1054 SA before any of the Sequence Number cycle. 1056 Finally, the Sequence Number field is followed by the data portion, 1057 whose content is identified by the Packet Type. The data portion may 1058 be protected. 1060 6.2. Security Parameter Index 1062 The SPI is a 32-bit field, where the first 4 bits indicate the Packet 1063 Type (PType) of the UDP encapsulated packet. The SPI value itself 1064 consists of the remaining 28-bit of the SPI field. The SPI field is 1065 treated as one 32-bit field during the integrity protection 1066 calculation. 1068 0 1 2 3 1069 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 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | PType | SPI | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 Figure 6: Security Parameter Index with Packet Type 1076 A SPI value of 0 (zero) indicates a plaintext packet. If the packet 1077 is integrity protected or both integrity protected and encrypted, the 1078 SPI value MUST be different from 0. 1080 6.3. Binding Management Message Formats 1082 The binding management messages that are only meant to be exchanged 1083 between the MN and the HA MUST be integrity protected and MAY be 1084 encrypted. They MUST use the packet format shown in Figure 7. All 1085 packets that are specific to the Mobile IPv6 protocol and contain a 1086 Mobility Header (as defined in Section 6.1.1. of RFC 3775) SHOULD use 1087 the packet format shown in Figure 7. (This means that some Mobile 1088 IPv6 mobility management messages, such as the HoTI message, as 1089 treated as data packets and using encapsulation described in 1090 Section 6.4). 1092 0 1 2 3 1093 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 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | | 1096 : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : 1097 | | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | | 1100 : UDP header (src-port=Xp,dst-port=Yp) : 1101 | | 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 1103 |PType=8| SPI | ^Int. 1104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 1105 | Sequence Number | |ered 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- 1107 | Payload Data* (variable) | | ^ 1108 : : | | 1109 | | |Conf. 1110 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 1111 | | Padding (0-255 bytes) | |ered* 1112 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 1113 | | Pad Length | Next Header | v v 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 1115 | Integrity Check Value-ICV (variable) | 1116 : : 1117 | | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 Figure 7: UDP Encapsulated Binding Management Message Format 1122 The PType value 8 (eight) identifies that the UDP encapsulated packet 1123 contains a RFC 3775 defined Mobility Header and other relevant IPv6 1124 extension headers. Note, there is no additional IP header inside the 1125 encapsulated part. The Next Header field MUST be set to value of the 1126 first encapsulated header. The encapsulated headers follow the 1127 natural IPv6 and Mobile IPv6 extension header alignment and 1128 formatting rules. 1130 The Padding, Pad Length, Next Header and ICV fields follow the rules 1131 of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this 1132 document. For a SPI value of 0 (zero) that indicates an unprotected 1133 packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT 1134 be present. 1136 The source and destination IP addresses of the outer IP header (i.e. 1137 the src-addr and the dst-addr in Figure 7) use the current care-of 1138 address of the MN and the HA address. 1140 6.4. Reverse Tunneled User Data Packet Formats 1142 There are two types of reverse tunneled user data packets between the 1143 MN and the HA. Those that are integrity protected and encrypted and 1144 those that are plaintext. The MN or the HA decide whether to apply 1145 integrity protection and encryption to a packet or to send it in 1146 plaintext based on the mip6-sas value in the SA. If the mip6-sas is 1147 set to 1 the originator MUST NOT send any plaintext packet, and the 1148 receiver MUST silently discard any packet with the PType set to 0 1149 (unprotected). It is RECOMMENDED to apply confidentiality and 1150 integrity protection of user data traffic. The reverse tunneled IPv4 1151 or IPv6 user data packets are encapsulated as-is inside the 'Payload 1152 Data' shown in Figure 8. and Figure 9. 1154 0 1 2 3 1155 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 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | | 1158 : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : 1159 | | 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | | 1162 : UDP header (src-port=Xp,dst-port=Yp) : 1163 | | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 |PType=1| SPI | ^Int. 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 1167 | Sequence Number | |ered 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- 1169 | Payload Data* (variable) | | ^ 1170 : : | | 1171 | | |Conf. 1172 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 1173 | | Padding (0-255 bytes) | |ered* 1174 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 1175 | | Pad Length | Next Header | v v 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 1177 | Integrity Check Value-ICV (variable) | 1178 : : 1179 | | 1180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 Figure 8: UDP Encapsulated Protected User Data Packet Format 1184 The PType value 1 (one) identifies that the UDP encapsulated packet 1185 contains an encrypted tunneled IPv4/IPv6 user data packet. The Next 1186 Header field header MUST be set to value corresponding the tunneled 1187 IP packet (e.g., 41 for IPv6). 1189 The Padding, Pad Length, Next Header and ICV fields follow the rules 1190 of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this 1191 document. For a SPI value of 0 (zero) that indicates an unprotected 1192 packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT 1193 be present. 1195 The source and destination IP addresses of the outer IP header (i.e., 1196 the src-addr and the dst-addr in Figure 8) use the current care-of 1197 address of the MN and the HA address. The ESP protected inner IP 1198 header, which is not shown in Figure 8, uses the home address of the 1199 MN and the correspondent node (CN) address. 1201 0 1 2 3 1202 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 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | | 1205 : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : 1206 | | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | | 1209 : UDP header (src-port=Xp,dst-port=Yp) : 1210 | | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 |PType=0| 0 | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | 0 | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | | 1217 : Payload Data (plain IPv4 or IPv6 Packet) : 1218 | | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 Figure 9: UDP Encapsulated Non-Protected User Data Packet Format 1223 The PType value 0 (zero) identifies that the UDP encapsulated packet 1224 contains a plaintext tunneled IPv4/IPv6 user data packet. Also the 1225 SPI and the Sequence Number fields MUST be set to 0 (zero). 1227 The source and destination IP addresses of the outer IP header (i.e., 1228 the src-addr and the dst-addr in Figure 9) use the current care-of 1229 address of the MN and the HA address. The plain text inner IP header 1230 uses the home address of the MN and the CN address. 1232 7. Route Optimization 1234 The treatment of MN-CN route optimization is outside the scope of 1235 this document. 1237 8. IANA Considerations 1239 8.1. New Registry: Packet Type 1241 IANA is requested to create a new registry for the Packet Type as 1242 described in Section 6.1. 1244 Packet Type | Value 1245 ----------------------------------+---------------------------------- 1246 non-encrypted IP packet | 0 1247 encrypted IP packet | 1 1248 mobility header | 8 1250 Following the allocation policies from [RFC5226] new values for the 1251 Packet Type AVP MUST be assigned based on the "RFC Required" policy. 1253 8.2. HTTP Headers 1255 A number of HTTP headers with their respective parameters are 1256 reserved. See Section 5.6 and Section 5.7 for a list of header names 1257 and their parameters. 1259 8.3. Status Codes 1261 A new Status Code (to be used in BA messages) is reserved for the 1262 cases where the HA wants to indicate to the MN that it needs to re- 1263 establish the SA information with the HAC. The Result Code is 1264 reserved from the 0-127 code space: 1266 REINIT_SA_WITH_HAC TBD1 1268 8.4. Port Numbers 1270 A new port number (HALTSEC) for UDP packets is reserved from the PORT 1271 NUMBERS registry. 1273 HALTSEC TBD2 1275 9. Security Considerations 1277 This document describes and uses a number of building blocks that 1278 introduce security mechanisms and need to inter-work in a secure 1279 manner. 1281 The following building blocks are considered from a security point of 1282 view: 1284 1. Discovery of the HAC 1285 2. Authentication and MN-HA SA establishment executed between the MN 1286 and the HAC (PSK or EAP-based) through a TLS tunnel 1287 3. Protection of MN-HA communication 1288 4. AAA Interworking 1290 9.1. Discovery of the HAC 1292 No dynamic procedure for discovering the HAC by the MN is described 1293 in this document. As such, no specific security considerations apply 1294 to the scope of this document. 1296 9.2. Authentication and Key Exchange executed between the MN and the 1297 HAC 1299 This document describes a simple authentication and MN-HA SA 1300 negotiation exchange over TLS. The TLS procedures remain unchanged; 1301 however, channel binding is provided. 1303 Authentication: Server-side certificate based authentication MUST be 1304 performed using TLS 1.2 [RFC5246]. 1306 The client-side authentication may depend on the specific 1307 deployment and is therefore not mandated. Note that TLS-PSK 1308 [RFC4279] cannot be used in conjunction with the methods described 1309 in section 5.8 and 5.9 of this document due to the limitations of 1310 the channel binding type used. 1312 Through the protected TLS tunnel, an additional authentication 1313 exchange is performed that provides client-side or mutual 1314 authentication and exchanges SA parameters and optional 1315 configuration data to be used in the subsequent protection of 1316 MN-HA communication. The additional authentication exchange can 1317 either be PSK-based (section 5.8) or EAP-based (section 5.9). 1318 Both exchanges are always performed within the protected TLS 1319 tunnel and MUST NOT be used as standalone protocols. 1321 The simple PSK-based authentication exchange provides mutual 1322 authentication and follows the GPSK exchange used by EAP-GPSK 1323 [RFC5433] and has similar properties, although some features of 1324 GPSK like the exchange of a protected container are not supported. 1326 The EAP-based authentication exchange simply defines message 1327 containers to allow carrying the EAP packets between the MN and 1328 the HAC. In principle, any EAP method can be used. However, it 1329 is strongly recommended to use only EAP methods that provide 1330 mutual authentication and that derive keys including an MSK key in 1331 compliance with [RFC3748]. 1333 Both exchanges use channel binding with the TLS tunnel. The 1334 channel binding type 'TLS-server-endpoint' as per [RFC5929] MUST 1335 be used. 1337 Dictionary Attacks: All messages of the authentication exchanges 1338 specified in this document are protected by TLS. However, any 1339 implementation SHOULD assume that the properties of the 1340 authentication exchange are the same as for GPSK [RFC5433] in case 1341 the PSK-based method as per section 5.8. is used, and are the same 1342 as those of the underlying EAP method in case the EAP-based 1343 exchange as per section 5.9 is used. 1345 Replay Protection: The underlying TLS protection provides protection 1346 against replays. 1348 Key Derivation and Key Strength: For TLS, the TLS specific 1349 considerations apply unchanged. For the authentication exchanges 1350 defined in this document, no key derivation step is performed as 1351 the MN-HA keys are generated by the HAC and are distributed to the 1352 MN through the secure TLS connection. 1354 Key Control: No joint key control for MN-HA keys is provided by this 1355 version of the specification. 1357 Lifetime: The TLS-protected authentication exchange between the MN 1358 and the HAC is only to bootstrap keys and other parameters for 1359 usage with MN-HA security. The SAs that contain the keys have an 1360 associated lifetime. The usage of Transport Layer Security (TLS) 1361 Session Resumption without Server-Side State, described in 1362 [RFC5077], provides the ability for the MN to minimize the latency 1363 of future exchanges towards the HA without having to keep state at 1364 the HA itself. 1366 Denial of Service Resistance: The level of resistance against denial 1367 of service attacks SHOULD be considered the same as for common TLS 1368 operation, as TLS is used unchanged. For the PSK-based 1369 authentication exchange, no additional factors are known. For the 1370 EAP-based authentication exchange, any considerations regarding 1371 denial-of-service resistance specific to the chosen EAP method are 1372 expected to be applicable and need to be be taken into account. 1374 Session Independence: Each individual TLS protocol run is 1375 independent from any previous exchange based on the security 1376 properties of the TLS handshake protocol. However, several PSK or 1377 EAP-based authentication exchanges can be performed across the 1378 same TLS connection. 1380 Fragmentation: TLS runs on top of TCP and no fragmentation specific 1381 considerations apply to the MN-HAC authentication exchanges. 1383 Channel Binding: Both the PSK and the EAP-based exchanges use 1384 channel binding with the TLS tunnel. The channel binding type 1385 'TLS-server-endpoint' as per [RFC5929] MUST be used. 1387 Fast Reconnect: This protocol provides session resumption as part of 1388 TLS and optionally the support for [RFC5077]. No fast reconnect 1389 is supported for the PSK-based authentication exchange. For the 1390 EAP-based authentication exchange, availability of fast reconnect 1391 depends on the EAP method used. 1393 Identity Protection: Based on the security properties of the TLS 1394 tunnel, passive user identity protection is provided. An attacker 1395 acting as man-in-the-middle in the TLS connection would be able to 1396 observe the MN identity value sent in MHAuth-Init messages. 1398 Protected Ciphersuite Negotiation: This protocol provides 1399 ciphersuite negotiation based on TLS. 1401 Confidentiality: Confidentiality protection of payloads exchanged 1402 between the MN and the HAC are protected with the TLS Record 1403 Layer. TLS ciphersuites with confidentiality and integrity 1404 protection MUST be negotiated and used in order to exchange 1405 security sensitive material inside the TLS connection. 1407 Cryptographic Binding: No cryptographic bindings are provided by 1408 this protocol specified in this document. 1410 Perfect Forward Secrecy: Perfect forward secrecy is provided with 1411 appropriate TLS ciphersuites. 1413 Key confirmation: Key confirmation of the keys established with TLS 1414 is provided by the TLS Record Layer when the keys are used to 1415 protect the subsequent TLS exchange. 1417 9.3. Protection of MN and HA Communication 1418 Authentication: Data origin authentication is provided for the 1419 communication between the MN and the HA. The chosen level of 1420 security of this authentication depends on the selected 1421 ciphersuite. Entity authentication is offered by the MN to HAC 1422 protocol exchange. 1424 Dictionary Attacks: The concept of dictionary attacks is not 1425 applicable to the MN-HA communication as the keying material used 1426 for this communication is randomly created by the HAC and its 1427 length depends on the chosen cryptographic algorithms. 1429 Replay Protection: Replay protection for the communication between 1430 the MN and the HA is provided based on sequence numbers and 1431 follows the design of IPsec ESP. 1433 Key Derivation and Key Strength: The strength of the keying material 1434 established for the communication between the MN and the HA is 1435 selected based on the negotiated ciphersuite (based on the MN-HAC 1436 exchange) and the key created by the HAC. The randomness 1437 requirements for security described in RFC 4086 [RFC4086] are 1438 applicable to the key generation by the HAC. 1440 Key Control: The keying material established during the MN-HAC 1441 protocol exchange for subsequent protection of the MN-HA 1442 communication is created by the HA and therefore no joint key 1443 control is provided for it. 1445 Key Naming: For the MN-HA communication the security associations 1446 are indexed with the help of the SPI and additionally based on the 1447 direction (in-bound communication or out-bound communication). 1449 Lifetime: The lifetime of the MN-HA security associations is based 1450 on the value in the mip6-sa-validity-end HTTP header field 1451 exchanged during the MN-HAC exchange. The HAC controls the SA 1452 lifetime. 1454 Denial of Service Resistance: For the communication between the MN 1455 and the HA there are no heavy cryptographic operations (such as 1456 public key computations). As such, there are no DoS concerns. 1458 Session Independence: Sessions are independent from each other when 1459 new keys are created by via the MN-HAC protocol. A new MN-HAC 1460 protocol run produces fresh and unique keying material for 1461 protection of the MN-HA communication. 1463 Fragmentation: There is no additional fragmentation support provided 1464 beyond what is offered by the network layer. 1466 Channel Binding: Channel binding is not applicable to the MN-HA 1467 communication. 1469 Fast Reconnect: The concept of fast reconnect is not applicable to 1470 the MN-HA communication. 1472 Identity Protection: User identities SHOULD NOT be exchanged between 1473 the MN and the HA. In a case binding management messages contain 1474 the user identity, the messages SHOULD be confidentity protected. 1476 Protected Ciphersuite Negotiation: The MN-HAC protocol provides 1477 protected ciphersuite negotiation through a secure TLS connection. 1479 Confidentiality: Confidentiality protection of payloads exchanged 1480 between the MN and the HAC (for Mobile IPv6 signaling and 1481 optionally for the data traffic) is provided utilizing algorithms 1482 negotiated during the MN-HAC exchange. 1484 Cryptographic Binding: No cryptographic bindings are provided by 1485 this protocol specified in this document. 1487 Perfect Forward Secrecy: Perfect forward secrecy is provided when 1488 the MN bootstraps new keying material with the help of the MN-HAC 1489 protocol (assuming that a proper TLS ciphersuite is used). 1491 Key confirmation: Key confirmation of the MN-HA keying material 1492 conveyed from the HAC to the MN is provided when the first packets 1493 are exchanged between the MN and the HA (in both directions as two 1494 different keys are used). 1496 9.4. AAA Interworking 1498 The AAA backend infrastructure interworking is not defined in this 1499 document and therefore out-of-scope. 1501 10. Acknowledgements 1503 The authors would like to thank Pasi Eronen, Domagoj Premec, and 1504 Christian Bauer for their comments. 1506 11. References 1507 11.1. Normative References 1509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1510 Requirement Levels", BCP 14, RFC 2119, March 1997. 1512 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1513 ESP and AH", RFC 2404, November 1998. 1515 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 1516 Its Use With IPsec", RFC 2410, November 1998. 1518 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 1519 Algorithms", RFC 2451, November 1998. 1521 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1522 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1523 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1525 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 1526 and Its Use With IPsec", RFC 3566, September 2003. 1528 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1529 Algorithm and Its Use with IPsec", RFC 3602, 1530 September 2003. 1532 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1533 in IPv6", RFC 3775, June 2004. 1535 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1536 Network Access Identifier", RFC 4282, December 2005. 1538 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1539 Channels", RFC 5056, November 2007. 1541 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1542 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1543 May 2008. 1545 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1546 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1548 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1549 for TLS", RFC 5929, July 2010. 1551 11.2. Informative References 1553 [I-D.patil-mext-mip6issueswithipsec] 1554 Patil, B., Premec, D., Perkins, C., and H. Tschofenig, 1555 "Problems with the use of IPsec as the security protocol 1556 for Mobile IPv6", draft-patil-mext-mip6issueswithipsec-03 1557 (work in progress), July 2010. 1559 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1560 August 1980. 1562 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1563 August 2002. 1565 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1566 Levkowetz, "Extensible Authentication Protocol (EAP)", 1567 RFC 3748, June 2004. 1569 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1570 Protect Mobile IPv6 Signaling Between Mobile Nodes and 1571 Home Agents", RFC 3776, June 2004. 1573 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1574 Requirements for Security", BCP 106, RFC 4086, June 2005. 1576 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1577 for Transport Layer Security (TLS)", RFC 4279, 1578 December 2005. 1580 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1581 Internet Protocol", RFC 4301, December 2005. 1583 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1584 RFC 4303, December 2005. 1586 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1587 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1588 April 2007. 1590 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1591 "Transport Layer Security (TLS) Session Resumption without 1592 Server-Side State", RFC 5077, January 2008. 1594 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 1595 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 1596 RFC 5433, February 2009. 1598 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1599 Routers", RFC 5555, June 2009. 1601 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1602 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1603 RFC 5996, September 2010. 1605 Authors' Addresses 1607 Jouni Korhonen (editor) 1608 Nokia Siemens Networks 1609 Linnoitustie 6 1610 Espoo FIN-02600 1611 Finland 1613 Email: jouni.nospam@gmail.com 1615 Basavaraj Patil 1616 Nokia 1617 6021 Connection Drive 1618 Irving, TX 75039 1619 USA 1621 Email: basavaraj.patil@nokia.com 1623 Hannes Tschofenig 1624 Nokia Siemens Networks 1625 Linnoitustie 6 1626 Espoo 02600 1627 Finland 1629 Phone: +358 (50) 4871445 1630 Email: Hannes.Tschofenig@gmx.net 1631 URI: http://www.tschofenig.priv.at 1633 Dirk Kroeselberg 1634 Nokia Siemens Networks 1635 St.-Martin-Str. 53 1636 Munich 81541 1637 Germany 1639 Email: dirk.kroeselberg@nsn.com