idnits 2.17.1 draft-vanderstok-anima-constrained-join-proxy-03.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 14, 2020) is 1496 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) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-38 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-07 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 anima Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Standards Track P. van der Stok 5 Expires: September 15, 2020 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 March 14, 2020 10 Constrained Join Proxy for Bootstrapping Protocols 11 draft-vanderstok-anima-constrained-join-proxy-03 13 Abstract 15 This document defines a protocol to securely assign a pledge to an 16 owner, using an intermediary node between pledge and owner. This 17 intermediary node is known as a "constrained Join Proxy". 19 This document extends the work of [ietf-anima-bootstrapping-keyinfra] 20 by replacing the Circuit-proxy by a stateless constrained Join Proxy, 21 that transports routing information. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 15, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 60 4. Join Proxy functionality . . . . . . . . . . . . . . . . . . 4 61 5. Join Proxy specification . . . . . . . . . . . . . . . . . . 4 62 5.1. Statefull Join Proxy . . . . . . . . . . . . . . . . . . 5 63 5.2. Stateless Join Proxy . . . . . . . . . . . . . . . . . . 6 64 5.3. Stateless Message structure . . . . . . . . . . . . . . . 7 65 6. Comparison of stateless and statefull modes . . . . . . . . . 8 66 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 7.1. Join Proxy discovers EST server . . . . . . . . . . . . . 9 68 7.1.1. Coap discovery . . . . . . . . . . . . . . . . . . . 9 69 7.1.2. Autonomous Network . . . . . . . . . . . . . . . . . 10 70 7.1.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 10 71 7.2. Pledge discovers Join Proxy . . . . . . . . . . . . . . . 10 72 7.2.1. Autonomous Network . . . . . . . . . . . . . . . . . 10 73 7.2.2. Coap discovery . . . . . . . . . . . . . . . . . . . 10 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 9.1. Resource Type registry . . . . . . . . . . . . . . . . . 11 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 78 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 79 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 12.1. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 12 81 12.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 12 82 12.3. 00 to 00 . . . . . . . . . . . . . . . . . . . . . . . . 12 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 13.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 13.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Appendix A. Stateless Proxy payload examples . . . . . . . . . . 14 87 A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 A.2. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 17 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 Enrolment of new nodes into constrained networks with constrained 94 nodes present is described in [I-D.ietf-anima-bootstrapping-keyinfra] 95 and makes use of Enrolment over Secure Transport (EST) [RFC7030]. 96 The specified solutions use https and may be too large in terms of 97 code space or bandwidth required. Constrained devices in constrained 98 networks [RFC7228] typically implement the IPv6 over Low-Power 99 Wireless personal Area Networks (6LoWPAN) [RFC4944] and Constrained 100 Application Protocol (CoAP) [RFC7252]. 102 CoAP has chosen Datagram Transport Layer Security (DTLS) [RFC6347] as 103 the preferred security protocol for authenticity and confidentiality 104 of the messages. A constrained version of EST, using Coap and DTLS, 105 is described in [I-D.ietf-ace-coap-est]. 107 DTLS is a client-server protocol relying on the underlying IP layer 108 to perform the routing between the DTLS Client and the DTLS Server. 109 However, the new "joining" device will not be IP routable until it is 110 authenticated to the network. A new "joining" device can only 111 initially use a link-local IPv6 address to communicate with a 112 neighbour node using neighbour discovery [RFC6775] until it receives 113 the necessary network configuration parameters. However, before the 114 device can receive these configuration parameters, it needs to 115 authenticate itself to the network to which it connects. In 116 [I-D.ietf-anima-bootstrapping-keyinfra] Enrolment over Secure 117 Transport (EST) [RFC7030] is used to authenticate the joining device. 118 However, IPv6 routing is necessary to establish a connection between 119 joining device and the EST server. 121 This document specifies a Join Proxy and protocol to act as 122 intermediary between joining device and EST server to establish a 123 connection between joining device and EST server. 125 This document is very much inspired by text published earlier in 126 [I-D.kumar-dice-dtls-relay]. 128 2. Terminology 130 The following terms are defined in [RFC8366], and are used 131 identically as in that document: artifact, imprint, domain, Join 132 Registrar/Coordinator (JRC), Manufacturer Authorized Signing 133 Authority (MASA), pledge, Trust of First Use (TOFU), and Voucher. 135 3. Requirements Language 137 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 138 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 139 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 140 [RFC2119] and indicate requirement levels for compliant STuPiD 141 implementations. 143 4. Join Proxy functionality 145 As depicted in the Figure 1, the joining Device, or pledge (P), is 146 more than one hop away from the EST server (E) and not yet 147 authenticated into the network. At this stage, it can only 148 communicate one-hop to its nearest neighbour, the Join Proxy (J) 149 using their link-local IPv6 addresses. However, the Pledge (P) needs 150 to communicate with end-to-end security with a Registrar hosting the 151 EST server (E) to authenticate and get the relevant system/network 152 parameters. If the Pledge (P) initiates a DTLS connection to the EST 153 server whose IP address has been pre-configured, then the packets are 154 dropped at the Join Proxy (J) since the Pledge (P) is not yet 155 admitted to the network or there is no IP routability to Pledge (P) 156 for any returned messages. 158 ++++ 159 |E |---- +--+ +--+ 160 | | \ |J |........|P | 161 ++++ \-----| | | | 162 EST server +--+ +--+ 163 REgistrar Join Proxy Pledge 164 "Joining" Device 166 Figure 1: multi-hop enrolment. 168 Furthermore, the Pledge (P) may wish to establish a secure connection 169 to the EST server (E) in the network assuming appropriate credentials 170 are exchanged out-of-band, e.g. a hash of the Pledge (P)'s raw public 171 key could be provided to the EST server (E). However, the Pledge (P) 172 may be unaware of the IP address of the EST-server (E) to initiate a 173 DTLS connection and perform authentication with. 175 A DTLS connection is required between Pledge and EST server. To 176 overcome the problems with non-routability of DTLS packets and/ or 177 discovery of the destination address of the EST Server to contact, 178 the Join Proxy is introduced. This Join Proxy functionality is 179 configured into all authenticated devices in the network which may 180 act as the Join Proxy for newly joining nodes. The Join Proxy allows 181 for routing of the packets from the Pledge using IP routing to the 182 intended EST Server. 184 5. Join Proxy specification 186 The Join Proxy can operate in two modes: 188 o Statefull mode 189 o Stateless mode 191 5.1. Statefull Join Proxy 193 In stateful mode, the joining node forwards the DTLS messages to the 194 EST Server. 196 Assume that the Pledge does not know the IP address of the EST Server 197 it needs to contact. In that situation, the Join Proxy knows the 198 (cofigured or discovered) IP address of a EST Server that the Pledge 199 needs to contact. The Pledge initiates its request as if the Join 200 Proxy is the intended EST Server. The Join Proxy changes the IP 201 packet (without modifying the DTLS message) as in the previous case 202 by modifying both the source and destination addresses to forward the 203 message to the intended EST Server. The Join Proxy maintains a 204 4-tuple array to translate the DTLS messages received from the EST 205 Server and forward it to the EST Client. In Figure 2 the various 206 steps of the message flow are shown: 208 +------------+------------+-------------+--------------------------+ 209 | EST Client | Join Proxy | EST Server | Message | 210 | (P) | (J) | (E) | Src_IP:port | Dst_IP:port| 211 +------------+------------+-------------+-------------+------------+ 212 | --ClientHello--> | IP_P:p_P | IP_Ja:5684 | 213 | --ClientHello--> | IP_Jb:p_Jb| IP_E:5684 | 214 | | | | 215 | <--ServerHello-- | IP_E:5684 | IP_Jb:p_Jb | 216 | : | | | 217 | <--ServerHello-- : | IP_Ja:5684| IP_P:p_P | 218 | : : | | | 219 | : : | : | : | 220 | : : | : | : | 221 | --Finished--> : | IP_P:p_P | IP_Ja:5684 | 222 | --Finished--> | IP_Jb:p_Jb| IP_E:5684 | 223 | | | | 224 | <--Finished-- | IP_E:5684 | IP_Jb:p_Jb | 225 | <--Finished-- | IP_Ja:5684| IP_P:p_P | 226 | : : | : | : | 227 +---------------------------------------+-------------+------------+ 228 IP_P:p_P = Link-local IP address and port of Pledge (DTLS Client) 229 IP_E:5684 = Global IP address and coaps port of EST Server 230 IP_Ja:5684 = Link-local IP address and coaps port of Join Proxy 231 IP_Jb:p_Rb = Global IP address and port of Join proxy 233 Figure 2: constrained statefull joining message flow with EST server 234 address known to Join Proxy. 236 5.2. Stateless Join Proxy 238 The Join Proxy is stateless to minimize the requirements on the 239 constrained Join Proxy device. 241 When a joining device as a client attempts a DTLS connection to the 242 EST server, it uses its link-local IP address as its IP source 243 address. This message is transmitted one-hop to a neighbour node. 244 Under normal circumstances, this message would be dropped at the 245 neighbour node since the joining device is not yet IP routable or it 246 is not yet authenticated to send messages through the network. 247 However, if the neighbour device has the Join Proxy functionality 248 enabled, it routes the DTLS message to a specific EST Server. 249 Additional security mechanisms need to exist to prevent this routing 250 functionality being used by rogue nodes to bypass any network 251 authentication procedures. 253 If an untrusted DTLS Client that can only use link-local addressing 254 wants to contact a trusted end-point EST Server, it sends the DTLS 255 message to the Join Proxy. The Join Proxy extends this message into 256 a new type of message called Join ProxY (JPY) message and sends it on 257 to the EST server. The JPY message payload consists of two parts: 259 o Header (H) field: consisting of the source link-local address and 260 port of the Pledge (P), and 262 o Contents (C) field: containing the original DTLS message. 264 On receiving the JPY message, the EST Server retrieves the two parts. 265 The EST Server transiently stores the Header field information. The 266 EST server uses the Contents field to execute the EST server 267 functionality. However, when the EST Server replies, it also extends 268 its DTLS message with the header field in a JPY message and sends it 269 back to the Join Proxy. The Header contains the original source 270 link-local address and port of the DTLS Client from the transient 271 state stored earlier (which can now be discarded) and the Contents 272 field contains the DTLS message. 274 On receiving the JPY message, the Join Proxy retrieves the two parts. 275 It uses the Header field to route the DTLS message retrieved from the 276 Contents field to the Pledge. 278 The Figure 3 depicts the message flow diagram: 280 +--------------+------------+---------------+-----------------------+ 281 | EST Client | Join Proxy | EST server | Message | 282 | (P) | (J) | (E) |Src_IP:port|Dst_IP:port| 283 +--------------+------------+---------------+-----------+-----------+ 284 | --ClientHello--> | IP_P:p_P |IP_Ja:5684 | 285 | --JPY[H(IP_P:p_P),--> | IP_Jb:p_Jb|IP_E:5684 | 286 | C(ClientHello)] | | | 287 | <--JPY[H(IP_P:p_P),-- | IP_E:5684 |IP_Jb:p_Jb | 288 | C(ServerHello)] | | | 289 | <--ServerHello-- | IP_Ja:5684|IP_P:p_P | 290 | : | | | 291 | : | : | : | 292 | | : | : | 293 | --Finished--> | IP_P:p_P |IP_Ja:5684 | 294 | --JPY[H(IP_P:p_P),--> | IP_Jb:p_Jb|IP_E:5684 | 295 | C(Finished)] | | | 296 | <--JPY[H(IP_P:p_P),-- | IP_E:5684 |IP_Jb:p_Jb | 297 | C(Finished)] | | | 298 | <--Finished-- | IP_Ja:5684|IP_P:p_P | 299 | : | : | : | 300 +-------------------------------------------+-----------+-----------+ 301 IP_P:p_P = Link-local IP address and port of the Pledge 302 IP_E:5684 = Global IP address and coaps port of EST Server 303 IP_Ja:5684 = Link-local IP address and coaps port of Join Proxy 304 IP_Jb:p_Jb = Global IP address and port of Join Proxy 306 JPY[H(),C()] = Join Proxy message with header H and content C 308 Figure 3: constrained stateless joining message flow. 310 5.3. Stateless Message structure 312 The JPY message is constructed as a payload with media-type 313 application/multipart-core specified in [I-D.ietf-core-multipart-ct]. 314 Header and Contents fields use different media formats: 316 1. header field: application/CBOR containing a CBOR array [RFC7049] 317 with the pledge IPv6 Link Local address as a 16-byte binary 318 value, the pledge's UDP port number, if different from 5684, as a 319 CBOR integer, and the proxy's ifindex or other identifier for the 320 physical port on which the pledge is connected. Header is not 321 DTLS encrypted. 323 2. Content field: Any of the media types specified in 324 [I-D.ietf-ace-coap-est] and [I-D.ietf-anima-constrained-voucher] 325 dependent on the function that is requested: 327 * application/pkcs7-mime; smime-type=server-generated-key 328 * application/pkcs7-mime; smime-type=certs-only 329 * application/voucher-cms+cbor 330 * application/voucher-cose+cbor 331 * application/pkcs8 332 * application/csrattrs 333 * application/pkcs10 334 * application/pkix-cert 336 The content fields are DTLS encrypted. In CBOR diagnostic notation 337 the payload JPY[H(IP_P:p_P), with cf is content-format of DTLS- 338 content, will look like: 340 [ 60: [IP_p, p_P, ident] 341 cf: h'DTLS-content'] 343 Examples are shown in Appendix A. 345 6. Comparison of stateless and statefull modes 347 The stateful and stateless mode of operation for the Join Proxy have 348 their advantages and disadvantages. This section should enable to 349 make a choice between the two modes based on the available device 350 resources and network bandwidth. 352 +-------------+----------------------------+------------------------+ 353 | Properties | Stateful mode | Stateless mode | 354 +-------------+----------------------------+------------------------+ 355 | State |The Join Proxy needs | No information is | 356 | Information |additional storage to | maintained by the Join | 357 | |maintain mapping between | Proxy | 358 | |the address and port number | | 359 | |of the pledge and those | | 360 | |of the EST-server. | | 361 +-------------+----------------------------+------------------------+ 362 |Packet size |The size of the forwarded |Size of the forwarded | 363 | |message is the same as the |message is bigger than | 364 | |original message. |the original,it includes| 365 | | |additional source and | 366 | | |destination addresses. | 367 +-------------+----------------------------+------------------------+ 368 |Specification|The Join Proxy needs |New JPY message to | 369 |complexity |additional functionality |encapsulate DTLS message| 370 | |to maintain state |The EST server | 371 | |information, and modify |and the Join Proxy | 372 | |the source and destination |have to understand the | 373 | |addresses of the DTLS |JPY message in order | 374 | |handshake messages |to process it. | 375 +-------------+----------------------------+------------------------+ 377 Figure 4: Comparison between stateful and stateless mode 379 7. Discovery 381 It is assumed that Join Proxy seamlessly provides a coaps connection 382 between Pledge and coaps EST-server. An additional Registrar is 383 needed to connect the Pledge to an http EST server, see section 8 of 384 [I-D.ietf-ace-coap-est]. In particular this section replaces section 385 4.2 of [I-D.ietf-anima-bootstrapping-keyinfra]. 387 Three discovery cases are discussed: coap discovery, 6tisch discovery 388 and GRASP discovery. 390 7.1. Join Proxy discovers EST server 392 7.1.1. Coap discovery 394 The discovery of the coaps EST server, using coap discovery, by the 395 Join Proxy follows section 6 of [I-D.ietf-ace-coap-est]. 397 7.1.2. Autonomous Network 399 In the context of autonomous networks, the Join Proxy uses the DULL 400 GRASP M_FLOOD mechanism to announce itself. Section 4.1.1 of 401 [I-D.ietf-anima-bootstrapping-keyinfra] discusses this in more 402 detail. The EST-server announces itself using ACP instance of GRASP 403 using M_FLOOD messages. Autonomous Network Join Proxies MUST support 404 GRASP discovery of EST-server as decribed in section 4.3 of 405 [I-D.ietf-anima-bootstrapping-keyinfra] . 407 7.1.3. 6tisch discovery 409 The discovery of EST server by the pledge uses the enhanced beacons 410 as discussed in [I-D.ietf-6tisch-enrollment-enhanced-beacon]. 412 7.2. Pledge discovers Join Proxy 414 The pledge and Join Proxy are assumed to communicate via Link-Local 415 addresses. 417 7.2.1. Autonomous Network 419 The pledge MUST listen for GRASP M_FLOOD [I-D.ietf-anima-grasp] 420 announcements of the objective: "AN_Proxy". See section 421 Section 4.1.1 [I-D.ietf-anima-bootstrapping-keyinfra] for the details 422 of the objective. 424 7.2.2. Coap discovery 426 In the context of a coap network without Autonomous Network support, 427 discovery follows the standard coap policy. The Pledge can discover 428 a Join Proxy by sending a link-local multicast message to ALL CoAP 429 Nodes with address FF02::FD. Multiple or no nodes may respond. The 430 handling of multiple responses and the absence of responses follow 431 section 4 of [I-D.ietf-anima-bootstrapping-keyinfra]. 433 The presence and location of (path to) the Join Proxy resource are 434 discovered by sending a GET request to "/.well-known/core" including 435 a resource type (rt) parameter with the value "brski-proxy" 436 [RFC6690]. Upon success, the return payload will contain the root 437 resource of the Join Proxy resources. It is up to the implementation 438 to choose its root resource; throughout this document the example 439 root resource /jp is used. The example below shows the discovery of 440 the presence and location of Join Proxy resources. 442 REQ: GET coap://[FF02::FD]/.well-known/core?rt=brski-proxy 444 RES: 2.05 Content 445 ; rt="brski-proxy";ct=62 447 Port numbers, not returned in the example, are assumed to be the 448 default numbers 5683 and 5684 for coap and coaps respectively 449 (sections 12.6 and 12.7 of [RFC7252]. Discoverable port numbers MAY 450 be returned in the of the payload (see section 5.1 of 451 [I-D.ietf-ace-coap-est]). 453 8. Security Considerations 455 It should be noted here that the contents of the CBOR map are not 456 protected, but that the communication is between the Proxy and a 457 known registrar (a connected UDP socket), and that messages from 458 other origins are ignored. 460 9. IANA Considerations 462 This document needs to create a registry for key indices in the CBOR 463 map. It should be given a name, and the amending formula should be 464 IETF Specification. 466 9.1. Resource Type registry 468 This specification registers a new Resource Type (rt=) Link Target 469 Attributes in the "Resource Type (rt=) Link Target Attribute Values" 470 subregistry under the "Constrained RESTful Environments (CoRE) 471 Parameters" registry. 473 rt="brski-proxy". This EST resource is used to query and return 474 the supported EST resource of a Join Proxy placed between Pledge 475 and EST server. 477 10. Acknowledgements 479 Many thanks for the comments by Brian Carpenter. 481 11. Contributors 483 Sandeep Kumar, Sye loong Keoh, and Oscar Garcia-Morchon are the co- 484 authors of the draft-kumar-dice-dtls-relay-02. Their draft has 485 served as a basis for this document. Much text from their draft is 486 copied over to this draft. 488 12. Changelog 490 12.1. 01 to 02 492 o extended the discovery section 494 o removed inconsistencies from the the flow diagrams 496 o Improved readability of the examples. 498 o stateful configurations reduced to one 500 12.2. 00 to 01 502 o Added Contributors section 504 o Adapted content-formats to est-coaps formats 506 o Aligned examples with est-coaps examples 508 o Added statefull Proxy to stateless proxy 510 12.3. 00 to 00 512 o added payload examples in appendix 514 o discovery for three cases: AN, 6tisch and coaps 516 13. References 518 13.1. Normative References 520 [I-D.ietf-6tisch-enrollment-enhanced-beacon] 521 Dujovne, D. and M. Richardson, "IEEE 802.15.4 Information 522 Element encapsulation of 6TiSCH Join and Enrollment 523 Information", draft-ietf-6tisch-enrollment-enhanced- 524 beacon-14 (work in progress), February 2020. 526 [I-D.ietf-ace-coap-est] 527 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 528 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 529 est-18 (work in progress), January 2020. 531 [I-D.ietf-anima-bootstrapping-keyinfra] 532 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 533 and K. Watsen, "Bootstrapping Remote Secure Key 534 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 535 keyinfra-38 (work in progress), March 2020. 537 [I-D.ietf-anima-constrained-voucher] 538 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 539 Voucher Artifacts for Bootstrapping Protocols", draft- 540 ietf-anima-constrained-voucher-07 (work in progress), 541 January 2020. 543 [I-D.ietf-anima-grasp] 544 Bormann, C., Carpenter, B., and B. Liu, "A Generic 545 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 546 grasp-15 (work in progress), July 2017. 548 [I-D.ietf-core-multipart-ct] 549 Fossati, T., Hartke, K., and C. Bormann, "Multipart 550 Content-Format for CoAP", draft-ietf-core-multipart-ct-04 551 (work in progress), August 2019. 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, 555 DOI 10.17487/RFC2119, March 1997, 556 . 558 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 559 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 560 January 2012, . 562 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 563 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 564 October 2013, . 566 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 567 "A Voucher Artifact for Bootstrapping Protocols", 568 RFC 8366, DOI 10.17487/RFC8366, May 2018, 569 . 571 13.2. Informative References 573 [duckling] 574 Stajano, F. and R. Anderson, "The resurrecting duckling: 575 security issues for ad-hoc wireless networks", 1999, 576 . 579 [I-D.kumar-dice-dtls-relay] 580 Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay 581 for Constrained Environments", draft-kumar-dice-dtls- 582 relay-02 (work in progress), October 2014. 584 [pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015, 585 . 587 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 588 "Transmission of IPv6 Packets over IEEE 802.15.4 589 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 590 . 592 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 593 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 594 . 596 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 597 Bormann, "Neighbor Discovery Optimization for IPv6 over 598 Low-Power Wireless Personal Area Networks (6LoWPANs)", 599 RFC 6775, DOI 10.17487/RFC6775, November 2012, 600 . 602 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 603 "Enrollment over Secure Transport", RFC 7030, 604 DOI 10.17487/RFC7030, October 2013, 605 . 607 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 608 Constrained-Node Networks", RFC 7228, 609 DOI 10.17487/RFC7228, May 2014, 610 . 612 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 613 Application Protocol (CoAP)", RFC 7252, 614 DOI 10.17487/RFC7252, June 2014, 615 . 617 Appendix A. Stateless Proxy payload examples 619 Examples are extensions of two examples shown in 620 [I-D.ietf-ace-coap-est]. The following content formats are used: 622 o 60: application/cbor 624 o 62: application/multipart 626 o 281: application/pkcs7-mime; smime-type=certs-only 628 o 284: application/pkcs8 630 o 286: application/pkcs10 631 For presentation purposes the payloads are abbreviated as follows: 633 cacrts request payload: 635 = 637 cacrts response payload: 639 = 640 DTLS_encrypt( 641 3082027b06092a864886f70d010702a082026c308202680201013100300b 642 06092a864886f70d010701a082024e3082024a308201f0a0030201020209 643 009189bcdf9c99244b300a06082a8648ce3d0403023067310b3009060355 644 040613025553310b300906035504080c024341310b300906035504070c02 645 4c4131143012060355040a0c0b4578616d706c6520496e63311630140603 646 55040b0c0d63657274696669636174696f6e3110300e06035504030c0752 647 6f6f74204341301e170d3139303130373130343034315a170d3339303130 648 323130343034315a3067310b3009060355040613025553310b3009060355 649 04080c024341310b300906035504070c024c4131143012060355040a0c0b 650 4578616d706c6520496e6331163014060355040b0c0d6365727469666963 651 6174696f6e3110300e06035504030c07526f6f742043413059301306072a 652 8648ce3d020106082a8648ce3d03010703420004814994082b6e8185f3df 653 53f5e0bee698973335200023ddf78cd17a443ffd8ddd40908769c55652ac 654 2ccb75c4a50a7c7ddb7c22dae6c85cca538209fdbbf104c9a38184308181 655 301d0603551d0e041604142495e816ef6ffcaaf356ce4adffe33cf492abb 656 a8301f0603551d230418301680142495e816ef6ffcaaf356ce4adffe33cf 657 492abba8300f0603551d130101ff040530030101ff300e0603551d0f0101 658 ff040403020106301e0603551d1104173015811363657274696679406578 659 616d706c652e636f6d300a06082a8648ce3d0403020348003045022100da 660 e37c96f154c32ec0b4af52d46f3b7ecc9687ddf267bcec368f7b7f135327 661 2f022047a28ae5c7306163b3c3834bab3c103f743070594c089aaa0ac870 662 cd13b902caa1003100 663 ) 665 serverkeygen request payload: 667 = 668 DTLS_encrypt( 669 3081cf3078020100301631143012060355040a0c0b736b67206578616d70 670 6c653059301306072a8648ce3d020106082a8648ce3d030107034200041b 671 b8c1117896f98e4506c03d70efbe820d8e38ea97e9d65d52c8460c5852c5 672 1dd89a61370a2843760fc859799d78cd33f3c1846e304f1717f8123f1a28 673 4cc99fa000300a06082a8648ce3d04030203470030440220387cd4e9cf62 674 8d4af77f92ebed4890d9d141dca86cd2757dd14cbd59cdf6961802202f24 675 5e828c77754378b66660a4977f113cacdaa0cc7bad7d1474a7fd155d090d 676 ) 678 serverkeygen response payload: 680 = 681 DTLS_encrypt( 682 84 # array(4) 683 19 011C # unsigned(284) 684 58 8A # bytes(138) 685 308187020100301306072a8648ce3d020106082a8648ce3d030107046d30 686 6b02010104200b9a67785b65e07360b6d28cfc1d3f3925c0755799deeca7 687 45372b01697bd8a6a144034200041bb8c1117896f98e4506c03d70efbe82 688 0d8e38ea97e9d65d52c8460c5852c51dd89a61370a2843760fc859799d78 689 cd33f3c1846e304f1717f8123f1a284cc99f 690 19 0119 # unsigned(281) 691 59 01D3 # bytes(467) 692 308201cf06092a864886f70d010702a08201c0308201bc0201013100300b 693 06092a864886f70d010701a08201a23082019e30820143a0030201020208 694 126de8571518524b300a06082a8648ce3d04030230163114301206035504 695 0a0c0b736b67206578616d706c65301e170d313930313039303835373038 696 5a170d3339303130343038353730385a301631143012060355040a0c0b73 697 6b67206578616d706c653059301306072a8648ce3d020106082a8648ce3d 698 030107034200041bb8c1117896f98e4506c03d70efbe820d8e38ea97e9d6 699 5d52c8460c5852c51dd89a61370a2843760fc859799d78cd33f3c1846e30 700 4f1717f8123f1a284cc99fa37b307930090603551d1304023000302c0609 701 6086480186f842010d041f161d4f70656e53534c2047656e657261746564 702 204365727469666963617465301d0603551d0e04160414494be598dc8dbc 703 0dbc071c486b777460e5cce621301f0603551d23041830168014494be598 704 dc8dbc0dbc071c486b777460e5cce621300a06082a8648ce3d0403020349 705 003046022100a4b167d0f9add9202810e6bf6a290b8cfdfc9b9c9fea2cc1 706 c8fc3a464f79f2c202210081d31ba142751a7b4a34fd1a01fcfb08716b9e 707 b53bdaadc9ae60b08f52429c0fa1003100 708 ) 710 A.1. cacerts 712 The request from Join Proxy to EST-server looks like: 714 Get coaps://192.0.2.1/est/crts 715 (Accept: 62) 716 (Content-format: 62) 717 payload = 718 82 # array(2) 719 18 3C # unsigned(60) 720 83 # array(3) 721 69 # text(9) 722 464538303A3A414238 # "FE80::AB8" 723 19 237D # unsigned(9085) 724 65 # text(5) 725 6964656E74 # "ident" 727 In CBOR Diagnostic: 729 payload = [60, ["FE80::AB8", 9085, "ident"]] 731 The response will then be: 733 2.05 Content 734 (Content-format: 62) 735 Payload = 736 84 # array(4) 737 18 3C # unsigned(60) 738 83 # array(3) 739 69 # text(9) 740 464538303A3A414238 # "FE80::AB8" 741 19 237D # unsigned(9085) 742 65 # text(5) 743 6964656E74 # "ident" 744 19 0119 # unsigned(281) 745 59 027F # bytes(639) 746 747 ] 749 In CBOR diagnostic: 751 payload = [60, ["FE80::AB8", 9085, "ident"], 752 62, h''] 754 A.2. serverkeygen 756 The request from Join Proxy to EST-server looks like: 758 Get coaps://192.0.2.1/est/skg 759 (Accept: 62) 760 (Content-Format: 62) 761 Payload = 762 83 # array(4) 763 18 3C # unsigned(60) 764 83 # array(3) 765 69 # text(9) 766 464538303A3A414238 # "FE80::AB8" 767 19 237D # unsigned(9085) 768 65 # text(5) 769 6964656E74 # "ident" 770 19 011E # unsigned(286) 771 58 D2 # bytes(210) 772 774 In CBOR diagnostic: 776 payload = [60, ["FE80::AB8", 9085, "ident"], 777 286, h''] 779 The response will then be: 781 2.05 Content 782 (Content-format: 62) 783 Payload = 784 83 # array(4) 785 18 3C # unsigned(60) 786 83 # array(3) 787 69 # text(9) 788 464538303A3A414238 # "FE80::AB8" 789 19 237D # unsigned(9085) 790 65 # text(5) 791 6964656E74 # "ident" 792 19 011E # unsigned(286) 793 59 0269 # bytes(617) 794 796 In CBOR diagnostic: 798 payload = [60, ["FE80::AB8", 9085, "ident"], 799 286, h''] 801 Authors' Addresses 803 Michael Richardson 804 Sandelman Software Works 806 Email: mcr+ietf@sandelman.ca 808 Peter van der Stok 809 vanderstok consultancy 811 Email: consultancy@vanderstok.org 813 Panos Kampanakis 814 Cisco Systems 816 Email: pkampana@cisco.com