idnits 2.17.1 draft-ietf-mext-mip6-tls-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6275, updated by this document, for RFC5378 checks: 2008-06-09) -- 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 (September 13, 2011) is 4602 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 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 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 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: 6275 (if approved) B. Patil 5 Intended status: Experimental Nokia 6 Expires: March 16, 2012 H. Tschofenig 7 Nokia Siemens Networks 8 D. Kroeselberg 9 Siemens 10 September 13, 2011 12 Transport Layer Security-based Mobile IPv6 Security Framework for Mobile 13 Node to Home Agent Communication 14 draft-ietf-mext-mip6-tls-01.txt 16 Abstract 18 RFC 6275 Mobile IPv6 signaling between the mobile node and home agent 19 is secured using IPsec. The security association between a mobile 20 node and the home agent is established using IKEv1 or IKEv2. The 21 security model specified for Mobile IPv6, which relies on IKE/IPsec, 22 requires interaction between the Mobile IPv6 protocol part of the IP 23 stack and the IKE/IPsec part of the IP stack. The IPsec/IKEv2 based 24 security architectures makes implementation and deployment of the 25 protocol infeasible for numerous reasons. This document updates RFC 26 6275 and proposes an alternate security framework, which relies on 27 Transport Layer Security for establishing keying material and other 28 bootstrapping parameters required to protect Mobile IPv6 signaling 29 and data traffic between the mobile node and home agent. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on March 16, 2012. 48 Copyright Notice 49 Copyright (c) 2011 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 66 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. TLS-based Security Establishment . . . . . . . . . . . . . . . 6 68 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.3. Security Association Management . . . . . . . . . . . . . 8 71 4.4. Bootstrapping of Additional Mobile IPv6 Parameters . . . . 10 72 4.5. Protecting Traffic Between Mobile Node and Home Agent . . 11 73 5. Mobile Node to Home Agent Controller Communication . . . . . . 11 74 5.1. Request-response Message Framing over TLS-tunnel . . . . . 11 75 5.2. Request-response Message Content Encoding . . . . . . . . 12 76 5.3. Request-Response Message Exchange . . . . . . . . . . . . 12 77 5.4. Home Agent Controller Discovery . . . . . . . . . . . . . 13 78 5.5. Generic Request-Response Parameters . . . . . . . . . . . 13 79 5.5.1. Mobile Node Identifier . . . . . . . . . . . . . . . . 13 80 5.5.2. Authentication Method . . . . . . . . . . . . . . . . 14 81 5.5.3. Extensible Authentication Protocol Payload . . . . . . 14 82 5.5.4. Status Code . . . . . . . . . . . . . . . . . . . . . 14 83 5.5.5. Message Authenticator . . . . . . . . . . . . . . . . 15 84 5.5.6. Retry After . . . . . . . . . . . . . . . . . . . . . 15 85 5.5.7. End of Message Content . . . . . . . . . . . . . . . . 15 86 5.5.8. Random Values . . . . . . . . . . . . . . . . . . . . 15 87 5.6. Security Association Configuration Parameters . . . . . . 15 88 5.6.1. Security Parameter Index . . . . . . . . . . . . . . . 16 89 5.6.2. MN-HA Shared Keys . . . . . . . . . . . . . . . . . . 16 90 5.6.3. Security Association Validity Time . . . . . . . . . . 16 91 5.6.4. Security association scope (SAS) . . . . . . . . . . . 16 92 5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping . . 17 93 5.7. Mobile IPv6 Bootstrapping Parameters . . . . . . . . . . . 18 94 5.7.1. Home Agent Address . . . . . . . . . . . . . . . . . . 18 95 5.7.2. Mobile IPv6 Service Port Number . . . . . . . . . . . 18 96 5.7.3. Home Addresses and Home Network Prefix . . . . . . . . 19 97 5.7.4. DNS Server . . . . . . . . . . . . . . . . . . . . . . 19 98 5.8. Authentication of the Mobile Node . . . . . . . . . . . . 19 99 5.9. Extensible Authentication Protocol Methods . . . . . . . . 21 100 6. Mobile Node to Home Agent communication . . . . . . . . . . . 23 101 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 23 102 6.2. PType and Security Parameter Index . . . . . . . . . . . . 24 103 6.3. Binding Management Message Formats . . . . . . . . . . . . 25 104 6.4. Reverse Tunneled User Data Packet Formats . . . . . . . . 27 105 7. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 28 106 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 107 8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 29 108 8.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 29 109 8.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 30 110 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 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 . . . . . . . . . . 33 115 9.4. AAA Interworking . . . . . . . . . . . . . . . . . . . . . 35 116 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 117 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 118 11.1. Normative References . . . . . . . . . . . . . . . . . . . 35 119 11.2. Informative References . . . . . . . . . . . . . . . . . . 36 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 122 1. Introduction 124 Mobile IPv6 [RFC6275] 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 [RFC5944] 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 [RFC6275] 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. PType and Security Parameter Index 1062 The PType is a 4-bit field that indicates the Packet Type (PType) of 1063 the UDP encapsulated packet. The PType is followed by a a 28-bit SPI 1064 value. The PType and the SPI fields are treated as one 32-bit field 1065 during the integrity protection calculation. 1067 0 1 2 3 1068 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 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | PType | SPI | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 Figure 6: Security Parameter Index with Packet Type 1075 A SPI value of 0 (zero) indicates a plaintext packet. If the packet 1076 is integrity protected or both integrity protected and encrypted, the 1077 SPI value MUST be different from 0. When the SPI value is set to 0, 1078 then the PType MUST also be 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 6275) 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 6275 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 MN-CN route optimization is to be defined in a future revision of 1235 this specification. 1237 [Discussion: the route optimization can be done in two ways: 1) using 1238 the return routability procedure described in [RFC6275] or 2) 1239 directly between the MN and the CN. Obviously the first approach has 1240 already been verified from the security considerations and procedures 1241 point of view (both proving the Home Address ownership and verifying 1242 the reachability). However, there are several gaps in scope of this 1243 specification. For instance, the binding management message 1244 encapsulation between the MN and the CN must be specified and how to 1245 reach a CN using an IPv4 address (following the trend in this 1246 specification we would use UDP encapsulated IPv6 and mobility headers 1247 as in Section 6.3). Another gap is the lack of SA between the MN and 1248 the CN, if the communication were to be protected. In order to 1249 enable the protection the CN should actually implement a HAC 1250 function, which would then allow the MN and the CN to negotiate 1251 required ciphersuites. If the CN were to implement a HAC and the HAC 1252 could also authenticate the MN (either using pre-shared secrets or 1253 using EAP+AAA against MN's home realm AAA server), then we could 1254 actually allow the MN and the CN to setup secured communication 1255 without doing the return routability test. These are the issues and 1256 choices to consider.] 1258 8. IANA Considerations 1260 8.1. New Registry: Packet Type 1262 IANA is requested to create a new registry for the Packet Type as 1263 described in Section 6.1. 1265 Packet Type | Value 1266 ----------------------------------+---------------------------------- 1267 non-encrypted IP packet | 0 1268 encrypted IP packet | 1 1269 mobility header | 8 1271 Following the allocation policies from [RFC5226] new values for the 1272 Packet Type AVP MUST be assigned based on the "RFC Required" policy. 1274 8.2. Status Codes 1276 A new Status Code (to be used in BA messages) is reserved for the 1277 cases where the HA wants to indicate to the MN that it needs to re- 1278 establish the SA information with the HAC. The Result Code is 1279 reserved from the 0-127 code space: 1281 REINIT_SA_WITH_HAC TBD1 1283 8.3. Port Numbers 1285 A new port number (HALTSEC) for UDP packets is reserved from the PORT 1286 NUMBERS registry. 1288 HALTSEC TBD2 1290 9. Security Considerations 1292 This document describes and uses a number of building blocks that 1293 introduce security mechanisms and need to inter-work in a secure 1294 manner. 1296 The following building blocks are considered from a security point of 1297 view: 1299 1. Discovery of the HAC 1300 2. Authentication and MN-HA SA establishment executed between the MN 1301 and the HAC (PSK or EAP-based) through a TLS tunnel 1302 3. Protection of MN-HA communication 1303 4. AAA Interworking 1305 9.1. Discovery of the HAC 1307 No dynamic procedure for discovering the HAC by the MN is described 1308 in this document. As such, no specific security considerations apply 1309 to the scope of this document. 1311 9.2. Authentication and Key Exchange executed between the MN and the 1312 HAC 1314 This document describes a simple authentication and MN-HA SA 1315 negotiation exchange over TLS. The TLS procedures remain unchanged; 1316 however, channel binding is provided. 1318 Authentication: Server-side certificate based authentication MUST be 1319 performed using TLS 1.2 [RFC5246]. 1321 The client-side authentication may depend on the specific 1322 deployment and is therefore not mandated. Note that TLS-PSK 1323 [RFC4279] cannot be used in conjunction with the methods described 1324 in section 5.8 and 5.9 of this document due to the limitations of 1325 the channel binding type used. 1327 Through the protected TLS tunnel, an additional authentication 1328 exchange is performed that provides client-side or mutual 1329 authentication and exchanges SA parameters and optional 1330 configuration data to be used in the subsequent protection of 1331 MN-HA communication. The additional authentication exchange can 1332 either be PSK-based (section 5.8) or EAP-based (section 5.9). 1333 Both exchanges are always performed within the protected TLS 1334 tunnel and MUST NOT be used as standalone protocols. 1336 The simple PSK-based authentication exchange provides mutual 1337 authentication and follows the GPSK exchange used by EAP-GPSK 1338 [RFC5433] and has similar properties, although some features of 1339 GPSK like the exchange of a protected container are not supported. 1341 The EAP-based authentication exchange simply defines message 1342 containers to allow carrying the EAP packets between the MN and 1343 the HAC. In principle, any EAP method can be used. However, it 1344 is strongly recommended to use only EAP methods that provide 1345 mutual authentication and that derive keys including an MSK key in 1346 compliance with [RFC3748]. 1348 Both exchanges use channel binding with the TLS tunnel. The 1349 channel binding type 'TLS-server-endpoint' as per [RFC5929] MUST 1350 be used. 1352 Dictionary Attacks: All messages of the authentication exchanges 1353 specified in this document are protected by TLS. However, any 1354 implementation SHOULD assume that the properties of the 1355 authentication exchange are the same as for GPSK [RFC5433] in case 1356 the PSK-based method as per section 5.8. is used, and are the same 1357 as those of the underlying EAP method in case the EAP-based 1358 exchange as per section 5.9 is used. 1360 Replay Protection: The underlying TLS protection provides protection 1361 against replays. 1363 Key Derivation and Key Strength: For TLS, the TLS specific 1364 considerations apply unchanged. For the authentication exchanges 1365 defined in this document, no key derivation step is performed as 1366 the MN-HA keys are generated by the HAC and are distributed to the 1367 MN through the secure TLS connection. 1369 Key Control: No joint key control for MN-HA keys is provided by this 1370 version of the specification. 1372 Lifetime: The TLS-protected authentication exchange between the MN 1373 and the HAC is only to bootstrap keys and other parameters for 1374 usage with MN-HA security. The SAs that contain the keys have an 1375 associated lifetime. The usage of Transport Layer Security (TLS) 1376 Session Resumption without Server-Side State, described in 1377 [RFC5077], provides the ability for the MN to minimize the latency 1378 of future exchanges towards the HA without having to keep state at 1379 the HA itself. 1381 Denial of Service Resistance: The level of resistance against denial 1382 of service attacks SHOULD be considered the same as for common TLS 1383 operation, as TLS is used unchanged. For the PSK-based 1384 authentication exchange, no additional factors are known. For the 1385 EAP-based authentication exchange, any considerations regarding 1386 denial-of-service resistance specific to the chosen EAP method are 1387 expected to be applicable and need to be be taken into account. 1389 Session Independence: Each individual TLS protocol run is 1390 independent from any previous exchange based on the security 1391 properties of the TLS handshake protocol. However, several PSK or 1392 EAP-based authentication exchanges can be performed across the 1393 same TLS connection. 1395 Fragmentation: TLS runs on top of TCP and no fragmentation specific 1396 considerations apply to the MN-HAC authentication exchanges. 1398 Channel Binding: Both the PSK and the EAP-based exchanges use 1399 channel binding with the TLS tunnel. The channel binding type 1400 'TLS-server-endpoint' as per [RFC5929] MUST be used. 1402 Fast Reconnect: This protocol provides session resumption as part of 1403 TLS and optionally the support for [RFC5077]. No fast reconnect 1404 is supported for the PSK-based authentication exchange. For the 1405 EAP-based authentication exchange, availability of fast reconnect 1406 depends on the EAP method used. 1408 Identity Protection: Based on the security properties of the TLS 1409 tunnel, passive user identity protection is provided. An attacker 1410 acting as man-in-the-middle in the TLS connection would be able to 1411 observe the MN identity value sent in MHAuth-Init messages. 1413 Protected Ciphersuite Negotiation: This protocol provides 1414 ciphersuite negotiation based on TLS. 1416 Confidentiality: Confidentiality protection of payloads exchanged 1417 between the MN and the HAC are protected with the TLS Record 1418 Layer. TLS ciphersuites with confidentiality and integrity 1419 protection MUST be negotiated and used in order to exchange 1420 security sensitive material inside the TLS connection. 1422 Cryptographic Binding: No cryptographic bindings are provided by 1423 this protocol specified in this document. 1425 Perfect Forward Secrecy: Perfect forward secrecy is provided with 1426 appropriate TLS ciphersuites. 1428 Key confirmation: Key confirmation of the keys established with TLS 1429 is provided by the TLS Record Layer when the keys are used to 1430 protect the subsequent TLS exchange. 1432 9.3. Protection of MN and HA Communication 1434 Authentication: Data origin authentication is provided for the 1435 communication between the MN and the HA. The chosen level of 1436 security of this authentication depends on the selected 1437 ciphersuite. Entity authentication is offered by the MN to HAC 1438 protocol exchange. 1440 Dictionary Attacks: The concept of dictionary attacks is not 1441 applicable to the MN-HA communication as the keying material used 1442 for this communication is randomly created by the HAC and its 1443 length depends on the chosen cryptographic algorithms. 1445 Replay Protection: Replay protection for the communication between 1446 the MN and the HA is provided based on sequence numbers and 1447 follows the design of IPsec ESP. 1449 Key Derivation and Key Strength: The strength of the keying material 1450 established for the communication between the MN and the HA is 1451 selected based on the negotiated ciphersuite (based on the MN-HAC 1452 exchange) and the key created by the HAC. The randomness 1453 requirements for security described in RFC 4086 [RFC4086] are 1454 applicable to the key generation by the HAC. 1456 Key Control: The keying material established during the MN-HAC 1457 protocol exchange for subsequent protection of the MN-HA 1458 communication is created by the HA and therefore no joint key 1459 control is provided for it. 1461 Key Naming: For the MN-HA communication the security associations 1462 are indexed with the help of the SPI and additionally based on the 1463 direction (in-bound communication or out-bound communication). 1465 Lifetime: The lifetime of the MN-HA security associations is based 1466 on the value in the mip6-sa-validity-end header field exchanged 1467 during the MN-HAC exchange. The HAC controls the SA lifetime. 1469 Denial of Service Resistance: For the communication between the MN 1470 and the HA there are no heavy cryptographic operations (such as 1471 public key computations). As such, there are no DoS concerns. 1473 Session Independence: Sessions are independent from each other when 1474 new keys are created by via the MN-HAC protocol. A new MN-HAC 1475 protocol run produces fresh and unique keying material for 1476 protection of the MN-HA communication. 1478 Fragmentation: There is no additional fragmentation support provided 1479 beyond what is offered by the network layer. 1481 Channel Binding: Channel binding is not applicable to the MN-HA 1482 communication. 1484 Fast Reconnect: The concept of fast reconnect is not applicable to 1485 the MN-HA communication. 1487 Identity Protection: User identities SHOULD NOT be exchanged between 1488 the MN and the HA. In a case binding management messages contain 1489 the user identity, the messages SHOULD be confidentity protected. 1491 Protected Ciphersuite Negotiation: The MN-HAC protocol provides 1492 protected ciphersuite negotiation through a secure TLS connection. 1494 Confidentiality: Confidentiality protection of payloads exchanged 1495 between the MN and the HAC (for Mobile IPv6 signaling and 1496 optionally for the data traffic) is provided utilizing algorithms 1497 negotiated during the MN-HAC exchange. 1499 Cryptographic Binding: No cryptographic bindings are provided by 1500 this protocol specified in this document. 1502 Perfect Forward Secrecy: Perfect forward secrecy is provided when 1503 the MN bootstraps new keying material with the help of the MN-HAC 1504 protocol (assuming that a proper TLS ciphersuite is used). 1506 Key confirmation: Key confirmation of the MN-HA keying material 1507 conveyed from the HAC to the MN is provided when the first packets 1508 are exchanged between the MN and the HA (in both directions as two 1509 different keys are used). 1511 9.4. AAA Interworking 1513 The AAA backend infrastructure interworking is not defined in this 1514 document and therefore out-of-scope. 1516 10. Acknowledgements 1518 The authors would like to thank Pasi Eronen, Domagoj Premec, Julien 1519 Laganier and Christian Bauer for their comments. 1521 11. References 1523 11.1. Normative References 1525 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1526 Requirement Levels", BCP 14, RFC 2119, March 1997. 1528 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1529 ESP and AH", RFC 2404, November 1998. 1531 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 1532 Its Use With IPsec", RFC 2410, November 1998. 1534 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 1535 Algorithms", RFC 2451, November 1998. 1537 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1538 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1539 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1541 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 1542 and Its Use With IPsec", RFC 3566, September 2003. 1544 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1545 Algorithm and Its Use with IPsec", RFC 3602, 1546 September 2003. 1548 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1549 Network Access Identifier", RFC 4282, December 2005. 1551 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1552 Channels", RFC 5056, November 2007. 1554 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1555 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1556 May 2008. 1558 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1559 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1561 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1562 for TLS", RFC 5929, July 2010. 1564 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1565 in IPv6", RFC 6275, July 2011. 1567 11.2. Informative References 1569 [I-D.patil-mext-mip6issueswithipsec] 1570 Patil, B., Premec, D., Perkins, C., and H. Tschofenig, 1571 "Problems with the use of IPsec as the security protocol 1572 for Mobile IPv6", draft-patil-mext-mip6issueswithipsec-03 1573 (work in progress), July 2010. 1575 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1576 August 1980. 1578 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1579 Levkowetz, "Extensible Authentication Protocol (EAP)", 1580 RFC 3748, June 2004. 1582 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1583 Protect Mobile IPv6 Signaling Between Mobile Nodes and 1584 Home Agents", RFC 3776, June 2004. 1586 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1587 Requirements for Security", BCP 106, RFC 4086, June 2005. 1589 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1590 for Transport Layer Security (TLS)", RFC 4279, 1591 December 2005. 1593 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1594 Internet Protocol", RFC 4301, December 2005. 1596 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1597 RFC 4303, December 2005. 1599 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1600 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1601 April 2007. 1603 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1604 "Transport Layer Security (TLS) Session Resumption without 1605 Server-Side State", RFC 5077, January 2008. 1607 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 1608 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 1609 RFC 5433, February 2009. 1611 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1612 Routers", RFC 5555, June 2009. 1614 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 1615 RFC 5944, November 2010. 1617 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1618 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1619 RFC 5996, September 2010. 1621 Authors' Addresses 1623 Jouni Korhonen (editor) 1624 Nokia Siemens Networks 1625 Linnoitustie 6 1626 Espoo FIN-02600 1627 Finland 1629 Email: jouni.nospam@gmail.com 1631 Basavaraj Patil 1632 Nokia 1633 6021 Connection Drive 1634 Irving, TX 75039 1635 USA 1637 Email: basavaraj.patil@nokia.com 1639 Hannes Tschofenig 1640 Nokia Siemens Networks 1641 Linnoitustie 6 1642 Espoo 02600 1643 Finland 1645 Phone: +358 (50) 4871445 1646 Email: Hannes.Tschofenig@gmx.net 1647 Dirk Kroeselberg 1648 Siemens 1650 Email: dirk.kroeselberg@siemens.com