idnits 2.17.1 draft-ietf-mext-mip6-tls-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 11, 2011) is 4581 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) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 3 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: April 13, 2012 Nokia 6 H. Tschofenig 7 Nokia Siemens Networks 8 D. Kroeselberg 9 Siemens 10 October 11, 2011 12 Transport Layer Security-based Mobile IPv6 Security Framework for Mobile 13 Node to Home Agent Communication 14 draft-ietf-mext-mip6-tls-02.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 April 13, 2012. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 65 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4. TLS-based Security Establishment . . . . . . . . . . . . . . . 6 67 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.3. Security Association Management . . . . . . . . . . . . . 8 70 4.4. Bootstrapping of Additional Mobile IPv6 Parameters . . . . 10 71 4.5. Protecting Traffic Between Mobile Node and Home Agent . . 11 72 5. Mobile Node to Home Agent Controller Communication . . . . . . 11 73 5.1. Request-response Message Framing over TLS-tunnel . . . . . 11 74 5.2. Request-response Message Content Encoding . . . . . . . . 12 75 5.3. Request-Response Message Exchange . . . . . . . . . . . . 12 76 5.4. Home Agent Controller Discovery . . . . . . . . . . . . . 13 77 5.5. Generic Request-Response Parameters . . . . . . . . . . . 13 78 5.5.1. Mobile Node Identifier . . . . . . . . . . . . . . . . 13 79 5.5.2. Authentication Method . . . . . . . . . . . . . . . . 14 80 5.5.3. Extensible Authentication Protocol Payload . . . . . . 14 81 5.5.4. Status Code . . . . . . . . . . . . . . . . . . . . . 14 82 5.5.5. Message Authenticator . . . . . . . . . . . . . . . . 15 83 5.5.6. Retry After . . . . . . . . . . . . . . . . . . . . . 15 84 5.5.7. End of Message Content . . . . . . . . . . . . . . . . 15 85 5.5.8. Random Values . . . . . . . . . . . . . . . . . . . . 15 86 5.6. Security Association Configuration Parameters . . . . . . 15 87 5.6.1. Security Parameter Index . . . . . . . . . . . . . . . 16 88 5.6.2. MN-HA Shared Keys . . . . . . . . . . . . . . . . . . 16 89 5.6.3. Security Association Validity Time . . . . . . . . . . 16 90 5.6.4. Security association scope (SAS) . . . . . . . . . . . 16 91 5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping . . 17 92 5.7. Mobile IPv6 Bootstrapping Parameters . . . . . . . . . . . 18 93 5.7.1. Home Agent Address . . . . . . . . . . . . . . . . . . 18 94 5.7.2. Mobile IPv6 Service Port Number . . . . . . . . . . . 18 95 5.7.3. Home Addresses and Home Network Prefix . . . . . . . . 19 96 5.7.4. DNS Server . . . . . . . . . . . . . . . . . . . . . . 19 97 5.8. Authentication of the Mobile Node . . . . . . . . . . . . 19 98 5.9. Extensible Authentication Protocol Methods . . . . . . . . 21 99 6. Mobile Node to Home Agent communication . . . . . . . . . . . 23 100 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 23 101 6.2. PType and Security Parameter Index . . . . . . . . . . . . 24 102 6.3. Binding Management Message Formats . . . . . . . . . . . . 25 103 6.4. Reverse Tunneled User Data Packet Formats . . . . . . . . 27 104 7. Route Optimization . . . . . . . . . . . . . . . . . . . . . . 28 105 7.1. Replicating RFC6275 Route Optimization . . . . . . . . . . 29 106 7.2. Enhanced Route Optimization with Home Agent-less 107 Operation . . . . . . . . . . . . . . . . . . . . . . . . 29 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 109 8.1. New Registry: Packet Type . . . . . . . . . . . . . . . . 30 110 8.2. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 30 111 8.3. Port Numbers . . . . . . . . . . . . . . . . . . . . . . . 30 112 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 113 9.1. Discovery of the HAC . . . . . . . . . . . . . . . . . . . 31 114 9.2. Authentication and Key Exchange executed between the 115 MN and the HAC . . . . . . . . . . . . . . . . . . . . . . 31 116 9.3. Protection of MN and HA Communication . . . . . . . . . . 33 117 9.4. AAA Interworking . . . . . . . . . . . . . . . . . . . . . 35 118 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 119 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 120 11.1. Normative References . . . . . . . . . . . . . . . . . . . 35 121 11.2. Informative References . . . . . . . . . . . . . . . . . . 36 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 124 1. Introduction 126 Mobile IPv6 signaling as specified in RFC6275 [RFC6275], and 127 optionally user traffic, between a mobile node (MN) and home agent 128 (HA) are secured by IPsec [RFC4301]. The current Mobile IPv6 129 security architecture is specified in [RFC3776] and [RFC4877]. This 130 security model requires a tight coupling between the Mobile IPv6 131 protocol part and the IKE(v2)/IPsec part of the IP stack. 132 Implementation experience has shown that the use of IKE(v2)/IPsec 133 with Mobile IPv6 is fairly complex. The issues with the IKE(v2)/ 134 IPsec based security architecture are documented in 135 [I-D.patil-mext-mip6issueswithipsec]. 137 This document proposes an alternate security framework for Mobile 138 IPv6 and Dual-Stack Mobile IPv6. The objective is to simplify 139 implementations as well as make it easy to deploy the protocol 140 without compromising on security. Transport Layer Security (TLS) 141 [RFC5246] is widely implemented in almost all major operating systems 142 and extensively used. Instead of using IKEv2, the security framework 143 proposed in this document is based on TLS protected messages to 144 exchange keys and bootstrapping parameters between the Mobile Node 145 and a new functional entity called as the Home Agent Controller 146 (HAC). The Mobile IPv6 signaling between the mobile node and home 147 agent is subsequently secured using the resulting keys and negotiated 148 cipher suite. The HAC can be co-located with the HA, or can be an 149 independent entity. For the latter case, communication between HAC 150 and HA is not defined by this document. The Diameter protocol can be 151 used between the HA and HAC when the two entities are not collocated. 153 The primary advantage of using TLS based establishment of Mobile IP6 154 security associations compared to IKEv2 is the ease of implementation 155 while providing equivalent level of security. For the protection of 156 Mobile IPv6 signaling messages a solution is provided that decouples 157 Mobile IPv6 protection from regular IPsec operation to reduce 158 complexity in Mobile IP client implementations. 160 The security framework proposed in this document is not intended to 161 replace the currently specified architecture which relies on IPsec 162 and IKEv2. It provides an alternative solution which is more optimal 163 for certain deployment scenarios. 165 2. Terminology and Abbreviations 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 Home Agent Controller (HAC): 173 The home agent controller is a node responsible for bootstrapping 174 Mobile IPv6 security associations between a mobile node and one or 175 more home agents. The home agent controller also provides key 176 distribution to both mobile nodes and home agents. Mobile IPv6 177 bootstrapping is also performed by the HA in addition to the 178 security association bootstrapping between the mobile node and 179 home agent controller. 181 Binding Management Messages: 183 Mobile IPv6 signaling messages between a mobile node and a home 184 agent, correspondent node or mobility access point to manage the 185 bindings are referred to as binding management messages. Binding 186 Updates and Binding Acknowledgement messages are examples of 187 binding management messages. 189 3. Background 191 Work on the design and specification of Mobile IPv6 has been done 192 since the late 90s. The security architecture of Mobile IPv6 was 193 based on the understanding that IPsec is an inherent and integral 194 part of the IPv6 stack and any protocol that needs security should 195 use IPsec unless there is a good reason not to. As a result of this 196 mindset the Mobile IP6 protocol relied on the use of IPsec for 197 security between the MN and HA. While reuse of security components 198 that are part of the IP stack is a good objective, in the case of 199 Mobile IPv6 implementation complexity increases quite dramatically. 200 It should be noted that Mobile IPv4 [RFC5944] for example does not 201 use IPsec for security and instead has specified its own security 202 solution. Mobile IPv4 has been implemented and deployed on a 203 reasonably large scale and the security model has proven itself to be 204 sound. 206 Mobile IPv6 standardization was completed in 2005 along with the 207 security architecture using IKE/IPsec specified in RFC 3776 208 [RFC3776]. With the transition to IKEv2 [RFC5996], Mobile IP6 209 security has also been updated to rely on the use of IKEv2 [RFC4877]. 210 Recent implementation exercises of Mobile IPv6 and Dual-stack Mobile 211 IPv6 [RFC5555] have identified the complexity of using IPsec and 212 IKEv2 in conjunction with Mobile IPv6. At an abstract level it can 213 be said that implementing Mobile IPv6 with IPsec and IKEv2 is 214 possible only with modifications to the IPsec and IKEv2 components. 215 The original design intent was to reuse IPsec without having to 216 modify them. The current security model requires an IPsec/IKEv2 217 implementation that is specific to Mobile IPv6. 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 where 232 the HAC uses a TLS server certificate as credentials. MN 233 authentication is done by the HAC via signaling messages that are 234 secured by the TLS connection. This can either be MN-only 235 authentication within the server-authenticated TLS channel, or mutual 236 authentication between the MN and HAC. Upon successful completion of 237 authentication, the HAC generates keys which are delivered to the MN 238 through the secure TLS channel. The same keys are also provided to 239 the assigned HA. The HAC also provides the MN with MIP6 240 bootstrapping information such as the address of the HA, the Home 241 network prefix, and the IPv6 and/or IPv4 HoA. 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. Figure 1 below 245 is an illustration of the process: 247 MN HAC HA 248 -- --- -- 249 | | | 250 | /-------------------------\ | | 251 |/ \| | 252 |\ TLS session setup /| | 253 | \-------------------------/ | | 254 | | | 255 | /-------------------------\ | | 256 |/ MN Authentication \| | 257 |\ /| | 258 | \-------------------------/ | | 259 | | | 260 | /-------------------------\ | | 261 |/ HAC provisions the MN \| | 262 |\ keys, SPI and MIP6 parms /| | 263 | \-------------------------/ | | 264 | |--MNID, keys, SPI->| 265 | | | 266 | /--------------------------------------------\ | 267 |/ MN-HA SA established; Secures \ | 268 |\ signaling and optionally user traffic / | 269 | \--------------------------------------------/ | 270 | | 271 |------------BU(encrypted)----------------------->| 272 | | 273 |<---------BAck(encrypted)------------------------| 275 Figure 1: High level architecture 277 4.2. Architecture 279 The TLS-based security architecture is shown in Figure 2. The 280 signaling message exchange between the MN and the HAC is protected by 281 TLS. It should be noted that a HAC, a AAA server and a HA are 282 logically separate entities and can be collocated in all possible 283 combinations. There MUST be a strong trust relationship between the 284 HA and the HAC, and the communication between them MUST be both 285 integrity and confidentially protected. 287 +------+ +------+ +------+ 288 |Mobile| TLS |Home | AAA | AAA | 289 | Node |<----------->|Agent |<---------->|Server| 290 | | |Contrl| | | 291 +------+ +------+ +------+ 292 ^ ^ ^ 293 | | | 294 | BU/BA/../ | e.g. AAA | AAA 295 | (Data) | | 296 | v | 297 | +---------+ | 298 | | MIPv6 | | 299 +--------------->| Home |<-------------+ 300 | Agent(s)| 301 +---------+ 303 Figure 2: TLS-based Security Architecture Overview 305 4.3. Security Association Management 307 Once the MN has contacted the HAC and mutual authentication has taken 308 place between the MN and the HAC, the HAC securely provisions the MN 309 with all security related information inside the TLS protected 310 tunnel. This security related information constitutes a security 311 association (SA) between the MN and the HA. The created SA MUST NOT 312 be tied to the Care-of Address (CoA) of the MN. 314 The HAC may proactively distribute the SA information to HAs, or the 315 HA may query the SA information from the HAC once the MN contacts the 316 HA. If the HA requests SA information from the HAC, then the HA MUST 317 be able to query/index the SA information from the HAC based on the 318 Security Parameter Index (SPI) identifying the correct security 319 association between the MN and the HA. 321 The HA may want the MN to re-establish the SA even if the existing SA 322 is still valid. The HA can indicate this to the MN using a dedicated 323 Status Code in a BA (value set to REINIT_SA_WITH_HAC). As a result, 324 the MN SHOULD contact the HAC prior to the SA timing out, and the HAC 325 would provision the MN and HAs with a new SA to be used subsequently. 327 The SA established between MN and HAC SHALL contain at least the 328 following information: 330 Mobility SPI: 332 This parameter is an SPI used by the MN and the HA to index the SA 333 between the MN and the HA. The HAC is responsible for assigning 334 SPIs to MNs. There is only one SPI for both binding management 335 messaging and possible user data protection. The same SPI is used 336 for both directions between the MN and the HA. The SPI values are 337 assigned by the HAC. The HAC MUST ensure uniqueness of the SPI 338 values across all MNs controlled by the HAC. 340 MN-HA keys for ciphering: 342 A pair of symmetric keys (MN -> HA, HA -> MN) used for ciphering 343 Mobile IPv6 traffic between the MN and the HA. The HAC is 344 responsible for generating these keys. The key generation 345 algorithm is specific to the HAC implementation. 347 MN-HA shared key for integrity protection: 349 A pair of symmetric keys (MN -> HA, HA -> MN) used for integrity 350 protecting Mobile IPv6 traffic between the MN and the HA. This 351 includes both binding management messages and reverse tunneled 352 user data traffic between the MN and the HA. The HAC is 353 responsible for generating these keys. The key generation 354 algorithm is specific to the HAC implementation. In case of 355 combined algorithms a separate integrity protection key is not 356 needed and may be omitted, i.e., the encryption keys SHALL be 357 used. 359 Security association validity time: 361 This parameter represents the validity time for the security 362 association. The HAC is responsible for defining the lifetime 363 value based on its policies. The lifetime may be in the order of 364 hours or weeks. The MN MUST re-contact the HAC before the SA 365 validity time ends. 367 Security Association Scope: 369 This parameter defines whether the security association is applied 370 to Mobile IPv6 signaling messages only, or to both Mobile IPv6 371 signaling messages and data traffic. 373 Selected ciphersuite: 375 This parameter is the ciphersuite used to protect the traffic 376 between the MN and the HA. This includes both binding management 377 messages and reverse tunneled user data traffic between the MN and 378 the HA. The selected algorithms SHOULD be one of the mutually 379 supported ciphersuites of the negotiated TLS version between the 380 MN and the HAC. The HAC is responsible for choosing the mutually 381 supported ciphersuite that complies with the policy of the HAC. 382 Obviously, the HAs under HAC's management must have at least one 383 ciphersuite with the HAC in common and need to be aware of the 384 implemented ciphersuites. The selected ciphersuite is the same 385 for both directions (MN -> HA and HA -> MN). 387 Sequence numbers: 389 A monotonically increasing unsigned sequence number used in all 390 protected packets exchanged between the MN and the HA in the same 391 direction. Sequence numbers are maintained per direction, so each 392 SA includes two independent sequence numbers (MN -> HA, HA -> MN). 393 The initial sequence number for each direction MUST always be set 394 to 0 (zero). Sequence numbers cycle to 0 (zero) when increasing 395 beyond their maximum defined value. 397 4.4. Bootstrapping of Additional Mobile IPv6 Parameters 399 When the MN contacts the HAC to distribute the security related 400 information, the HAC may also provision the MN with various Mobile 401 IPv6 related bootstrapping information. Bootstrapping of the 402 following information SHOULD at least be possible: 404 Home Agent IP Address: 406 Concerns both IPv6 and IPv4 home agent addresses. 408 Mobile IPv6 Service Port Number: 410 The port number where the HA is listening to UDP [RFC0768] 411 packets. 413 Home Address: 415 Concerns both IPv6 and IPv4 Home Addresses. 417 Home Link Prefix: 419 Concerns the IPv6 Home link prefix and the associated prefix 420 length. 421 DNS Server Address: 423 The address of a DNS server that can be reached via the HA. DNS 424 queries in certain cases cannot be routed to the DNS servers 425 assigned by the access network to which the MN is attached and 426 hence an additional DNS server address which is reachable via the 427 HA needs to be configured. 429 The Mobile IPv6 related bootstrapping information is delivered from 430 the HAC to the MN over the same TLS protected tunnel as the security 431 related information. 433 4.5. Protecting Traffic Between Mobile Node and Home Agent 435 The same integrity and confidentiality algorithms MUST be used to 436 protect both binding management messages and reverse tunneled user 437 data traffic between the MN and the HA. Generally, all binding 438 management messages (BUs, BAs and so on) MUST be integrity protected 439 and SHOULD be confidentially protected. The reverse tunneled user 440 data traffic SHOULD be equivalently protected. Generally, the 441 requirements stated in [RFC6275] concerning the protection of the 442 traffic between the MN and the HA also apply to the mechanisms 443 defined by this specification. 445 5. Mobile Node to Home Agent Controller Communication 447 5.1. Request-response Message Framing over TLS-tunnel 449 The MN and the HAC communicate with each other using a simple lock- 450 step request-response protocol that is run inside the protected TLS- 451 tunnel. A generic message container framing for the request messages 452 and for the response messages is defined. The message containers are 453 only meant to be exchanged on top of connection oriented TLS-layer. 454 Therefore, the end of message exchange is determined by the other end 455 closing the transport connection (assuming the "application layer" 456 has also indicated the completion of the message exchange). The peer 457 initiating the TLS-connection is always sending "Requests" and the 458 peer accepting the TLS-connection is always sending "Responses". The 459 format of the message container is shown in Figure 3. 461 All data inside the Content portion of the message container MUST be 462 encoded using octets. Fragmentation of message containers is not 463 supported, which means one request or response at the "application 464 layer" MUST NOT exceed the maximum size allowed by the message 465 container format. 467 0 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Ver | Rsrvd | Identifier | Length | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 | Content portion.. ~ 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Figure 3: Request-Response Message Container 477 The three bit Ver field identifies the protocol version. The current 478 version is 0 i.e. all bits are set to value 0 (zero). 480 The Rsrvd field MUST be set to value 0 (zero), 482 The Identifier field is meant for matching requests and responses. 483 The valid Identifier values are between 1-255. The value 0 MUST NOT 484 be used. The first request for each communication session between 485 the MN and the HAC MUST have the Identifier values set to 1. 487 The Length field tells the length of the Content portion of the 488 container (i.e. Reserved octet, Identifier octet and Length field 489 are excluded). The Content portion length MUST always be at least 490 one octet up to 65535 octets. The value is in network order. 492 5.2. Request-response Message Content Encoding 494 The encoding of the message content is similar to HTTP header 495 encoding, and complies to the augmented Backus-Naur Form (BNF) 496 defined in Section 2.1 of [RFC2616]. All presented hexadecimal 497 numbers are in network byte order. From now on, we use TypeValue 498 header (TV-header) term to refer request-response message content 499 HTTP-like headers. 501 5.3. Request-Response Message Exchange 503 The message exchange between the MN and the HAC is a simple lock-step 504 request-response type as stated in Section 5.1. A request message 505 includes monotonically increasing Identifier value that is copied to 506 the corresponding response message. Each request MUST have a 507 different Identifier value. Hence, a reliable connection oriented 508 transport below the message container framing is assumed. The number 509 of request-response message exchanges MUST NOT exceed 255. 511 Each new communication session between the MN and the HAC MUST reset 512 the Identifier value to 1. The MN is also the peer that always sends 513 only request messages and the HAC only sends response messages. Once 514 the request-response message exchange completes, the HAC and the MN 515 MUST close the transport connection and the corresponding TLS-tunnel. 517 In a case of a HAC side error, the HAC MUST send a response back to a 518 MN with an appropriate status code and then close the transport 519 connection. 521 The first request message - MHAuth-Init - (i.e. the Identifier is 1) 522 MUST always contain at least the following parameters: 524 MN-Identity - See Section 5.5.1. 525 Authentication Method - See Section 5.5.2. 527 The first response message - MHAuth-Init - (i.e. the Identifier is 1) 528 MUST contain at minimum the following parameters: 530 Selected authentication Method - See Section 5.5.2. 532 The last request message from the MN side - MHAuth-Done - MUST 533 contain the following parameters: 535 Security Association Scope - See Section 5.6.4. 536 Proposed ciphersuites - See Section 5.6.5. 537 Message Authenticator - See Section 5.5.5. 539 The last response message - MHAuth-Done - that ends the request- 540 response message exchange MUST contain the following parameters: 542 Status Code - See Section 5.5.4. 543 Message Authenticator - See Section 5.5.5. 545 And in a case of successful authentication the following additional 546 parameters: 548 Selected ciphersuite - See Section 5.6.5. 549 Security Association Scope - See Section 5.6.4. 550 The rest of the security association data - See Section 5.6. 552 5.4. Home Agent Controller Discovery 554 All bootstrapping information, whether for setting up the SA or for 555 bootstrapping Mobile IPv6 specific information, is exchanged between 556 the MN and the HAC using the framing protocol defined in Section 5.1. 557 The IP address of the HAC MAY be statically configured to the MN or 558 may be dynamically discovered using DNS. In a case of DNS-based HAC 559 discovery, the MN either queries an A/AAAA or a SRV record for the 560 HAC IP address. The actual domain name used in queries is up to the 561 deployment to decide and out of scope of this specification. 563 5.5. Generic Request-Response Parameters 565 5.5.1. Mobile Node Identifier 567 An identifier that identifies a MN. The Mobile Node Identifier is in 568 form of a Network Access Identifier (NAI) [RFC4282]. 570 mn-id = "mn-id" ":" nai CRLF 571 nai = username 572 | "@" realm 573 | username "@" realm 574 ... 576 5.5.2. Authentication Method 578 The HAC is the peer that mandates the authentication method. The MN 579 sends its authentication method proposal to the HAC. The HAC, upon 580 receipt of the MN proposal returns the selected authentication 581 method. The MN MUST propose at least one authentication method. The 582 HAC MUST select exactly one authentication method, or return an error 583 and then close the connection. 585 auth-method = "auth-method" ":" a-method *("," a-method) CRLF 586 a-method = 587 "psk" ; Pre-shared key based authentication 588 | "eap" ; EAP-based authentication 590 5.5.3. Extensible Authentication Protocol Payload 592 Each Extensible Authentication Protocol (EAP) [RFC3748] message is an 593 encoded string of hexadecimal numbers. The "eap-payload" is 594 completely transparent what EAP-method or EAP message is carried 595 inside it. The "eap-payload" can appear in both request and response 596 messages: 598 eap-payload = "eap-payload" ":" 1*(HEX HEX) CRLF 600 5.5.4. Status Code 602 The "status-code" MUST only be present in the response message that 603 ends the request-response message exchange. The "status-code" 604 follows the principles of HTTP and the definitions found in Section 605 10 of RFC 2616 also apply for these status codes listed below: 607 status-code = "status-code" ":" status-value CRLF 608 status-value = 609 "100" ; Continue 610 | "200" ; OK 611 | "400" ; Bad Request 612 | "401" ; Unauthorized 613 | "500" ; Internal Server Error 614 | "501" ; Not Implemented 615 | "503" ; Service Unavailable 616 | "504" ; Gateway Time-out 618 5.5.5. Message Authenticator 620 The "auth" header contains data used for authentication purposes. It 621 MUST be the last TV-header in the message and calculated over the 622 whole message till the start of the "msg-header": 624 msg-auth = "auth" ":" 1*(HEX HEX) CRLF 626 5.5.6. Retry After 628 retry-after = "retry-after" ":" rfc1123-date CRLF 630 5.5.7. End of Message Content 632 end-of-message = 2CRLF 634 5.5.8. Random Values 636 Random numbers generated by the MN and the HAC, respectively. The 637 length of the random number MUST be 32 octets (before TV-header 638 encoding): 640 mn-rand = "mn-rand" ":" 32(HEX HEX) CRLF 641 hac-rand = "hac-rand" ":" 32(HEX HEX) CRLF 643 5.6. Security Association Configuration Parameters 645 During the Mobile IPv6 bootstrapping, the MN and the HAC negotiate a 646 single ciphersuite for protecting the traffic between the MN and the 647 HA. The allowed ciphersuites for this specification are a subset of 648 those in TLS v1.2 (see Annex A.5 of [RFC5246]) as per Section 5.6.5. 649 This might appear as a constraint as the HA and the HAC may have 650 implemented different ciphersuites. These two nodes are, however, 651 assumed to belong to the same administrative domain. In order to 652 avoid exchanging supported MN-HA ciphersuites in the MN-HAC protocol 653 and to reuse the TLS ciphersuite negotiation procedure we make this 654 simplifying assumption. The selected ciphersuite MUST provide 655 integrity and confidentiality protection. 657 Section 5.6.5 provides the mapping from the TLS ciphersuites to the 658 integrity and encryption algorithms allowed for MN-HA protection. 659 This mapping mainly ignores the authentication algorithm part that is 660 not required within the context of this specification. For example, 661 [RFC5246] defines a number of AES based ciphersuites for TLS 662 including 'TLS_RSA_WITH_AES_128_CBC_SHA'. For this specification the 663 relevant part is 'AES_128_CBC_SHA'. 665 All the parameters described in the following sections apply only to 666 a request-response protocol response message to the MN. The MN has 667 no way affecting to the provisioning decision of the HAC. 669 5.6.1. Security Parameter Index 671 The 28-bit unsigned SPI number identifies the SA used between the MN 672 and the HA. The value 0 (zero) is reserved and MUST NOT be used. 673 Therefore, values ranging from 1 to 268435455 are valid. 675 The TV-header corresponding to the SPI number is: 677 mip6-spi = "mip6-spi" ":" 1*DIGIT CRLF 679 5.6.2. MN-HA Shared Keys 681 The MN-HA shared integrity (ikey) and encryption (ekey) keys are used 682 to protect the traffic between the MN and the HA. The length of 683 these keys depend on the selected ciphersuite. 685 The TV-headers that carry these two parameters are: 687 mip6-mn-to-ha-ikey = "mip6-mn-to-ha-ikey" ":" 1*(HEX HEX) CRLF 688 mip6-ha-to-mn-ikey = "mip6-ha-to-mn-ikey" ":" 1*(HEX HEX) CRLF 689 mip6-mn-to-ha-ekey = "mip6-mn-to-ha-ekey" ":" 1*(HEX HEX) CRLF 690 mip6-ha-to-mn-ekey = "mip6-ha-to-mn-ekey" ":" 1*(HEX HEX) CRLF 692 5.6.3. Security Association Validity Time 694 The end of the SA validity time is encoded using the "rfc1123-date" 695 format, as defined in Section 3.3.1 of [RFC2616]. 697 The TV-header corresponding to the SA validity time value is: 699 mip6-sa-validity-end = "mip6-sa-validity-end" ":" rfc1123-date 700 CRLF 702 5.6.4. Security association scope (SAS) 704 The SA is applied either to Mobile IPv6 signaling messages only, or 705 to both Mobile IPv6 signaling messages and data traffic. This policy 706 MUST be agreed between the MN and HA prior to using the SA. 707 Otherwise the receiving side would not be aware of whether the SA 708 applies to data traffic and could not decide how to act when 709 receiving unprotected packets of PType 1 (see Section 6.4). 711 mip6-sas = "mip6-sas" ":" 1DIGIT CRLF 713 where a value of "0" indicates that the SA does not protect data 714 traffic and a value of "1" indicates that all data traffic MUST be 715 protected by the SA. If the mip6-sas value of an SA is set to 1, any 716 packet received with a PType value that does not match the mip6-sas 717 value of the SA MUST be silently discarded. 719 The HAC is the peer that mandates the used security association 720 scope. The MN sends its proposal to the HAC but eventually the 721 security association scope returned from the HAC defines the used 722 scope. 724 5.6.5. CipherSuites and Ciphersuite-to-Algorithm Mapping 726 The ciphersuite negotiation between HAC and MN uses a subset of the 727 TLS 1.2 ciphersuites and follows the TLS 1.2 numeric representation 728 defined in Annex A.5 of [RFC5246]. The TV-headers corresponding to 729 the selected ciphersuite and ciphersuite list are: 731 mip6-ciphersuite = "mip6-ciphersuite" ":" csuite CRLF 732 csuite = "{" suite "}" 733 suite = 734 "00" "," "02" ; CipherSuite NULL_SHA = {0x00,0x02} 735 | "00" "," "3B" ; CipherSuite NULL_SHA256 = {0x00,0x3B} 736 | "00" "," "0A" ; CipherSuite 3DES_EDE_CBC_SHA = {0x00,0x0A} 737 | "00" "," "2F" ; CipherSuite AES_128_CBC_SHA = {0x00,0x2F} 738 | "00" "," "3C" ; CipherSuite AES_128_CBC_SHA256 = {0x00,0x3C} 739 mip6-suitelist = "mip6-suitelist" ":" csuite *("," csuite) CRLF 741 All other Ciphersuite values are reserved. 743 The following integrity algorithms MUST be supported by all 744 implementations: 746 HMAC-SHA1-96 [RFC2404] 747 AES-XCBC-MAC-96 [RFC3566] 749 The binding management messages between the MN and HA MUST be 750 integrity protected. Implementations MUST NOT use a NULL integrity 751 algorithm. 753 The following encryption algorithms MUST be supported: 755 NULL [RFC2410] 756 TripleDES-CBC [RFC2451] 757 AES-CBC with 128-bit keys [RFC3602] 759 Traffic between MN and HA MAY be encrypted. Any integrity-only 760 CipherSuite makes use of the NULL encryption algorithm. 762 Note: In the present version, this document does not consider 763 combined algorithms. The following table provides the mapping of 764 each ciphersuite to a combination of integrity and encryption 765 algorithms that are part of the negotiated SA between MN and HA. 767 +-------------------+-----------------+--------------------------+ 768 |Ciphersuite |Integ. Algorithm |Encr. Algorithm | 769 +-------------------+-----------------+--------------------------+ 770 |NULL_SHA |HMAC-SHA1-96 |NULL | 771 |NULL_SHA256 |AES-XCBC-MAC-96 |NULL | 772 |3DES_EDE_CBC_SHA |HMAC-SHA1-96 |TripleDES-CBC | 773 |AES_128_CBC_SHA |HMAC-SHA1-96 |AES-CBC with 128-bit keys | 774 |AES_128_CBC_SHA256 |AES-XCBC-MAC-96 |AES-CBC with 128-bit keys | 775 +-------------------+----------------+---------------------------+ 777 Ciphersuite-to-Algorithm Mapping 779 5.7. Mobile IPv6 Bootstrapping Parameters 781 In parallel with the SA bootstrapping, the HAC SHOULD provision the 782 MN with relevant Mobile IPv6 related bootstrapping information. 784 The following generic BNFs are used to form IP addresses and 785 prefixes. They are used in subsequent sections. 787 ip6-addr = 7( word ":" ) word CRLF 788 word = 1*4HEX 789 ip6-prefix = ip6-addr "/" 1*2DIGIT 790 ip4-addr = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT 791 ip4-subnet = ip4-addr "/" 1*2DIGIT 793 5.7.1. Home Agent Address 795 The HAC MAY provision the MN with an IPv4 or an IPv6 address of a HA, 796 or both. 798 mip6-haa-ip6 = "mip6-haa-ip6" ":" ip6-addr CRLF 799 mip6-haa-ip4 = "mip6-haa-ip4" ":" ip4-addr CRLF 801 5.7.2. Mobile IPv6 Service Port Number 803 The HAC SHOULD provision the MN with an UDP port number, where the HA 804 expects to receive UDP packets. If this parameter is not present, 805 then the IANA reserved port number (HALTSEC) MUST be used instead. 807 mip6-port = "mip6-port" ":" 1*5DIGIT CRLF 809 5.7.3. Home Addresses and Home Network Prefix 811 The HAC MAY provision the MN with an IPv4 or an IPv6 home address, or 812 both. The HAC MAY also provision the MN with its home network 813 prefix. 815 mip6-ip6-hoa = "mip6-ip6-hoa" ":" ip6-addr CRLF 816 mip6-ip4-hoa = "mip6-ip4-hoa" ":" ip4-addr CRLF 817 mip6-ip6-hnp = "mip6-ip6-hnp" ":" ip6-prefix CRLF 818 mip6-ip4-hnp = "mip6-ip4-hnp" ":" ip4-subnet CRLF 820 5.7.4. DNS Server 822 The HAC may also provide the MN with DNS server configuration 823 options. These DNS servers are reachable via the home agent. 825 dns-ip6 = "dns-ip6" ":" ip6-addr CRLF 826 dns-ip4 = "dns-ip4" ":" ip4-addr CRLF 828 5.8. Authentication of the Mobile Node 830 This section describes the basic operation required for the MN-HAC 831 mutual authentication and the channel binding. The authentication 832 protocol described as part of this section is a simple exchange that 833 follows the GPSK exchange used by EAP-GPSK [RFC5433]. It is secured 834 by the TLS tunnel and is cryptographically bound to the TLS tunnel 835 through channel binding based on [RFC5056] and on the channel binding 836 type 'tls-server-endpoint' described in [RFC5929]. As a result of 837 the channel binding type, this method can only be used with TLS 838 ciphersuites that use server certificates and the Certificate 839 handshake message. For example, TLS ciphersuites based on PSK or 840 anonymous authentication cannot be used. 842 The authentication exchange MUST be performed through the encrypted 843 TLS tunnel. It performs mutual authentication between the MN and the 844 HAC based on a pre-shared key (PSK) or based on an EAP-method (see 845 Section 5.9). The PSK protocol is described in this section. It 846 consists of the message exchanges (MHAuth-Init, MHAuth-Mid, MHAuth- 847 Done) in which both sides exchange nonces and their identities, and 848 compute and exchange a message authenticator 'auth' over the 849 previously exchanged values, keyed with the pre-shared key. The 850 MHAuth-Done messages are used to deal with error situations. Key 851 binding with the TLS tunnel is ensured by channel binding of the type 852 "tls-server-endpoint" as described by [RFC5929] where the hash of the 853 TLS server certificate serves as input to the 'auth' calculation of 854 the MHAuth messages. 856 Note: The authentication exchange is based on the GPSK exchange used 857 by EAP-GPSK. In comparison to GPSK, it does not support exchanging 858 an encrypted container (it always runs through an already protected 859 TLS tunnel). Furthermore, the initial request of the authentication 860 exchange (MHAuth-Init) is sent by the MN (client side) and is 861 comparable to EAP-Response/Identity, which reverses the roles of 862 request and response messages compared to EAP-GPSK. Figure 4 shows a 863 successful protocol exchange. 865 MN HAC 866 | | 867 | Request/MHAuth-Init (...) | 868 |------------------------------------------------------>| 869 | | 870 | Response/MHAuth-Init (...) | 871 |<------------------------------------------------------| 872 | | 873 | Request/MHAuth-Done (...) | 874 |------------------------------------------------------>| 875 | | 876 | Response/MHAuth-Done (...) | 877 |<------------------------------------------------------| 878 | | 880 Figure 4: Authentication of the Mobile Node Using Shared Secrets 882 1) Request/MHAuth-Init: (MN -> HAC) 883 mn-id, mn-rand, auth-method=psk 885 2) Response/MHAuth-Init: (MN <- HAC) 886 [mn-rand, hac-rand, auth-method=psk, [status],] auth 888 3) Request/MHAuth-Done: (MN -> HAC) 889 mn-rand, hac-rand, sa-scope, ciphersuite-list, auth 891 4) Response/MHAuth-Done: (MN <- HAC) 892 [sa-scope, sa-data, ciphersuite, bootstrapping-data,] mn-rand, 893 hac-rand, status, auth 895 Where: 897 auth = HMAC-SHA256(PSK, msg-octets | CB-octets) 899 The length "mn-rand", "hac-rand" is 32 octets. Note that "|" 900 indicates concatenation and optional parameters are shown in square 901 brackets [..]. The square brackets can be nested. 903 The shared secret PSK can be variable length. 'msg-octets' includes 904 all payload parameters of the respective message to be signed except 905 the 'auth' payload. CB-octets is the channel binding input to the 906 auth calculation that is the "TLS-server-endpoint" channel binding 907 type. The content and algorithm (only required for the "TLS-server- 908 endpoint" type) are the same as described in [RFC5929]. 910 The MN starts by selecting a random number 'mn-rand' and choosing a 911 list of supported authentication methods coded in 'auth-method'. The 912 MN sends its identity 'mn-id', 'mn-rand' and 'auth-method' to the HAC 913 in MHAuth-Init. The decision of which authentication method to offer 914 and which to pick is policy- and implementation-dependent and, 915 therefore, outside the scope of this document. 917 In MHAuth-Done, the HAC sends a random number 'hac-rand' and the 918 selected ciphersuite. The selection MUST be one of the MN-supported 919 ciphersuites as received in 'ciphersuite-list'. Furthermore, it 920 repeats the received parameters of the MHAuth-Init message 'mn-rand'. 921 It computes a message authenticator 'auth' over all the transmitted 922 parameters except 'auth' itself. The HAC calculates 'auth' over all 923 parameters and appends it to the message. 925 The MN verifies the received MAC and the consistency of the 926 identities, nonces, and ciphersuite parameters transmitted in MHAuth- 927 Auth. In case of successful verification, the MN computes a MAC over 928 the session parameter and returns it to the HAC in MHAuth-Done. The 929 HAC verifies the received MAC and the consistency of the identities, 930 nonces, and ciphersuite parameters transmitted in MHAuth-Init. If 931 the verification is successful, MHAuth-Done is prepared and sent by 932 the HAC to confirm successful completion of the exchange. 934 5.9. Extensible Authentication Protocol Methods 936 Basic operation required for the MN-HAC mutual authentication using 937 EAP-based methods. 939 MN HAC 940 | | 941 | Request/MHAuth-Init (...) | 942 |------------------------------------------------------>| 943 | | 944 | Response/MHAuth-Init (..., | 945 | eap-payload=EAP-Request/Identity) | 946 |<------------------------------------------------------| 947 | | 948 | Request/MHAuth-Mid (eap-payload= | 949 | EAP-Response/Identity) | 950 |------------------------------------------------------>| 951 | | 952 | Response/MHAuth-Mid (eap-payload=EAP-Request/...) | 953 |<------------------------------------------------------| 954 | | 955 : : 956 : ..EAP-method specific exchanges.. : 957 : : 958 | | 959 | Request/MHAuth-Done (eap-payload=EAP-Response/..., | 960 | ..., auth) | 961 |------------------------------------------------------>| 962 | | 963 | Response/MHAuth-Done (eap-payload=EAP-Success, | 964 | ..., auth) | 965 |<------------------------------------------------------| 966 | | 968 Figure 5: Authentication of the Mobile Node Using EAP 970 1) Request/MHAuth-Init: (MN -> HAC) 971 mn-id, mn-rand, auth-method=eap 973 2) Response/MHAuth-Init: (MN <- HAC) 974 [auth-method=eap, eap, [status,]] auth 976 3) Request/MHAuth-Mid: (MN -> HAC) 977 eap, auth 979 4) Response/MHAuth-Mid: (MN <- HAC) 980 eap, auth 982 MHAuth-Mid exchange is repeated as many times as needed by the 983 used EAP-method. 985 5) Request/MHAuth-Done: (MN -> HAC) 986 sa-scope, ciphersuite-list, eap, auth 988 6) Response/MHAuth-Done: (MN <- HAC) 989 [sa-scope, sa-data, ciphersuite, bootstrapping-data,] eap, 990 status, auth 992 Where: 994 auth = HMAC-SHA256(shared-key, msg-octets | CB-octets) 996 In MHAuth-Init and MHAuth-Mid messages, shared-key is set to "1". If 997 the EAP-method is key-deriving and creates a shared MSK key as a side 998 effect of Authentication shared-key MUST be the MSK in all MHAuth- 999 Done messages. This MSK MUST NOT be used for any other purpose. In 1000 case the EAP method does not generate an MSK key, shared-key is set 1001 to "1". 1003 'msg-octets' includes all payload parameters of the respective 1004 message to be signed except the 'auth' payload. CB-octets is the 1005 channel binding input to the AUTH calculation that is the "TLS- 1006 server-endpoint" channel binding type. The content and algorithm 1007 (only required for the "TLS-server-endpoint" type) are the same as 1008 described in [RFC5929]. 1010 6. Mobile Node to Home Agent communication 1012 6.1. General 1014 The following sections describe the packet formats used for the 1015 traffic between the MN and the HA. This traffic includes binding 1016 management messages (for example, BU and BA messages), reverse 1017 tunneled and encrypted user data, and reverse tunneled plain text 1018 user data. This specification defines a generic packet format, where 1019 everything is encapsulated inside UDP. See Section 6.3 and 1020 Section 6.4 for detailed illustrations of the corresponding packet 1021 formats. 1023 The Mobile IPv6 service port number is where the HA expects to 1024 receive UDP packets. The same port number is used for both binding 1025 management messages and user data packets. The reason for 1026 multiplexing data and control messages over the same port number is 1027 due to the possibility of Network Address and Port Translators 1028 located along the path between the MN and the HA. The Mobile IPv6 1029 service MAY use any ephemeral port number as the UDP source port, and 1030 MUST use the Mobile IPv6 service port number as the UDP destination 1031 port. The Mobile IPv6 service port is either dynamically assigned to 1032 the MN during the bootstrapping phase (i.e. the mip6-port parameter) 1033 or in absence of the bootstrapping parameter the IANA reserved port 1034 (HALTSEC) MUST be used. 1036 The encapsulating UDP header is immediately followed by a 4-bit 1037 Packet Type (PType) field that defines whether the packet contains an 1038 encrypted mobility management message or a, an encrypted user data 1039 packet, or a plain text user data packet. 1041 The Packet Type field is followed by a 28-bit SPI value, which 1042 identifies the correct SA concerning the encrypted packet. For any 1043 packet that is neither integrity protected nor encrypted (i.e. no SA 1044 is applied by the originator) the SPI MUST be set to 0 (zero). 1045 Mobility management messages MUST always be at least integrity 1046 protected. Hence, mobility management messages MUST NOT be sent with 1047 a SPI value of 0 (zero). 1049 There is always only one SPI per MN-HA mobility session and the same 1050 SPI is used for all types of protected packets independent of the 1051 direction. 1053 The SPI value is followed by a 32-bit Sequence Number value that is 1054 used to identify retransmissions of encrypted messages. Each 1055 endpoint in the security association maintains two "current" Sequence 1056 Numbers: the next one to be used for a packet it initiates and the 1057 next one it expects to see in a packet from the other end. If the MN 1058 and the HA ends initiate very different numbers of messages, the 1059 Sequence Numbers in the two directions can be very different. In a 1060 case encryption is not used, the Sequence Number MUST be set to 0 1061 (zero). Note that the HA SHOULD initiate a re-establishement of the 1062 SA before any of the Sequence Number cycle. 1064 Finally, the Sequence Number field is followed by the data portion, 1065 whose content is identified by the Packet Type. The data portion may 1066 be protected. 1068 6.2. PType and Security Parameter Index 1070 The PType is a 4-bit field that indicates the Packet Type (PType) of 1071 the UDP encapsulated packet. The PType is followed by a a 28-bit SPI 1072 value. The PType and the SPI fields are treated as one 32-bit field 1073 during the integrity protection calculation. 1075 0 1 2 3 1076 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 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | PType | SPI | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 Figure 6: Security Parameter Index with Packet Type 1083 A SPI value of 0 (zero) indicates a plaintext packet. If the packet 1084 is integrity protected or both integrity protected and encrypted, the 1085 SPI value MUST be different from 0. When the SPI value is set to 0, 1086 then the PType MUST also be 0. 1088 6.3. Binding Management Message Formats 1090 The binding management messages that are only meant to be exchanged 1091 between the MN and the HA MUST be integrity protected and MAY be 1092 encrypted. They MUST use the packet format shown in Figure 7. All 1093 packets that are specific to the Mobile IPv6 protocol and contain a 1094 Mobility Header (as defined in Section 6.1.1. of RFC 6275) SHOULD use 1095 the packet format shown in Figure 7. (This means that some Mobile 1096 IPv6 mobility management messages, such as the HoTI message, as 1097 treated as data packets and using encapsulation described in 1098 Section 6.4). 1100 0 1 2 3 1101 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 1102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | | 1104 : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : 1105 | | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | | 1108 : UDP header (src-port=Xp,dst-port=Yp) : 1109 | | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 1111 |PType=8| SPI | ^Int. 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 1113 | Sequence Number | |ered 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- 1115 | Payload Data* (variable) | | ^ 1116 : : | | 1117 | | |Conf. 1118 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 1119 | | Padding (0-255 bytes) | |ered* 1120 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 1121 | | Pad Length | Next Header | v v 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 1123 | Integrity Check Value-ICV (variable) | 1124 : : 1125 | | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 Figure 7: UDP Encapsulated Binding Management Message Format 1130 The PType value 8 (eight) identifies that the UDP encapsulated packet 1131 contains a RFC 6275 defined Mobility Header and other relevant IPv6 1132 extension headers. Note, there is no additional IP header inside the 1133 encapsulated part. The Next Header field MUST be set to value of the 1134 first encapsulated header. The encapsulated headers follow the 1135 natural IPv6 and Mobile IPv6 extension header alignment and 1136 formatting rules. 1138 The Padding, Pad Length, Next Header and ICV fields follow the rules 1139 of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this 1140 document. For a SPI value of 0 (zero) that indicates an unprotected 1141 packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT 1142 be present. 1144 The source and destination IP addresses of the outer IP header (i.e. 1145 the src-addr and the dst-addr in Figure 7) use the current care-of 1146 address of the MN and the HA address. 1148 6.4. Reverse Tunneled User Data Packet Formats 1150 There are two types of reverse tunneled user data packets between the 1151 MN and the HA. Those that are integrity protected and encrypted and 1152 those that are plaintext. The MN or the HA decide whether to apply 1153 integrity protection and encryption to a packet or to send it in 1154 plaintext based on the mip6-sas value in the SA. If the mip6-sas is 1155 set to 1 the originator MUST NOT send any plaintext packet, and the 1156 receiver MUST silently discard any packet with the PType set to 0 1157 (unprotected). It is RECOMMENDED to apply confidentiality and 1158 integrity protection of user data traffic. The reverse tunneled IPv4 1159 or IPv6 user data packets are encapsulated as-is inside the 'Payload 1160 Data' shown in Figure 8. and Figure 9. 1162 0 1 2 3 1163 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 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | | 1166 : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : 1167 | | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | | 1170 : UDP header (src-port=Xp,dst-port=Yp) : 1171 | | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 |PType=1| SPI | ^Int. 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 1175 | Sequence Number | |ered 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- 1177 | Payload Data* (variable) | | ^ 1178 : : | | 1179 | | |Conf. 1180 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- 1181 | | Padding (0-255 bytes) | |ered* 1182 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 1183 | | Pad Length | Next Header | v v 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ 1185 | Integrity Check Value-ICV (variable) | 1186 : : 1187 | | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 Figure 8: UDP Encapsulated Protected User Data Packet Format 1192 The PType value 1 (one) identifies that the UDP encapsulated packet 1193 contains an encrypted tunneled IPv4/IPv6 user data packet. The Next 1194 Header field header MUST be set to value corresponding the tunneled 1195 IP packet (e.g., 41 for IPv6). 1197 The Padding, Pad Length, Next Header and ICV fields follow the rules 1198 of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this 1199 document. For a SPI value of 0 (zero) that indicates an unprotected 1200 packet, the Padding, Pad Length, Next Header and ICV fields MUST NOT 1201 be present. 1203 The source and destination IP addresses of the outer IP header (i.e., 1204 the src-addr and the dst-addr in Figure 8) use the current care-of 1205 address of the MN and the HA address. The ESP protected inner IP 1206 header, which is not shown in Figure 8, uses the home address of the 1207 MN and the correspondent node (CN) address. 1209 0 1 2 3 1210 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 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | | 1213 : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : 1214 | | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | | 1217 : UDP header (src-port=Xp,dst-port=Yp) : 1218 | | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 |PType=0| 0 | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | 0 | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | | 1225 : Payload Data (plain IPv4 or IPv6 Packet) : 1226 | | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 Figure 9: UDP Encapsulated Non-Protected User Data Packet Format 1231 The PType value 0 (zero) identifies that the UDP encapsulated packet 1232 contains a plaintext tunneled IPv4/IPv6 user data packet. Also the 1233 SPI and the Sequence Number fields MUST be set to 0 (zero). 1235 The source and destination IP addresses of the outer IP header (i.e., 1236 the src-addr and the dst-addr in Figure 9) use the current care-of 1237 address of the MN and the HA address. The plain text inner IP header 1238 uses the home address of the MN and the CN address. 1240 7. Route Optimization 1242 The MN-CN route optimization protocol functionality, related messages 1243 and mobility options are out of scope of this specification. A 1244 future specification may add route optimization functionality to the 1245 Transport Layer Security-based Mobile IPv6 protocol. 1247 We discuss few possible route optimization approaches in the 1248 following sections. The route optimization could be done in two 1249 ways: 1) using the return routability procedure described in 1250 [RFC6275] or 2) directly between the MN and the CN i.e. enhancing the 1251 route optimization also for Home Agent-less operation. 1253 Both discussed solution approaches share the same tunneling 1254 considerations between the MN and the CN. When the MN sends UDP 1255 encapsulated packets to the CN, those are destined to CN's CoA. That 1256 implies, the inner tunneled packets would also have the same 1257 destination address as the outer tunneling packets. There should not 1258 be issues regarding the decapsulation and encapsulation as long as 1259 the inner tunneled packet does not have UDP payload with the same 1260 destination port that the CN uses for its MN-CN UDP tunnel. 1262 7.1. Replicating RFC6275 Route Optimization 1264 Obviously [RFC6275] approach has already been verified from the 1265 security considerations and procedures point of view. The existing 1266 protocol proves both the Home Address ownership and verifies the 1267 reachability. However, there are several gaps in scope of this 1268 specification (TLS-based solution). For instance, the binding 1269 management message encapsulation between the MN and the CN must be 1270 specified and how to reach a CN using an IPv4 address. Following the 1271 trend in this specification that would use UDP encapsulated IPv6 and 1272 mobility headers as in Section 6.3. Another gap is the lack of SA 1273 between the MN and the CN, if the communication were to be protected. 1274 In order to enable the protection the CN should actually implement a 1275 HAC function, which would then allow the MN and the CN to negotiate 1276 required ciphersuites. 1278 7.2. Enhanced Route Optimization with Home Agent-less Operation 1280 If the CN were to implement a HAC, then the HAC could also 1281 authenticate the MN. Possible authentication methods include pre- 1282 shared secrets, certificates or using EAP+AAA against MN's home realm 1283 AAA server (assuming the AAA infrastructure is in place). That 1284 approach could actually allow the MN and the CN to setup secured 1285 communication without doing the return routability test and support 1286 Home Agent-less operation of MNs. However, the prerequisite is that 1287 the MN has at some point of time bootstrapped with its HA e.g. to 1288 acquire the HoA. 1290 The "bootstrapping" between the MN and the "CN HAC" would concern a 1291 subset of parameter needed between the MN and the "HA HAC". For 1292 example, there is no need to negotiate Home Addresses and such. The 1293 main use would be establishing the SA and authenticating at least the 1294 MN to the CN. 1296 8. IANA Considerations 1298 8.1. New Registry: Packet Type 1300 IANA is requested to create a new registry for the Packet Type as 1301 described in Section 6.1. 1303 Packet Type | Value 1304 ----------------------------------+---------------------------------- 1305 non-encrypted IP packet | 0 1306 encrypted IP packet | 1 1307 mobility header | 8 1309 Following the allocation policies from [RFC5226] new values for the 1310 Packet Type AVP MUST be assigned based on the "RFC Required" policy. 1312 8.2. Status Codes 1314 A new Status Code (to be used in BA messages) is reserved for the 1315 cases where the HA wants to indicate to the MN that it needs to re- 1316 establish the SA information with the HAC. The Result Code is 1317 reserved from the 0-127 code space: 1319 REINIT_SA_WITH_HAC TBD1 1321 8.3. Port Numbers 1323 A new port number (HALTSEC) for UDP packets is reserved from the PORT 1324 NUMBERS registry. 1326 HALTSEC TBD2 1328 9. Security Considerations 1330 This document describes and uses a number of building blocks that 1331 introduce security mechanisms and need to inter-work in a secure 1332 manner. 1334 The following building blocks are considered from a security point of 1335 view: 1337 1. Discovery of the HAC 1338 2. Authentication and MN-HA SA establishment executed between the MN 1339 and the HAC (PSK or EAP-based) through a TLS tunnel 1340 3. Protection of MN-HA communication 1341 4. AAA Interworking 1343 9.1. Discovery of the HAC 1345 No dynamic procedure for discovering the HAC by the MN is described 1346 in this document. As such, no specific security considerations apply 1347 to the scope of this document. 1349 9.2. Authentication and Key Exchange executed between the MN and the 1350 HAC 1352 This document describes a simple authentication and MN-HA SA 1353 negotiation exchange over TLS. The TLS procedures remain unchanged; 1354 however, channel binding is provided. 1356 Authentication: Server-side certificate based authentication MUST be 1357 performed using TLS 1.2 [RFC5246]. 1359 The client-side authentication may depend on the specific 1360 deployment and is therefore not mandated. Note that TLS-PSK 1361 [RFC4279] cannot be used in conjunction with the methods described 1362 in section 5.8 and 5.9 of this document due to the limitations of 1363 the channel binding type used. 1365 Through the protected TLS tunnel, an additional authentication 1366 exchange is performed that provides client-side or mutual 1367 authentication and exchanges SA parameters and optional 1368 configuration data to be used in the subsequent protection of 1369 MN-HA communication. The additional authentication exchange can 1370 either be PSK-based (section 5.8) or EAP-based (section 5.9). 1371 Both exchanges are always performed within the protected TLS 1372 tunnel and MUST NOT be used as standalone protocols. 1374 The simple PSK-based authentication exchange provides mutual 1375 authentication and follows the GPSK exchange used by EAP-GPSK 1376 [RFC5433] and has similar properties, although some features of 1377 GPSK like the exchange of a protected container are not supported. 1379 The EAP-based authentication exchange simply defines message 1380 containers to allow carrying the EAP packets between the MN and 1381 the HAC. In principle, any EAP method can be used. However, it 1382 is strongly recommended to use only EAP methods that provide 1383 mutual authentication and that derive keys including an MSK key in 1384 compliance with [RFC3748]. 1386 Both exchanges use channel binding with the TLS tunnel. The 1387 channel binding type 'TLS-server-endpoint' as per [RFC5929] MUST 1388 be used. 1390 Dictionary Attacks: All messages of the authentication exchanges 1391 specified in this document are protected by TLS. However, any 1392 implementation SHOULD assume that the properties of the 1393 authentication exchange are the same as for GPSK [RFC5433] in case 1394 the PSK-based method as per section 5.8. is used, and are the same 1395 as those of the underlying EAP method in case the EAP-based 1396 exchange as per section 5.9 is used. 1398 Replay Protection: The underlying TLS protection provides protection 1399 against replays. 1401 Key Derivation and Key Strength: For TLS, the TLS specific 1402 considerations apply unchanged. For the authentication exchanges 1403 defined in this document, no key derivation step is performed as 1404 the MN-HA keys are generated by the HAC and are distributed to the 1405 MN through the secure TLS connection. 1407 Key Control: No joint key control for MN-HA keys is provided by this 1408 version of the specification. 1410 Lifetime: The TLS-protected authentication exchange between the MN 1411 and the HAC is only to bootstrap keys and other parameters for 1412 usage with MN-HA security. The SAs that contain the keys have an 1413 associated lifetime. The usage of Transport Layer Security (TLS) 1414 Session Resumption without Server-Side State, described in 1415 [RFC5077], provides the ability for the MN to minimize the latency 1416 of future exchanges towards the HA without having to keep state at 1417 the HA itself. 1419 Denial of Service Resistance: The level of resistance against denial 1420 of service attacks SHOULD be considered the same as for common TLS 1421 operation, as TLS is used unchanged. For the PSK-based 1422 authentication exchange, no additional factors are known. For the 1423 EAP-based authentication exchange, any considerations regarding 1424 denial-of-service resistance specific to the chosen EAP method are 1425 expected to be applicable and need to be be taken into account. 1427 Session Independence: Each individual TLS protocol run is 1428 independent from any previous exchange based on the security 1429 properties of the TLS handshake protocol. However, several PSK or 1430 EAP-based authentication exchanges can be performed across the 1431 same TLS connection. 1433 Fragmentation: TLS runs on top of TCP and no fragmentation specific 1434 considerations apply to the MN-HAC authentication exchanges. 1436 Channel Binding: Both the PSK and the EAP-based exchanges use 1437 channel binding with the TLS tunnel. The channel binding type 1438 'TLS-server-endpoint' as per [RFC5929] MUST be used. 1440 Fast Reconnect: This protocol provides session resumption as part of 1441 TLS and optionally the support for [RFC5077]. No fast reconnect 1442 is supported for the PSK-based authentication exchange. For the 1443 EAP-based authentication exchange, availability of fast reconnect 1444 depends on the EAP method used. 1446 Identity Protection: Based on the security properties of the TLS 1447 tunnel, passive user identity protection is provided. An attacker 1448 acting as man-in-the-middle in the TLS connection would be able to 1449 observe the MN identity value sent in MHAuth-Init messages. 1451 Protected Ciphersuite Negotiation: This protocol provides 1452 ciphersuite negotiation based on TLS. 1454 Confidentiality: Confidentiality protection of payloads exchanged 1455 between the MN and the HAC are protected with the TLS Record 1456 Layer. TLS ciphersuites with confidentiality and integrity 1457 protection MUST be negotiated and used in order to exchange 1458 security sensitive material inside the TLS connection. 1460 Cryptographic Binding: No cryptographic bindings are provided by 1461 this protocol specified in this document. 1463 Perfect Forward Secrecy: Perfect forward secrecy is provided with 1464 appropriate TLS ciphersuites. 1466 Key confirmation: Key confirmation of the keys established with TLS 1467 is provided by the TLS Record Layer when the keys are used to 1468 protect the subsequent TLS exchange. 1470 9.3. Protection of MN and HA Communication 1472 Authentication: Data origin authentication is provided for the 1473 communication between the MN and the HA. The chosen level of 1474 security of this authentication depends on the selected 1475 ciphersuite. Entity authentication is offered by the MN to HAC 1476 protocol exchange. 1478 Dictionary Attacks: The concept of dictionary attacks is not 1479 applicable to the MN-HA communication as the keying material used 1480 for this communication is randomly created by the HAC and its 1481 length depends on the chosen cryptographic algorithms. 1483 Replay Protection: Replay protection for the communication between 1484 the MN and the HA is provided based on sequence numbers and 1485 follows the design of IPsec ESP. 1487 Key Derivation and Key Strength: The strength of the keying material 1488 established for the communication between the MN and the HA is 1489 selected based on the negotiated ciphersuite (based on the MN-HAC 1490 exchange) and the key created by the HAC. The randomness 1491 requirements for security described in RFC 4086 [RFC4086] are 1492 applicable to the key generation by the HAC. 1494 Key Control: The keying material established during the MN-HAC 1495 protocol exchange for subsequent protection of the MN-HA 1496 communication is created by the HA and therefore no joint key 1497 control is provided for it. 1499 Key Naming: For the MN-HA communication the security associations 1500 are indexed with the help of the SPI and additionally based on the 1501 direction (in-bound communication or out-bound communication). 1503 Lifetime: The lifetime of the MN-HA security associations is based 1504 on the value in the mip6-sa-validity-end header field exchanged 1505 during the MN-HAC exchange. The HAC controls the SA lifetime. 1507 Denial of Service Resistance: For the communication between the MN 1508 and the HA there are no heavy cryptographic operations (such as 1509 public key computations). As such, there are no DoS concerns. 1511 Session Independence: Sessions are independent from each other when 1512 new keys are created by via the MN-HAC protocol. A new MN-HAC 1513 protocol run produces fresh and unique keying material for 1514 protection of the MN-HA communication. 1516 Fragmentation: There is no additional fragmentation support provided 1517 beyond what is offered by the network layer. 1519 Channel Binding: Channel binding is not applicable to the MN-HA 1520 communication. 1522 Fast Reconnect: The concept of fast reconnect is not applicable to 1523 the MN-HA communication. 1525 Identity Protection: User identities SHOULD NOT be exchanged between 1526 the MN and the HA. In a case binding management messages contain 1527 the user identity, the messages SHOULD be confidentity protected. 1529 Protected Ciphersuite Negotiation: The MN-HAC protocol provides 1530 protected ciphersuite negotiation through a secure TLS connection. 1532 Confidentiality: Confidentiality protection of payloads exchanged 1533 between the MN and the HAC (for Mobile IPv6 signaling and 1534 optionally for the data traffic) is provided utilizing algorithms 1535 negotiated during the MN-HAC exchange. 1537 Cryptographic Binding: No cryptographic bindings are provided by 1538 this protocol specified in this document. 1540 Perfect Forward Secrecy: Perfect forward secrecy is provided when 1541 the MN bootstraps new keying material with the help of the MN-HAC 1542 protocol (assuming that a proper TLS ciphersuite is used). 1544 Key confirmation: Key confirmation of the MN-HA keying material 1545 conveyed from the HAC to the MN is provided when the first packets 1546 are exchanged between the MN and the HA (in both directions as two 1547 different keys are used). 1549 9.4. AAA Interworking 1551 The AAA backend infrastructure interworking is not defined in this 1552 document and therefore out-of-scope. 1554 10. Acknowledgements 1556 The authors would like to thank Pasi Eronen, Domagoj Premec, Julien 1557 Laganier and Christian Bauer for their comments. 1559 11. References 1561 11.1. Normative References 1563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1564 Requirement Levels", BCP 14, RFC 2119, March 1997. 1566 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within 1567 ESP and AH", RFC 2404, November 1998. 1569 [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and 1570 Its Use With IPsec", RFC 2410, November 1998. 1572 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 1573 Algorithms", RFC 2451, November 1998. 1575 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1576 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1577 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1579 [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm 1580 and Its Use With IPsec", RFC 3566, September 2003. 1582 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 1583 Algorithm and Its Use with IPsec", RFC 3602, 1584 September 2003. 1586 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1587 Network Access Identifier", RFC 4282, December 2005. 1589 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1590 Channels", RFC 5056, November 2007. 1592 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1593 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1594 May 2008. 1596 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1597 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1599 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1600 for TLS", RFC 5929, July 2010. 1602 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1603 in IPv6", RFC 6275, July 2011. 1605 11.2. Informative References 1607 [I-D.patil-mext-mip6issueswithipsec] 1608 Patil, B., Perkins, C., Tschofenig, H., and D. Premec, 1609 "Problems with the use of IPsec as the security protocol 1610 for Mobile IPv6", draft-patil-mext-mip6issueswithipsec-04 1611 (work in progress), October 2011. 1613 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1614 August 1980. 1616 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1618 Levkowetz, "Extensible Authentication Protocol (EAP)", 1619 RFC 3748, June 2004. 1621 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1622 Protect Mobile IPv6 Signaling Between Mobile Nodes and 1623 Home Agents", RFC 3776, June 2004. 1625 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1626 Requirements for Security", BCP 106, RFC 4086, June 2005. 1628 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 1629 for Transport Layer Security (TLS)", RFC 4279, 1630 December 2005. 1632 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1633 Internet Protocol", RFC 4301, December 2005. 1635 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1636 RFC 4303, December 2005. 1638 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1639 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1640 April 2007. 1642 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 1643 "Transport Layer Security (TLS) Session Resumption without 1644 Server-Side State", RFC 5077, January 2008. 1646 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 1647 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 1648 RFC 5433, February 2009. 1650 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 1651 Routers", RFC 5555, June 2009. 1653 [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", 1654 RFC 5944, November 2010. 1656 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1657 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1658 RFC 5996, September 2010. 1660 Authors' Addresses 1662 Jouni Korhonen (editor) 1663 Nokia Siemens Networks 1664 Linnoitustie 6 1665 Espoo FIN-02600 1666 Finland 1668 Email: jouni.nospam@gmail.com 1670 Basavaraj Patil 1671 Nokia 1672 6021 Connection Drive 1673 Irving, TX 75039 1674 USA 1676 Email: basavaraj.patil@nokia.com 1678 Hannes Tschofenig 1679 Nokia Siemens Networks 1680 Linnoitustie 6 1681 Espoo 02600 1682 Finland 1684 Phone: +358 (50) 4871445 1685 Email: Hannes.Tschofenig@gmx.net 1687 Dirk Kroeselberg 1688 Siemens 1690 Email: dirk.kroeselberg@siemens.com