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