idnits 2.17.1 draft-schmertmann-dice-codtls-00.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 (February 14, 2014) is 3717 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ChangeCipherSpec' is mentioned on line 232, but not defined == Missing Reference: 'RFC-THIS-SPEC' is mentioned on line 379, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-core-block-13 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-01 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Schmertmann 3 Internet-Draft K. Hartke 4 Intended status: Informational C. Bormann, Ed. 5 Expires: August 18, 2014 Universitaet Bremen TZI 6 February 14, 2014 8 CoDTLS: DTLS handshakes over CoAP 9 draft-schmertmann-dice-codtls-00 11 Abstract 13 The Datagram Transport Layer Security protocol, DTLS, is usually 14 transported over UDP. In Constrained Node Networks, there may be 15 considerable limitations on the packet delivery rates and on 16 practically usable packet sizes. Applications often can control the 17 size and retransmission requirements of their data packets, but the 18 DTLS handshake is out of scope for such application optimizations. 20 This specification defines how to perform a DTLS handshake on top of 21 the CoAP protocol. The resulting DTLS connection may then be used 22 for instance for transporting CoAP, or as a source of keying 23 material. The latter case is particularly interesting if the CoAP 24 exchanges transporting the DTLS handshake messages traverse CoAP 25 proxies. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 18, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Stateless Compression . . . . . . . . . . . . . . . . . . . . 3 64 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 5.1. Media Types ("MIME Type") . . . . . . . . . . . . . . . . 7 68 5.2. CoAP Content-Formats . . . . . . . . . . . . . . . . . . 8 69 5.3. Link relation . . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 8.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 Constrained nodes in constrained node networks 80 [I-D.ietf-lwig-terminology] often need robust security. The 81 Constrained Application Protocol (CoAP), [I-D.ietf-core-coap], has 82 chosen DTLS as the protocol to be used for communication security 83 between CoAP nodes. DTLS was defined without special considerations 84 for the capabilities of constrained nodes. The packets are 85 relatively verbose, and the error control mechanisms and parameters 86 work best in a typical Ethernet-like environment. 88 [I-D.hartke-core-codtls] proposes to mitigate these problems by 89 running the DTLS handshake over CoAP. The present document discusses 90 such a protocol in more detail, based on an initial implementation 91 that was tested on MC13224-based constrained nodes (ARM7TDMI, 96 KiB 92 RAM shared for both code and data filled from serial flash). 94 1.1. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 2. Stateless Compression 102 DTLS handshake messages are carried in CoAP bodies exchanged in CoAP 103 requests and responses, possibly sliced up by the block protocol 104 [I-D.ietf-core-block]. Each body is of a media type (Content-Format) 105 that can contain multiple concatenated handshake messages. Along the 106 lines of a compression scheme also defined in 107 [I-D.hartke-core-codtls], the DTLS header is compressed as follows: 109 struct { 110 ContentType type; 111 ProtocolVersion version; 112 uint16 epoch; // New field 113 uint48 sequence_number; // New field 114 uint16 length; 115 opaque fragment[DTLSPlaintext.length]; 116 } DTLSPlaintext; 118 enum { 119 change_cipher_spec(20), alert(21), handshake(22), 120 application_data(23), (255) 121 } ContentType; 123 -> 125 0 1 126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 |0| T | V | E |1 1 0| S | L | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 For T = 0, the initial header is followed by an 8-bit field for the 132 "type". T = 1 compactly encodes the "type" value "alert" (21), T = 2 133 stands for "handshake" (22), T = 3 for "application_data" (23). (Not 134 that "change_cipher_spec" is transported in a different way.) 135 For V = 1, this is followed by a two-byte field for the "version". 136 For V = 0, version is 254.255 (TLS 1.0), for V = 2 version is 254.253 137 (TLS 1.2), and V = 3 is reserved. 139 E encodes the epoch directly (0..4), 5 or 6 specifies that an 8 or 140 16-bit field followed. The value 7 is only allowed for handshake 141 packets following another handshake packet in a CoAP body, it means 142 the epoch is copied from the previous handshake packet in the same 143 body. 145 S encodes the sequence number. For values 1 to 6, the sequence 146 number is attached in 1 to 6 bytes, respectively. Value 0 means the 147 sequence number is not sent at all. Value 7 again refers to the 148 preceding handshake packet in the same body, adding one to the 149 sequence number used there. 151 L encodes the length. For values 1 and 2, the length is attached in 152 1 or 2 bytes. For value 3, the length is the remaining length of the 153 payload. Value 0 is reserved. 155 Within a handshake payload, multiple handshake messages are 156 concatenated, each preceded by a short header: 158 0 1 2 3 4 5 6 7 159 +-+-+-+-+-+-+-+-+ 160 | T | L | 161 +-+-+-+-+-+-+-+-+ 163 T defines the handshake type (with two values special-cased: 32 for 164 change_cipher_spec and 33 for alert). L is the number of bytes that 165 follow and give the length; 0 stands for length 0, 1 and 2 for 1 or 2 166 bytes following giving the length, and 3 standing for the rest of the 167 handshake payload. Note that this format does not address the 168 fragmentation mechanism provided by DTLS, as the assumption is this 169 will not be required in DTLS handshakes performed by constrained 170 nodes. 172 3. Operation 174 To offer DTLS over CoAP, a CoAP server provides a resource that 175 accepts the media types defined in this section, identified by the 176 content-formats in Section 5.2. The specific URI of the resource is 177 up to the server. (In the examples, we are assuming it is at the 178 root of the server, i.e., no Uri-Path options are sent.) The client 179 learns the URI using the usual discovery processes, e.g., the CoRE 180 resource directory [I-D.ietf-core-resource-directory]. 182 The client sends the client hello as an application/dtls-hello 183 payload in a POST request to the DTLS URI of the server. The server 184 MUST NOT accept Block1 options on requests carrying application/dtls- 185 hello hello payloads unless it can already verify a cookie from the 186 first block. (This means that both a cookieless ClientHello request, 187 and the part of a cookied ClientHello that contains the cookie, need 188 to fit into a single UDP packet of an appropriate size. The server 189 needs to dimension its cookies accordingly.) 191 Once the client hello is accepted, the server builds state, as 192 indicated in Location options in the 2.01 created response. The 193 client switches to PATCHing that state using application/dtls- 194 handshake messages. Instead of creating a separate resource for 195 this, the client simply continues sending to the same DTLS resource. 196 (Alternatively, the server could send back a URI for a new resource 197 from the first successful POST exchange. This is not implemented in 198 the current code, but will be required for operation through 199 proxies.) 201 Figure 1 shows an example message exchange. The PATCH method is 202 currently implemented as a POST, awaiting a PATCH method registration 203 for CoAP. 205 Client Server 206 ------ ------ 208 POST / 209 ClientHello -----> 211 4.01 Unauthorized 212 <----- HelloVerifyRequest 214 POST / 215 ClientHello -----> 217 2.01 Created /dCST0E 218 ServerHello 219 Certificate* 220 ServerKeyExchange* 221 CertificateRequest* 222 <----- ServerHelloDone 224 PATCH /dCST0E 225 Certificate* 226 ClientKeyExchange 227 CertificateVerify* 228 [ChangeCipherSpec] 229 Finished -----> 231 2.04 Changed 232 [ChangeCipherSpec] 233 <----- Finished 235 Figure 1: Message Flights for Full Handshake 237 Table 1 shows the implementation size of the current demonstrator 238 implementation. Assuming that a CoAP library is already available, 239 around 7.2 KiB are required for the entire CoDTLS implementation. 240 (Note that the specific CoAP library in use required about 2134 bytes 241 additional code to implement all the CoAP features required, 242 including Block1, and some management code.) The implementation can 243 operate with 2.0 KiB stack size. 245 +------------+--------------------------------------+ 246 | Size (KiB) | Function | 247 +------------+--------------------------------------+ 248 | 2.41 | ECC functions | 249 | 0.95 | AES modes (CCM + CMAC) | 250 | 0.80 | Storage management | 251 | 0.79 | Session management | 252 | 0.15 | PRF | 253 | 1.78 | CoAP Resource implementing handshake | 254 | 0.32 | Parse & Send | 255 +------------+--------------------------------------+ 257 Table 1: Code sizes in demonstrator implementation 259 4. Discussion 261 An alternative approach to the DTLS tunneling described here is to 262 directly use the TLS handshake [RFC5246], as all prerequisites are 263 already available in the reliability mechanisms provided by CoAP. 264 However, this would require the addition of a DoS countermeasure, 265 which in turn might be a useful component beyond the usage in this 266 specification. Also, if it is desired to directly use the DTLS 267 record layer after a CoAP-mediated handshake, the details of the 268 transition from TLS to DTLS need to be specified. 270 5. IANA Considerations 272 This specification defines two new Internet media types [RFC6838]: 274 o application/dtls-hello 276 o application/dtls-handshake 277 This specification also defines the entries in the Content-Format 278 registry for these new media types. 280 5.1. Media Types ("MIME Type") 282 The Internet media type [RFC6838] for a DTLS hello is application/ 283 dtls-hello. 285 Type name: application 287 Subtype name: dtls-hello 289 Required parameters: n/a 291 Optional parameters: n/a 293 Encoding considerations: binary 295 Security considerations: See Section 6 of this document 297 Interoperability considerations: n/a 299 Published specification: This document 301 Applications that use this media type: Setup of DTLS sessions over 302 CoAP 304 Additional information: 305 Magic number(s): n/a 306 File extension(s): n/a 307 Macintosh file type code(s): n/a 309 Person & email address to contact for further information: 310 Carsten Bormann 311 cabo@tzi.org 313 Intended usage: COMMON 315 Restrictions on usage: none 317 Author: 318 Carsten Bormann 320 Change controller: 321 The IESG 323 The Internet media type [RFC6838] for a DTLS handshake message is 324 application/dtls-handshake. 326 Type name: application 328 Subtype name: dtls-hello 330 Required parameters: n/a 332 Optional parameters: n/a 334 Encoding considerations: binary 336 Security considerations: See Section 6 of this document 338 Interoperability considerations: n/a 340 Published specification: This document 342 Applications that use this media type: Setup of DTLS sessions over 343 CoAP 345 Additional information: 346 Magic number(s): n/a 347 File extension(s): n/a 348 Macintosh file type code(s): n/a 350 Person & email address to contact for further information: 351 Carsten Bormann 352 cabo@tzi.org 354 Intended usage: COMMON 356 Restrictions on usage: none 358 Author: 359 Carsten Bormann 361 Change controller: 362 The IESG 364 5.2. CoAP Content-Formats 366 Media Type: application/dtls-hello 368 Encoding: - 369 Id: TBD1 371 Reference: [RFC-THIS-SPEC] 373 Media Type: application/dtls-handshake 375 Encoding: - 377 Id: TBD2 379 Reference: [RFC-THIS-SPEC] 381 5.3. Link relation 383 TBD: There needs to be a way to find DTLS resources on a server, 384 e.g., in a resource directory. This is usually done by defining an 385 appropriate link relation. 387 6. Security Considerations 389 The security considerations of [RFC6347] and [I-D.ietf-core-coap] 390 apply. 392 In its main part, this specification provides a way to carry around 393 DTLS packets. Under the Internet Threat Model, those packets already 394 traverse unsecured networks, so any attack that could be used to 395 subvert DTLS packets sent over CoAP could already be used to subvert 396 the DTLS packets when sent over traditional transports. Obviously 397 implementers still need to implement the DTLS state machine fully. 398 In addition, if the CoAP exchanges run over unsecured channels, those 399 channels will need to be made robust to the usual attacks. 401 If the option is chosen to derive the Finished MACs from the CoAP 402 representation, much more substantial security analysis is required, 403 and this section will need to discuss its security considerations. 405 7. Acknowledgements 407 Olaf Bergmann is a co-author of the base specification this 408 implementation has been derived from. 410 8. References 411 8.1. Normative References 413 [I-D.ietf-core-block] 414 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 415 draft-ietf-core-block-13 (work in progress), October 2013. 417 [I-D.ietf-core-coap] 418 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 419 Application Protocol (CoAP)", draft-ietf-core-coap-18 420 (work in progress), June 2013. 422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 423 Requirement Levels", BCP 14, RFC 2119, March 1997. 425 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 426 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 428 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 429 Security Version 1.2", RFC 6347, January 2012. 431 8.2. Informative References 433 [I-D.hartke-core-codtls] 434 Hartke, K. and O. Bergmann, "Datagram Transport Layer 435 Security in Constrained Environments", draft-hartke-core- 436 codtls-02 (work in progress), July 2012. 438 [I-D.ietf-core-resource-directory] 439 Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource 440 Directory", draft-ietf-core-resource-directory-01 (work in 441 progress), December 2013. 443 [I-D.ietf-lwig-terminology] 444 Bormann, C., Ersue, M., and A. Keranen, "Terminology for 445 Constrained Node Networks", draft-ietf-lwig-terminology-07 446 (work in progress), February 2014. 448 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 449 Specifications and Registration Procedures", BCP 13, RFC 450 6838, January 2013. 452 Authors' Addresses 453 Lars Schmertmann 454 Universitaet Bremen TZI 455 Postfach 330440 456 Bremen D-28359 457 Germany 459 Email: lars@tzi.de 461 Klaus Hartke 462 Universitaet Bremen TZI 463 Postfach 330440 464 Bremen D-28359 465 Germany 467 Phone: +49-421-218-63905 468 Email: hartke@tzi.org 470 Carsten Bormann (editor) 471 Universitaet Bremen TZI 472 Postfach 330440 473 Bremen D-28359 474 Germany 476 Phone: +49-421-218-63921 477 Email: cabo@tzi.org