idnits 2.17.1 draft-ietf-anima-constrained-join-proxy-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (14 April 2022) is 743 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 (-24) exists of draft-ietf-anima-constrained-voucher-17 -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802-1AR' ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: 16 October 2022 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 14 April 2022 10 Constrained Join Proxy for Bootstrapping Protocols 11 draft-ietf-anima-constrained-join-proxy-10 13 Abstract 15 This document extends the work of Bootstrapping Remote Secure Key 16 Infrastructures (BRSKI) by replacing the Circuit-proxy between Pledge 17 and Registrar by a stateless/stateful constrained Join Proxy. The 18 constrained Join Proxy is a mesh neighbor of the Pledge and can relay 19 a DTLS session originating from a Pledge with only link-local 20 addresses to a Registrar which is not a mesh neighbor of the Pledge. 22 This document defines a protocol to securely assign a Pledge to a 23 domain, represented by a Registrar, using an intermediary node 24 between Pledge and Registrar. This intermediary node is known as a 25 "constrained Join Proxy". An enrolled Pledge can act as a 26 constrained Join Proxy. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 16 October 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Revised BSD License text as 56 described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Revised BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 64 4. constrained Join Proxy functionality . . . . . . . . . . . . 5 65 5. constrained Join Proxy specification . . . . . . . . . . . . 7 66 5.1. Stateful Join Proxy . . . . . . . . . . . . . . . . . . . 7 67 5.2. Stateless Join Proxy . . . . . . . . . . . . . . . . . . 8 68 5.3. Stateless Message structure . . . . . . . . . . . . . . . 10 69 6. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 6.1. Join Proxy discovers Registrar . . . . . . . . . . . . . 12 71 6.1.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 13 72 6.1.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 13 73 6.1.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 13 74 6.2. Pledge discovers Registrar . . . . . . . . . . . . . . . 13 75 6.2.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 13 76 6.2.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 14 77 6.2.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 14 78 6.3. Pledge discovers Join Proxy . . . . . . . . . . . . . . . 14 79 6.3.1. CoAP discovery . . . . . . . . . . . . . . . . . . . 14 80 6.3.2. GRASP discovery . . . . . . . . . . . . . . . . . . . 15 81 6.3.3. 6tisch discovery . . . . . . . . . . . . . . . . . . 15 82 7. Comparison of stateless and stateful modes . . . . . . . . . 15 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 85 9.1. Resource Type Attributes registry . . . . . . . . . . . . 17 86 9.2. service name and port number registry . . . . . . . . . . 17 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 88 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 89 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 12.1. 10 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 18 91 12.2. 09 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 18 92 12.3. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 18 93 12.4. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 19 94 12.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 19 95 12.6. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 19 96 12.7. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 19 97 12.8. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 19 98 12.9. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 19 99 12.10. 00 to 00 . . . . . . . . . . . . . . . . . . . . . . . . 19 100 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 101 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 102 13.2. Informative References . . . . . . . . . . . . . . . . . 21 103 Appendix A. Stateless Proxy payload examples . . . . . . . . . . 23 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 106 1. Introduction 108 The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol 109 described in [RFC8995] provides a solution for a secure zero-touch 110 (automated) bootstrap of new (unconfigured) devices. In the context 111 of BRSKI, new devices, called "Pledges", are equipped with a factory- 112 installed Initial Device Identifier (IDevID) (see [ieee802-1AR]), and 113 are enrolled into a network. BRSKI makes use of Enrollment over 114 Secure Transport (EST) [RFC7030] with [RFC8366] vouchers to securely 115 enroll devices. A Registrar provides the security anchor of the 116 network to which a Pledge enrolls. In this document, BRSKI is 117 extended such that a Pledge connects to "Registrars" via a 118 constrained Join Proxy. In particular, the underlying IP network is 119 assumed to be a mesh newtork as described in [RFC4944], although 120 other IP-over-foo networks are not excluded. 122 A complete specification of the terminology is pointed at in 123 Section 2. 125 The specified solutions in [RFC8995] and [RFC7030] are based on POST 126 or GET requests to the EST resources (/cacerts, /simpleenroll, 127 /simplereenroll, /serverkeygen, and /csrattrs), and the brski 128 resources (/requestvoucher, /voucher_status, and /enrollstatus). 129 These requests use https and may be too large in terms of code space 130 or bandwidth required for constrained devices. Constrained devices 131 which may be part of constrained networks [RFC7228], typically 132 implement the IPv6 over Low-Power Wireless personal Area Networks 133 (6LoWPAN) [RFC4944] and Constrained Application Protocol (CoAP) 134 [RFC7252]. 136 CoAP can be run with the Datagram Transport Layer Security (DTLS) 137 [RFC6347] as a security protocol for authenticity and confidentiality 138 of the messages. This is known as the "coaps" scheme. A constrained 139 version of EST, using Coap and DTLS, is described in 140 [I-D.ietf-ace-coap-est]. The [I-D.ietf-anima-constrained-voucher] 141 extends [I-D.ietf-ace-coap-est] with BRSKI artifacts such as voucher, 142 request voucher, and the protocol extensions for constrained Pledges. 144 DTLS is a client-server protocol relying on the underlying IP layer 145 to perform the routing between the DTLS Client and the DTLS Server. 146 However, the Pledge will not be IP routable over the mesh network 147 until it is authenticated to the mesh network. A new Pledge can only 148 initially use a link-local IPv6 address to communicate with a mesh 149 neighbor [RFC6775] until it receives the necessary network 150 configuration parameters. The Pledge receives these configuration 151 parameters from the Registrar. When the Registrar is not a direct 152 neighbor of the Registrar but several hops away, the Pledge discovers 153 a neighbor constrained Join Proxy, which transmits the DTLS protected 154 request coming from the Pledge to the Registrar. The constrained 155 Join Proxy must be enrolled previously such that the message from 156 constrained Join Proxy to Registrar can be routed over one or more 157 hops. 159 During enrollment, a DTLS connection is required between Pledge and 160 Registrar. 162 Once a Pledge is enrolled, it can act as constrained Join Proxy 163 between other Pledges and the enrolling Registrar. 165 This document specifies a new form of constrained Join Proxy and 166 protocol to act as intermediary between Pledge and Registrar to relay 167 DTLS messages between Pledge and Registrar. Two modes of the 168 constrained Join Proxy are specified: 170 1 A stateful Join Proxy that locally stores IP addresses 171 during the connection. 172 2 A stateless Join Proxy that where the connection state 173 is stored in the messages. 175 This document is very much inspired by text published earlier in 176 [I-D.kumar-dice-dtls-relay]. 177 [I-D.richardson-anima-state-for-joinrouter] outlined the various 178 options for building a constrained Join Proxy. [RFC8995] adopted 179 only the Circuit Proxy method (1), leaving the other methods as 180 future work. 182 The stateful and stateless modes differ in the way that they store 183 the state required to forward the return packet to the pledge. 184 Similar to the difference between storing and non_storing Modes of 185 Operations (MOP) in RPL [RFC6550]. In the stateful method, the 186 return forward state is stored in the join proxy. In the stateless 187 method, the return forward state is stored in the network. 189 2. Terminology 191 The following terms are defined in [RFC8366], and are used 192 identically as in that document: artifact, imprint, domain, Join 193 Registrar/Coordinator (JRC), Pledge, and Voucher. 195 In this document, the term "Registrar" is used throughout instead of 196 "Join Registrar/Coordinator (JRC)". 198 The term "installation network" refers to all devices in the 199 installation and the network connections between them. The term 200 "installation IP_address" refers to an address out of the set of 201 addresses which are routable over the whole installation network. 203 The "Constrained Join Proxy" enables a pledge that is multiple hops 204 away from the Registrar, to securely execute the BRSKI protocol 205 [RFC8995] over a secure channel. 207 The term "join Proxy" is used interchangeably with the term 208 "constrained Join Proxy" throughout this document. 210 3. Requirements Language 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 214 "OPTIONAL" in this document are to be interpreted as described in 215 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 216 capitals, as shown here. 218 4. constrained Join Proxy functionality 220 As depicted in the Figure 1, the Pledge (P), in a Low-Power and Lossy 221 Network (LLN) mesh [RFC7102] can be more than one hop away from the 222 Registrar (R) and not yet authenticated into the network. 224 In this situation, the Pledge can only communicate one-hop to its 225 nearest neighbor, the constrained Join Proxy (J) using their link- 226 local IPv6 addresses. However, the Pledge (P) needs to communicate 227 with end-to-end security with a Registrar to authenticate and get the 228 relevant system/network parameters. If the Pledge (P), knowing the 229 IP-address of the Registrar, initiates a DTLS connection to the 230 Registrar, then the packets are dropped at the constrained Join Proxy 231 (J) since the Pledge (P) is not yet admitted to the network or there 232 is no IP routability to Pledge (P) for any returned messages from the 233 Registrar. 235 ++++ multi-hop 236 |R |---- mesh +--+ +--+ 237 | | \ |J |........|P | 238 ++++ \-----| | | | 239 +--+ +--+ 240 Registrar Join Proxy Pledge 242 Figure 1: multi-hop enrollment. 244 Without routing the Pledge (P) cannot establish a secure connection 245 to the Registrar (R) over multiple hops in the network. 247 Furthermore, the Pledge (P) cannot discover the IP address of the 248 Registrar (R) over multiple hops to initiate a DTLS connection and 249 perform authentication. 251 To overcome the problems with non-routability of DTLS packets and/or 252 discovery of the destination address of the Registrar, the 253 constrained Join Proxy is introduced. This constrained Join Proxy 254 functionality is configured into all authenticated devices in the 255 network which may act as a constrained Join Proxy for Pledges. The 256 constrained Join Proxy allows for routing of the packets from the 257 Pledge using IP routing to the intended Registrar. An authenticated 258 constrained Join Proxy can discover the routable IP address of the 259 Registrar over multiple hops. The following Section 5 specifies the 260 two constrained Join Proxy modes. A comparison is presented in 261 Section 7. 263 When a mesh network is set up, it consists of a Registrar and a set 264 of connected pledges. No constrained Join Proxies are present. The 265 wanted end-state is a network with a Registrar and a set of enrolled 266 devices. Some of these enrolled devices can act as constrained Join 267 Proxies. Pledges can only employ link-local communication untill 268 they are enrolled. A Pledge will regularly try to discover a 269 constrained Join Proxy or a Registrar with link-local discovery 270 requests. The Pledges which are neigbors of the Registrar will 271 discover the Registrar and be enrolled following the BRSKI protocol. 272 An enrolled device can act as constrained Join Proxy. The Pledges 273 which are not a neighbor of the Registrar will eventually discover a 274 constrained Join Proxy and follow the BRSKI protocol to be enrolled. 275 While this goes on, more and more constrained Join Proxies with a 276 larger hop distance to the Registrar will emerge. The network should 277 be configured such that at the end of the enrollment process, all 278 pledges have discovered a neigboring constrained Join Proxy or the 279 Registrar, and all "legal" Pledges are enrolled. 281 5. constrained Join Proxy specification 283 A Join Proxy can operate in two modes: 285 * Stateful mode 287 * Stateless mode 289 A Join Proxy MAY implement both. A mechanism to switch between modes 290 is out of scope of this document. It is recommended that a Join 291 Proxy uses only one of these modes at any given moment during an 292 installation lifetime. 294 5.1. Stateful Join Proxy 296 In stateful mode, the Join Proxy forwards the DTLS messages to the 297 Registrar. 299 Assume that the Pledge does not know the IP address of the Registrar 300 it needs to contact. The Join Proxy has been enrolled via the 301 Registrar and learns the IP address and port of the Registrar, for 302 example by using the discovery mechanism described in Section 6. The 303 Pledge first discovers (see Section 6) and selects the most 304 appropriate Join Proxy. (Discovery can also be based upon [RFC8995] 305 section 4.1). For service discovery via DNS-SD [RFC6763], this 306 document specifies the service names in Section 9.2. The Pledge 307 initiates its request as if the Join Proxy is the intended Registrar. 308 The Join Proxy receives the message at a discoverable join-port. The 309 Join Proxy constructs an IP packet by copying the DTLS payload from 310 the message received from the Pledge, and provides source and 311 destination addresses to forward the message to the intended 312 Registrar. The Join Proxy stores the 4-tuple array of the messages 313 received from the Registrar and copies it back to the header of the 314 message returned to the Pledge. 316 In Figure 2 the various steps of the message flow are shown, with 317 5684 being the standard coaps port: 319 +------------+------------+-------------+--------------------------+ 320 | Pledge | Join Proxy | Registrar | Message | 321 | (P) | (J) | (R) | Src_IP:port | Dst_IP:port| 322 +------------+------------+-------------+-------------+------------+ 323 | --ClientHello--> | IP_P:p_P | IP_Jl:p_Jl | 324 | --ClientHello--> | IP_Jr:p_Jr| IP_R:5684 | 325 | | | | 326 | <--ServerHello-- | IP_R:5684 | IP_Jr:p_Jr | 327 | : | | | 328 | <--ServerHello-- : | IP_Jl:p_Jl| IP_P:p_P | 329 | : : | | | 330 | [DTLS messages] | : | : | 331 | : : | : | : | 332 | --Finished--> : | IP_P:p_P | IP_Jl:p_Jl | 333 | --Finished--> | IP_Jr:p_Jr| IP_R:5684 | 334 | | | | 335 | <--Finished-- | IP_R:5684 | IP_Jr:p_Jr | 336 | <--Finished-- | IP_Jl:p_Jl| IP_P:p_P | 337 | : : | : | : | 338 +---------------------------------------+-------------+------------+ 339 IP_P:p_P = Link-local IP address and port of Pledge (DTLS Client) 340 IP_R:5684 = Routable IP address and coaps port of Registrar 341 IP_Jl:p_Jl = Link-local IP address and join-port of Join Proxy 342 IP_Jr:p_Jr = Routable IP address and client port of Join Proxy 344 Figure 2: constrained stateful joining message flow with 345 Registrar address known to Join Proxy. 347 5.2. Stateless Join Proxy 349 The stateless Join Proxy aims to minimize the requirements on the 350 constrained Join Proxy device. Stateless operation requires no 351 memory in the Join Proxy device, but may also reduce the CPU impact 352 as the device does not need to search through a state table. 354 If an untrusted Pledge that can only use link-local addressing wants 355 to contact a trusted Registrar, and the Registrar is more than one 356 hop away, it sends its DTLS messages to the Join Proxy. 358 When a Pledge attempts a DTLS connection to the Join Proxy, it uses 359 its link-local IP address as its IP source address. This message is 360 transmitted one-hop to a neighboring (Join Proxy) node. Under normal 361 circumstances, this message would be dropped at the neighbor node 362 since the Pledge is not yet IP routable or is not yet authenticated 363 to send messages through the network. However, if the neighbor 364 device has the Join Proxy functionality enabled; it routes the DTLS 365 message to its Registrar of choice. 367 The Join Proxy transforms the DTLS message to a JPY message which 368 includes the DTLS data as payload, and sends the JPY message to the 369 join-port of the Registrar. 371 The JPY message payload consists of two parts: 373 * Header (H) field: consisting of the source link-local address and 374 port of the Pledge (P), and 376 * Contents (C) field: containing the original DTLS payload. 378 On receiving the JPY message, the Registrar (or proxy) retrieves the 379 two parts. 381 The Registrar transiently stores the Header field information. The 382 Registrar uses the Contents field to execute the Registrar 383 functionality. However, when the Registrar replies, it also extends 384 its DTLS message with the header field in a JPY message and sends it 385 back to the Join Proxy. The Registrar SHOULD NOT assume that it can 386 decode the Header Field, it should simply repeat it when responding. 387 The Header contains the original source link-local address and port 388 of the Pledge from the transient state stored earlier and the 389 Contents field contains the DTLS payload. 391 On receiving the JPY message, the Join Proxy retrieves the two parts. 392 It uses the Header field to route the DTLS message containing the 393 DTLS payload retrieved from the Contents field to the Pledge. 395 In this scenario, both the Registrar and the Join Proxy use 396 discoverable join-ports, for the Join Proxy this may be a default 397 CoAP port. 399 The Figure 3 depicts the message flow diagram: 401 +--------------+------------+---------------+-----------------------+ 402 | Pledge | Join Proxy | Registrar | Message | 403 | (P) | (J) | (R) |Src_IP:port|Dst_IP:port| 404 +--------------+------------+---------------+-----------+-----------+ 405 | --ClientHello--> | IP_P:p_P |IP_Jl:p_Jl | 406 | --JPY[H(IP_P:p_P),--> | IP_Jr:p_Jr|IP_R:p_Ra | 407 | C(ClientHello)] | | | 408 | <--JPY[H(IP_P:p_P),-- | IP_R:p_Ra |IP_Jr:p_Jr | 409 | C(ServerHello)] | | | 410 | <--ServerHello-- | IP_Jl:p_Jl|IP_P:p_P | 411 | : | | | 412 | [ DTLS messages ] | : | : | 413 | : | : | : | 414 | --Finished--> | IP_P:p_P |IP_Jr:p_Jr | 415 | --JPY[H(IP_P:p_P),--> | IP_Jl:p_Jl|IP_R:p_Ra | 416 | C(Finished)] | | | 417 | <--JPY[H(IP_P:p_P),-- | IP_R:p_Ra |IP_Jr:p_Jr | 418 | C(Finished)] | | | 419 | <--Finished-- | IP_Jl:p_Jl|IP_P:p_P | 420 | : | : | : | 421 +-------------------------------------------+-----------+-----------+ 422 IP_P:p_P = Link-local IP address and port of the Pledge 423 IP_R:p_Ra = Routable IP address and join-port of Registrar 424 IP_Jl:p_Jl = Link-local IP address and join-port of Join Proxy 425 IP_Jr:p_Jr = Routable IP address and port of Join Proxy 427 JPY[H(),C()] = Join Proxy message with header H and content C 429 Figure 3: constrained stateless joining message flow. 431 5.3. Stateless Message structure 433 The JPY message is constructed as a payload with media-type 434 application/cbor 436 Header and Contents fields together are one CBOR array of 5 elements: 438 1. header field: containing a CBOR array [RFC8949] with the Pledge 439 IPv6 Link Local address as a CBOR byte string, the Pledge's UDP 440 port number as a CBOR integer, the IP address family (IPv4/IPv6) 441 as a CBOR integer, and the proxy's ifindex or other identifier 442 for the physical port as CBOR integer. The header field is not 443 DTLS encrypted. 445 2. Content field: containing the DTLS payload as a CBOR byte string. 447 The address family integer is defined in [family] with: 449 1 IP (IP version 4) 450 2 IP6 (IP version 6) 452 The Join Proxy cannot decrypt the DTLS payload and has no knowledge 453 of the transported media type. 455 JPY_message = 456 [ 457 ip : bstr, 458 port : int, 459 family : int, 460 index : int 461 content : bstr 462 ] 464 Figure 4: CDDL representation of JPY message 466 The contents are DTLS encrypted. In CBOR diagnostic notation the 467 payload JPY[H(IP_P:p_P)], will look like: 469 [h'IP_p', p_P, family, ident, h'DTLS-payload'] 471 On reception by the Registrar, the Registrar MUST verify that the 472 number of array elements is larger than or equal to 5, and reject the 473 message when the number of array elements is smaller than 5. After 474 replacing the 5th "content" element with the DTLS payload of the 475 response message and leaving all other array elements unchanged, the 476 Registrar returns the response message. 478 Examples are shown in Appendix A. 480 The header field is completely opaque to the receiver. A Registrar 481 MUST copy the header and return it unmodified in the return message. 483 6. Discovery 485 It is assumed that Join Proxy seamlessly provides a coaps connection 486 between Pledge and Registrar. In particular this section extends 487 section 4.1 of [RFC8995] for the constrained case. 489 The discovery follows two steps with two alternatives for step 1: 491 * Step 1. Two alternatives exist (near and remote): 493 - Near: the Pledge is one hop away from the Registrar. The 494 Pledge discovers the link-local address of the Registrar as 495 described in [I-D.ietf-ace-coap-est]. From then on, it follows 496 the BRSKI process as described in [I-D.ietf-ace-coap-est] and 497 [I-D.ietf-anima-constrained-voucher], using link-local 498 addresses. 500 - Remote: the Pledge is more than one hop away from a relevant 501 Registrar, and discovers the link-local address and join-port 502 of a Join Proxy. The Pledge then follows the BRSKI procedure 503 using the link-local address of the Join Proxy. 505 * Step 2. The enrolled Join Proxy discovers the join-port of the 506 Registrar. 508 The order in which the two alternatives of step 1 are tried is 509 installation dependent. The trigger for discovery in Step 2 is 510 implementation dependent. 512 Once a Pledge is enrolled, it may function as Join Proxy. The Join 513 Proxy functions are advertised as described below. In principle, the 514 Join Proxy functions are offered via a join-port, and not the 515 standard coaps port. Also, the Registrar offers a join-port to which 516 the stateless Join Proxy sends the JPY message. The Join Proxy and 517 Registrar show the extra join-port number when responding to a 518 /.well-known/core discovery request addressed to the standard coap/ 519 coaps port. 521 Three discovery cases are discussed: Join Proxy discovers Registrar, 522 Pledge discovers Registrar, and Pledge discovers Join Proxy. Each 523 discovery case considers three alternatives: CoAP based discovery, 524 GRASP Based discovery, and 6tisch based discovery. The choice of 525 discovery mechanism depends on the type of installation, and 526 manufacturers can provide the pledge/Join Proxy with support for more 527 than one discovery mechanism. The pledge/Join Proxy can be designed 528 to dynamically try different discovery mechanisms until a successful 529 discovery mechanism is found, or the choice of discovery mechanism 530 could be configured during device installation. 532 6.1. Join Proxy discovers Registrar 534 In this section, the Join Proxy and Registrar are assumed to 535 communicate via Link-Local addresses. This section describes the 536 discovery of the Registrar by the Join Proxy. 538 6.1.1. CoAP discovery 540 The discovery of the coaps Registrar, using coap discovery, by the 541 Join Proxy follows sections 6.3 and 6.5.1 of 542 [I-D.ietf-anima-constrained-voucher]. The stateless Join Proxy can 543 discover the join-port of the Registrar by sending a GET request to 544 "/.well-known/core" including a resource type (rt) parameter with the 545 value "brski.rjp" [RFC6690]. Upon success, the return payload will 546 contain the join-port of the Registrar. 548 REQ: GET coap://[IP_address]/.well-known/core?rt=brski.rjp 550 RES: 2.05 Content 551 ; rt="brski.rjp" 553 The discoverable port numbers are usually returned for Join Proxy 554 resources in the of the payload (see section 5.1 of 555 [I-D.ietf-ace-coap-est]). 557 6.1.2. GRASP discovery 559 This section is normative for uses with an ANIMA ACP. In the context 560 of autonomic networks, the Join Proxy uses the DULL GRASP M_FLOOD 561 mechanism to announce itself. Section 4.1.1 of [RFC8995] discusses 562 this in more detail. The Registrar announces itself using ACP 563 instance of GRASP using M_FLOOD messages. Autonomic Network Join 564 Proxies MUST support GRASP discovery of Registrar as described in 565 section 4.3 of [RFC8995]. 567 6.1.3. 6tisch discovery 569 The discovery of the Registrar by the Join Proxy uses the enhanced 570 beacons as discussed in [I-D.ietf-6tisch-enrollment-enhanced-beacon]. 572 6.2. Pledge discovers Registrar 574 In this section, the Pledge and Registrar are assumed to communicate 575 via Link-Local addresses. This section describes the discovery of 576 the Registrar by the Pledge. 578 6.2.1. CoAP discovery 580 The discovery of the coaps Registrar, using coap discovery, by the 581 Pledge follows sections 6.3 and 6.5.1 of 582 [I-D.ietf-anima-constrained-voucher]. 584 6.2.2. GRASP discovery 586 This section is normative for uses with an ANIMA ACP. In the context 587 of autonomic networks, the Pledge uses the DULL GRASP M_FLOOD 588 mechanism to announce itself. Section 4.1.1 of [RFC8995] discusses 589 this in more detail. The Registrar announces itself using ACP 590 instance of GRASP using M_FLOOD messages. Autonomic Network Join 591 Proxies MUST support GRASP discovery of Registrar as described in 592 section 4.3 of [RFC8995] . 594 6.2.3. 6tisch discovery 596 The discovery of Registrar by the Pledge uses the enhanced beacons as 597 discussed in [I-D.ietf-6tisch-enrollment-enhanced-beacon]. 599 6.3. Pledge discovers Join Proxy 601 In this section, the Pledge and Join Proxy are assumed to communicate 602 via Link-Local addresses. This section describes the discovery of 603 the Join Proxy by the Pledge. 605 6.3.1. CoAP discovery 607 In the context of a coap network without Autonomic Network support, 608 discovery follows the standard coap policy. The Pledge can discover 609 a Join Proxy by sending a link-local multicast message to ALL CoAP 610 Nodes with address FF02::FD. Multiple or no nodes may respond. The 611 handling of multiple responses and the absence of responses follow 612 section 4 of [RFC8995]. 614 The join-port of the Join Proxy is discovered by sending a GET 615 request to "/.well-known/core" including a resource type (rt) 616 parameter with the value "brski.jp" [RFC6690]. Upon success, the 617 return payload will contain the join-port. 619 The example below shows the discovery of the join-port of the Join 620 Proxy. 622 REQ: GET coap://[FF02::FD]/.well-known/core?rt=brski.jp 624 RES: 2.05 Content 625 ; rt="brski.jp" 627 Port numbers are assumed to be the default numbers 5683 and 5684 for 628 coap and coaps respectively (sections 12.6 and 12.7 of [RFC7252]) 629 when not shown in the response. Discoverable port numbers are 630 usually returned for Join Proxy resources in the of 631 the payload (see section 5.1 of [I-D.ietf-ace-coap-est]). 633 6.3.2. GRASP discovery 635 This section is normative for uses with an ANIMA ACP. The Pledge 636 MUST listen for GRASP M_FLOOD [RFC8990] announcements of the 637 objective: "AN_Proxy". See section 4.1.1 [RFC8995] for the details 638 of the objective. 640 6.3.3. 6tisch discovery 642 The discovery of the Join Proxy by the Pledge uses the enhanced 643 beacons as discussed in [I-D.ietf-6tisch-enrollment-enhanced-beacon]. 645 7. Comparison of stateless and stateful modes 647 The stateful and stateless mode of operation for the Join Proxy have 648 their advantages and disadvantages. This section should enable to 649 make a choice between the two modes based on the available device 650 resources and network bandwidth. 652 +-------------+----------------------------+------------------------+ 653 | Properties | Stateful mode | Stateless mode | 654 +-------------+----------------------------+------------------------+ 655 | State |The Join Proxy needs | No information is | 656 | Information |additional storage to | maintained by the Join | 657 | |maintain mapping between | Proxy. Registrar needs | 658 | |the address and port number | to store the packet | 659 | |of the Pledge and those | header. | 660 | |of the Registrar. | | 661 +-------------+----------------------------+------------------------+ 662 |Packet size |The size of the forwarded |Size of the forwarded | 663 | |message is the same as the |message is bigger than | 664 | |original message. |the original,it includes| 665 | | |additional information | 666 +-------------+----------------------------+------------------------+ 667 |Specification|The Join Proxy needs |New JPY message to | 668 |complexity |additional functionality |encapsulate DTLS payload| 669 | |to maintain state |The Registrar | 670 | |information, and specify |and the Join Proxy | 671 | |the source and destination |have to understand the | 672 | |addresses of the DTLS |JPY message in order | 673 | |handshake messages |to process it. | 674 +-------------+----------------------------+------------------------+ 675 | Ports | Join Proxy needs |Join Proxy and Registrar| 676 | | discoverable join-port |need discoverable | 677 | | | join-ports | 678 +-------------+----------------------------+------------------------+ 680 Figure 5: Comparison between stateful and stateless mode 682 8. Security Considerations 684 All the concerns in [RFC8995] section 4.1 apply. The Pledge can be 685 deceived by malicious Join Proxy announcements. The Pledge will only 686 join a network to which it receives a valid [RFC8366] voucher 687 [I-D.ietf-anima-constrained-voucher]. Once the Pledge joined, the 688 payload between Pledge and Registrar is protected by DTLS. 690 A malicious constrained Join Proxy has a number of routing 691 possibilities: 693 * It sends the message on to a malicious Registrar. This is the 694 same case as the presence of a malicious Registrar discussed in 695 RFC 8995. 697 * It does not send on the request or does not return the response 698 from the Registrar. This is the case of the not responding or 699 crashing Registrar discussed in RFC 8995. 701 * It uses the returned response of the Registrar to enroll itself in 702 the network. With very low probability it can decrypt the 703 response. Successful enrollment is deemed too unlikely. 705 * It uses the request from the pledge to appropriate the pledge 706 certificate, but then it still needs to acquire the private key of 707 the pledge. Also this is assumed to be highly unlikely. 709 * A malicious node can construct an invalid Join Proxy message. 710 Suppose, the destination port is the coaps port. In that case, a 711 Join Proxy can accept the message and add the routing addresses 712 without checking the payload. The Join Proxy then routes it to 713 the Registrar. In all cases, the Registrar needs to receive the 714 message at the join-port, checks that the message consists of two 715 parts and uses the DTLS payload to start the BRSKI procedure. It 716 is highly unlikely that this malicious payload will lead to node 717 acceptance. 719 * A malicious node can sniff the messages routed by the constrained 720 Join Proxy. It is very unlikely that the malicious node can 721 decrypt the DTLS payload. A malicious node can read the header 722 field of the message sent by the stateless Join Proxy. This 723 ability does not yield much more information than the visible 724 addresses transported in the network packets. 726 It should be noted here that the contents of the CBOR array used to 727 convey return address information is not DTLS protected. When the 728 communication between JOIN Proxy and Registrar passes over an 729 unsecure network, an attacker can change the CBOR array, causing the 730 Registrar to deviate traffic from the intended Pledge. These 731 concerns are also expressed in [RFC8974]. It is also pointed out 732 that the encryption in the source is a local matter. Similarly to 733 [RFC8974], the use of AES-CCM [RFC3610] with a 64-bit tag is 734 recommended, combined with a sequence number and a replay window. 736 If such scenario needs to be avoided, the constrained Join Proxy MUST 737 encrypt the CBOR array using a locally generated symmetric key. The 738 Registrar is not able to examine the encrypted result, but does not 739 need to. The Registrar stores the encrypted header in the return 740 packet without modifications. The constrained Join Proxy can decrypt 741 the contents to route the message to the right destination. 743 In some installations, layer 2 protection is provided between all 744 member pairs of the mesh. In such an enviroment encryption of the 745 CBOR array is unnecessay because the layer 2 protection already 746 provide it. 748 9. IANA Considerations 750 9.1. Resource Type Attributes registry 752 This specification registers two new Resource Type (rt=) Link Target 753 Attributes in the "Resource Type (rt=) Link Target Attribute Values" 754 subregistry under the "Constrained RESTful Environments (CoRE) 755 Parameters" registry per the [RFC6690] procedure. 757 Attribute Value: brski.jp 758 Description: This BRSKI resource type is used to query and return 759 the supported BRSKI resources of the constrained 760 Join Proxy. 761 Reference: [this document] 763 Attribute Value: brski.rjp 764 Description: This BRSKI resource type is used for the constrained 765 Join Proxy to query and return Join Proxy specific 766 BRSKI resources of a Registrar. 767 Reference: [this document] 769 9.2. service name and port number registry 771 This specification registers two service names under the "Service 772 Name and Transport Protocol Port Number" registry. 774 Service Name: brski-jp 775 Transport Protocol(s): udp 776 Assignee: IESG 777 Contact: IESG 778 Description: Bootstrapping Remote Secure Key Infrastructure 779 constrained Join Proxy 780 Reference: [this document] 782 Service Name: brski-rjp 783 Transport Protocol(s): udp 784 Assignee: IESG 785 Contact: IESG 786 Description: Bootstrapping Remote Secure Key Infrastructure 787 Registrar join-port used by stateless constrained 788 Join Proxy 789 Reference: [this document] 791 10. Acknowledgements 793 Many thanks for the comments by Cartsen, Bormann, Brian Carpenter, 794 Esko Dijk, Toerless Eckert, Russ Housley, Ines Robles, Juergen 795 Schoenwaelder, Malisa Vučinić, and Rob Wilton. 797 11. Contributors 799 Sandeep Kumar, Sye loong Keoh, and Oscar Garcia-Morchon are the co- 800 authors of the draft-kumar-dice-dtls-relay-02. Their draft has 801 served as a basis for this document. Much text from their draft is 802 copied over to this draft. 804 12. Changelog 806 12.1. 10 to 09 808 * OPSDIR review 809 * IANA review 810 * SECDIR review 811 * GENART review 813 12.2. 09 to 07 815 * typos 817 12.3. 06 to 07 819 * AD review changes 821 12.4. 05 to 06 823 * RT value change to brski.jp and brski.rjp 824 * new registry values for IANA 825 * improved handling of jpy header array 827 12.5. 04 to 05 829 * Join Proxy and join-port consistent spelling 830 * some nits removed 831 * restructured discovery 832 * section 833 * rephrased parts of security section 835 12.6. 03 to 04 837 * mail address and reference 839 12.7. 02 to 03 841 * Terminology updated 842 * Several clarifications on discovery and routability 843 * DTLS payload introduced 845 12.8. 01 to 02 847 * Discovery of Join Proxy and Registrar ports 849 12.9. 00 to 01 851 * Registrar used throughout instead of EST server 853 * Emphasized additional Join Proxy port for Join Proxy and Registrar 855 * updated discovery accordingly 857 * updated stateless Join Proxy JPY header 859 * JPY header described with CDDL 861 * Example simplified and corrected 863 12.10. 00 to 00 865 * copied from vanderstok-anima-constrained-join-proxy-05 867 13. References 868 13.1. Normative References 870 [family] "Address Family Numbers", 19 October 2021, 871 . 874 [I-D.ietf-ace-coap-est] 875 Stok, P. V. D., Kampanakis, P., Richardson, M. C., and S. 876 Raza, "EST over secure CoAP (EST-coaps)", Work in 877 Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 878 January 2020, . 881 [I-D.ietf-anima-constrained-voucher] 882 Richardson, M., Stok, P. V. D., Kampanakis, P., and E. 883 Dijk, "Constrained Bootstrapping Remote Secure Key 884 Infrastructure (BRSKI)", Work in Progress, Internet-Draft, 885 draft-ietf-anima-constrained-voucher-17, 7 April 2022, 886 . 889 [ieee802-1AR] 890 "IEEE 802.1AR Secure Device Identifier", 2009, 891 . 893 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 894 Requirement Levels", BCP 14, RFC 2119, 895 DOI 10.17487/RFC2119, March 1997, 896 . 898 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 899 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 900 January 2012, . 902 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 903 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 904 May 2017, . 906 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 907 "A Voucher Artifact for Bootstrapping Protocols", 908 RFC 8366, DOI 10.17487/RFC8366, May 2018, 909 . 911 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 912 Representation (CBOR)", STD 94, RFC 8949, 913 DOI 10.17487/RFC8949, December 2020, 914 . 916 [RFC8990] Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic 917 Autonomic Signaling Protocol (GRASP)", RFC 8990, 918 DOI 10.17487/RFC8990, May 2021, 919 . 921 [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 922 and K. Watsen, "Bootstrapping Remote Secure Key 923 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 924 May 2021, . 926 13.2. Informative References 928 [I-D.ietf-6tisch-enrollment-enhanced-beacon] 929 (editor), D. D. and M. Richardson, "Encapsulation of 930 6TiSCH Join and Enrollment Information Elements", Work in 931 Progress, Internet-Draft, draft-ietf-6tisch-enrollment- 932 enhanced-beacon-14, 21 February 2020, 933 . 936 [I-D.kumar-dice-dtls-relay] 937 Kumar, S. S., Keoh, S. L., and O. Garcia-Morchon, "DTLS 938 Relay for Constrained Environments", Work in Progress, 939 Internet-Draft, draft-kumar-dice-dtls-relay-02, 20 October 940 2014, . 943 [I-D.richardson-anima-state-for-joinrouter] 944 Richardson, M. C., "Considerations for stateful vs 945 stateless join router in ANIMA bootstrap", Work in 946 Progress, Internet-Draft, draft-richardson-anima-state- 947 for-joinrouter-03, 22 September 2020, 948 . 951 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 952 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 953 2003, . 955 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 956 "Transmission of IPv6 Packets over IEEE 802.15.4 957 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 958 . 960 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 961 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 962 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 963 Low-Power and Lossy Networks", RFC 6550, 964 DOI 10.17487/RFC6550, March 2012, 965 . 967 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 968 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 969 . 971 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 972 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 973 . 975 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 976 Bormann, "Neighbor Discovery Optimization for IPv6 over 977 Low-Power Wireless Personal Area Networks (6LoWPANs)", 978 RFC 6775, DOI 10.17487/RFC6775, November 2012, 979 . 981 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 982 "Enrollment over Secure Transport", RFC 7030, 983 DOI 10.17487/RFC7030, October 2013, 984 . 986 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 987 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 988 2014, . 990 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 991 Constrained-Node Networks", RFC 7228, 992 DOI 10.17487/RFC7228, May 2014, 993 . 995 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 996 Application Protocol (CoAP)", RFC 7252, 997 DOI 10.17487/RFC7252, June 2014, 998 . 1000 [RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and 1001 Stateless Clients in the Constrained Application Protocol 1002 (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021, 1003 . 1005 Appendix A. Stateless Proxy payload examples 1007 The examples show the request "GET coaps://192.168.1.200:5965/est/ 1008 crts" to a Registrar. The header generated between Join Proxy and 1009 Registrar and from Registrar to Join Proxy are shown in detail. The 1010 DTLS payload is not shown. 1012 The request from Join Proxy to Registrar looks like: 1014 85 # array(5) 1015 50 # bytes(16) 1016 FE800000000000000000FFFFC0A801C8 # 1017 19 BDA7 # unsigned(48551) 1018 01 # unsigned(1) IP 1019 00 # unsigned(0) 1020 58 2D # bytes(45) 1021 1023 In CBOR Diagnostic: 1025 [h'FE800000000000000000FFFFC0A801C8', 48551, 1, 0, 1026 h''] 1028 The response is: 1030 85 # array(5) 1031 50 # bytes(16) 1032 FE800000000000000000FFFFC0A801C8 # 1033 19 BDA7 # unsigned(48551) 1034 01 # unsigned(1) IP 1035 00 # unsigned(0) 1036 59 026A # bytes(618) 1037 1039 In CBOR diagnostic: 1041 [h'FE800000000000000000FFFFC0A801C8', 48551, 1, 0, 1042 h''] 1044 Authors' Addresses 1046 Michael Richardson 1047 Sandelman Software Works 1048 Email: mcr+ietf@sandelman.ca 1050 Peter van der Stok 1051 vanderstok consultancy 1052 Email: stokcons@bbhmail.nl 1054 Panos Kampanakis 1055 Cisco Systems 1056 Email: pkampana@cisco.com