idnits 2.17.1 draft-ietf-mext-mip6-tls-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 28, 2012) is 4384 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) -- Obsolete informational reference (is this intentional?): RFC 5077 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 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 Intended status: Experimental B. Patil 5 Expires: September 29, 2012 Nokia 6 H. Tschofenig 7 Nokia Siemens Networks 8 D. Kroeselberg 9 Siemens 10 March 28, 2012 12 Transport Layer Security-based Mobile IPv6 Security Framework for Mobile 13 Node to Home Agent Communication 14 draft-ietf-mext-mip6-tls-05.txt 16 Abstract 18 Mobile IPv6 signaling between a mobile node and its home agent is 19 secured using IPsec. The security association between a mobile node 20 and the home agent is established using IKEv1 or IKEv2. The security 21 model specified for Mobile IPv6, which relies on IKE/IPsec, requires 22 interaction between the Mobile IPv6 protocol component and the IKE/ 23 IPsec module of the IP stack. This document proposes an alternate 24 security framework for Mobile IPv6 and Dual-Stack Mobile IPv6, which 25 relies on Transport Layer Security for establishing keying material 26 and other bootstrapping parameters required to protect Mobile IPv6 27 signaling and data traffic between the mobile node and home agent. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 29, 2012. 46 Copyright Notice 48 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . 14 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 . . . . . . . . 18 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. PType and Security Parameter Index . . . . . . . . . . . . 25 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. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 29 108 8.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 29 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 110 9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 30 111 9.2. Authentication and Key Exchange executed between the 112 MN and the HAC . . . . . . . . . . . . . . . . . . . . . . 30 113 9.3. Protection of MN and HA Communication . . . . . . . . . . 33 114 9.4. AAA Interworking . . . . . . . . . . . . . . . . . . . . . 35 115 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 117 11.1. Normative References . . . . . . . . . . . . . . . . . . . 35 118 11.2. Informative References . . . . . . . . . . . . . . . . . . 36 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 121 1. Introduction 123 Mobile IPv6 [RFC6275] signaling, and optionally user traffic, between 124 a mobile node (MN) and home agent (HA) are secured by IPsec 125 [RFC4301]. The current Mobile IPv6 security architecture is 126 specified in [RFC3776] and [RFC4877]. This security model requires a 127 tight coupling between the Mobile IPv6 protocol part and the IKE(v2)/ 128 IPsec part of the IP stack. Client implementation experience has 129 shown that the use of IKE(v2)/IPsec with Mobile IPv6 is fairly 130 complex. 132 This document proposes an alternate security framework for Mobile 133 IPv6 and Dual-Stack Mobile IPv6. The objective is to simplify 134 implementations as well as make it easy to deploy the protocol 135 without compromising on security. Transport Layer Security (TLS) 136 [RFC5246] is widely implemented in almost all major operating systems 137 and extensively used by various applications. Instead of using IKEv2 138 to establish security associations, the security framework proposed 139 in this document is based on TLS protected messages to exchange keys 140 and bootstrapping parameters between the Mobile Node and a new 141 functional entity called as the Home Agent Controller (HAC). The 142 Mobile IPv6 signaling between the mobile node and home agent is 143 subsequently secured using the resulting keys and negotiated cipher 144 suite. The HAC can be co-located with the HA, or can be an 145 independent entity. For the latter case, communication between HAC 146 and HA is not defined by this document. Such communication could be 147 built on top of AAA protocols such as Diameter, for instance. 149 The primary advantage of using TLS based establishment of Mobile IP6 150 security associations compared to IKEv2 is the ease of implementation 151 while providing an equivalent level of security. For the protection 152 of signaling messages and user plane traffic a solution is provided 153 that decouples Mobile IPv6 security from IPsec, thereby reducing 154 client implementation complexity. 156 The security framework proposed in this document is not intended to 157 replace the currently specified architecture which relies on IPsec 158 and IKEv2. It provides an alternative solution which is more optimal 159 for certain deployment scenarios. This and other alternative 160 security models have been considered by the MEXT working group at the 161 IETF, and it has been decided that the alternative solutions should 162 be published as Experimental RFCs, so that more implementation and 163 deployment experience with these models can be gathered. The working 164 group may reconsider the status of the different models in the 165 future, if it becomes clear that one is superior to the others. 167 2. Terminology and Abbreviations 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 Home Agent Controller (HAC): 175 The home agent controller is a node responsible for bootstrapping 176 Mobile IPv6 security associations between a mobile node and one or 177 more home agents. The home agent controller also provides key 178 distribution to both mobile nodes and home agents. Mobile IPv6 179 bootstrapping is also performed by the HA in addition to the 180 security association bootstrapping between the mobile node and 181 home agent controller. 183 Binding Management Messages: 185 Mobile IPv6 signaling messages between a mobile node and a home 186 agent, correspondent node or mobility access point to manage the 187 bindings are referred to as binding management messages. Binding 188 Updates and Binding Acknowledgement messages are examples of 189 binding management messages. 191 3. Background 193 Mobile IPv6 design and specification was begun in the mid to late 194 90s. The security architecture of Mobile IPv6 was based on the 195 understanding that IPsec is an inherent and integral part of the IPv6 196 stack and any protocol that needs security should use IPsec unless 197 there is a good reason not to. As a result of this mindset the 198 Mobile IP6 protocol relied on the use of IPsec for security between 199 the MN and HA. While reuse of security components that are part of 200 the IP stack is a good objective, in the case of Mobile IPv6, 201 implementation complexity increases. It should be noted that Mobile 202 IPv4 [RFC5944] for example does not use IPsec for security and 203 instead has specified its own security solution. Mobile IPv4 has 204 been implemented and deployed on a reasonably large scale and the 205 security model has proven itself to be sound. 207 Mobile IPv6 standardization was completed in 2005 along with the 208 security architecture using IKE/IPsec specified in RFC 3776 209 [RFC3776]. With the evolution to IKEv2 [RFC5996], Mobile IP6 210 security has also been updated to rely on the use of IKEv2 [RFC4877]. 211 Implementation exercises of Mobile IPv6 and Dual-stack Mobile IPv6 212 [RFC5555] have identified the complexity of using IPsec and IKEv2 in 213 conjunction with Mobile IPv6. Implementing Mobile IPv6 with IPsec 214 and IKEv2 requires modifications to both the IPsec and IKEv2 215 components, due to the communication models that Mobile IPv6 uses and 216 the changing IP addresses. For further details, see Section 7.1 in 217 [RFC3776]. 219 This document proposes a security framework based on TLS protected 220 establishment of Mobile IPv6 security associations with reduced 221 implementation complexity, while maintaining an equivalent (to IKEv2/ 222 IPsec) level of security. 224 4. TLS-based Security Establishment 226 4.1. Overview 228 The security architecture proposed in this document relies on a 229 secure TLS session established between the MN and the HAC for 230 authentication and MN-HA security association bootstrapping. 231 Authentication of the HAC is done via standard TLS operation wherein 232 the HAC uses a TLS server certificate as its credentials. MN 233 authentication is done by the HAC via signaling messages that are 234 secured by the TLS connection. Any EAP method can be used for 235 authenticating the MN to the HAC. Upon successful completion of 236 authentication, the HAC generates keys which are delivered to the MN 237 through the secure TLS channel. The same keys are also provided to 238 the assigned HA. The HAC also provides the MN with MIP6 239 bootstrapping information such as the IPv6 and IPv4 address of the 240 HA, the Home network prefix, the IPv6 and/or IPv4 HoA and, DNS server 241 address. 243 The MN and HA use security associations based on the keys and SPIs 244 generated by the HAC and delivered to the MN and HA to secure 245 signaling and optionally user plane traffic. Figure 1 below is an 246 illustration of the process. 248 Signaling messages and user plane traffic between the MN and HA are 249 always UDP encapsulated. The packet formats for the signaling and 250 user plane traffic is described in Sections 6.3 and 6.4. 252 MN HAC HA 253 -- --- -- 254 | | | 255 | /-------------------------\ | | 256 |/ \| | 257 |\ TLS session setup /| | 258 | \-------------------------/ | | 259 | | | 260 | /-------------------------\ | | 261 |/ MN Authentication \| | 262 |\ /| | 263 | \-------------------------/ | | 264 | | | 265 | /-------------------------\ | | 266 |/ HAC provisions the MN \| | 267 |\ keys, SPI and MIP6 parms /| | 268 | \-------------------------/ | | 269 | |--MNID, keys, SPI->| 270 | | | 271 | /--------------------------------------------\ | 272 |/ MN-HA SA established; Secures \ | 273 |\ signaling and optionally user traffic / | 274 | \--------------------------------------------/ | 275 | | 276 |------------BU(encrypted)----------------------->| 277 | | 278 |<---------BAck(encrypted)------------------------| 280 Figure 1: High level architecture 282 4.2. Architecture 284 The TLS-based security architecture is shown in Figure 2. The 285 signaling message exchange between the MN and the HAC is protected by 286 TLS. It should be noted that a HAC, a AAA server and a HA are 287 logically separate entities and can be collocated in all possible 288 combinations. There MUST be a strong trust relationship between the 289 HA and the HAC, and the communication between them MUST be both 290 integrity and confidentially protected. 292 +------+ +------+ +------+ 293 |Mobile| TLS |Home | AAA | AAA | 294 | Node |<----------->|Agent |<---------->|Server| 295 | | |Contrl| | | 296 +------+ +------+ +------+ 297 ^ ^ ^ 298 | | | 299 | BU/BA/../ | e.g. AAA | AAA 300 | (Data) | | 301 | v | 302 | +---------+ | 303 | | MIPv6 | | 304 +--------------->| Home |<-------------+ 305 | Agent(s)| 306 +---------+ 308 Figure 2: TLS-based Security Architecture Overview 310 4.3. Security Association Management 312 Once the MN has contacted the HAC and mutual authentication has taken 313 place between the MN and the HAC, the HAC securely provisions the MN 314 with all security related information inside the TLS protected 315 tunnel. This security related information constitutes a security 316 association (SA) between the MN and the HA. The created SA MUST NOT 317 be tied to the Care-of Address (CoA) of the MN. 319 The HAC may proactively distribute the SA information to HAs, or the 320 HA may query the SA information from the HAC once the MN contacts the 321 HA. If the HA requests SA information from the HAC, then the HA MUST 322 be able to query/index the SA information from the HAC based on the 323 Security Parameter Index (SPI) identifying the correct security 324 association between the MN and the HA. 326 The HA may want the MN to re-establish the SA even if the existing SA 327 is still valid. The HA can indicate this to the MN using a dedicated 328 Status Code in a BA (value set to REINIT_SA_WITH_HAC). As a result, 329 the MN SHOULD contact the HAC prior to the SA timing out, and the HAC 330 would provision the MN and HAs with a new SA to be used subsequently. 332 The SA established between MN and HAC SHALL contain at least the 333 following information: 335 Mobility SPI: 337 This parameter is an SPI used by the MN and the HA to index the SA 338 between the MN and the HA. The HAC is responsible for assigning 339 SPIs to MNs. There is only one SPI for both binding management 340 messaging and possible user data protection. The same SPI is used 341 for both directions between the MN and the HA. The SPI values are 342 assigned by the HAC. The HAC MUST ensure uniqueness of the SPI 343 values across all MNs controlled by the HAC. 345 MN-HA keys for ciphering: 347 A pair of symmetric keys (MN -> HA, HA -> MN) used for ciphering 348 Mobile IPv6 traffic between the MN and the HA. The HAC is 349 responsible for generating these keys. The key generation 350 algorithm is specific to the HAC implementation. 352 MN-HA shared key for integrity protection: 354 A pair of symmetric keys (MN -> HA, HA -> MN) used for integrity 355 protecting Mobile IPv6 traffic between the MN and the HA. This 356 includes both binding management messages and reverse tunneled 357 user data traffic between the MN and the HA. The HAC is 358 responsible for generating these keys. The key generation 359 algorithm is specific to the HAC implementation. In case of 360 combined algorithms a separate integrity protection key is not 361 needed and may be omitted, i.e., the encryption keys SHALL be 362 used. 364 Security association validity time: 366 This parameter represents the validity time for the security 367 association. The HAC is responsible for defining the lifetime 368 value based on its policies. The lifetime may be in the order of 369 hours or weeks. The MN MUST re-contact the HAC before the SA 370 validity time ends. 372 Security Association Scope: 374 This parameter defines whether the security association is applied 375 to Mobile IPv6 signaling messages only, or to both Mobile IPv6 376 signaling messages and data traffic. 378 Selected ciphersuite: 380 This parameter is the ciphersuite used to protect the traffic 381 between the MN and the HA. This includes both binding management 382 messages and reverse tunneled user data traffic between the MN and 383 the HA. The selected algorithms SHOULD be one of the mutually 384 supported ciphersuites of the negotiated TLS version between the 385 MN and the HAC. The HAC is responsible for choosing the mutually 386 supported ciphersuite that complies with the policy of the HAC. 387 Obviously, the HAs under HAC's management must have at least one 388 ciphersuite with the HAC in common and need to be aware of the 389 implemented ciphersuites. The selected ciphersuite is the same 390 for both directions (MN -> HA and HA -> MN). 392 Sequence numbers: 394 A monotonically increasing unsigned sequence number used in all 395 protected packets exchanged between the MN and the HA in the same 396 direction. Sequence numbers are maintained per direction, so each 397 SA includes two independent sequence numbers (MN -> HA, HA -> MN). 398 The initial sequence number for each direction MUST always be set 399 to 0 (zero). Sequence numbers cycle to 0 (zero) when increasing 400 beyond their maximum defined value. 402 4.4. Bootstrapping of Additional Mobile IPv6 Parameters 404 When the MN contacts the HAC to distribute the security related 405 information, the HAC may also provision the MN with various Mobile 406 IPv6 related bootstrapping information. Bootstrapping of the 407 following information SHOULD at least be possible: 409 Home Agent IP Address: 411 Concerns both IPv6 and IPv4 home agent addresses. 413 Mobile IPv6 Service Port Number: 415 The port number where the HA is listening to UDP [RFC0768] 416 packets. 418 Home Address: 420 Concerns both IPv6 and IPv4 Home Addresses. 422 Home Link Prefix: 424 Concerns the IPv6 Home link prefix and the associated prefix 425 length. 426 DNS Server Address: 428 The address of a DNS server that can be reached via the HA. DNS 429 queries in certain cases cannot be routed to the DNS servers 430 assigned by the access network to which the MN is attached and 431 hence an additional DNS server address which is reachable via the 432 HA needs to be configured. 434 The Mobile IPv6 related bootstrapping information is delivered from 435 the HAC to the MN over the same TLS protected tunnel as the security 436 related information. 438 4.5. Protecting Traffic Between Mobile Node and Home Agent 440 The same integrity and confidentiality algorithms MUST be used to 441 protect both binding management messages and reverse tunneled user 442 data traffic between the MN and the HA. Generally, all binding 443 management messages (BUs, BAs and so on) MUST be integrity protected 444 and SHOULD be confidentially protected. The reverse tunneled user 445 data traffic SHOULD be equivalently protected. Generally, the 446 requirements stated in [RFC6275] concerning the protection of the 447 traffic between the MN and the HA also apply to the mechanisms 448 defined by this specification. 450 5. Mobile Node to Home Agent Controller Communication 452 5.1. Request-response Message Framing over TLS-tunnel 454 The MN and the HAC communicate with each other using a simple lock- 455 step request-response protocol that is run inside the protected TLS- 456 tunnel. A generic message container framing for the request messages 457 and for the response messages is defined. The message containers are 458 only meant to be exchanged on top of connection oriented TLS-layer. 459 Therefore, the end of message exchange is determined by the other end 460 closing the transport connection (assuming the "application layer" 461 has also indicated the completion of the message exchange). The peer 462 initiating the TLS-connection is always sending "Requests" and the 463 peer accepting the TLS-connection is always sending "Responses". The 464 format of the message container is shown in Figure 3. 466 All data inside the Content portion of the message container MUST be 467 encoded using octets. Fragmentation of message containers is not 468 supported, which means one request or response at the "application 469 layer" MUST NOT exceed the maximum size allowed by the message 470 container format. 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Ver | Rsrvd | Identifier | Length | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Content portion.. ~ 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 Figure 3: Request-Response Message Container 482 The three bit Ver field identifies the protocol version. The current 483 version is 0 i.e. all bits are set to value 0 (zero). 485 The Rsrvd field MUST be set to value 0 (zero), 487 The Identifier field is meant for matching requests and responses. 488 The valid Identifier values are between 1-255. The value 0 MUST NOT 489 be used. The first request for each communication session between 490 the MN and the HAC MUST have the Identifier values set to 1. 492 The Length field tells the length of the Content portion of the 493 container (i.e. Reserved octet, Identifier octet and Length field 494 are excluded). The Content portion length MUST always be at least 495 one octet up to 65535 octets. The value is in network order. 497 5.2. Request-response Message Content Encoding 499 The encoding of the message content is similar to HTTP header 500 encoding, and complies to the augmented Backus-Naur Form (BNF) 501 defined in Section 2.1 of [RFC2616]. All presented hexadecimal 502 numbers are in network byte order. From now on, we use TypeValue 503 header (TV-header) term to refer request-response message content 504 HTTP-like headers. 506 5.3. Request-Response Message Exchange 508 The message exchange between the MN and the HAC is a simple lock-step 509 request-response type as stated in Section 5.1. A request message 510 includes monotonically increasing Identifier value that is copied to 511 the corresponding response message. Each request MUST have a 512 different Identifier value. Hence, a reliable connection oriented 513 transport below the message container framing is assumed. The number 514 of request-response message exchanges MUST NOT exceed 255. 516 Each new communication session between the MN and the HAC MUST reset 517 the Identifier value to 1. The MN is also the peer that always sends 518 only request messages and the HAC only sends response messages. Once 519 the request-response message exchange completes, the HAC and the MN 520 MUST close the transport connection and the corresponding TLS-tunnel. 522 In a case of a HAC side error, the HAC MUST send a response back to a 523 MN with an appropriate status code and then close the transport 524 connection. 526 The first request message - MHAuth-Init - (i.e. the Identifier is 1) 527 MUST always contain at least the following parameters: 529 MN-Identity - See Section 5.5.1. 530 Authentication Method - See Section 5.5.2. 532 The first response message - MHAuth-Init - (i.e. the Identifier is 1) 533 MUST contain at minimum the following parameters: 535 Selected authentication Method - See Section 5.5.2. 537 The last request message from the MN side - MHAuth-Done - MUST 538 contain the following parameters: 540 Security Association Scope - See Section 5.6.4. 541 Proposed ciphersuites - See Section 5.6.5. 542 Message Authenticator - See Section 5.5.5. 544 The last response message - MHAuth-Done - that ends the request- 545 response message exchange MUST contain the following parameters: 547 Status Code - See Section 5.5.4. 548 Message Authenticator - See Section 5.5.5. 550 And in a case of successful authentication the following additional 551 parameters: 553 Selected ciphersuite - See Section 5.6.5. 554 Security Association Scope - See Section 5.6.4. 555 The rest of the security association data - See Section 5.6. 557 5.4. Home Agent Controller Discovery 559 All bootstrapping information, whether for setting up the SA or for 560 bootstrapping Mobile IPv6 specific information, is exchanged between 561 the MN and the HAC using the framing protocol defined in Section 5.1. 562 The IP address of the HAC MAY be statically configured to the MN or 563 may be dynamically discovered using DNS. In a case of DNS-based HAC 564 discovery, the MN either queries an A/AAAA or a SRV record for the 565 HAC IP address. The actual domain name used in queries is up to the 566 deployment to decide and out of scope of this specification. 568 5.5. Generic Request-Response Parameters 570 The grammar used in the following sections is the augmented Backus- 571 Naur Form (BNF) same to that used by HTTP [RFC2616]. 573 5.5.1. Mobile Node Identifier 575 An identifier that identifies a MN. The Mobile Node Identifier is in 576 form of a Network Access Identifier (NAI) [RFC4282]. 578 mn-id = "mn-id" ":" RFC4282-NAI CRLF 580 5.5.2. Authentication Method 582 The HAC is the peer that mandates the authentication method. The MN 583 sends its authentication method proposal to the HAC. The HAC, upon 584 receipt of the MN proposal returns the selected authentication 585 method. The MN MUST propose at least one authentication method. The 586 HAC MUST select exactly one authentication method, or return an error 587 and then close the connection. 589 auth-method = "auth-method" ":" a-method *("," a-method) CRLF 590 a-method = 591 "psk" ; Pre-shared key based authentication 592 | "eap" ; EAP-based authentication 594 5.5.3. Extensible Authentication Protocol Payload 596 Each Extensible Authentication Protocol (EAP) [RFC3748] message is an 597 encoded string of hexadecimal numbers. The "eap-payload" is 598 completely transparent what EAP-method or EAP message is carried 599 inside it. The "eap-payload" can appear in both request and response 600 messages: 602 eap-payload = "eap-payload" ":" 1*(HEX HEX) CRLF 604 5.5.4. Status Code 606 The "status-code" MUST only be present in the response message that 607 ends the request-response message exchange. The "status-code" 608 follows the principles of HTTP and the definitions found in Section 609 10 of RFC 2616 also apply for these status codes listed below: 611 status-code = "status-code" ":" status-value CRLF 612 status-value = 613 "100" ; Continue 614 | "200" ; OK 615 | "400" ; Bad Request 616 | "401" ; Unauthorized 617 | "500" ; Internal Server Error 618 | "501" ; Not Implemented 619 | "503" ; Service Unavailable 620 | "504" ; Gateway Time-out 622 5.5.5. Message Authenticator 624 The "auth" header contains data used for authentication purposes. It 625 MUST be the last TV-header in the message and calculated over the 626 whole message till the start of the "msg-header": 628 msg-auth = "auth" ":" 1*(HEX HEX) CRLF 630 5.5.6. Retry After 632 retry-after = "retry-after" ":" rfc1123-date CRLF 634 5.5.7. End of Message Content 636 end-of-message = 2CRLF 638 5.5.8. Random Values 640 Random numbers generated by the MN and the HAC, respectively. The 641 length of the random number MUST be 32 octets (before TV-header 642 encoding): 644 mn-rand = "mn-rand" ":" 32(HEX HEX) CRLF 645 hac-rand = "hac-rand" ":" 32(HEX HEX) CRLF 647 5.6. Security Association Configuration Parameters 649 During the Mobile IPv6 bootstrapping, the MN and the HAC negotiate a 650 single ciphersuite for protecting the traffic between the MN and the 651 HA. The allowed ciphersuites for this specification are a subset of 652 those in TLS v1.2 (see Annex A.5 of [RFC5246]) as per Section 5.6.5. 653 This might appear as a constraint as the HA and the HAC may have 654 implemented different ciphersuites. These two nodes are, however, 655 assumed to belong to the same administrative domain. In order to 656 avoid exchanging supported MN-HA ciphersuites in the MN-HAC protocol 657 and to reuse the TLS ciphersuite negotiation procedure we make this 658 simplifying assumption. The selected ciphersuite MUST provide 659 integrity and confidentiality protection. 661 Section 5.6.5 provides the mapping from the TLS ciphersuites to the 662 integrity and encryption algorithms allowed for MN-HA protection. 663 This mapping mainly ignores the authentication algorithm part that is 664 not required within the context of this specification. For example, 665 [RFC5246] defines a number of AES based ciphersuites for TLS 666 including 'TLS_RSA_WITH_AES_128_CBC_SHA'. For this specification the 667 relevant part is 'AES_128_CBC_SHA'. 669 All the parameters described in the following sections apply only to 670 a request-response protocol response message to the MN. The MN has 671 no way affecting to the provisioning decision of the HAC. 673 5.6.1. Security Parameter Index 675 The 28-bit unsigned SPI number identifies the SA used between the MN 676 and the HA. The value 0 (zero) is reserved and MUST NOT be used. 677 Therefore, values ranging from 1 to 268435455 are valid. 679 The TV-header corresponding to the SPI number is: 681 mip6-spi = "mip6-spi" ":" 1*DIGIT CRLF 683 5.6.2. MN-HA Shared Keys 685 The MN-HA shared integrity (ikey) and encryption (ekey) keys are used 686 to protect the traffic between the MN and the HA. The length of 687 these keys depend on the selected ciphersuite. 689 The TV-headers that carry these two parameters are: 691 mip6-mn-to-ha-ikey = "mip6-mn-to-ha-ikey" ":" 1*(HEX HEX) CRLF 692 mip6-ha-to-mn-ikey = "mip6-ha-to-mn-ikey" ":" 1*(HEX HEX) CRLF 693 mip6-mn-to-ha-ekey = "mip6-mn-to-ha-ekey" ":" 1*(HEX HEX) CRLF 694 mip6-ha-to-mn-ekey = "mip6-ha-to-mn-ekey" ":" 1*(HEX HEX) CRLF 696 5.6.3. Security Association Validity Time 698 The end of the SA validity time is encoded using the "rfc1123-date" 699 format, as defined in Section 3.3.1 of [RFC2616]. 701 The TV-header corresponding to the SA validity time value is: 703 mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date 704 CRLF 706 5.6.4. Security association scope (SAS) 708 The SA is applied either to Mobile IPv6 signaling messages only, or 709 to both Mobile IPv6 signaling messages and data traffic. This policy 710 MUST be agreed between the MN and HA prior to using the SA. 711 Otherwise the receiving side would not be aware of whether the SA 712 applies to data traffic and could not decide how to act when 713 receiving unprotected packets of PType 1 (see Section 6.4). 715 mip6-sas = "mip6-sas" ":" 1DIGIT CRLF 717 where a value of "0" indicates that the SA does not protect data 718 traffic and a value of "1" indicates that all data traffic MUST be 719 protected by the SA. If the mip6-sas value of an SA is set to 1, any 720 packet received with a PType value that does not match the mip6-sas 721 value of the SA MUST be silently discarded. 723 The HAC is the peer that mandates the used security association 724 scope. The MN sends its proposal to the HAC but eventually the 725 security association scope returned from the HAC defines the used 726 scope. 728 5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping 730 The ciphersuite negotiation between HAC and MN uses a subset of the 731 TLS 1.2 ciphersuites and follows the TLS 1.2 numeric representation 732 defined in Annex A.5 of [RFC5246]. The TV-headers corresponding to 733 the selected ciphersuite and ciphersuite list are: 735 mip6-ciphersuite = "mip6-ciphersuite" ":" csuite CRLF 736 csuite = "{" suite "}" 737 suite = 738 "00" "," "02" ; CipherSuite NULL_SHA = {0x00,0x02} 739 | "00" "," "3B" ; CipherSuite NULL_SHA256 = {0x00,0x3B} 740 | "00" "," "0A" ; CipherSuite 3DES_EDE_CBC_SHA = {0x00,0x0A} 741 | "00" "," "2F" ; CipherSuite AES_128_CBC_SHA = {0x00,0x2F} 742 | "00" "," "3C" ; CipherSuite AES_128_CBC_SHA256 = {0x00,0x3C} 743 mip6-suitelist = "mip6-suitelist" ":" csuite *("," csuite) CRLF 745 All other Ciphersuite values are reserved. 747 The following integrity algorithms MUST be supported by all 748 implementations: 750 HMAC-SHA1-96 [RFC2404] 751 AES-XCBC-MAC-96 [RFC3566] 753 The binding management messages between the MN and HA MUST be 754 integrity protected. Implementations MUST NOT use a NULL integrity 755 algorithm. 757 The following encryption algorithms MUST be supported: 759 NULL [RFC2410] 760 TripleDES-CBC [RFC2451] 761 AES-CBC with 128-bit keys [RFC3602] 763 Traffic between MN and HA MAY be encrypted. Any integrity-only 764 CipherSuite makes use of the NULL encryption algorithm. 766 Note: In the present version, this document does not consider 767 combined algorithms. The following table provides the mapping of 768 each ciphersuite to a combination of integrity and encryption 769 algorithms that are part of the negotiated SA between MN and HA. 771 +-------------------+-----------------+--------------------------+ 772 |Ciphersuite |Integ. Algorithm |Encr. Algorithm | 773 +-------------------+-----------------+--------------------------+ 774 |NULL_SHA |HMAC-SHA1-96 |NULL | 775 |NULL_SHA256 |AES-XCBC-MAC-96 |NULL | 776 |3DES_EDE_CBC_SHA |HMAC-SHA1-96 |TripleDES-CBC | 777 |AES_128_CBC_SHA |HMAC-SHA1-96 |AES-CBC with 128-bit keys | 778 |AES_128_CBC_SHA256 |AES-XCBC-MAC-96 |AES-CBC with 128-bit keys | 779 +-------------------+----------------+---------------------------+ 781 Ciphersuite-to-Algorithm Mapping 783 5.7. Mobile IPv6 Bootstrapping Parameters 785 In parallel with the SA bootstrapping, the HAC SHOULD provision the 786 MN with relevant Mobile IPv6 related bootstrapping information. 788 The following generic BNFs are used to form IP addresses and 789 prefixes. They are used in subsequent sections. 791 ip6-addr = 7( word ":" ) word CRLF 792 word = 1*4HEX 793 ip6-prefix = ip6-addr "/" 1*2DIGIT 794 ip4-addr = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 795 ip4-subnet = ip4-addr "/" 1*2DIGIT 797 5.7.1. Home Agent Address 799 The HAC MAY provision the MN with an IPv4 or an IPv6 address of a HA, 800 or both. 802 mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr CRLF 803 mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr CRLF 805 5.7.2. Mobile IPv6 Service Port Number 807 The HAC SHOULD provision the MN with an UDP port number, where the HA 808 expects to receive UDP packets. If this parameter is not present, 809 then the IANA reserved port number (HALTSEC) MUST be used instead. 811 mip6-port = "mip6-port" ":" 1*5DIGIT CRLF 813 5.7.3. Home Addresses and Home Network Prefix 815 The HAC MAY provision the MN with an IPv4 or an IPv6 home address, or 816 both. The HAC MAY also provision the MN with its home network 817 prefix. 819 mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr CRLF 820 mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr CRLF 821 mip6-ip6-hnp = "mip6-ip6-hnp" ":" ip6-prefix CRLF 822 mip6-ip4-hnp = "mip6-ip4-hnp" ":" ip4-subnet CRLF 824 5.7.4. DNS Server 826 The HAC may also provide the MN with DNS server configuration 827 options. These DNS servers are reachable via the home agent. 829 dns-ip6 = "dns-ip6" ":" ip6-addr CRLF 830 dns-ip4 = "dns-ip4" ":" ip4-addr CRLF 832 5.8. Authentication of the Mobile Node 834 This section describes the basic operation required for the MN-HAC 835 mutual authentication and the channel binding. The authentication 836 protocol described as part of this section is a simple exchange that 837 follows the GPSK exchange used by EAP-GPSK [RFC5433]. It is secured 838 by the TLS tunnel and is cryptographically bound to the TLS tunnel 839 through channel binding based on [RFC5056] and on the channel binding 840 type 'tls-server-endpoint' described in [RFC5929]. As a result of 841 the channel binding type, this method can only be used with TLS 842 ciphersuites that use server certificates and the Certificate 843 handshake message. For example, TLS ciphersuites based on PSK or 844 anonymous authentication cannot be used. 846 The authentication exchange MUST be performed through the encrypted 847 TLS tunnel. It performs mutual authentication between the MN and the 848 HAC based on a pre-shared key (PSK) or based on an EAP-method (see 849 Section 5.9). Note that a HAC MUST NOT allow MNs to renegotiate TLS 850 sessions. The PSK protocol is described in this section. It 851 consists of the message exchanges (MHAuth-Init, MHAuth-Mid, MHAuth- 852 Done) in which both sides exchange nonces and their identities, and 853 compute and exchange a message authenticator 'auth' over the 854 previously exchanged values, keyed with the pre-shared key. The 855 MHAuth-Done messages are used to deal with error situations. Key 856 binding with the TLS tunnel is ensured by channel binding of the type 857 "tls-server-endpoint" as described by [RFC5929] where the hash of the 858 TLS server certificate serves as input to the 'auth' calculation of 859 the MHAuth messages. 861 Note: The authentication exchange is based on the GPSK exchange used 862 by EAP-GPSK. In comparison to GPSK, it does not support exchanging 863 an encrypted container (it always runs through an already protected 864 TLS tunnel). Furthermore, the initial request of the authentication 865 exchange (MHAuth-Init) is sent by the MN (client side) and is 866 comparable to EAP-Response/Identity, which reverses the roles of 867 request and response messages compared to EAP-GPSK. Figure 4 shows a 868 successful protocol exchange. 870 MN HAC 871 | | 872 | Request/MHAuth-Init (...) | 873 |------------------------------------------------------>| 874 | | 875 | Response/MHAuth-Init (...) | 876 |<------------------------------------------------------| 877 | | 878 | Request/MHAuth-Done (...) | 879 |------------------------------------------------------>| 880 | | 881 | Response/MHAuth-Done (...) | 882 |<------------------------------------------------------| 883 | | 885 Figure 4: Authentication of the Mobile Node Using Shared Secrets 887 1) Request/MHAuth-Init: (MN -> HAC) 888 mn-id, mn-rand, auth-method=psk 890 2) Response/MHAuth-Init: (MN <- HAC) 891 [mn-rand, hac-rand, auth-method=psk, [status],] auth 893 3) Request/MHAuth-Done: (MN -> HAC) 894 mn-rand, hac-rand, sa-scope, ciphersuite-list, auth 896 4) Response/MHAuth-Done: (MN <- HAC) 897 [sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand, 898 hac-rand, status, auth 900 Where 'auth' for MN -> HAC direction is: 902 auth = HMAC-SHA256(PSK, "MN" | msg-octets | CB-octets) 904 Where 'auth' for MN <- HAC direction is: 906 auth = HMAC-SHA256(PSK, "HAC" | msg-octets | CB-octets) 908 In the above "MN" is 2 ASCII characters without null termination and 909 "HAC" is 3 2 ASCII characters without null termination. 911 The length "mn-rand", "hac-rand" is 32 octets. Note that "|" 912 indicates concatenation and optional parameters are shown in square 913 brackets [..]. The square brackets can be nested. 915 The shared secret PSK can be variable length. 'msg-octets' includes 916 all payload parameters of the respective message to be signed except 917 the 'auth' payload. CB-octets is the channel binding input to the 918 auth calculation that is the "TLS-server-endpoint" channel binding 919 type. The content and algorithm (only required for the "TLS-server- 920 endpoint" type) are the same as described in [RFC5929]. 922 The MN starts by selecting a random number 'mn-rand' and choosing a 923 list of supported authentication methods coded in 'auth-method'. The 924 MN sends its identity 'mn-id', 'mn-rand' and 'auth-method' to the HAC 925 in MHAuth-Init. The decision of which authentication method to offer 926 and which to pick is policy- and implementation-dependent and, 927 therefore, outside the scope of this document. 929 In MHAuth-Done, the HAC sends a random number 'hac-rand' and the 930 selected ciphersuite. The selection MUST be one of the MN-supported 931 ciphersuites as received in 'ciphersuite-list'. Furthermore, it 932 repeats the received parameters of the MHAuth-Init message 'mn-rand'. 933 It computes a message authenticator 'auth' over all the transmitted 934 parameters except 'auth' itself. The HAC calculates 'auth' over all 935 parameters and appends it to the message. 937 The MN verifies the received MAC and the consistency of the 938 identities, nonces, and ciphersuite parameters transmitted in MHAuth- 939 Auth. In case of successful verification, the MN computes a MAC over 940 the session parameter and returns it to the HAC in MHAuth-Done. The 941 HAC verifies the received MAC and the consistency of the identities, 942 nonces, and ciphersuite parameters transmitted in MHAuth-Init. If 943 the verification is successful, MHAuth-Done is prepared and sent by 944 the HAC to confirm successful completion of the exchange. 946 5.9. Extensible Authentication Protocol Methods 948 Basic operation required for the MN-HAC mutual authentication using 949 EAP-based methods. 951 MN HAC 952 | | 953 | Request/MHAuth-Init (...) | 954 |------------------------------------------------------>| 955 | | 956 | Response/MHAuth-Init (..., | 957 | eap-payload=EAP-Request/Identity) | 958 |<------------------------------------------------------| 959 | | 960 | Request/MHAuth-Mid (eap-payload= | 961 | EAP-Response/Identity) | 962 |------------------------------------------------------>| 963 | | 964 | Response/MHAuth-Mid (eap-payload=EAP-Request/...) | 965 |<------------------------------------------------------| 966 | | 967 : : 968 : ..EAP-method specific exchanges.. : 969 : : 970 | | 971 | Request/MHAuth-Done (eap-payload=EAP-Response/..., | 972 | ..., auth) | 973 |------------------------------------------------------>| 974 | | 975 | Response/MHAuth-Done (eap-payload=EAP-Success, | 976 | ..., auth) | 977 |<------------------------------------------------------| 978 | | 980 Figure 5: Authentication of the Mobile Node Using EAP 982 1) Request/MHAuth-Init: (MN -> HAC) 983 mn-id, mn-rand, auth-method=eap 985 2) Response/MHAuth-Init: (MN <- HAC) 986 [auth-method=eap, eap, [status,]] auth 988 3) Request/MHAuth-Mid: (MN -> HAC) 989 eap, auth 991 4) Response/MHAuth-Mid: (MN <- HAC) 992 eap, auth 994 MHAuth-Mid exchange is repeated as many times as needed by the 995 used EAP-method. 997 5) Request/MHAuth-Done: (MN -> HAC) 998 sa-scope, ciphersuite-list, eap, auth 1000 6) Response/MHAuth-Done: (MN <- HAC) 1001 [sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap, 1002 status, auth 1004 Where 'auth' for MN -> HAC direction is: 1006 auth = HMAC-SHA256(shared-key, "MN" | msg-octets | CB-octets) 1008 Where 'auth' for MN <- HAC direction is: 1010 auth = HMAC-SHA256(shared-key, "HAC" | msg-octets | CB-octets) 1012 In the above "MN" is 2 ASCII characters without null termination and 1013 "HAC" is 3 2 ASCII characters without null termination. 1015 In MHAuth-Init and MHAuth-Mid messages, shared-key is set to "1". If 1016 the EAP-method is key-deriving and creates a shared MSK key as a side 1017 effect of Authentication shared-key MUST be the MSK in all MHAuth- 1018 Done messages. This MSK MUST NOT be used for any other purpose. In 1019 case the EAP method does not generate an MSK key, shared-key is set 1020 to "1". 1022 'msg-octets' includes all payload parameters of the respective 1023 message to be signed except the 'auth' payload. CB-octets is the 1024 channel binding input to the AUTH calculation that is the "TLS- 1025 server-endpoint" channel binding type. The content and algorithm 1026 (only required for the "TLS-server-endpoint" type) are the same as 1027 described in [RFC5929]. 1029 6. Mobile Node to Home Agent communication 1031 6.1. General 1033 The following sections describe the packet formats used for the 1034 traffic between the MN and the HA. This traffic includes binding 1035 management messages (for example, BU and BA messages), reverse 1036 tunneled and encrypted user data, and reverse tunneled plain text 1037 user data. This specification defines a generic packet format, where 1038 everything is encapsulated inside UDP. See Section 6.3 and 1039 Section 6.4 for detailed illustrations of the corresponding packet 1040 formats. 1042 The Mobile IPv6 service port number is where the HA expects to 1043 receive UDP packets. The same port number is used for both binding 1044 management messages and user data packets. The reason for 1045 multiplexing data and control messages over the same port number is 1046 due to the possibility of Network Address and Port Translators 1047 located along the path between the MN and the HA. The Mobile IPv6 1048 service MAY use any ephemeral port number as the UDP source port, and 1049 MUST use the Mobile IPv6 service port number as the UDP destination 1050 port. The Mobile IPv6 service port is either dynamically assigned to 1051 the MN during the bootstrapping phase (i.e. the mip6-port parameter) 1052 or in absence of the bootstrapping parameter the IANA reserved port 1053 (HALTSEC) MUST be used. 1055 The encapsulating UDP header is immediately followed by a 4-bit 1056 Packet Type (PType) field that defines whether the packet contains an 1057 encrypted mobility management message or a, an encrypted user data 1058 packet, or a plain text user data packet. 1060 The Packet Type field is followed by a 28-bit SPI value, which 1061 identifies the correct SA concerning the encrypted packet. For any 1062 packet that is neither integrity protected nor encrypted (i.e. no SA 1063 is applied by the originator) the SPI MUST be set to 0 (zero). 1064 Mobility management messages MUST always be at least integrity 1065 protected. Hence, mobility management messages MUST NOT be sent with 1066 a SPI value of 0 (zero). 1068 There is always only one SPI per MN-HA mobility session and the same 1069 SPI is used for all types of protected packets independent of the 1070 direction. 1072 The SPI value is followed by a 32-bit Sequence Number value that is 1073 used to identify retransmissions of protected messages (integrity 1074 protected or both integrity protected and encrypted, see Figures 7 1075 and 8) . Each endpoint in the security association maintains two 1076 "current" Sequence Numbers: the next one to be used for a packet it 1077 initiates and the next one it expects to see in a packet from the 1078 other end. If the MN and the HA ends initiate very different numbers 1079 of messages, the Sequence Numbers in the two directions can be very 1080 different. In a case data protection is not used (see Figure 9), the 1081 Sequence Number MUST be set to 0 (zero). Note that the HA SHOULD 1082 initiate a re-establishement of the SA before any of the Sequence 1083 Number cycle. 1085 Finally, the Sequence Number field is followed by the data portion, 1086 whose content is identified by the Packet Type. The data portion may 1087 be protected. 1089 6.2. PType and Security Parameter Index 1091 The PType is a 4-bit field that indicates the Packet Type (PType) of 1092 the UDP encapsulated packet. The PType is followed by a a 28-bit SPI 1093 value. The PType and the SPI fields are treated as one 32-bit field 1094 during the integrity protection calculation. 1096 0 1 2 3 1097 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 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | PType | SPI | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 Figure 6: Security Parameter Index with Packet Type 1104 A SPI value of 0 (zero) indicates a plaintext packet. If the packet 1105 is integrity protected or both integrity protected and encrypted, the 1106 SPI value MUST be different from 0. When the SPI value is set to 0, 1107 then the PType MUST also be 0. 1109 6.3. Binding Management Message Formats 1111 The binding management messages that are only meant to be exchanged 1112 between the MN and the HA MUST be integrity protected and MAY be 1113 encrypted. They MUST use the packet format shown in Figure 7. 1115 All packets that are specific to the Mobile IPv6 protocol, contain a 1116 Mobility Header (as defined in Section 6.1.1. of RFC 6275), and are 1117 used between the MN and the HA use the packet format shown in 1118 Figure 7. (This means that some Mobile IPv6 mobility management 1119 messages, such as the HoTI message, are treated as data packets and 1120 using encapsulation described in Section 6.4 and shown in Figures 8 1121 and 9). 1123 0 1 2 3 1124 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 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | | 1127 : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : 1128 | | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | | 1131 : UDP header (src-port=Xp,dst-port=Yp) : 1132 | | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 1134 |PType=8| SPI | ^Int. 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 1136 | Sequence Number | |ered 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- 1138 | Payload Data* (variable) | | ^ 1139 : : | | 1140 | | |Conf. 1141 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 1142 | | Padding (0-255 bytes) | |ered* 1143 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 1144 | | Pad Length | Next Header | v v 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 1146 | Integrity Check Value-ICV (variable) | 1147 : : 1148 | | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 Figure 7: UDP Encapsulated Binding Management Message Format 1153 The PType value 8 (eight) identifies that the UDP encapsulated packet 1154 contains a RFC 6275 defined Mobility Header and other relevant IPv6 1155 extension headers. Note, there is no additional IP header inside the 1156 encapsulated part. The Next Header field MUST be set to value of the 1157 first encapsulated header. The encapsulated headers follow the 1158 natural IPv6 and Mobile IPv6 extension header alignment and 1159 formatting rules. 1161 The Padding, Pad Length, Next Header and ICV fields follow the rules 1162 of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this 1163 document. For a SPI value of 0 (zero) that indicates an unprotected 1164 packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT 1165 be present. 1167 The source and destination IP addresses of the outer IP header (i.e. 1168 the src-addr and the dst-addr in Figure 7) use the current care-of 1169 address of the MN and the HA address. 1171 6.4. Reverse Tunneled User Data Packet Formats 1173 There are two types of reverse tunneled user data packets between the 1174 MN and the HA. Those that are integrity protected and encrypted and 1175 those that are plaintext. The MN or the HA decide whether to apply 1176 integrity protection and encryption to a packet or to send it in 1177 plaintext based on the mip6-sas value in the SA. If the mip6-sas is 1178 set to 1 the originator MUST NOT send any plaintext packet, and the 1179 receiver MUST silently discard any packet with the PType set to 0 1180 (unprotected). It is RECOMMENDED to apply confidentiality and 1181 integrity protection of user data traffic. The reverse tunneled IPv4 1182 or IPv6 user data packets are encapsulated as-is inside the 'Payload 1183 Data' shown in Figures 8 and 9. 1185 0 1 2 3 1186 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 1187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1188 | | 1189 : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : 1190 | | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | | 1193 : UDP header (src-port=Xp,dst-port=Yp) : 1194 | | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 |PType=1| SPI | ^Int. 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 1198 | Sequence Number | |ered 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- 1200 | Payload Data* (variable) | | ^ 1201 : : | | 1202 | | |Conf. 1203 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 1204 | | Padding (0-255 bytes) | |ered* 1205 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 1206 | | Pad Length | Next Header | v v 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 1208 | Integrity Check Value-ICV (variable) | 1209 : : 1210 | | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 Figure 8: UDP Encapsulated Protected User Data Packet Format 1215 The PType value 1 (one) identifies that the UDP encapsulated packet 1216 contains an encrypted tunneled IPv4/IPv6 user data packet. The Next 1217 Header field header MUST be set to value corresponding the tunneled 1218 IP packet (e.g., 41 for IPv6). 1220 The Padding, Pad Length, Next Header and ICV fields follow the rules 1221 of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this 1222 document. For a SPI value of 0 (zero) that indicates an unprotected 1223 packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT 1224 be present. 1226 The source and destination IP addresses of the outer IP header (i.e., 1227 the src-addr and the dst-addr in Figure 8) use the current care-of 1228 address of the MN and the HA address. The ESP protected inner IP 1229 header, which is not shown in Figure 8, uses the home address of the 1230 MN and the correspondent node (CN) address. 1232 0 1 2 3 1233 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 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 | | 1236 : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : 1237 | | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 | | 1240 : UDP header (src-port=Xp,dst-port=Yp) : 1241 | | 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 |PType=0| 0 | 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | 0 | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | | 1248 : Payload Data (plain IPv4 or IPv6 Packet) : 1249 | | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 Figure 9: UDP Encapsulated Non-Protected User Data Packet Format 1254 The PType value 0 (zero) identifies that the UDP encapsulated packet 1255 contains a plaintext tunneled IPv4/IPv6 user data packet. Also the 1256 SPI and the Sequence Number fields MUST be set to 0 (zero). 1258 The source and destination IP addresses of the outer IP header (i.e., 1259 the src-addr and the dst-addr in Figure 9) use the current care-of 1260 address of the MN and the HA address. The plain text inner IP header 1261 uses the home address of the MN and the CN address. 1263 7. Route Optimization 1265 Mobile IPv6 route optimization as described in [RFC6275] is not 1266 affected by this specification. Route optimization is possible only 1267 between an IPv6 MN and CN. UDP encapsulation of signaling and data 1268 traffic is only between the MN and HA. The return routability 1269 signaling messages such as HoTI/HoT and CoTI/CoT [RFC6275] are 1270 treated as data packets and encapsulation, when needed, is as per the 1271 description in Section 6.4 of this specification. The data packets 1272 between an MN and CN which have successfully completed the return 1273 routability test and created the appropriate entries in their binding 1274 cache are not UDP encapsulated using the packet formats defined in 1275 this specification but follow the [RFC6275] specification. 1277 8. IANA Considerations 1279 8.1. New Registry: Packet Type 1281 IANA is requested to create a new registry under the [RFC6275] Mobile 1282 IPv6 parameters registry for the Packet Type as described in 1283 Section 6.1. 1285 Packet Type | Value 1286 ----------------------------------+---------------------------------- 1287 non-encrypted IP packet | 0 1288 encrypted IP packet | 1 1289 mobility header | 8 1291 Following the allocation policies from [RFC5226] new values for the 1292 Packet Type AVP MUST be assigned based on the "RFC Required" policy. 1294 8.2. Status Codes 1296 A new Status Code (to be used in BA messages) is reserved for the 1297 cases where the HA wants to indicate to the MN that it needs to re- 1298 establish the SA information with the HAC. The Result Code is 1299 reserved from the 0-127 code space in [RFC6275] Status Codes 1300 registry: 1302 REINIT_SA_WITH_HAC TBD1 1304 8.3. Port Numbers 1306 A new port number (HALTSEC) for UDP packets is reserved from the 1307 existing PORT NUMBERS registry. 1309 HALTSEC TBD2 1311 9. Security Considerations 1313 This document describes and uses a number of building blocks that 1314 introduce security mechanisms and need to inter-work in a secure 1315 manner. 1317 The following building blocks are considered from a security point of 1318 view: 1320 1. Discovery of the HAC 1321 2. Authentication and MN-HA SA establishment executed between the MN 1322 and the HAC (PSK or EAP-based) through a TLS tunnel 1323 3. Protection of MN-HA communication 1324 4. AAA Interworking 1326 9.1. Discovery of the HAC 1328 No dynamic procedure for discovering the HAC by the MN is described 1329 in this document. As such, no specific security considerations apply 1330 to the scope of this document. 1332 9.2. Authentication and Key Exchange executed between the MN and the 1333 HAC 1335 This document describes a simple authentication and MN-HA SA 1336 negotiation exchange over TLS. The TLS procedures remain unchanged; 1337 however, channel binding is provided. 1339 Authentication: Server-side certificate based authentication MUST be 1340 performed using TLS 1.2 [RFC5246]. The MN MUST verify the HAC's 1341 TLS server certificate, using either subjectAltName extension 1342 [RFC5280] dNSName identities as described in [RFC6125] or 1343 subjectAltName iPAddress identities. In case of iPAddress 1344 identities the MN MUST check the IP address of the TLS connection 1345 against these iPAddress identities and SHOULD reject the 1346 connection if none of the iPAddress identities match the 1347 connection. In case of dNSName identities the rules and 1348 guidelines defined in [RFC6125] apply here, with the following 1349 considerations: 1351 * Support for DNS-ID identifier type (the dNSName identity in the 1352 subjectAltName extension) is REQUIRED in the HAC and the MN TLS 1353 implementations. 1354 * DNS names in the HAC server certificates MUST NOT contain the 1355 wildcard character "*". 1356 * The CN-ID MUST NOT be used for authentication within the rules 1357 described in [RFC6125]. 1359 * The MN MUST set its "reference identifier" to the DNS name of 1360 the HAC. 1362 The client-side authentication may depend on the specific 1363 deployment and is therefore not mandated. Note that TLS-PSK 1364 [RFC4279] cannot be used in conjunction with the methods described 1365 in section 5.8 and 5.9 of this document due to the limitations of 1366 the channel binding type used. 1368 Through the protected TLS tunnel, an additional authentication 1369 exchange is performed that provides client-side or mutual 1370 authentication and exchanges SA parameters and optional 1371 configuration data to be used in the subsequent protection of 1372 MN-HA communication. The additional authentication exchange can 1373 either be PSK-based (section 5.8) or EAP-based (section 5.9). 1374 Both exchanges are always performed within the protected TLS 1375 tunnel and MUST NOT be used as standalone protocols. 1377 The simple PSK-based authentication exchange provides mutual 1378 authentication and follows the GPSK exchange used by EAP-GPSK 1379 [RFC5433] and has similar properties, although some features of 1380 GPSK like the exchange of a protected container are not supported. 1382 The EAP-based authentication exchange simply defines message 1383 containers to allow carrying the EAP packets between the MN and 1384 the HAC. In principle, any EAP method can be used. However, it 1385 is strongly recommended to use only EAP methods that provide 1386 mutual authentication and that derive keys including an MSK key in 1387 compliance with [RFC3748]. 1389 Both exchanges use channel binding with the TLS tunnel. The 1390 channel binding type 'TLS-server-endpoint' as per [RFC5929] MUST 1391 be used. 1393 Dictionary Attacks: All messages of the authentication exchanges 1394 specified in this document are protected by TLS. However, any 1395 implementation SHOULD assume that the properties of the 1396 authentication exchange are the same as for GPSK [RFC5433] in case 1397 the PSK-based method as per section 5.8. is used, and are the same 1398 as those of the underlying EAP method in case the EAP-based 1399 exchange as per section 5.9 is used. 1401 Replay Protection: The underlying TLS protection provides protection 1402 against replays. 1404 Key Derivation and Key Strength: For TLS, the TLS specific 1405 considerations apply unchanged. For the authentication exchanges 1406 defined in this document, no key derivation step is performed as 1407 the MN-HA keys are generated by the HAC and are distributed to the 1408 MN through the secure TLS connection. 1410 Key Control: No joint key control for MN-HA keys is provided by this 1411 version of the specification. 1413 Lifetime: The TLS-protected authentication exchange between the MN 1414 and the HAC is only to bootstrap keys and other parameters for 1415 usage with MN-HA security. The SAs that contain the keys have an 1416 associated lifetime. The usage of Transport Layer Security (TLS) 1417 Session Resumption without Server-Side State, described in 1418 [RFC5077], provides the ability for the MN to minimize the latency 1419 of future exchanges towards the HA without having to keep state at 1420 the HA itself. 1422 Denial of Service Resistance: The level of resistance against denial 1423 of service attacks SHOULD be considered the same as for common TLS 1424 operation, as TLS is used unchanged. For the PSK-based 1425 authentication exchange, no additional factors are known. For the 1426 EAP-based authentication exchange, any considerations regarding 1427 denial-of-service resistance specific to the chosen EAP method are 1428 expected to be applicable and need to be be taken into account. 1430 Session Independence: Each individual TLS protocol run is 1431 independent from any previous exchange based on the security 1432 properties of the TLS handshake protocol. However, several PSK or 1433 EAP-based authentication exchanges can be performed across the 1434 same TLS connection. 1436 Fragmentation: TLS runs on top of TCP and no fragmentation specific 1437 considerations apply to the MN-HAC authentication exchanges. 1439 Channel Binding: Both the PSK and the EAP-based exchanges use 1440 channel binding with the TLS tunnel. The channel binding type 1441 'TLS-server-endpoint' as per [RFC5929] MUST be used. 1443 Fast Reconnect: This protocol provides session resumption as part of 1444 TLS and optionally the support for [RFC5077]. No fast reconnect 1445 is supported for the PSK-based authentication exchange. For the 1446 EAP-based authentication exchange, availability of fast reconnect 1447 depends on the EAP method used. 1449 Identity Protection: Based on the security properties of the TLS 1450 tunnel, passive user identity protection is provided. An attacker 1451 acting as man-in-the-middle in the TLS connection would be able to 1452 observe the MN identity value sent in MHAuth-Init messages. 1454 Protected Ciphersuite Negotiation: This protocol provides 1455 ciphersuite negotiation based on TLS. 1457 Confidentiality: Confidentiality protection of payloads exchanged 1458 between the MN and the HAC are protected with the TLS Record 1459 Layer. TLS ciphersuites with confidentiality and integrity 1460 protection MUST be negotiated and used in order to exchange 1461 security sensitive material inside the TLS connection. 1463 Cryptographic Binding: No cryptographic bindings are provided by 1464 this protocol specified in this document. 1466 Perfect Forward Secrecy: Perfect forward secrecy is provided with 1467 appropriate TLS ciphersuites. 1469 Key confirmation: Key confirmation of the keys established with TLS 1470 is provided by the TLS Record Layer when the keys are used to 1471 protect the subsequent TLS exchange. 1473 9.3. Protection of MN and HA Communication 1475 Authentication: Data origin authentication is provided for the 1476 communication between the MN and the HA. The chosen level of 1477 security of this authentication depends on the selected 1478 ciphersuite. Entity authentication is offered by the MN to HAC 1479 protocol exchange. 1481 Dictionary Attacks: The concept of dictionary attacks is not 1482 applicable to the MN-HA communication as the keying material used 1483 for this communication is randomly created by the HAC and its 1484 length depends on the chosen cryptographic algorithms. 1486 Replay Protection: Replay protection for the communication between 1487 the MN and the HA is provided based on sequence numbers and 1488 follows the design of IPsec ESP. 1490 Key Derivation and Key Strength: The strength of the keying material 1491 established for the communication between the MN and the HA is 1492 selected based on the negotiated ciphersuite (based on the MN-HAC 1493 exchange) and the key created by the HAC. The randomness 1494 requirements for security described in RFC 4086 [RFC4086] are 1495 applicable to the key generation by the HAC. 1497 Key Control: The keying material established during the MN-HAC 1498 protocol exchange for subsequent protection of the MN-HA 1499 communication is created by the HA and therefore no joint key 1500 control is provided for it. 1502 Key Naming: For the MN-HA communication the security associations 1503 are indexed with the help of the SPI and additionally based on the 1504 direction (in-bound communication or out-bound communication). 1506 Lifetime: The lifetime of the MN-HA security associations is based 1507 on the value in the mip6-sa-validity-end header field exchanged 1508 during the MN-HAC exchange. The HAC controls the SA lifetime. 1510 Denial of Service Resistance: For the communication between the MN 1511 and the HA there are no heavy cryptographic operations (such as 1512 public key computations). As such, there are no DoS concerns. 1514 Session Independence: Sessions are independent from each other when 1515 new keys are created by via the MN-HAC protocol. A new MN-HAC 1516 protocol run produces fresh and unique keying material for 1517 protection of the MN-HA communication. 1519 Fragmentation: There is no additional fragmentation support provided 1520 beyond what is offered by the network layer. 1522 Channel Binding: Channel binding is not applicable to the MN-HA 1523 communication. 1525 Fast Reconnect: The concept of fast reconnect is not applicable to 1526 the MN-HA communication. 1528 Identity Protection: User identities SHOULD NOT be exchanged between 1529 the MN and the HA. In a case binding management messages contain 1530 the user identity, the messages SHOULD be confidentiality 1531 protected. 1533 Protected Ciphersuite Negotiation: The MN-HAC protocol provides 1534 protected ciphersuite negotiation through a secure TLS connection. 1536 Confidentiality: Confidentiality protection of payloads exchanged 1537 between the MN and the HAC (for Mobile IPv6 signaling and 1538 optionally for the data traffic) is provided utilizing algorithms 1539 negotiated during the MN-HAC exchange. 1541 Cryptographic Binding: No cryptographic bindings are provided by 1542 this protocol specified in this document. 1544 Perfect Forward Secrecy: Perfect forward secrecy is provided when 1545 the MN bootstraps new keying material with the help of the MN-HAC 1546 protocol (assuming that a proper TLS ciphersuite is used). 1548 Key confirmation: Key confirmation of the MN-HA keying material 1549 conveyed from the HAC to the MN is provided when the first packets 1550 are exchanged between the MN and the HA (in both directions as two 1551 different keys are used). 1553 9.4. AAA Interworking 1555 The AAA backend infrastructure interworking is not defined in this 1556 document and therefore out-of-scope. 1558 10. Acknowledgements 1560 The authors would like to thank Pasi Eronen, Domagoj Premec, Julien 1561 Laganier, Jari Arkko, Stephen Farrell, Peter Saint-Andre and 1562 Christian Bauer for their comments. 1564 11. References 1566 11.1. Normative References 1568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1569 Requirement Levels", BCP 14, RFC 2119, March 1997. 1571 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1572 ESP and AH", RFC 2404, November 1998. 1574 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 1575 Its Use With IPsec", RFC 2410, November 1998. 1577 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 1578 Algorithms", RFC 2451, November 1998. 1580 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1581 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1582 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1584 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 1585 and Its Use With IPsec", RFC 3566, September 2003. 1587 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1588 Algorithm and Its Use with IPsec", RFC 3602, 1589 September 2003. 1591 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1592 Network Access Identifier", RFC 4282, December 2005. 1594 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1595 Channels", RFC 5056, November 2007. 1597 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1598 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1599 May 2008. 1601 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1602 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1604 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1605 Housley, R., and W. Polk, "Internet X.509 Public Key 1606 Infrastructure Certificate and Certificate Revocation List 1607 (CRL) Profile", RFC 5280, May 2008. 1609 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1610 for TLS", RFC 5929, July 2010. 1612 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1613 in IPv6", RFC 6275, July 2011. 1615 11.2. Informative References 1617 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1618 August 1980. 1620 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1621 Levkowetz, "Extensible Authentication Protocol (EAP)", 1622 RFC 3748, June 2004. 1624 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1625 Protect Mobile IPv6 Signaling Between Mobile Nodes and 1626 Home Agents", RFC 3776, June 2004. 1628 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1629 Requirements for Security", BCP 106, RFC 4086, June 2005. 1631 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1632 for Transport Layer Security (TLS)", RFC 4279, 1633 December 2005. 1635 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1636 Internet Protocol", RFC 4301, December 2005. 1638 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1639 RFC 4303, December 2005. 1641 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1642 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1643 April 2007. 1645 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1646 "Transport Layer Security (TLS) Session Resumption without 1647 Server-Side State", RFC 5077, January 2008. 1649 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 1650 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 1651 RFC 5433, February 2009. 1653 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1654 Routers", RFC 5555, June 2009. 1656 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 1657 RFC 5944, November 2010. 1659 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1660 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1661 RFC 5996, September 2010. 1663 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1664 Verification of Domain-Based Application Service Identity 1665 within Internet Public Key Infrastructure Using X.509 1666 (PKIX) Certificates in the Context of Transport Layer 1667 Security (TLS)", RFC 6125, March 2011. 1669 Authors' Addresses 1671 Jouni Korhonen (editor) 1672 Nokia Siemens Networks 1673 Linnoitustie 6 1674 Espoo FIN-02600 1675 Finland 1677 Email: jouni.nospam@gmail.com 1678 Basavaraj Patil 1679 Nokia 1680 6021 Connection Drive 1681 Irving, TX 75039 1682 USA 1684 Email: basavaraj.patil@nokia.com 1686 Hannes Tschofenig 1687 Nokia Siemens Networks 1688 Linnoitustie 6 1689 Espoo 02600 1690 Finland 1692 Phone: +358 (50) 4871445 1693 Email: Hannes.Tschofenig@gmx.net 1695 Dirk Kroeselberg 1696 Siemens 1698 Email: dirk.kroeselberg@siemens.com