idnits 2.17.1 draft-schmertmann-dice-codtls-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 15, 2014) is 3540 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-15 ** 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: February 16, 2015 Universitaet Bremen TZI 6 August 15, 2014 8 CoDTLS: DTLS handshakes over CoAP 9 draft-schmertmann-dice-codtls-01 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 February 16, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Media Types ("MIME Type") . . . . . . . . . . . . . . . . 7 68 5.2. CoAP Content-Formats . . . . . . . . . . . . . . . . . . 9 69 5.3. Link relation . . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 8.2. Informative References . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Constrained nodes in constrained node networks [RFC7228] often need 80 robust security. The Constrained Application Protocol (CoAP), 81 [RFC7252], has chosen DTLS as the protocol to be used for 82 communication security between CoAP nodes. DTLS was defined without 83 special considerations for the capabilities of constrained nodes. 84 The packets are relatively verbose, and the error control mechanisms 85 and parameters work best in a typical Ethernet-like environment. 87 [I-D.hartke-core-codtls] proposes to mitigate these problems by 88 running the DTLS handshake over CoAP. The present document discusses 89 such a protocol in more detail, based on an initial implementation 90 that was tested on MC13224-based constrained nodes (ARM7TDMI, 96 KiB 91 RAM shared for both code and data filled from serial flash). 93 1.1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 2. Stateless Compression 101 DTLS handshake messages are carried in CoAP bodies exchanged in CoAP 102 requests and responses, possibly sliced up by the block protocol 103 [I-D.ietf-core-block]. Each body is of a media type (Content-Format) 104 that can contain multiple concatenated handshake messages. Along the 105 lines of a compression scheme also defined in 106 [I-D.hartke-core-codtls], the DTLS header is compressed as follows: 108 struct { 109 ContentType type; 110 ProtocolVersion version; 111 uint16 epoch; // New field 112 uint48 sequence_number; // New field 113 uint16 length; 114 opaque fragment[DTLSPlaintext.length]; 115 } DTLSPlaintext; 117 enum { 118 change_cipher_spec(20), alert(21), handshake(22), 119 application_data(23), (255) 120 } ContentType; 122 -> 124 0 1 125 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 |0| T | V | E |1 1 0| S | L | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 For T = 0, the initial header is followed by an 8-bit field for the 131 "type". T = 1 compactly encodes the "type" value "alert" (21), T = 2 132 stands for "handshake" (22), T = 3 for "application_data" (23). (Not 133 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 278 This specification also defines the entries in the Content-Format 279 registry for these new media types. 281 5.1. Media Types ("MIME Type") 283 The Internet media type [RFC6838] for a DTLS hello is application/ 284 dtls-hello. 286 Type name: application 288 Subtype name: dtls-hello 290 Required parameters: n/a 292 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 341 Applications that use this media type: Setup of DTLS sessions over 342 CoAP 344 Additional information: 345 Magic number(s): n/a 346 File extension(s): n/a 347 Macintosh file type code(s): n/a 349 Person & email address to contact for further information: 350 Carsten Bormann 351 cabo@tzi.org 353 Intended usage: COMMON 355 Restrictions on usage: none 357 Author: 358 Carsten Bormann 360 Change controller: 361 The IESG 363 5.2. CoAP Content-Formats 365 Media Type: application/dtls-hello 367 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 [RFC7252] apply. 391 In its main part, this specification provides a way to carry around 392 DTLS packets. Under the Internet Threat Model, those packets already 393 traverse unsecured networks, so any attack that could be used to 394 subvert DTLS packets sent over CoAP could already be used to subvert 395 the DTLS packets when sent over traditional transports. Obviously 396 implementers still need to implement the DTLS state machine fully. 397 In addition, if the CoAP exchanges run over unsecured channels, those 398 channels will need to be made robust to the usual attacks. 400 If the option is chosen to derive the Finished MACs from the CoAP 401 representation, much more substantial security analysis is required, 402 and this section will need to discuss its security considerations. 404 7. Acknowledgements 406 Olaf Bergmann is a co-author of the base specification this 407 implementation has been derived from. 409 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-15 (work in progress), July 2014. 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 421 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 423 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 424 Security Version 1.2", RFC 6347, January 2012. 426 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 427 Application Protocol (CoAP)", RFC 7252, June 2014. 429 8.2. Informative References 431 [I-D.hartke-core-codtls] 432 Hartke, K. and O. Bergmann, "Datagram Transport Layer 433 Security in Constrained Environments", draft-hartke-core- 434 codtls-02 (work in progress), July 2012. 436 [I-D.ietf-core-resource-directory] 437 Shelby, Z., Bormann, C., and S. Krco, "CoRE Resource 438 Directory", draft-ietf-core-resource-directory-01 (work in 439 progress), December 2013. 441 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 442 Specifications and Registration Procedures", BCP 13, RFC 443 6838, January 2013. 445 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 446 Constrained-Node Networks", RFC 7228, May 2014. 448 Authors' Addresses 450 Lars Schmertmann 451 Universitaet Bremen TZI 452 Postfach 330440 453 Bremen D-28359 454 Germany 456 Email: lars@tzi.de 458 Klaus Hartke 459 Universitaet Bremen TZI 460 Postfach 330440 461 Bremen D-28359 462 Germany 464 Phone: +49-421-218-63905 465 Email: hartke@tzi.org 467 Carsten Bormann (editor) 468 Universitaet Bremen TZI 469 Postfach 330440 470 Bremen D-28359 471 Germany 473 Phone: +49-421-218-63921 474 Email: cabo@tzi.org