idnits 2.17.1 draft-ietf-anima-constrained-join-proxy-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-anima-bootstrapping-keyinfra]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 December 2020) is 1235 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) == Unused Reference: 'I-D.ietf-anima-constrained-voucher' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-multipart-ct' is defined on line 610, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-09 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) Summary: 3 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: 5 June 2021 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 2 December 2020 10 Constrained Join Proxy for Bootstrapping Protocols 11 draft-ietf-anima-constrained-join-proxy-01 13 Abstract 15 This document defines a protocol to securely assign a pledge to a 16 domain, represented by a Registrar, using an intermediary node 17 between pledge and Registrar. This intermediary node is known as a 18 "constrained Join Proxy". 20 This document extends the work of 21 [I-D.ietf-anima-bootstrapping-keyinfra] by replacing the Circuit- 22 proxy by a stateless/stateful constrained (CoAP) Join Proxy. It 23 transports join traffic from the pledge to the Registrar without 24 requiring per-client state. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 5 June 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 62 4. Join Proxy functionality . . . . . . . . . . . . . . . . . . 4 63 5. Join Proxy specification . . . . . . . . . . . . . . . . . . 5 64 5.1. Statefull Join Proxy . . . . . . . . . . . . . . . . . . 5 65 5.2. Stateless Join Proxy . . . . . . . . . . . . . . . . . . 6 66 5.3. Stateless Message structure . . . . . . . . . . . . . . . 8 67 6. Comparison of stateless and statefull modes . . . . . . . . . 9 68 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.1. Pledge discovery of Registrar . . . . . . . . . . . . . . 11 70 7.1.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 11 71 7.1.2. Autonomous Network . . . . . . . . . . . . . . . . . 11 72 7.1.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 11 73 7.2. Pledge discovers Join Proxy . . . . . . . . . . . . . . . 11 74 7.2.1. Autonomous Network . . . . . . . . . . . . . . . . . 11 75 7.2.2. CoAP discovery . . . . . . . . . . . . . . . . . . . 12 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 78 9.1. Resource Type registry . . . . . . . . . . . . . . . . . 13 79 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 80 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 81 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 12.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 13 83 12.2. 00 to 00 . . . . . . . . . . . . . . . . . . . . . . . . 14 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 13.1. Normative References . . . . . . . . . . . . . . . . . . 14 86 13.2. Informative References . . . . . . . . . . . . . . . . . 15 87 Appendix A. Stateless Proxy payload examples . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 90 1. Introduction 92 Enrolment of new nodes into networks with enrolled nodes present is 93 described in [I-D.ietf-anima-bootstrapping-keyinfra] ("BRSKI") and 94 makes use of Enrolment over Secure Transport (EST) [RFC7030] with 95 [RFC8366] vouchers to securely enroll devices. BRSKI connects new 96 devices ("pledges") to "Registrars" via a Join Proxy. 98 The specified solutions use https and may be too large in terms of 99 code space or bandwidth required for constrained devices. 100 Constrained devices possibly part of constrained networks [RFC7228] 101 typically implement the IPv6 over Low-Power Wireless personal Area 102 Networks (6LoWPAN) [RFC4944] and Constrained Application Protocol 103 (CoAP) [RFC7252]. 105 CoAP can be run with the Datagram Transport Layer Security (DTLS) 106 [RFC6347] as a security protocol for authenticity and confidentiality 107 of the messages. This is known as the "coaps" scheme. A constrained 108 version of EST, using Coap and DTLS, is described in 109 [I-D.ietf-ace-coap-est]. The {I-D.ietf-anima-constrained-voucher} 110 describes the BRSKI extensions to the Registrar. 112 DTLS is a client-server protocol relying on the underlying IP layer 113 to perform the routing between the DTLS Client and the DTLS Server. 114 However, the new "joining" device will not be IP routable until it is 115 authenticated to the network. A new "joining" device can only 116 initially use a link-local IPv6 address to communicate with a 117 neighbour node using neighbour discovery [RFC6775] until it receives 118 the necessary network configuration parameters. However, before the 119 device can receive these configuration parameters, it needs to 120 authenticate itself to the network to which it connects. IPv6 121 routing is necessary to establish a connection between joining device 122 and the Registrar. 124 A DTLS connection is required between Pledge and Registrar. 126 This document specifies a new form of Join Proxy and protocol to act 127 as intermediary between joining device and Registrar to establish a 128 connection between joining device and Registrar. 130 This document is very much inspired by text published earlier in 131 [I-D.kumar-dice-dtls-relay]. 132 [I-D.richardson-anima-state-for-joinrouter] outlined the various 133 options for building a join proxy. 134 [I-D.ietf-anima-bootstrapping-keyinfra] adopted only the Circuit 135 Proxy method (1), leaving the other methods as future work. This 136 document standardizes the CoAP/DTLS (method 4). 138 2. Terminology 140 The following terms are defined in [RFC8366], and are used 141 identically as in that document: artifact, imprint, domain, Join 142 Registrar/Coordinator (JRC), Manufacturer Authorized Signing 143 Authority (MASA), pledge, Trust of First Use (TOFU), and Voucher. 145 3. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in 150 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 4. Join Proxy functionality 155 As depicted in the Figure 1, the joining Device, or pledge (P), in an 156 LLN mesh can be more than one hop away from the Registrar (R) and not 157 yet authenticated into the network. 159 In this situation, it can only communicate one-hop to its nearest 160 neighbour, the Join Proxy (J) using their link-local IPv6 addresses. 161 However, the Pledge (P) needs to communicate with end-to-end security 162 with a Registrar hosting the Registrar (R) to authenticate and get 163 the relevant system/network parameters. If the Pledge (P) initiates 164 a DTLS connection to the Registrar whose IP address has been pre- 165 configured, then the packets are dropped at the Join Proxy (J) since 166 the Pledge (P) is not yet admitted to the network or there is no IP 167 routability to Pledge (P) for any returned messages. 169 ++++ multi-hop 170 |R |---- mesh +--+ +--+ 171 | | \ |J |........|P | 172 ++++ \-----| | | | 173 +--+ +--+ 174 Registrar Join Proxy Pledge 175 "Joining" Device 177 Figure 1: multi-hop enrolment. 179 Without routing the Pledge (P) cannot establish a secure connection 180 to the Registrar (R) in the network assuming appropriate credentials 181 are exchanged out-of-band, e.g. a hash of the Pledge (P)'s raw public 182 key could be provided to the Registrar (R). 184 Furthermore, the Pledge (P) may be unaware of the IP address of the 185 Registrar (R) to initiate a DTLS connection and perform 186 authentication. 188 To overcome the problems with non-routability of DTLS packets and/or 189 discovery of the destination address of the EST Server to contact, 190 the Join Proxy is introduced. This Join Proxy functionality is 191 configured into all authenticated devices in the network which may 192 act as the Join Proxy for newly joining nodes. The Join Proxy allows 193 for routing of the packets from the Pledge using IP routing to the 194 intended Registrar. 196 5. Join Proxy specification 198 A Join Proxy can operate in two modes: 200 * Statefull mode 202 * Stateless mode 204 5.1. Statefull Join Proxy 206 In stateful mode, the joining node forwards the DTLS messages to the 207 Registrar. 209 Assume that the Pledge does not know the IP address of the Registrar 210 it needs to contact. In that situation, the Join Proxy must know the 211 (configured or discovered) IP address of a Registrar. (Discovery can 212 be based upon [I-D.ietf-anima-bootstrapping-keyinfra] section 4.3, or 213 via DNS-SD service discovery [RFC6763]). The Pledge initiates its 214 request as if the Join Proxy is the intended Registrar. The Join 215 Proxy changes the IP packet (without modifying the DTLS message) by 216 modifying both the source and destination addresses to forward the 217 message to the intended Registrar. The Join Proxy maintains a 218 4-tuple array to translate the DTLS messages received from the 219 Registrar and forward it to the EST Client. This is a form of 220 Network Address translation, where the Join Proxy acts as a forward 221 proxy. In Figure 2 the various steps of the message flow are shown, 222 with 5684 being the standard coaps port: 224 +------------+------------+-------------+--------------------------+ 225 | Pledge | Join Proxy | Registrar | Message | 226 | (P) | (J) | (R) | Src_IP:port | Dst_IP:port| 227 +------------+------------+-------------+-------------+------------+ 228 | --ClientHello--> | IP_P:p_P | IP_Ja:5684 | 229 | --ClientHello--> | IP_Jb:p_Jb| IP_R:5684 | 230 | | | | 231 | <--ServerHello-- | IP_R:5684 | IP_Jb:p_Jb | 232 | : | | | 233 | <--ServerHello-- : | IP_Ja:5684| IP_P:p_P | 234 | : : | | | 235 | : : | : | : | 236 | : : | : | : | 237 | --Finished--> : | IP_P:p_P | IP_Ja:5684 | 238 | --Finished--> | IP_Jb:p_Jb| IP_R:5684 | 239 | | | | 240 | <--Finished-- | IP_R:5684 | IP_Jb:p_Jb | 241 | <--Finished-- | IP_Ja:5684| IP_P:p_P | 242 | : : | : | : | 243 +---------------------------------------+-------------+------------+ 244 IP_P:p_P = Link-local IP address and port of Pledge (DTLS Client) 245 IP_R:5684 = Global IP address and coaps port of Registrar 246 IP_Ja:5684 = Link-local IP address and coaps port of Join Proxy 247 IP_Jb:p_Rb = Global IP address and port of Join proxy 249 Figure 2: constrained statefull joining message flow with 250 Registrar address known to Join Proxy. 252 5.2. Stateless Join Proxy 254 The stateless Join Proxy aims to minimize the requirements on the 255 constrained Join Proxy device. Stateless operation requires no 256 memory in the Join Proxy device, but may also reduce the CPU impact 257 as the device does not need to search through a state table. 259 When a client joining device attempts a DTLS connection to the 260 Registrar, it uses its link-local IP address as its IP source 261 address. This message is transmitted one-hop to a neighbouring (join 262 proxy) node. Under normal circumstances, this message would be 263 dropped at the neighbour node since the pledge is not yet IP routable 264 or it is not yet authenticated to send messages through the network. 265 However, if the neighbour device has the Join Proxy functionality 266 enabled, it routes the DTLS message to a specific Registrar. 267 Additional security mechanisms need to exist to prevent this routing 268 functionality being used by rogue nodes to bypass any network 269 authentication procedures. 271 If an untrusted pledge that can only use link-local addressing wants 272 to contact a trusted Registrar, it sends the DTLS message to the Join 273 Proxy. 275 The Join Proxy extends this message into a new type of message called 276 Join ProxY (JPY) message and sends it on to the Registrar. 278 The JPY message payload consists of two parts: 280 * Header (H) field: consisting of the source link-local address and 281 port of the Pledge (P), and 283 * Contents (C) field: containing the original DTLS message. 285 On receiving the JPY message, the Registrar retrieves the two parts. 287 The Registrar transiently stores the Header field information. The 288 Registrar uses the Contents field to execute the Registrar 289 functionality. However, when the Registrar replies, it also extends 290 its DTLS message with the header field in a JPY message and sends it 291 back to the Join Proxy. The Registrar SHOULD NOT assume that it can 292 decode the Header Field, it should simply repeat it when responding. 293 The Header contains the original source link-local address and port 294 of the pledge from the transient state stored earlier and the 295 Contents field contains the DTLS message. 297 On receiving the JPY message, the Join Proxy retrieves the two parts. 298 It uses the Header field to route the DTLS message retrieved from the 299 Contents field to the Pledge. 301 The Figure 3 depicts the message flow diagram: 303 +--------------+------------+---------------+-----------------------+ 304 | EST Client | Join Proxy | Registrar | Message | 305 | (P) | (J) | (R) |Src_IP:port|Dst_IP:port| 306 +--------------+------------+---------------+-----------+-----------+ 307 | --ClientHello--> | IP_P:p_P |IP_Ja:p_Ja | 308 | --JPY[H(IP_P:p_P),--> | IP_Jb:p_Jb|IP_R:p_Ra | 309 | C(ClientHello)] | | | 310 | <--JPY[H(IP_P:p_P),-- | IP_R:p_Ra |IP_Jb:p_Jb | 311 | C(ServerHello)] | | | 312 | <--ServerHello-- | IP_Ja:p_Ja|IP_P:p_P | 313 | : | | | 314 | : | : | : | 315 | | : | : | 316 | --Finished--> | IP_P:p_P |IP_Ja:p_Ja | 317 | --JPY[H(IP_P:p_P),--> | IP_Jb:p_Jb|IP_R:p_Ra | 318 | C(Finished)] | | | 319 | <--JPY[H(IP_P:p_P),-- | IP_R:p_Ra |IP_Jb:p_Jb | 320 | C(Finished)] | | | 321 | <--Finished-- | IP_Ja:p_Ja|IP_P:p_P | 322 | : | : | : | 323 +-------------------------------------------+-----------+-----------+ 324 IP_P:p_P = Link-local IP address and port of the Pledge 325 IP_R:p_Ra = Global IP address and join port of Registrar 326 IP_Ja:p_Ja = Link-local IP address and join port of Join Proxy 327 IP_Jb:p_Jb = Global IP address and port of Join Proxy 329 JPY[H(),C()] = Join Proxy message with header H and content C 331 Figure 3: constrained stateless joining message flow. 333 5.3. Stateless Message structure 335 The JPY message is constructed as a payload with medi-type 336 aplication/cbor 338 Header and Contents fields togther are one cbor array of 5 elements: 340 1. header field: containing a CBOR array [RFC7049] with the pledge 341 IPv6 Link Local address as a cbor byte string, the pledge's UDP 342 port number as a CBOR integer, the IP address family (IPv4/IPv6) 343 as a cbor integer, and the proxy's ifindex or other identifier 344 for the physical port as cbor integer. The header field is not 345 DTLS encrypted. 347 2. Content field: containing the DTLS encrypted payload as a CBOR 348 byte string. 350 The join_proxy cannot decrypt the DTLS ecrypted payload and has no 351 knowledge of the transported media type. 353 JPY_message = 354 [ 355 ip : bstr, 356 port : int, 357 family : int, 358 index : int 359 payload : bstr 360 ] 362 Figure 4: CDDL representation of JPY message 364 The content fields are DTLS encrypted. In CBOR diagnostic notation 365 the payload JPY[H(IP_P:p_P)], will look like: 367 [h'IP_p', p_P, family, ident, h'DTLS-content'] 369 Examples are shown in Appendix A. 371 6. Comparison of stateless and statefull modes 373 The stateful and stateless mode of operation for the Join Proxy have 374 their advantages and disadvantages. This section should enable to 375 make a choice between the two modes based on the available device 376 resources and network bandwidth. 378 +-------------+----------------------------+------------------------+ 379 | Properties | Stateful mode | Stateless mode | 380 +-------------+----------------------------+------------------------+ 381 | State |The Join Proxy needs | No information is | 382 | Information |additional storage to | maintained by the Join | 383 | |maintain mapping between | Proxy. Registrar needs | 384 | |the address and port number | to store the packet | 385 | |of the pledge and those | header. | 386 | |of the Registrar. | | 387 +-------------+----------------------------+------------------------+ 388 |Packet size |The size of the forwarded |Size of the forwarded | 389 | |message is the same as the |message is bigger than | 390 | |original message. |the original,it includes| 391 | | |additional source and | 392 | | |destination addresses. | 393 +-------------+----------------------------+------------------------+ 394 |Specification|The Join Proxy needs |New JPY message to | 395 |complexity |additional functionality |encapsulate DTLS message| 396 | |to maintain state |The Registrar | 397 | |information, and modify |and the Join Proxy | 398 | |the source and destination |have to understand the | 399 | |addresses of the DTLS |JPY message in order | 400 | |handshake messages |to process it. | 401 +-------------+----------------------------+------------------------+ 403 Figure 5: Comparison between stateful and stateless mode 405 7. Discovery 407 It is assumed that Join Proxy seamlessly provides a coaps connection 408 between Pledge and coaps Registrar. In particular this section 409 replaces section 4.2 of [I-D.ietf-anima-bootstrapping-keyinfra]. 411 The discovery follows two steps: 413 1. The pledge is one hop away from the Registrar. The pledge 414 discovers the link-local address of the Registrar as described in 415 {I-D.ietf-ace-coap-est}. From then on, it follows the BRSKI 416 process as described in {I-D.ietf-ace-coap-est}, using link-local 417 addresses. 419 2. The pledge is more than one hop away from a relevant Registrar, 420 and discovers the link-local address of a Join Proxy. The pledge 421 then follows the BRSKI procedure using the link-local address of 422 the Join Proxy. 424 Once a pledge is enrolled, it may function as Join Proxy. The Join 425 Proxy functions are advertised as descibed below. In principle, the 426 Join Proxy functions are offered via a "join" port, and not the 427 standard coaps port. Also the Registrar offer a "join" port to which 428 the stateless join proxy sends the JPY message. The Join Proxy and 429 Registrar MUST show the extra join port number when reponding to the 430 .well-known/core request addressed to the standard coap/coaps port. 432 Three discovery cases are discussed: coap discovery, 6tisch discovery 433 and GRASP discovery. 435 7.1. Pledge discovery of Registrar 437 The Pledge and Join Proxy are assumed to communicate via Link-Local 438 addresses. 440 7.1.1. CoAP discovery 442 The discovery of the coaps Registrar, using coap discovery, by the 443 Join Proxy follows section 6 of [I-D.ietf-ace-coap-est]. The 444 extension to discover the additional port needed by the stateless 445 proxy is described in Section 7.2.2 by using rt=brski-proxy. 447 7.1.2. Autonomous Network 449 In the context of autonomous networks, the Join Proxy uses the DULL 450 GRASP M_FLOOD mechanism to announce itself. Section 4.1.1 of 451 [I-D.ietf-anima-bootstrapping-keyinfra] discusses this in more 452 detail. The Registrar announces itself using ACP instance of GRASP 453 using M_FLOOD messages. Autonomous Network Join Proxies MUST support 454 GRASP discovery of Registrar as decribed in section 4.3 of 455 [I-D.ietf-anima-bootstrapping-keyinfra] . 457 7.1.3. 6tisch discovery 459 The discovery of Registrar by the pledge uses the enhanced beacons as 460 discussed in [I-D.ietf-6tisch-enrollment-enhanced-beacon]. 462 7.2. Pledge discovers Join Proxy 464 7.2.1. Autonomous Network 466 The pledge MUST listen for GRASP M_FLOOD [I-D.ietf-anima-grasp] 467 announcements of the objective: "AN_Proxy". See section 468 Section 4.1.1 [I-D.ietf-anima-bootstrapping-keyinfra] for the details 469 of the objective. 471 7.2.2. CoAP discovery 473 In the context of a coap network without Autonomous Network support, 474 discovery follows the standard coap policy. The Pledge can discover 475 a Join Proxy by sending a link-local multicast message to ALL CoAP 476 Nodes with address FF02::FD. Multiple or no nodes may respond. The 477 handling of multiple responses and the absence of responses follow 478 section 4 of [I-D.ietf-anima-bootstrapping-keyinfra]. 480 The presence and location of (path to) the Join Proxy resource are 481 discovered by sending a GET request to "/.well-known/core" including 482 a resource type (rt) parameter with the value "brski-proxy" 483 [RFC6690]. Upon success, the return payload will contain the root 484 resource of the Join Proxy resources. It is up to the implementation 485 to choose its root resource; throughout this document the example 486 root resource /jp is used. The example below shows the discovery of 487 the presence and location of Join Proxy resources. 489 REQ: GET coap://[FF02::FD]/.well-known/core?rt=brski-proxy 491 RES: 2.05 Content 492 ; rt="brski-proxy" 494 Port numbers are assumed to be the default numbers 5683 and 5684 for 495 coap and coaps respectively (sections 12.6 and 12.7 of [RFC7252] when 496 not shown in the response. Discoverable port numbers are usually 497 returned for Join Proxy resources in the of the payload (see 498 section 5.1 of [I-D.ietf-ace-coap-est]). 500 8. Security Considerations 502 It should be noted here that the contents of the CBOR map used to 503 convey return address information is not protected. However, the 504 communication is between the Proxy and a known registrar are over the 505 already secured portion of the network, so are not visible to 506 eavesdropping systems. 508 All of the concerns in [I-D.ietf-anima-bootstrapping-keyinfra] 509 section 4.1 apply. The pledge can be deceived by malicious AN_Proxy 510 announcements. The pledge will only join a network to which it 511 receives a valid [RFC8366] voucher. 513 If the proxy/Registrar was not over a secure network, then an 514 attacker could change the cbor array, causing the pledge to send 515 traffic to another node. If the such scenario needed to be 516 supported, then it would be reasonable for the Proxy to encrypt the 517 CBOR array using a locally generated symmetric key. The Registrar 518 would not be able to examine the result, but it does not need to do 519 so. This is a topic for future work. 521 9. IANA Considerations 523 This document needs to create a registry for key indices in the CBOR 524 map. It should be given a name, and the amending formula should be 525 IETF Specification. 527 9.1. Resource Type registry 529 This specification registers a new Resource Type (rt=) Link Target 530 Attributes in the "Resource Type (rt=) Link Target Attribute Values" 531 subregistry under the "Constrained RESTful Environments (CoRE) 532 Parameters" registry. 534 rt="brski-proxy". This BRSKI resource is used to query and return 535 the supported BRSKI resource using the additional BRSKI port of 536 Join Proxy or Registrar. 538 10. Acknowledgements 540 Many thanks for the comments by Brian Carpenter. 542 11. Contributors 544 Sandeep Kumar, Sye loong Keoh, and Oscar Garcia-Morchon are the co- 545 authors of the draft-kumar-dice-dtls-relay-02. Their draft has 546 served as a basis for this document. Much text from their draft is 547 copied over to this draft. 549 12. Changelog 551 12.1. 00 to 01 553 * Registrar used throughout instead of EST server 555 * Emphasized additional Join Proxy port for Join Proxy and Registrar 557 * updated discovery accordingly 559 * updated stateless Join Proxy JPY header 560 * JPY header described with CDDL 562 * Example simplified and corrected 564 12.2. 00 to 00 566 * copied from vanderstok-anima-constrained-join-proxy-05 568 13. References 570 13.1. Normative References 572 [I-D.ietf-6tisch-enrollment-enhanced-beacon] 573 Dujovne, D. and M. Richardson, "IEEE 802.15.4 Information 574 Element encapsulation of 6TiSCH Join and Enrollment 575 Information", Work in Progress, Internet-Draft, draft- 576 ietf-6tisch-enrollment-enhanced-beacon-14, 21 February 577 2020, . 580 [I-D.ietf-ace-coap-est] 581 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 582 "EST over secure CoAP (EST-coaps)", Work in Progress, 583 Internet-Draft, draft-ietf-ace-coap-est-18, 6 January 584 2020, . 587 [I-D.ietf-anima-bootstrapping-keyinfra] 588 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 589 and K. Watsen, "Bootstrapping Remote Secure Key 590 Infrastructures (BRSKI)", Work in Progress, Internet- 591 Draft, draft-ietf-anima-bootstrapping-keyinfra-45, 11 592 November 2020, . 595 [I-D.ietf-anima-constrained-voucher] 596 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 597 Voucher Artifacts for Bootstrapping Protocols", Work in 598 Progress, Internet-Draft, draft-ietf-anima-constrained- 599 voucher-09, 2 November 2020, . 603 [I-D.ietf-anima-grasp] 604 Bormann, C., Carpenter, B., and B. Liu, "A Generic 605 Autonomic Signaling Protocol (GRASP)", Work in Progress, 606 Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017, 607 . 610 [I-D.ietf-core-multipart-ct] 611 Fossati, T., Hartke, K., and C. Bormann, "Multipart 612 Content-Format for CoAP", Work in Progress, Internet- 613 Draft, draft-ietf-core-multipart-ct-04, 21 August 2019, 614 . 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, 619 DOI 10.17487/RFC2119, March 1997, 620 . 622 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 623 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 624 January 2012, . 626 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 627 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 628 October 2013, . 630 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 631 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 632 May 2017, . 634 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 635 "A Voucher Artifact for Bootstrapping Protocols", 636 RFC 8366, DOI 10.17487/RFC8366, May 2018, 637 . 639 13.2. Informative References 641 [I-D.kumar-dice-dtls-relay] 642 Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay 643 for Constrained Environments", Work in Progress, Internet- 644 Draft, draft-kumar-dice-dtls-relay-02, 20 October 2014, 645 . 648 [I-D.richardson-anima-state-for-joinrouter] 649 Richardson, M., "Considerations for stateful vs stateless 650 join router in ANIMA bootstrap", Work in Progress, 651 Internet-Draft, draft-richardson-anima-state-for- 652 joinrouter-03, 22 September 2020, . 656 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 657 "Transmission of IPv6 Packets over IEEE 802.15.4 658 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 659 . 661 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 662 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 663 . 665 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 666 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 667 . 669 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 670 Bormann, "Neighbor Discovery Optimization for IPv6 over 671 Low-Power Wireless Personal Area Networks (6LoWPANs)", 672 RFC 6775, DOI 10.17487/RFC6775, November 2012, 673 . 675 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 676 "Enrollment over Secure Transport", RFC 7030, 677 DOI 10.17487/RFC7030, October 2013, 678 . 680 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 681 Constrained-Node Networks", RFC 7228, 682 DOI 10.17487/RFC7228, May 2014, 683 . 685 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 686 Application Protocol (CoAP)", RFC 7252, 687 DOI 10.17487/RFC7252, June 2014, 688 . 690 Appendix A. Stateless Proxy payload examples 692 The examples show the get coaps://[192.168.1.200]:5965/est/crts to a 693 Registrar. The header generated between Client and registrar and 694 from registrar to client are shown in detail. The DTLS encrypted 695 code is not shown. 697 The request from Join Proxy to Registrar looks like: 699 85 # array(5) 700 50 # bytes(16) 701 00000000000000000000FFFFC0A801C8 # 702 19 BDA7 # unsigned(48551) 703 0A # unsigned(10) 704 00 # unsigned(0) 705 58 2D # bytes(45) 706 708 In CBOR Diagnostic: 710 [h'00000000000000000000FFFFC0A801C8', 48551, 10, 0, 711 h''] 713 The response is: 715 85 # array(5) 716 50 # bytes(16) 717 00000000000000000000FFFFC0A801C8 # 718 19 BDA7 # unsigned(48551) 719 0A # unsigned(10) 720 00 # unsigned(0) 721 59 026A # bytes(618) 722 724 In CBOR diagnostic: 726 [h'00000000000000000000FFFFC0A801C8', 48551, 10, 0, 727 h''] 729 Authors' Addresses 731 Michael Richardson 732 Sandelman Software Works 734 Email: mcr+ietf@sandelman.ca 736 Peter van der Stok 737 vanderstok consultancy 739 Email: consultancy@vanderstok.org 741 Panos Kampanakis 742 Cisco Systems 744 Email: pkampana@cisco.com