idnits 2.17.1 draft-vanderstok-ace-coap-est-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-6tisch-dtsecurity-secure-join], [RFC7030], [RFC7252], [I-D.ietf-anima-bootstrapping-keyinfra]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2017) is 2577 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC0791' is mentioned on line 416, but not defined == Missing Reference: 'Empty' is mentioned on line 1059, but not defined == Unused Reference: 'I-D.selander-ace-cose-ecdhe' is defined on line 827, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-hartke-core-pending-00 ** Downref: Normative reference to an Informational draft: draft-hartke-core-pending (ref. 'I-D.hartke-core-pending') == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-04 ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) ** Downref: Normative reference to an Informational RFC: RFC 5967 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-01 == Outdated reference: A later version (-07) exists of draft-ietf-anima-voucher-00 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-01 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-04 -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE S. Kumar 3 Internet-Draft Philips Lighting Research 4 Intended status: Standards Track P. van der Stok 5 Expires: September 10, 2017 Consultant 6 P. Kampanakis 7 Cisco Systems 8 M. Furuhed 9 Nexus Group 10 S. Raza 11 RISE SICS 12 March 9, 2017 14 EST over secure CoAP (EST-coaps) 15 draft-vanderstok-ace-coap-est-01 17 Abstract 19 Low-resource devices in a Low-power and Lossy Network (LLN) can 20 operate in a mesh network using the IPv6 over Low-power Wireless 21 Personal Area Networks (6LoWPAN) and IEEE 802.15.4 link-layer 22 standards. Provisioning these devices in a secure manner with keys 23 (often called secure bootstrapping) used to encrypt and authenticate 24 messages is the subject of Bootstrapping of Remote Secure Key 25 Infrastructures (BRSKI) [I-D.ietf-anima-bootstrapping-keyinfra] and 26 6tisch Secure Join [I-D.ietf-6tisch-dtsecurity-secure-join]. 27 Enrollment over Secure Transport (EST) [RFC7030], based on TLS and 28 HTTP, is used in BRSKI. Low-resource devices often use the 29 lightweight Constrained Application Protocol (CoAP) [RFC7252] for 30 message exchanges. This document defines how low-resource devices 31 are expected to use EST over secure CoAP (EST-coaps) for secure 32 bootstrapping and certificate enrollment. 6LoWPAN fragmentation 33 management and minor extensions to CoAP are needed to enable EST- 34 coaps. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 10, 2017. 53 Copyright Notice 55 Copyright (c) 2017 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. EST operational differences . . . . . . . . . . . . . . . . . 4 73 3. Conformance to RFC7925 profiles . . . . . . . . . . . . . . . 5 74 4. Protocol Design and Layering . . . . . . . . . . . . . . . . 6 75 4.1. Discovery and URI . . . . . . . . . . . . . . . . . . . . 7 76 4.2. Payload format . . . . . . . . . . . . . . . . . . . . . 8 77 4.3. Message Bindings . . . . . . . . . . . . . . . . . . . . 8 78 4.4. CoAP response codes . . . . . . . . . . . . . . . . . . . 8 79 4.5. Message fragmentation . . . . . . . . . . . . . . . . . . 9 80 5. Transport Protocol . . . . . . . . . . . . . . . . . . . . . 10 81 5.1. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 5.2. 6tisch approach . . . . . . . . . . . . . . . . . . . . . 11 83 6. Proxying . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 7. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 88 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 91 12.2. Informative References . . . . . . . . . . . . . . . . . 17 92 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 19 93 A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 A.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 21 95 A.3. csrattr . . . . . . . . . . . . . . . . . . . . . . . . . 22 96 A.4. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 22 97 A.5. voucher_status . . . . . . . . . . . . . . . . . . . . . 22 98 A.6. requestvoucher . . . . . . . . . . . . . . . . . . . . . 22 99 A.7. requestlog . . . . . . . . . . . . . . . . . . . . . . . 22 100 Appendix B. EST-coaps Block message examples . . . . . . . . . . 22 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 103 1. Introduction 105 IPv6 over Low-power Wireless Personal Area Networks (6LoWPANs) 106 [RFC4944] on IEEE 802.15.4 [ieee802.15.4] wireless networks is 107 becoming common in many industry application domains such as lighting 108 controls. However, commissioning of such networks suffers from a 109 lack of standardized secure bootstrapping mechanisms for these 110 networks. 112 Although IEEE 802.15.4 defines how security can be enabled between 113 nodes within a single mesh network, it does not specify the 114 provisioning and management of the keys. Therefore, securing a 115 6LoWPAN network with devices from multiple manufacturers with 116 different provisioning techniques is often tedious and time 117 consuming. 119 Bootstrapping of Remote Secure Infrastructures (BRSKI) 120 [I-D.ietf-anima-bootstrapping-keyinfra] addresses the issue of 121 bootstrapping networked devices in the context of Autonomic 122 Networking Integrated Model and Approach (ANIMA). 123 [I-D.ietf-6tisch-minimal-security] and 124 [I-D.ietf-6tisch-dtsecurity-secure-join] also address secure 125 bootstrapping in the 6tisch context targeted to low-resource devices. 126 BRSKI has not been developed specifically for low-resource devices in 127 constrained networks. Constrained networks use DTLS [RFC6347], CoAP 128 [RFC7252], and UDP instead of TLS [RFC5246], HTTP [RFC7230] and TCP. 129 BRSKI relies on Enrollment over Secure Transport (EST) [RFC7030] for 130 the provisioning of the operational domain certificates. 132 EST-coaps provides a subset of EST functionality and extends EST with 133 BRSKI functions. EST-coaps replaces the invocations of TLS and HTTP 134 by DTLS and CoAP invocations thus enabling EST and BRSKI for CoAP- 135 based low-resource devices. 137 Although EST-coaps paves the way for the utilization of EST for 138 constrained devices on constrained networks, some devices will not 139 have enough resources to handle the large payloads that come with 140 EST-coaps. The specification of EST-coaps is intended to ensure that 141 bootstrapping works for less constrained devices that choose to limit 142 their communications stack to UDP/CoAP. It is up to the network 143 designer to decide which devices execute the EST protocol and which 144 not. 146 EST-coaps is designed for use in professional control networks such 147 as Building Control. The autonomic bootstrapping is interesting 148 because it reduces the manual intervention during the commissioning 149 of the network. Typing in passwords is contrary to this wish. 150 Therefore, the HTTP Basic authentication of EST is not supported in 151 EST-coaps. 153 In the constrained devices context it is very unlikely that full PKI 154 request messages will be used. For that reason, full PKI messages 155 are not supported in EST-coaps. 157 Because the relatively large EST messages cannot be readily 158 transported over constrained (6LoWPAN, LLN) wireless networks, this 159 document specifies the use of CoAP Block-Wise Transfer ("Block") 160 [RFC7959] to fragment EST messages at the application layer. 162 Support for Observe CoAP options [RFC7641] with BRSKI is not 163 supported in the current BRSKI/EST message flows and is thus out-of- 164 scope for this discussion. Observe options could be used by the 165 server to notify clients about a change in the cacerts or csr 166 attributes (resources) and might be an area of future work. 168 1.1. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in [RFC2119]. 174 Many of the concepts in this document are taken over from [RFC7030]. 175 Consequently, much text is directly traceable to [RFC7030]. The same 176 document structure is followed to point out the differences and 177 commonalities between EST and EST-coaps. 179 The following terms are defined in the BRSKI protocol 180 [I-D.ietf-anima-bootstrapping-keyinfra]: pledge, Join proxy, Join 181 Registrar, and Manufacturer Authorized Signing Authorities (MASA). 183 2. EST operational differences 185 Only the differences to EST with respect to operational scenarios are 186 described in this section. EST-coaps server differs from EST server 187 as follows: 189 o Replacement of TLS by DTLS and HTTP by CoAP, resulting in: 191 * DTLS-secured CoAP sessions between EST-coaps client and EST- 192 coaps server. 194 o Only certificate-based client authentication is supported, which 195 results in: 197 * The EST-coaps client does not support HTTP Basic authentication 198 (as described in Section 3.2.3 of [RFC7030]) 200 * The EST-coaps client does not support authentication at the 201 application layer (as described in Section 3.2.3 of [RFC7030]). 203 o EST-coaps does not support full PKI request messages[RFC5272]. 205 o EST-coaps specifies the BRSKI extensions over CoAP as specified in 206 section 5 of [I-D.ietf-anima-bootstrapping-keyinfra]. 208 3. Conformance to RFC7925 profiles 210 This section shows how EST-coaps fits into the profiles of low- 211 resource devices as described in [RFC7925]. Within the bootstrap 212 context a Public Key Infrastructure (PKI) is used, where the client 213 is called "pledge", the Registration Authority (RA) is called Join 214 Registrar, which acts at the front-end for the Certificate Authority 215 (CA) and receives voucher feedback from as many Manufacturer 216 Authorized Signing Authorities (MASA) as there are manufacturers. A 217 Join-Proxy is placed between client and RA to receive join requests 218 over a 1-hop unsecured channel and transmitted over the secure 219 network to the EST-server. The EST-server of EST-coaps is placed 220 between proxy and RA or is part of RA. 222 EST-coaps transports Public keys and certificates. Private keys can 223 be transported as response to a request to a server-side key 224 generation as described in section 4.4 of [RFC7030]. In the 225 bootstrapping context, EST-coaps transport is limited to the EST 226 certificate transport conformant to section 4.4 of [RFC7925]. For 227 BRSKI, outside the profiles of [RFC7925], EST-coaps transports 228 vouchers, which are YANG files specified in [I-D.ietf-anima-voucher]. 230 The mandatory cipher suite for DTLS is 231 TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the 232 mandatory-to-implement cipher suite in CoAP. Additionally the curve 233 secp256r1 MUST be supported [RFC4492]; this curve is equivalent to 234 the NIST P-256 curve. The hash algorithm is SHA-256. DTLS 235 implementations MUST use the Supported Elliptic Curves and Supported 236 Point Formats Extensions [RFC4492]; the uncompressed point format 237 MUST be supported; [RFC6090] can be used as an implementation method. 239 The EST-coaps client MUST be configured with an explicit TA database 240 or at least an implicit TA database from its manufacturer. The 241 authentication of the EST-coaps server by the EST-coaps client is 242 based on Certificate authentication in the DTLS handshake. 244 The authentication of the EST-coaps client is based on client 245 certificate in the DTLS handshake. This can either be 247 o DTLS with a previously issued client certificate (e.g., an 248 existing certificate issued by the EST CA); this could be a common 249 case for simple re-enrollment of clients; 251 o DTLS with a previously installed certificate (e.g., manufacturer- 252 installed certificate or a certificate issued by some other 253 party); 255 4. Protocol Design and Layering 257 EST-coaps uses CoAP to transfer EST messages, aided by Block-Wise 258 Transfer [RFC7959] to transport CoAP messages in blocks thus avoiding 259 (excessive) 6LoWPAN fragmentation of UDP datagrams. The use of 260 "Block" for the transfer of larger EST messages is specified in 261 Section 4.5. The Figure 1 below shows the layered EST-coaps 262 architecture. 264 +------------------------------------------------+ 265 | EST request/response messages | 266 +------------------------------------------------+ 267 | CoAP for message transfer and signaling | 268 +------------------------------------------------+ 269 | DTLS for transport security | 270 +------------------------------------------------+ 271 | UDP for transport | 272 +------------------------------------------------+ 274 Figure 1: EST-coaps protocol layers 276 The EST-coaps protocol design follows closely the EST design, 277 excluding some aspects that are not relevant for automatic 278 bootstrapping of constrained devices within a professional context. 279 The parts supported by EST-coaps are identified by their message 280 types: 282 o Simple enroll and reenroll. 284 o CA certificate retrieval. 286 o CSR Attributes request messages. 288 o Server-side key generation messages. 290 4.1. Discovery and URI 292 EST-coaps is targeted to low-resource networks with small packets. 293 Saving header space is important and the EST-coaps URI is shorter 294 than the EST URI. 296 The presence and location of (path to) the management data are 297 discovered by sending a GET request to "/.well-known/core" including 298 a resource type (RT) parameter with the value "core.est" [RFC6690]. 299 Upon success, the return payload will contain the root resource of 300 the EST resources. It is up to the implementation to choose its root 301 resource, but it is recommended that the value "/est" is used, where 302 possible. The example below shows the discovery of the presence and 303 location of management data. 305 REQ: GET /.well-known/core?rt=core.est 307 RES: 2.05 Content ; rt="core.est" 309 The EST-coaps server URIs differ from the EST URI by replacing the 310 scheme https by coaps and by specifying shorter resource path names: 312 coaps://www.example.com/est/short-name 314 Figure 5 in section 3.2.2 of [RFC7030] enumerates the operations and 315 corresponding paths which are supported by EST. Table 1 provides the 316 mapping from the EST and BRSKI URI path to the EST-coaps URI path. 318 +------------------+------------------+-----------+ 319 | BRSKI | EST | EST-coaps | 320 +------------------+------------------+-----------+ 321 | | /cacerts | /crts | 322 | | /simpleenroll | /sen | 323 | | /simplereenroll | /sren | 324 | | /csrattrs | /att | 325 | | /serverkeygen | /skg | 326 | /requestvoucher | | /rv | 327 | /voucherstatus | | /vs | 328 | /enrollstatus | | /es | 329 +------------------+------------------+-----------+ 331 Table 1 333 /requestvoucher and /enrollstatus are needed between pledge and 334 Registrar. 336 4.2. Payload format 338 The content-format (media type equivalent) of the CoAP message 339 determines which EST message is transported in the CoAP payload. The 340 media types specified in the HTTP Content-Type header(see section 341 3.2.2 of [RFC7030]) are in EST-coaps specified by the Content-Format 342 Option (12) of CoAP. The combination of URI path-suffix and content- 343 format used for coap MUST map to an allowed combination of path- 344 suffix and media type as defined for EST. The required content- 345 formats for these request and response messages are defined in 346 Section 8. The CoAP response codes are defined in Section 4.4. 348 EST-coaps is designed for use between low-resource devices using CoAP 349 and hence does not need to send base64-encoded data. Simple CBOR 350 byte string is more efficient (30% less payload compared to base64) 351 and well supported by CoAP. Therefore, the content formats 352 specification in Section 8 requires the use of CBOR byte string 353 (h'xxxx' in Diagnostic JSON) for all EST-coaps CoAP payloads. 355 4.3. Message Bindings 357 This section describes BRSKI to CoAP message mappings. 359 All /crts, /sen, /sren, /att, /skg, /rv, /vs, and /es EST-coaps 360 messages expect a response, so they are all CoAP CON messages. 362 The Ver, TKL, Token, and Message ID values of the CoAP header are not 363 influenced by EST. 365 CoAP options are used to convey Uri-Host, Uri-Path, Uri-Port, 366 Content-Format and more in CoAP. The CoAP Options are used to 367 communicate the HTTP fields specified in the BRSKI REST messages. 369 BRSKI URLs are HTTPS based (https:// ), in CoAP these will be assumed 370 to be transformed to coaps (coaps://) 372 Appendix A includes some practical examples of EST messages 373 translated to CoAP. 375 4.4. CoAP response codes 377 Section 5.9 of [RFC7252] specifies the mapping of HTTP response codes 378 to CoAP response codes. Every time the HTTP response code 200 is 379 specified in [RFC7030] in response to a GET request, in EST-coaps the 380 equivalent CoAP response code 2.05 MUST be used. Response code HTTP 381 202 in EST is mapped to CoAP 2.06 as specified in 382 [I-D.hartke-core-pending]. All other HTTP 2xx response codes are not 383 used by EST. For the following HTTP 4xx error codes that may occur: 384 400, 401, 403, 404, 405, 406, 412, 413, 415 ; the equivalent CoAP 385 response code for EST-coaps is 4.xx. For the HTTP 5xx error codes: 386 500, 501, 502, 503, 504 the equivalent CoAP response code is 5.xx. 388 Appendix A includes some practical examples of HTTP response codes 389 from EST translated to CoAP. 391 4.5. Message fragmentation 393 DTLS defines fragmentation only for the handshake part and not for 394 secure data exchange (DTLS records). [RFC6347] states "Each DTLS 395 record MUST fit within a single datagram". In order to avoid using 396 IP fragmentation, which is not supported by 6LoWPAN, invokers of the 397 DTLS record layer MUST size DTLS records so that they fit within any 398 Path MTU estimates obtained from the record layer. In addition, 399 invokers residing on a 6LoWPAN over IEEE 802.15.4 network SHOULD 400 attempt to size CoAP messages such that each DTLS record will fit 401 within one or two IEEE 802.15.4 frames. 403 That is not always possible. Even though ECC certificates are small 404 in size, they can vary greatly based on signature algorithms, key 405 sizes, and OID fields used. For 256-bit curves, common ECDSA cert 406 sizes are 500-1000 bytes which could fluctuate further based on the 407 algorithms, OIDs, SANs and cert fields. For 384-bit curves, ECDSA 408 certs increase in size and can sometimes reach 1.5KB. Additionally, 409 there are times when the EST cacerts response from the server can 410 include multiple certs that amount to large payloads. CoAP 411 [RFC7252]'s section 4.6 describes the possible payload sizes: "if 412 nothing is known about the size of the headers, good upper bounds are 413 1152 bytes for the message size and 1024 bytes for the payload size". 414 Also "If IPv4 support on unusual networks is a consideration, 415 implementations may want to limit themselves to more conservative 416 IPv4 datagram sizes such as 576 bytes; per [RFC0791], the absolute 417 minimum value of the IP MTU for IPv4 is as low as 68 bytes, which 418 would leave only 40 bytes minus security overhead for a UDP payload". 419 Thus, even with ECC certs, EST-coaps messages can still exceed sizes 420 in MTU of 1280 for IPv6 or 60-80 bytes for 6LoWPAN [RFC4919] as 421 explained in section 2 of [RFC7959]. EST-coaps needs to be able to 422 fragment EST messages into multiple DTLS datagrams with each DTLS 423 datagram. Fine-grained fragmentation of EST messages is essential. 425 To perform fragmentation in CoAP, [RFC7959] specifies the "Block1" 426 option for fragmentation of the request payload and the "Block2" 427 option for fragmentation of the return payload of a CoAP flow. 429 The BLOCK draft defines SZX in the Block1 and block2 option fields. 430 These are used to convey the size of the blocks in the requests or 431 responses. 433 The CoAP client MAY specify the Block1 size and MAY also specify the 434 Block2 size. The CoAP server MAY specify the Block2 size, but not 435 the Block1 size. As explained in Section 1 of [RFC7959]), blockwise 436 transfers SHOULD be used in Confirmable CoAP messages to avoid the 437 exacerbation of lost blocks. 439 The Size1 response MAY be parsed by the client as a size indication 440 of the Block2 resource in the server response or by the server as a 441 request for a size estimate by the client. Similarly, Size2 option 442 defined in BLOCK should be parsed by the server as an indication of 443 the size of the resource carried in Block1 options and by the client 444 as a maximum size expected in the 4.13 (Request Entity Too Large) 445 response to a request. 447 Examples of fragmented messages are shown in Appendix B. 449 5. Transport Protocol 451 EST-coaps depends on a secure transport mechanism over UDP that can 452 secure (confidentiality, authenticity) the CoAP messages exchanged. 454 5.1. DTLS 456 DTLS is one such secure protocol. Within BRSKI and EST when "TLS" is 457 referred to, it is understood that in EST-coaps, security is provided 458 using DTLS instead. No other changes are necessary (all provisional 459 modes etc are the same as for TLS). 461 CoAP was designed to avoid fragmentation. DTLS is used to secure 462 CoAP messages. However, fragmentation is still possible at the DTLS 463 layer during the DTLS handshake when using ECC ciphersuites. If 464 fragmentation is necessary, "DTLS provides a mechanism for 465 fragmenting a handshake message over a number of records, each of 466 which can be transmitted separately, thus avoiding IP fragmentation" 467 [RFC6347]. 469 EST-coaps does not support full PKI Requests. Consequently, the 470 fullcmc request of section 4.3 of [RFC7030] and response MUST NOT be 471 supported by EST-coaps. 473 Channel-binding information for linking proof-of-identity with 474 message-based proof-of-possession is optional for EST-coaps. Given 475 that CoAP and DTLS can provide proof of identity for EST-coaps 476 clients and server, simple PKI messages can be used conformant to 477 section 3.1 of [RFC5272]. EST-coaps supports the certificate types 478 and Trust Anchors (TA) that are specified for EST in section 3 of 479 [RFC7030]. 481 When proof-of-possession is desired, a set of actions are required 482 regarding the use of tls-connect, described in section 3.5 in 483 [RFC7030] -- Linking Identity and POP Information. The tls-unique 484 information translates to the contents of the first "Finished" 485 message in the TLS handshake between server and client. The client 486 is then supposed to add this "Finished" message as a 487 ChallengePassword to the PKCS#10 to prove that the client is indeed 488 in control of the private key at the time of the TLS session when 489 performing a /simpleenroll, for example. In the case of EST-coaps, 490 the same operations can be performed during the DTLS handshake. 492 In a constrained CoAP environment, endpoints can't afford to 493 establish a DTLS connection for every EST transaction. 494 Authenticating and negotiating DTLS keys requires resources on low- 495 end endpoints and consumes valuable bandwidth. The DTLS connection 496 SHOULD remain open for persistent EST connections. For example, an 497 EST cacerts request that is followed by a simpleenroll request can 498 use the same authenticated DTLS connection. Given that after a 499 successful enrollment, it is more likely that a new EST transaction 500 will take place after a significant amount of time, the DTLS 501 connections SHOULD only be kept alive for EST messages that are 502 relatively close to each other. 504 5.2. 6tisch approach 506 The 6tisch bootstrapping is targeted to the "imprinting" of the 507 "pledge" with layer 2 keys. The content formats for the transport 508 are being defined and may be expressed in a YANG module. 510 Instead of using transport security, the 6tisch approach relies on 511 application security provided by OSCOAP 512 [I-D.ietf-core-object-security]. 514 It is suggested that the EST-coaps communication between pledge and 515 registrar, specified in this document, can be freely exchanged with 516 the same communication specified in 517 [I-D.ietf-6tisch-dtsecurity-secure-join] and 518 [I-D.ietf-6tisch-minimal-security]. 520 [EDNOTE: The evolution of this section depends on the directions 521 taken by 6tisch and anima and the possible commonality that will be 522 provided.] 524 6. Proxying 526 [EDNOTE: This section to be populated. It will address how proxying 527 can take place by an entity that resides at the edge of the CoAP 528 network, such as the Registrar, and can reach the BRSKI server 529 residing in a traditional "TCP setting". It makes sense to mention 530 the properties that the proxy has to fulfill.] 532 7. Parameters 534 [EDNOTE: This section to be populated. It will address transmission 535 parameters for BRSKI described in sections 4.7 and 4.8 of the CoAP 536 draft. BRSKI does not impose any unique parameters that affect the 537 CoAP parameters in Table 2 and 3 in the CoAP draft but the ones in 538 CoAP could be affecting BRSKI. For example the processing delay of 539 CAs could be less then 2s, but in this case they should send a CoAP 540 ACK every 2s while processing.] 542 8. IANA Considerations 544 Additions to the sub-registry "CoAP Content-Formats", within the 545 "CoRE Parameters" registry are needed for the below media types. 546 These can be registered either in the Expert Review range (0-255) or 547 IETF Review range (256-9999). 549 1. 551 * application/pkcs7-mime 553 * Type name: application 555 * Subtype name: pkcs7-mime 557 * smime-type: certs-only 559 * ID: TBD1 561 * Required parameters: None 563 * Optional parameters: None 565 * Encoding considerations: CBOR byte string 567 * Security considerations: As defined in this specification 569 * Published specification: [RFC5751] 570 * Applications that use this media type: ANIMA Bootstrap (BRSKI) 571 and EST 573 2. 575 * application/pkcs8 577 * Type name: application 579 * Subtype name: pkcs8 581 * ID: TBD2 583 * Required parameters: None 585 * Optional parameters: None 587 * Encoding considerations: CBOR byte string 589 * Security considerations: As defined in this specification 591 * Published specification: [RFC5958] 593 * Applications that use this media type: ANIMA Bootstrap (BRSKI) 594 and EST 596 3. 598 * application/csrattrs 600 * Type name: application 602 * Subtype name: csrattrs 604 * ID: TBD3 606 * Required parameters: None 608 * Optional parameters: None 610 * Encoding considerations: CBOR byte string 612 * Security considerations: As defined in this specification 614 * Published specification: [RFC7030] 616 * Applications that use this media type: ANIMA Bootstrap (BRSKI) 617 and EST 619 4. 621 * application/pkcs10 623 * Type name: application 625 * Subtype name: pkcs10 627 * ID: TBD4 629 * Required parameters: None 631 * Optional parameters: None 633 * Encoding considerations: CBOR byte string 635 * Security considerations: As defined in this specification 637 * Published specification: [RFC5967] 639 * Applications that use this media type: ANIMA bootstrap (BRSKI) 640 and EST 642 * 644 + application/pkcs12 646 + Type name: application 648 + Subtype name: pkcs12 650 + ID: TBD5 652 + Required parameters: None 654 + Optional parameters: None 656 + Encoding considerations: CBOR byte string 658 + Security considerations: As defined in this specification 660 + Published specification: IETF 662 + Applications that use this media type: ANIMA bootstrap 663 (BRSKI) and EST 665 * 666 + application/auditnonce 668 + Type name: application 670 + Subtype name: auditnonce 672 + ID: TBD6 674 + Required parameters: None 676 + Optional parameters: None 678 + Encoding considerations: CBOR byte string 680 + Security considerations: As defined in this specification 682 + Published specification: BRSKI?? 684 + Applications that use this media type: ANIMA bootstrap 685 (BRSKI) 687 * 689 + application/authorizationvoucher 691 + Type name: application 693 + Subtype name: authorizationvoucher 695 + ID: TBD7 697 + Required parameters: None 699 + Optional parameters: None 701 + Encoding considerations: CBOR byte string 703 + Security considerations: As defined in this specification 705 + Published specification: BRSKI?? 707 + Applications that use this media type: ANIMA bootstrap 708 (BRSKI) 710 Additions to the sub-registry "CoAP Resource Type", within the "CoRE 711 Parameters" registry are needed for a new resource type. 713 o rt="core.est" needs registration with IANA. 715 [EDNOTE: This section will be expanded to include types needed that 716 do not exist in CoAP.] 718 9. Security Considerations 720 [EDNOTE: This section to be populated. This document describes an 721 existing protocol moved to CoAP and there should not be additional 722 security concerns added beyond the protocol's or CoAP's specifics 723 security considerations. The security considerations mentioned in 724 EST applies also to EST-coaps. Specifically for server-side key 725 generation, it introduces implications for the endpoints and their 726 private keys, which will be covered here. ] 728 10. Acknowledgements 730 The authors are very grateful to Klaus Hartke for his detailed 731 explanations on the use of Block with DTLS. The authors would like 732 to thank Esko Dijk and Michael Verschoor for the valuable discussions 733 that helped in shaping the solution. They would also like to thank 734 Peter Panburana from Cisco for his feedback on technical details of 735 the solution. 737 11. Change Log 739 -01: 741 Merging of draft-vanderstok-ace-coap-est-00 and draft-pritikin- 742 coap-bootstrap-01 744 URI and discovery are modified 746 More text about 6tisch bootstrap including EDHOC and OSCOAP 748 mapping to DICE IoT profiles 750 adapted to BRSKI progress 752 12. References 754 12.1. Normative References 756 [I-D.hartke-core-pending] 757 Stok, P. and K. Hartke, "The 'Pending' Response Code for 758 the Constrained Application Protocol (CoAP)", draft- 759 hartke-core-pending-00 (work in progress), February 2017. 761 [I-D.ietf-anima-bootstrapping-keyinfra] 762 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 763 S., and K. Watsen, "Bootstrapping Remote Secure Key 764 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 765 keyinfra-04 (work in progress), October 2016. 767 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 768 Requirement Levels", BCP 14, RFC 2119, 769 DOI 10.17487/RFC2119, March 1997, 770 . 772 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 773 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 774 . 776 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 777 Mail Extensions (S/MIME) Version 3.2 Message 778 Specification", RFC 5751, DOI 10.17487/RFC5751, January 779 2010, . 781 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 782 DOI 10.17487/RFC5967, August 2010, 783 . 785 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 786 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 787 January 2012, . 789 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 790 "Enrollment over Secure Transport", RFC 7030, 791 DOI 10.17487/RFC7030, October 2013, 792 . 794 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 795 Application Protocol (CoAP)", RFC 7252, 796 DOI 10.17487/RFC7252, June 2014, 797 . 799 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 800 the Constrained Application Protocol (CoAP)", RFC 7959, 801 DOI 10.17487/RFC7959, August 2016, 802 . 804 12.2. Informative References 806 [I-D.ietf-6tisch-dtsecurity-secure-join] 807 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 808 6tisch-dtsecurity-secure-join-01 (work in progress), 809 February 2017. 811 [I-D.ietf-6tisch-minimal-security] 812 Vucinic, M., Simon, J., and K. Pister, "Minimal Security 813 Framework for 6TiSCH", draft-ietf-6tisch-minimal- 814 security-01 (work in progress), February 2017. 816 [I-D.ietf-anima-voucher] 817 Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 818 "Voucher and Voucher Revocation Profiles for Bootstrapping 819 Protocols", draft-ietf-anima-voucher-00 (work in 820 progress), January 2017. 822 [I-D.ietf-core-object-security] 823 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 824 "Object Security of CoAP (OSCOAP)", draft-ietf-core- 825 object-security-01 (work in progress), December 2016. 827 [I-D.selander-ace-cose-ecdhe] 828 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 829 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 830 cose-ecdhe-04 (work in progress), October 2016. 832 [ieee802.15.4] 833 Institute of Electrical and Electronics Engineers, , "IEEE 834 Standard 802.15.4-2006", 2006. 836 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 837 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 838 for Transport Layer Security (TLS)", RFC 4492, 839 DOI 10.17487/RFC4492, May 2006, 840 . 842 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 843 over Low-Power Wireless Personal Area Networks (6LoWPANs): 844 Overview, Assumptions, Problem Statement, and Goals", 845 RFC 4919, DOI 10.17487/RFC4919, August 2007, 846 . 848 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 849 "Transmission of IPv6 Packets over IEEE 802.15.4 850 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 851 . 853 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 854 (TLS) Protocol Version 1.2", RFC 5246, 855 DOI 10.17487/RFC5246, August 2008, 856 . 858 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 859 DOI 10.17487/RFC5958, August 2010, 860 . 862 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 863 Curve Cryptography Algorithms", RFC 6090, 864 DOI 10.17487/RFC6090, February 2011, 865 . 867 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 868 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 869 . 871 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 872 Protocol (HTTP/1.1): Message Syntax and Routing", 873 RFC 7230, DOI 10.17487/RFC7230, June 2014, 874 . 876 [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 877 CCM Elliptic Curve Cryptography (ECC) Cipher Suites for 878 TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, 879 . 881 [RFC7641] Hartke, K., "Observing Resources in the Constrained 882 Application Protocol (CoAP)", RFC 7641, 883 DOI 10.17487/RFC7641, September 2015, 884 . 886 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 887 Security (TLS) / Datagram Transport Layer Security (DTLS) 888 Profiles for the Internet of Things", RFC 7925, 889 DOI 10.17487/RFC7925, July 2016, 890 . 892 Appendix A. EST messages to EST-coaps 894 [EDNOTE: This section to be expanded to ensure it covers all BRSKI 895 edge conditions.] 897 A.1. cacerts 899 In EST, an HTTPS cacerts message can be 901 GET /.well-known/est/cacerts HTTP/1.1 902 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 903 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 904 Host: 192.0.2.1:8085 905 Accept: */* 907 The corresponding secure CoAP request is 909 GET coaps://[192.0.2.1:8085]/est/crts 911 with CoAP fields 913 Ver = 1 914 T = 0 (CON) 915 Code = 0x01 (0.01 is GET) 916 Options 917 Option1 (Uri-Host) 918 Option Delta = 0x3 (option nr = 3) 919 Option Length = 0x9 920 Option Value = 192.0.2.1 921 Option2 (Uri-Port) 922 Option Delta = 0x4 (option nr = 4+3=7) 923 Option Length = 0x4 924 Option Value = 8085 925 Option3 (Uri-Path) 926 Option Delta = 0x4 (option nr = 7+4= 11) 927 Option Length = 0x9 928 Option Value = /est/crts 929 Payload = [Empty] 931 A 200 OK response with a cert in EST will then be 932 200 OK 933 Status: 200 OK 934 Content-Type: application/pkcs7-mime 935 Content-Transfer-Encoding: base64 936 Content-Length: 4246 [EDNOTE: this example overflows and would 937 need fragmentation. Choose a better example. 938 Regardless we might need an CoAP option for 939 the content-length ie the CoAP payload?) 941 MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYCAQExADALBgkqhkiG9w0BBwGgggwMMIIC 942 +zCCAeOgAwIBAgIJAJpY3nUZO3qcMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMT 943 ... 945 The corresponding CoAP response is 947 2.05 Content (Content-Format: application/pkcs7-mime) 948 {payload} 950 with CoAP fields 952 Ver = 1 953 T = 2 (ACK) 954 Code = 0x45 (2.05 Content) 955 Options 956 Option1 (Content-Format) 957 Option Delta = 0xC (option nr = 12) 958 Option Length = 0x2 959 Option Value = TBD1 (defined in this note) 961 Payload = h'123456789ABCDEF...' 963 A.2. enroll / reenroll 965 [EDNOTE: username/password authentication can be described here but 966 is not a primary focus for BRSKI. It is important for generic EST 967 exchanges but would an endpoint device with sufficient user interface 968 to allow username/password input from an end user be required to use 969 CoAP instead of a full HTTPS exchange?] 971 [EDNOTE: We might need a new Option for the Retry-After response 972 message. We might need a new Option for the WWW-Authenticate 973 response.] 975 [EDNOTE: Include CoAP message examples. ] 977 A.3. csrattr 979 [EDNOTE: Include CoAP message examples. ] 981 A.4. enrollstatus 983 [EDNOTE: Include CoAP message examples. ] 985 A.5. voucher_status 987 [EDNOTE: Include CoAP message examples. ] 989 A.6. requestvoucher 991 [EDNOTE: Include CoAP message examples. ] 993 A.7. requestlog 995 [EDNOTE: Include CoAP message examples. ] 997 [EDNOTE: More examples can be added, for server-side key generation 998 in CMS envelopes. ] 1000 Appendix B. EST-coaps Block message examples 1002 This section provides a detailed example of the messages using DTLS 1003 and BLOCK option Block2. The minimum PMTU is 1280 bytes, which is 1004 the example value assumed for the DTLS datagram size. The example 1005 block length is taken as 64 which gives an SZX value of 2. 1007 The following is an example of a valid /cacerts exchange over DTLS. . 1008 The content length of the cacerts response in appendix A.1 of 1009 [RFC7030] is 4246 bytes using base64. This leads to a length of 3185 1010 bytes in binary. The CoAP message adds around 10 bytes, the DTLS 1011 record 29 bytes. To avoid IP fragmentation, the CoAP block option is 1012 used and an MTU of 127 is assumed to stay within one IEEE 802.15.4 1013 packet. To stay below the MTU of 127, the payload is split in 50 1014 packets with a payload of 64 bytes each. The client sends an IPv6 1015 packet containing the UDP datagram with the DTLS record that 1016 encapsulates the CoAP Request 50 times. The server returns an IPv6 1017 packet containing the UDP datagram with the DTLS record that 1018 encapsulates the CoAP response. The CoAP request-response exchange 1019 with block option is shown below. Block option is shown in a 1020 decomposed way indicating the kind of Block option (2 in this case 1021 because used in the response) followed by a colon, and then the block 1022 number (NUM), the more bit (M = 0 means last block), and block size 1023 exponent (2**(SZX+4)) separated by slashes. The Length 64 is used 1024 with SZX= 2 to avoid IP fragmentation. The CoAP Request is sent with 1025 confirmable (CON) option and the content format of the Response is 1026 /application/cacerts. 1028 GET [192.0.2.1:8085]/est/crts --> 1029 <-- (2:0/1/64) 2.05 Content 1030 GET URI (2:1/1/64) --> 1031 <-- (2:1/1/64) 2.05 Content 1032 | 1033 | 1034 | 1035 GET URI (2:49/1/64) --> 1036 <-- (2:49/0/64) 2.05 Content 1038 For further detailing the CoAP headers of the first two blocks are 1039 written out. 1041 The header of the first GET looks like: 1043 Ver = 1 1044 T = 0 (CON) 1045 Code = 0x01 (0.1 GET) 1046 Options 1047 Option1 (Uri-Host) 1048 Option Delta = 0x3 (option nr = 3) 1049 Option Length = 0x9 1050 Option Value = 192.0.2.1 1051 Option2 (Uri-Port) 1052 Option Delta = 0x4 (option nr = 3+4=7) 1053 Option Length = 0x4 1054 Option Value = 8085 1055 Option3 (Uri-Path) 1056 Option Delta = 0x4 (option nr = 7+4=11) 1057 Option Length = 0x9 1058 Option Value = /est/crts 1059 Payload = [Empty] 1061 The header of the first response looks like: 1063 [EDNOTE: The contents of the payload do not need to be written as 1064 they are encoded with DTLS into something unreadable.] 1065 Ver = 1 1066 T = 2 (ACK) 1067 Code = 0x45 (2.05 Content.) 1068 Options 1069 Option1 (Content-Format) 1070 Option Delta = 0xC (option 12) 1071 Option Length = 0x2 1072 Option Value = TBD1 1073 Option2 (Block2) 1074 Option Delta = 0xB (option 23 = 12 + 11) 1075 Option Length = 0x1 1076 Option Value = 0x0A (block number = 0, M=1, SZX=2) 1077 Payload = h'123456789ABCDEF...' (512 bytes) 1079 The second Block2: 1081 Ver = 1 1082 T = 2 (means ACK) 1083 Code = 0x45 (2.05 Content.) 1084 Options 1085 Option1 (Content-Format) 1086 Option Delta = 0xC (option 12) 1087 Option Length = 0x2 1088 Option Value = TBD1 1089 Option2 (Block2) 1090 Option Delta = 0xB (option 23 = 12 + 11) 1091 Option Length = 0x1 1092 Option Value = 0x1D (block number = 1, M=1, SZX=2) 1093 Payload = = h'123456789ABCDEF...' (512 bytes) 1095 The 49th and final Block2: 1097 Ver = 1 1098 T = 2 (means ACK) 1099 Code = 0x21 1100 Options 1101 Option1 (Content-Format) 1102 Option Delta = 0xC (option 12) 1103 Option Length = 0x2 1104 Option Value = TBD1 1105 Option2 (Block2) 1106 Option Delta = 0xB (option 23 = 12 + 11) 1107 Option Length = 0x2 1108 Option Value = 0x312 (block number = 49, M=0, SZX=2) 1109 Payload = = h'123456789ABCDEF...' (512 bytes) 1111 Authors' Addresses 1113 Sandeep S. Kumar 1114 Philips Lighting Research 1115 High Tech Campus 7 1116 Eindhoven 5656 AE 1117 NL 1119 Email: ietf@sandeep.de 1121 Peter van der Stok 1122 Consultant 1124 Email: consultancy@vanderstok.org 1126 Panos Kampanakis 1127 Cisco Systems 1129 Email: pkampana@cisco.com 1131 Martin Furuhed 1132 Nexus Group 1134 Email: martin.furuhed@nexusgroup.com 1136 Shahid Raza 1137 RISE SICS 1138 Isafjordsgatan 22 1139 Kista, Stockholm 16440 1140 SE 1142 Email: shahid@sics.se