idnits 2.17.1 draft-vanderstok-constrained-anima-dtls-join-proxy-00.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 (September 29, 2018) is 2037 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-ace-cbor-web-token' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-object-security' is defined on line 302, but no explicit reference was found in the text == Unused Reference: 'ieee802-1AR' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'RFC7250' is defined on line 330, but no explicit reference was found in the text == Unused Reference: 'RFC7950' is defined on line 336, but no explicit reference was found in the text == Unused Reference: 'RFC8152' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'RFC6690' is defined on line 370, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-ace-coap-est-05 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-16 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-15 -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802-1AR' ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 4 errors (**), 0 flaws (~~), 12 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: April 2, 2019 vanderstok consultancy 6 P. Kampanakis 7 Cisco Systems 8 September 29, 2018 10 Constrained Join Proxy for Bootstrapping Protocols 11 draft-vanderstok-constrained-anima-dtls-join-proxy-00 13 Abstract 15 This document defines a protocol to securely assign a pledge to an 16 owner, using an intermediary node between pledge and owner. This 17 intermediary node is known as a "constrained-join-proxy". 19 This document extends the work of 20 [I-D.ietf-anima-bootstrapping-keyinfra] by replacing the Circuit- 21 proxy by a stateless constrained join-proxy, that uses IP 22 encapsulation. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 2, 2019. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 61 4. Join Proxy functionality . . . . . . . . . . . . . . . . . . 3 62 5. Join Proxy specification . . . . . . . . . . . . . . . . . . 4 63 6. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 67 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 11.2. Informative References . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 Enrolment of new nodes into constrained networks with constrained 76 nodes present is described in [I-D.ietf-anima-bootstrapping-keyinfra] 77 and makes use of Enrolment over Secure Transport (EST) [RFC7030]. 78 The specified solutions use https and may be too large in terms of 79 code space or bandwidth required. Constrained devices in constrained 80 networks [RFC7228] typically implement the IPv6 over Low-Power 81 Wireless personal Area Networks (6LoWPAN) [RFC4944] and Constrained 82 Application Protocol (CoAP) [RFC7252]. 84 CoAP has chosen Datagram Transport Layer Security (DTLS) [RFC6347] as 85 the preferred security protocol for authenticity and confidentiality 86 of the messages. A constrained version of EST, using Coap and DTLS, 87 is described in [I-D.ietf-ace-coap-est]. 89 DTLS is a client-server protocol relying on the underlying IP layer 90 to perform the routing between the DTLS Client and the DTLS Server. 91 However, the new "joining" device will not be IP routable until it is 92 authenticated to the network. A new "joining" device can only 93 initially use a link-local IPv6 address to communicate with a 94 neighbour node using neighbour discovery [RFC6775] until it receives 95 the necessary network configuration parameters. However, before the 96 device can receive these configuration parameters, it needs to 97 authenticate itself to the network to which it connects. In 98 [I-D.ietf-anima-bootstrapping-keyinfra] Enrolment over Secure 99 Transport (EST) [RFC7030] is used to authenticate the joining device. 100 However, IPv6 routing is necessary to establish a connection between 101 joining device and the EST server. 103 This document specifies a Join-proxy and protocol to act as 104 intermediary between joining device and EST server to establish a 105 connection between joining device and EST server. 107 This document is very much inspired by text published earlier in 108 [I-D.kumar-dice-dtls-relay]. 110 2. Terminology 112 The following terms are defined in [RFC8366], and are used 113 identically as in that document: artifact, imprint, domain, Join 114 Registrar/Coordinator (JRC), Manufacturer Authorized Signing 115 Authority (MASA), pledge, Trust of First Use (TOFU), and Voucher. 117 3. Requirements Language 119 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 120 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 121 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 122 [RFC2119] and indicate requirement levels for compliant STuPiD 123 implementations. 125 4. Join Proxy functionality 127 As depicted in the Figure 1, the joining Device, or pledge (P), is 128 more than one hop away from the EST server (E) and not yet 129 authenticated into the network. At this stage, it can only 130 communicate one-hop to its nearest neighbour, the Join proxy (J) 131 using their link-local IPv6 addresses. However, the Device needs to 132 communicate with end-to-end security with a Registrar hosting the EST 133 server (E) to authenticate and get the relevant system/network 134 parameters. If the Pledge (P) initiates a DTLS connection to the EST 135 server whose IP address has been pre-configured, then the packets are 136 dropped at the Join Proxy (J) since the Pledge (P) is not yet 137 admitted to the network or there is no IP routability to Pledge (P) 138 for any returned messages. 140 ++++ 141 |E |---- +--+ +--+ 142 | | \ |J |........|P | 143 ++++ \-----| | | | 144 EST server +--+ +--+ 145 REgistrar Join Proxy PLedge 146 "Joining" Device 148 Figure 1: multi-hop enrolment. 150 Furthermore, the Pledge (P) may wish to establish a secure connection 151 to the EST server (E) in the network assuming appropriate credentials 152 are exchanged out-of-band, e.g. a hash of the Pledge (P)'s raw public 153 key could be provided to the EST server (E). However, the Pledge (P) 154 is unaware of the IP address of the EST-server (E) to initiate a DTLS 155 connection and perform authentication with. 157 An DTLS connection is required between Pledge and EST server. To 158 overcome the problems with non-routability of DTLS packets and/ or 159 discovery of the destination address of the EST Server to contact, 160 the Join Proxy is introduced. This Join-Proxy functionality is 161 configured into all authenticated devices in the network which may 162 act as the Join Proxy (J) for newly joining nodes. The Join Proxy 163 allows for routing of the packets from the Pledge (P) using IP 164 routing to the intended EST Server. 166 5. Join Proxy specification 168 In this section, the constrained Join Proxy functionality is 169 specified using DTLS and coaps. When a joining device as a client 170 attempts a DTLS connection to the EST server, it uses its link- local 171 IP address as its IP source address. This message is transmitted 172 one-hop to a neighbour node. Under normal circumstances, this 173 message would be dropped at the neighbour node since the joining 174 device is not yet IP routable or it is not yet authenticated to send 175 messages through the network. However, if the neighbour device has 176 the Join Proxy functionality enabled, it routes the DTLS message to a 177 specific EST Server. Additional security mechanisms need to exist to 178 prevent this routing functionality being used by rogue nodes to 179 bypass any network authentication procedures. 181 The Join-proxy is stateless to minimize the requirements on the 182 constrained Join-proxy device. 184 If an untrusted DTLS Client that can only use link-local addressing 185 wants to contact a trusted end-point EST Server, it sends the DTLS 186 message to the Join Proxy. The Join Proxy encapsulates this message 187 into a new type of message called Join ProxY (JPY) message. The JPY 188 message consists of two parts: 190 o Header (H) field: consisting of the source link-local address and 191 port of the DTLS Client device, and 193 o Contents (C) field: containing the original DTLS message. 195 On receiving the JPY message, the EST Server decapsulates it to 196 retrieve the two parts. It uses the Header field information to 197 transiently store the DTLS Client's address and port. The EST Server 198 then performs the normal DTLS operations on the DTLS message from the 199 Contents field. However, when the EST Server replies, it also 200 encapsulates its DTLS message in a JPY message back to the Join 201 Proxy. The Header contains the original source link-local address 202 and port of the DTLS Client from the transient state stored earlier 203 (which can now be discarded) and the Contents field contains the DTLS 204 message. 206 On receiving the JPY message, the Join Proxy decapsulates it to 207 retrieve the two parts. It uses the Header field to route the DTLS 208 message retrieved from the Contents field to the joining node. 210 The Figure 2 depicts the message flow diagram when the EST Server 211 end-point address is known only to the Join Proxy: 213 +--------------+------------+---------------+-----------------------+ 214 | EST Client | Join Proxy | EST server | Message | 215 | (P) | (J) | (E) |Src_IP:port|Dst_IP:port| 216 +--------------+------------+---------------+-----------+-----------+ 217 | --ClientHello--> | IP_C:p_C |IP_Ra:5684 | 218 | --JPY[H(IP_C:p_C),--> | IP_Rb:p_Rb|IP_S:5684 | 219 | C(ClientHello)] | | | 220 | <--JPY[H(IP_C:p_C),-- | IP_S:5684 |IP_Rb:p_Rb | 221 | C(ServerHello)] | | | 222 | <--ServerHello-- | IP_Ra:5684|IP_C:p_C | 223 | : | | | 224 | : | : | : | 225 | | : | : | 226 | --Finished--> | IP_C:p_C |IP_Ra:5684 | 227 | --JPY[H(IP_C:p_C),--> | IP_Rb:p_Rb|IP_S:5684 | 228 | C(Finished)] | | | 229 | <--JPY[H(IP_C:p_C),-- | IP_S:5684 |IP_Rb:p_Rb | 230 | C(Finished)] | | | 231 | <--Finished-- | IP_Ra:5684|IP_C:p_C | 232 | : | : | : | 233 +-------------------------------------------+-----------+-----------+ 234 IP_C:p_C = Link-local IP address and port of DTLS Client 235 IP_S:5684 = IP address and coaps port of DTLS Server 236 IP_Ra:5684 = Link-local IP address and coaps port of DTLS Relay 237 IP_Rb:p_Rb = IP address(can be same as IP_Ra) and port of DTLS Relay 239 JPY[H(),C()] = Join Proxy message with header H and content C 241 Figure 2: constrained joining message flow. 243 6. Protocol 245 The JPY message is constructed as a single untagged [RFC7049] CBOR 246 map. The contents of the map include: 248 1: the pledge IPv6 Link Local address as a 16-byte binary value. 250 2: the pledge's UDP port number, if different from 5684, as a CBOR 251 integer. 253 3: the proxy's ifindex or other identifier for the physical port on 254 which the pledge is connected. 256 4: the contents of the UDP (DTLS) message received from the pledge. 258 (INSERT CDDL notation) 260 7. Security Considerations 262 It should be noted here that the contents of the CBOR map are not 263 protected, but that the communication is between the Proxy and a 264 known registrar (a connected UDP socket), and that messages from 265 other origins are ignored. 267 8. IANA Considerations 269 This document needs to create a registry for key indexes in the CBOR 270 map. It should be given a name, and the amending formula should be 271 IETF Specification. 273 9. Acknowledgements 275 Much of this text is inspired by [I-D.kumar-dice-dtls-relay]. 277 10. Changelog 279 empty 281 11. References 283 11.1. Normative References 285 [I-D.ietf-ace-cbor-web-token] 286 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 287 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15 288 (work in progress), March 2018. 290 [I-D.ietf-ace-coap-est] 291 Stok, P., Kampanakis, P., Kumar, S., Richardson, M., 292 Furuhed, M., and S. Raza, "EST over secure CoAP (EST- 293 coaps)", draft-ietf-ace-coap-est-05 (work in progress), 294 July 2018. 296 [I-D.ietf-anima-bootstrapping-keyinfra] 297 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 298 S., and K. Watsen, "Bootstrapping Remote Secure Key 299 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 300 keyinfra-16 (work in progress), June 2018. 302 [I-D.ietf-core-object-security] 303 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 304 "Object Security for Constrained RESTful Environments 305 (OSCORE)", draft-ietf-core-object-security-15 (work in 306 progress), August 2018. 308 [ieee802-1AR] 309 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 310 2009, . 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, 315 DOI 10.17487/RFC2119, March 1997, 316 . 318 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 319 RFC 5652, DOI 10.17487/RFC5652, September 2009, 320 . 322 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 323 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 324 January 2012, . 326 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 327 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 328 October 2013, . 330 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 331 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 332 Transport Layer Security (TLS) and Datagram Transport 333 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 334 June 2014, . 336 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 337 RFC 7950, DOI 10.17487/RFC7950, August 2016, 338 . 340 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 341 RFC 8152, DOI 10.17487/RFC8152, July 2017, 342 . 344 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 345 "A Voucher Artifact for Bootstrapping Protocols", 346 RFC 8366, DOI 10.17487/RFC8366, May 2018, 347 . 349 11.2. Informative References 351 [duckling] 352 Stajano, F. and R. Anderson, "The resurrecting duckling: 353 security issues for ad-hoc wireless networks", 1999, 354 . 357 [I-D.kumar-dice-dtls-relay] 358 Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay 359 for Constrained Environments", draft-kumar-dice-dtls- 360 relay-02 (work in progress), October 2014. 362 [pledge] Dictionary.com, ., "Dictionary.com Unabridged", 2015, 363 . 365 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 366 "Transmission of IPv6 Packets over IEEE 802.15.4 367 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 368 . 370 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 371 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 372 . 374 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 375 Bormann, "Neighbor Discovery Optimization for IPv6 over 376 Low-Power Wireless Personal Area Networks (6LoWPANs)", 377 RFC 6775, DOI 10.17487/RFC6775, November 2012, 378 . 380 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 381 "Enrollment over Secure Transport", RFC 7030, 382 DOI 10.17487/RFC7030, October 2013, 383 . 385 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 386 Constrained-Node Networks", RFC 7228, 387 DOI 10.17487/RFC7228, May 2014, 388 . 390 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 391 Application Protocol (CoAP)", RFC 7252, 392 DOI 10.17487/RFC7252, June 2014, 393 . 395 Authors' Addresses 397 Michael Richardson 398 Sandelman Software Works 400 Email: mcr+ietf@sandelman.ca 401 Peter van der Stok 402 vanderstok consultancy 404 Email: consultancy@vanderstok.org 406 Panos Kampanakis 407 Cisco Systems 409 Email: pkampana@cisco.com