idnits 2.17.1 draft-barrett-mobile-dtls-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 4, 2009) is 5533 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Layer Security M. Williams 3 Internet-Draft J. Barrett 4 Intended status: Standards Track Nokia 5 Expires: September 5, 2009 March 4, 2009 7 Mobile DTLS 8 draft-barrett-mobile-dtls-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 5, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Mobile DTLS (Mobi-D) is an extension to DTLS that provides host 47 mobility support. After obtaining a new IP address or port, a DTLS 48 client mobile host can continue sending to its DTLS server 49 correspondent host. The mobile host continues to use the existing 50 set of security parameters, from the new address, without re- 51 negotiation. The correspondent host accepts packets from the new IP 52 address or port, also without re-negotiation. After receiving any 53 valid DTLS packet from the mobile host's new address or port, the 54 correspondent host uses the new address or port to send to the mobile 55 host. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.1. Mobility Extension . . . . . . . . . . . . . . . . . . . . 4 63 2.2. OP Extension . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.3. New Message . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Usage Model . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. System Diagram . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. Example Flow . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Usage: Single Interface Host . . . . . . . . . . . . . . . 7 69 3.4. Usage: Multi-Interface Host . . . . . . . . . . . . . . . 7 70 4. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.2. Record Layer . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.3. Message . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 5.1. Cryptography . . . . . . . . . . . . . . . . . . . . . . . 11 76 5.2. Connection ID . . . . . . . . . . . . . . . . . . . . . . 11 77 5.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 11 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 80 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 81 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 Mobility service for hosts is available at the network layer from 87 Mobile IP and from Proxy Mobile IP. For cases when neither of those 88 mobility solutions are available, Mobi-D provides alternative 89 mobility, at the transport layer. 91 Applications are now carrying audio and video over UDP for the 92 benefits of low latency, help with NAT traversal, and where 93 reliability has to be done at a higher layer. These applications are 94 also being adapted for mobile devices, including multi-access devices 95 such as those with both wired and wireless interfaces, or those with 96 a wireless local area interface and a wireless wide area interface. 98 Mobi-D extends DTLS [RFC4347] to provide host based mobility for the 99 secure transport provided by DTLS. Mobi-D adds a connection 100 identifier (ID) to the DTLS record layer. The connection ID is used 101 for efficient indexing of the security parameters of a DTLS flow 102 between the hosts. By associating packets to a flow based on 103 security parameters instead of IP address and port, the connection 104 can be maintained across change of the IP address, port, or change of 105 interface. 107 A basic principle of Mobi-D is that no special messages are required 108 to inform the correspondent host of a mobile host's move. Receipt of 109 a fully valid Mobi-D record from the new address and port is 110 sufficient. The mobile host can move without any re-negotation, and 111 the other end can react immediately upon receipt of the first packet 112 from the new address/port. An additional benefit is that 113 applications on the mobile host can choose to ignore whether or not 114 they are moving, and just make the assumption that the operating 115 system has some address. 117 In whichever cases DTLS might be useful for securing UDP traffic, 118 Mobi-D extends those cases to support mobile hosts and multi access 119 hosts. 121 The terms "client" and "server" are used as in DTLS. In this 122 document a mobile host may have the role of DTLS client or server, 123 but will typically take the client role. In other words, mobility 124 support is not limited to client roles, either role may be mobile. 126 1.1. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [RFC2119]. 132 2. Overview 134 Mobi-D extends DTLS in four ways: 136 1. A new DTLS Hello extension (Mobility) 138 2. A new TLS Hello extension (OP) 140 3. An additional field in the Record Layer (connection_id) 142 4. A new type of message (OP) 144 2.1. Mobility Extension 146 The Mobility extension allows a client and server to negotiate and 147 establish mobility support for a DTLS connection. 149 The client allocates a unique connection_id associated with each DTLS 150 handshake. For each full DTLS handshake, the client includes the 151 connection_id in the Mobility extension, for use by the server when 152 sending to this client. Likewise, the server allocates a unique 153 connection_id and responds with a Mobility extension in ServerHello, 154 including the connection_id for use by the client. 156 If the server includes the Mobility extension in its ServerHello, the 157 client MUST include the server's connection_id in the very next 158 record sent in the session, and all subsequent records. Likewise, 159 the server MUST include the client's connection_id in the very next 160 record sent in the session, and all subsequent records. 162 The Mobility extension includes a MobilityType value, which allows 163 the server to declare that its address is fixed. If the server sends 164 MobilityType fixed, then the client MUST NOT adjust its idea of the 165 server's IP or port, even if a datagram is received from a different 166 IP or port. This allows us to prevent the DoS attack described in 167 the Security Considerations (Section 5) in one direction. 169 Clients which include the Mobility extension SHOULD include the OP 170 extension as well, to allow OP messages to be used in the connection. 171 Likewise, a server including Mobility SHOULD include OP as well, if 172 the client did so. 174 Because TLS is inherently bound to a single host/port quartet, this 175 extension MUST only be used with DTLS, and not with TLS. Any TLS 176 server which receives this extension MUST ignore it. 178 2.2. OP Extension 180 The OP extension allows a client and server to negotiate and 181 establish support for the OP message. The client MAY include the OP 182 extension in its ClientHello. The extension contains a list of 183 OpTypes supported by the client. The server MAY respond with the OP 184 extension in its ServerHello, containing the list of OpTypes to be 185 supported in the connection. The server's list is the intersection 186 of the set of OpTypes supported by the server with the list provided 187 by the client. If the intersection is nil, the server MUST NOT 188 include the OP extension in its ServerHello. 190 2.3. New Message 192 Mobi-D specifies a new type of TLS message to be used for intra- 193 protocol communication. The OP message consists of an OpType and 194 opaque op_data and is encrypted and compressed as per the current 195 connection state (like any other message). The OP message gets a new 196 content type (managed by IANA, see Section 6). 198 The OP message is extensible to allow for future use. Mobi-D 199 specifies one OpType, NOP (no-op), which is just an empty message. 200 OP messages MUST be consumed by the receiving DTLS implementation, 201 they are not delivered to the application. 203 If Mobility has been negotiated for the flow, the recipient of a NOP 204 message MUST use the message's source address and port as the 205 destination address and port for all new messages back to the sender. 206 The NOP message is then discarded. 208 3. Usage Model 210 3.1. System Diagram 212 TODO: this diagram needs explanation. 214 ---------------- ------------------------- 215 |Mobi-D client |SP(cidS)------->|Mobi-D server | 216 | mobile host |<-------SP(cidC)| fixed or mobile server| 217 ---------------- | correspondent host | 218 ------------------------- 220 The Mobi-D communication is between the DTLS client and server. The 221 server allocates a connection ID (cidS) for use by the client. The 222 client sends that ID in all records it sends to that server. The 223 server receives a record with the connection ID it allocated, and 224 uses that to look up the security parameters (SP) for the DTLS flow 225 from the client, to authenticate and decrypt the record. 227 The client also allocates a connection ID (cidC) for use by the 228 server. The server sends that ID in all records it sends to that 229 client. The client receives a record with the connection ID it 230 allocated, and uses that to look up the security parameters (SP) for 231 the DTLS flow from the server, to authenticate and decrypt the 232 record. 234 The terms server and client are used as in DTLS. However, the server 235 and client may both be mobile devices. Note that the flows are not 236 bound to or dependent on particular interfaces of the hosts. 238 3.2. Example Flow 240 In this example, the client changes IP address and the server 241 immediately begins sending traffic to the new address. For the sake 242 of simplicity, the "src" and "sport" examples given here are the 243 values seen by the server. Quite possibly the client is behind a NAT 244 and has a different address on its own interface. 246 Client Server 247 ------ ------ 248 Data ------> 249 (cid=100) 250 (src=208.16.24.2) 251 (sport=6723) 253 <----- Data 254 (cid=200) 255 (dst=208.16.24.2) 256 (dport=6723) 258 Data ------> 259 (cid=100) 260 (src=208.69.36.132) 261 (sport=8901) 263 <----- Data 264 (cid=200) 265 (dst=208.69.36.132) 266 (dport=8901) 268 <----- Data 269 (cid=200) 270 (dst=208.69.36.132) 271 (dport=8901) 273 3.3. Usage: Single Interface Host 275 For a single-interface mobile host (MH), when the host moves to a new 276 network and is assigned a new IP address, the MH can continue the 277 secure communication by using the new IP address with the old 278 security parameters. No signaling is needed, and the transport and 279 application will continue as soon as the MH is ready to use the new 280 IP address. 282 3.4. Usage: Multi-Interface Host 284 Mobi-D is not intended to allow two interfaces to carry a single DTLS 285 flow simultaneously. If the MH has a Mobi-D connection and needs to 286 continue that connection on a new interface, and has a different IP 287 address on the new interface, the MH can continue the secure 288 connection on the new interface by using the new IP address with the 289 old security parameters. 291 If the MH wants to use two or more interfaces at once, it perform the 292 DTLS handshake multiple times, allocating a unique connection_id for 293 each flow on each interface. This way the MH can create separate 294 Mobi-D connections for each of the flows from each interface. 295 Mobility that causes only one of the interfaces to need a change of 296 IP address is supported. For example, consider a mobile device with 297 a small cell radio such as WLAN and a large cell radio such as LTE or 298 WiMAX. Local mobility might cause the Mobi-D connection on the WLAN 299 to move to a new network and configure a new IP address, while the 300 larger cell is still in range and doesn't create a need to modify the 301 IP address. In this case the host can continue to use both Mobi-D 302 connections while updating the IP address on one. 304 In another multi-radio use case, the host may have two Mobi-D 305 connections on two different interfaces, but may lose coverage on one 306 of the radios. In this case the MH may use the interface that is 307 still in range and the IP address already available on that 308 interface. The MH begins sending the Mobi-D connection of the 309 failing interface over the working interface. There is no need to 310 get a new IP address, or re-handshake on the new interface to 311 accomodate the second flow. 313 The receiving host of a Mobi-D connection will typically be a server 314 of some kind, but may be another MH. The receiving host accepts 315 Mobi-D packets from any IP address. The connection to which the 316 inbound packet belongs is determined by the connection identifier and 317 corresponding security parameters. In the case of a server receiving 318 two inbound Mobi-D packets from the same client IP address, they will 319 belong to the same connection or to different connections depending 320 on the connection identifier and security parameters used by the MH 321 when transmitting. 323 If an MH is behind a NAT, the Mobi-D packets may have NATed IP 324 addresses or ports. These will still be delivered based on them 325 having a connection identifier and matching security parameters. 327 During and after the MH changes IP address, in-bound datagrams may be 328 lost, until the MH sends a packet to the receiving server or host to 329 cause the receiving host to add or update the new IP address to the 330 connection. This packet can be the next packet in the connection, or 331 can be a special Mobi-D NOP packet to optimize the remote host's 332 detection of the address change. 334 4. Details 336 4.1. Extensions 338 The Mobility and OP extensions follow the TLS Extension format as 339 defined in TLS [RFC5246]: 341 struct { 342 ExtensionType extension_type; 343 opaque extension_data<0..2^16-1>; 344 } Extension; 346 enum { 347 (65535) 348 } ExtensionType; 350 The Mobility extension, OP extension, and new ExtensionType are 351 defined as follows: 353 enum { 354 mobility(), op(), (65535) 355 } ExtensionType; 357 struct { 358 uint32 connection_id; 359 MobilityType mobile_type; 360 } Mobility; 362 enum { mobile(1), fixed(2), (255) } MobilityType; 364 struct { 365 uint8 length; 366 OpType<1..256> op_types; 367 } OP; 369 enum { nop(1), (255) } OpType; 371 The extension_type for Mobi-D is maintained by IANA as described in 372 the section on IANA considerations (Section 6). 374 4.2. Record Layer 376 Mobi-D adds a connection identifier to the DTLS record layer which 377 each host uses to look up the security parameters for the connection. 378 The identifier (connection_id) is a single 32-bit integer, placed 379 immediately after the content type. 381 TODO: should this handle collisions with non-Mobi-D DTLS records? 382 For example, certain values of the high order byte of connection_id 383 could be made illegal. The current placement in the record leaves 384 this possibility open. 386 The modified DTLS record layer is as follows. connection_id is always 387 the ID provided by the receiving party. 389 struct { 390 ContentType type; 391 uint32 connection_id; // New field 392 ProtocolVersion version; 393 uint16 epoch; 394 uint48 sequence_number; 395 uint16 length; 396 opaque fragment[DTLSPlaintext.length]; 398 } DTLSPlaintext; 400 Once established, the connection_id remains in use throughout the 401 life of the DTLS session, including in a re-handshake. The client 402 MUST include the server's connection_id in every record sent to the 403 server, and likewise, the server MUST include the client's 404 connection_id in every record sent to the client. 406 If a host receives a valid Mobi-D record with a valid connection_id 407 from a new IP address or port, the host MUST use the message's source 408 address and port as the destination address and port for all new 409 messages back to the sender. A host MUST NOT change the destination 410 address and port for the correspondent host until after successfully 411 authenticating and verifying the sequence number of the DTLS record 412 according to the connection_id contained within. 414 A new handshake (either for session resumption or a full handshake) 415 MUST NOT use connection_ids in ClientHello and ServerHello because 416 the IDs will point to existing security parameters that do not yet 417 apply to the flow. The client and server MAY agree to re-use the 418 same connection_ids via the Mobility extension negotiation in the 419 handshake. Multiple connections between the same client and server 420 MUST use different connection_ids and security parameters. 422 However, a re-handshake during an established session MUST include 423 connection_ids in all records, as the connection_ids are necessary 424 for each party to find the current security parameters. 426 The introduction of the connection identifier creates the possibility 427 for an attacker with access to the packet flow to forward a packet 428 after modifying the IP address or port, causing the return packet to 429 be misaddressed. This attack is discussed further in the Security 430 Considerations section (Section 5) below. 432 4.3. Message 434 Mobi-D adds a new message to TLS: the OP message. OP MUST be 435 consumed by the receiving DTLS implementation and MUST NOT be 436 delivered to the application. OP is an extensible message; other 437 extensions may add OP message types. OP is implemented using a new 438 content type, op, provided by IANA (see Section 6). Like other 439 messages, op messages are encrypted and compressed, as specified by 440 the current connection state. Mobi-D defines the NOP (no-op) OP 441 message type. 443 Only OP message types negotiated in the OP Hello extension may be 444 sent in a connection. 446 The extended ContentType is as follows. The OP content type is 447 maintained by IANA as described in Section 6. 449 enum { 450 change_cipher_spec(20), alert(21), handshake(22), 451 application_data(23), op(), (255) 452 } ContentType; 454 The OP message is defined as follows: 456 enum { nop(1), (255) } OpType; 458 struct { 459 OpType op_type; 460 opaque op_data<0..2^14-1>; 461 } OP; 463 5. Security Considerations 465 5.1. Cryptography 467 Mobi-D makes no changes to the cryptography of DTLS. 469 5.2. Connection ID 471 The connection_id has no cryptographic properties. An attacker able 472 to capture packets can modify the connection_id. A Mobi-D host that 473 receives a DTLS record with an incorrect (but valid) connection_id 474 will be unable to authenticate the record and will reject it. A 475 Mobi-D host that receives a record with an invalid connection_id (one 476 it does not recognize) MUST discard the record. 478 5.3. Denial of Service 480 Mobi-D introduces new DoS attack. An attacker able to capture 481 datagrams from the client will be able to send a valid datagram to 482 the server from a forged IP address. This will cause the server to 483 transmit packets to the forged address until the server receives a 484 new packet from the real client. The same attack can occur in the 485 other direction, but can be mitigated by the use of the fixed 486 MobilityType in the server's Mobility extension. 488 Such an attack could deny service to the victim(s), but would not 489 compromise the integrity of the encrypted data, nor allow the 490 attacker to inject data of his own choosing, or to replay datagrams. 491 Further, this attack is not substantially different from other denial 492 of service attacks. 494 6. IANA Considerations 496 The Mobility extension number, OP extension number, and the OP 497 content type will need to be registered with IANA. 499 7. Acknowledgements 501 The authors want to thank Pasi Eronen, Hannes Tschofenig, Basaravaj 502 (Raj) Patil, Dan Wing, Teemu Savolainen, Lars Eggert, and Eric 503 Rescorla 505 8. Normative References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 511 Security", RFC 4347, April 2006. 513 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 514 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 516 Appendix A. Additional Stuff 518 This becomes an Appendix. 520 Authors' Addresses 522 Michael Williams 523 Nokia 525 Email: michael.g.williams@nokia.com 527 Jeremey Barrett 528 Nokia 530 Email: jeremey.barrett@nokia.com