idnits 2.17.1 draft-ietf-6tisch-dtsecurity-zerotouch-join-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.ietf-6tisch-minimal-security], [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 == Line 292 has weird spacing: '... pledge the p...' == Line 296 has weird spacing: '...ed Node the p...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 22, 2018) is 2013 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-6tisch-minimal' is defined on line 1247, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-grasp' is defined on line 1286, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-yang-cbor' is defined on line 1307, but no explicit reference was found in the text == Unused Reference: 'RFC6775' is defined on line 1384, but no explicit reference was found in the text == Unused Reference: 'RFC7217' is defined on line 1395, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-sid' is defined on line 1441, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-useofrplinfo' is defined on line 1446, but no explicit reference was found in the text == Unused Reference: 'ISA100' is defined on line 1451, but no explicit reference was found in the text == Unused Reference: 'RFC7554' is defined on line 1476, but no explicit reference was found in the text == Unused Reference: 'RFC7731' is defined on line 1487, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-06 == Outdated reference: A later version (-18) exists of draft-ietf-ace-coap-est-06 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-16 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-02 == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-03 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-15 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-07 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-06 == Outdated reference: A later version (-03) exists of draft-schaad-cose-x509-02 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-10 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-18 == Outdated reference: A later version (-24) exists of draft-ietf-core-sid-04 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-23 Summary: 1 error (**), 0 flaws (~~), 27 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6tisch Working Group M. Richardson 3 Internet-Draft Sandelman Software Works 4 Intended status: Informational October 22, 2018 5 Expires: April 25, 2019 7 6tisch Zero-Touch Secure Join protocol 8 draft-ietf-6tisch-dtsecurity-zerotouch-join-03 10 Abstract 12 This document describes a Zero-touch Secure Join (ZSJ) mechanism to 13 enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network 14 using the 6tisch signaling mechanisms. The resulting device will 15 obtain a domain specific credential that can be used with either 16 802.15.9 per-host pair keying protocols, or to obtain the network- 17 wide key from a coordinator. The mechanism describe here is an 18 augmentation to the one-touch mechanism described in 19 [I-D.ietf-6tisch-minimal-security], and a constrained version of 20 [I-D.ietf-anima-bootstrapping-keyinfra]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 25, 2019. 39 Copyright Notice 41 Copyright (c) 2018 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 6 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 59 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 7 60 1.3.1. Support environment . . . . . . . . . . . . . . . . . 8 61 1.3.2. Constrained environments . . . . . . . . . . . . . . 8 62 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 8 63 1.4. Leveraging the new key infrastructure / next steps . . . 8 64 1.4.1. Key Distribution Process . . . . . . . . . . . . . . 8 65 1.5. Requirements for Autonomic Network Infrastructure (ANI) 66 devices . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 8 68 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 9 69 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 10 70 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 10 71 2.3.1. Identification of the Pledge . . . . . . . . . . . . 11 72 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 12 73 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 12 74 2.5. Architectural Components . . . . . . . . . . . . . . . . 13 75 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 13 76 2.5.2. Stateless IPIP Join Proxy . . . . . . . . . . . . . . 13 77 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 13 78 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 14 79 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 14 80 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 14 81 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 14 82 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 14 83 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 14 84 2.8. Determining the MASA to contact . . . . . . . . . . . . . 15 85 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 15 86 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 15 87 5. Proxy details . . . . . . . . . . . . . . . . . . . . . . . . 15 88 5.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 15 89 5.2. CoAP connection to Registrar . . . . . . . . . . . . . . 16 90 5.3. HTTPS proxy connection to Registrar . . . . . . . . . . . 16 91 5.4. Proxy discovery of Registrar . . . . . . . . . . . . . . 16 92 6. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 16 93 6.1. BRSKI-EST (D)TLS establishment details . . . . . . . . . 17 94 6.1.1. BRSKI-EST CoAP/DTLS estasblishment details . . . . . 17 95 6.1.2. BRSKI-EST CoAP/EDHOC estasblishment details . . . . . 17 96 6.2. Pledge Requests Voucher from the Registrar . . . . . . . 19 97 6.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 19 98 6.4. Registrar Requests Voucher from MASA . . . . . . . . . . 19 99 6.4.1. MASA renewal of expired vouchers . . . . . . . . . . 20 100 6.4.2. MASA verification of voucher-request signature 101 consistency . . . . . . . . . . . . . . . . . . . . . 20 102 6.4.3. MASA authentication of registrar (certificate) . . . 20 103 6.4.4. MASA revocation checking of registrar (certificate) . 20 104 6.4.5. MASA verification of pledge prior-signed-voucher- 105 request . . . . . . . . . . . . . . . . . . . . . . . 21 106 6.4.6. MASA pinning of registrar . . . . . . . . . . . . . . 21 107 6.4.7. MASA nonce handling . . . . . . . . . . . . . . . . . 21 108 6.5. MASA Voucher Response . . . . . . . . . . . . . . . . . . 21 109 6.5.1. Pledge voucher verification . . . . . . . . . . . . . 22 110 6.5.2. Pledge authentication of provisional TLS connection . 22 111 6.6. Pledge Voucher Status Telemetry . . . . . . . . . . . . . 22 112 6.7. Registrar audit log request . . . . . . . . . . . . . . . 22 113 6.7.1. MASA audit log response . . . . . . . . . . . . . . . 22 114 6.7.2. Registrar audit log verification . . . . . . . . . . 22 115 6.8. EST Integration for PKI bootstrapping . . . . . . . . . . 22 116 6.8.1. EST Distribution of CA Certificates . . . . . . . . . 22 117 6.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 23 118 6.8.3. EST Client Certificate Request . . . . . . . . . . . 23 119 6.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 23 120 6.8.5. Multiple certificates . . . . . . . . . . . . . . . . 23 121 6.8.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 23 122 6.9. Use of Secure Transport for Minimal Join . . . . . . . . 23 123 7. Reduced security operational modes . . . . . . . . . . . . . 24 124 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 24 125 7.2. Pledge security reductions . . . . . . . . . . . . . . . 24 126 7.3. Registrar security reductions . . . . . . . . . . . . . . 24 127 7.4. MASA security reductions . . . . . . . . . . . . . . . . 24 128 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 129 8.1. Well-known EST registration . . . . . . . . . . . . . . . 24 130 8.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 24 131 8.3. Voucher Status Telemetry . . . . . . . . . . . . . . . . 24 132 8.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 25 133 8.5. MUD File Extension for the MASA server . . . . . . . . . 25 134 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25 135 9.1. Privacy Considerations for Production network . . . . . . 25 136 9.2. Privacy Considerations for New Pledges . . . . . . . . . 25 137 9.2.1. EUI-64 derived address for join time IID . . . . . . 26 138 9.3. Privacy Considerations for Join Proxy . . . . . . . . . . 26 139 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26 140 10.1. Security of MASA voucher signing key(s) . . . . . . . . 26 141 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 142 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 143 12.1. Normative References . . . . . . . . . . . . . . . . . . 27 144 12.2. Informative References . . . . . . . . . . . . . . . . . 31 146 Appendix A. Extra text . . . . . . . . . . . . . . . . . . . . . 32 147 A.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 32 148 A.1.1. One-Touch Assumptions . . . . . . . . . . . . . . . . 32 149 A.1.2. Factory provided credentials (if any) . . . . . . . . 33 150 A.1.3. Credentials to be introduced . . . . . . . . . . . . 33 151 A.2. Network Assumptions . . . . . . . . . . . . . . . . . . . 33 152 A.2.1. Security above and below IP . . . . . . . . . . . . . 33 153 A.2.2. Join network assumptions . . . . . . . . . . . . . . 34 154 A.2.3. Number and cost of round trips . . . . . . . . . . . 35 155 A.2.4. Size of packets, number of fragments . . . . . . . . 35 156 A.3. Target end-state for join process . . . . . . . . . . . . 35 157 Appendix B. Join Protocol . . . . . . . . . . . . . . . . . . . 35 158 B.1. Key Agreement process . . . . . . . . . . . . . . . . . . 36 159 B.2. Provisional Enrollment process . . . . . . . . . . . . . 36 160 Appendix C. IANA Considerations . . . . . . . . . . . . . . . . 37 161 Appendix D. Protocol Definition . . . . . . . . . . . . . . . . 37 162 D.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 37 163 D.1.1. Proxy Discovery Protocol Details . . . . . . . . . . 38 164 D.1.2. Registrar Discovery Protocol Details . . . . . . . . 38 165 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38 167 1. Introduction 169 Enrollment of new nodes into LLNs present unique challenges. The 170 constrained nodes has no user interfaces, and even if they did, 171 configuring thousands of such nodes manually is undesireable from a 172 human resources issue, as well as the difficulty in getting 173 consistent results. 175 This document is about a standard way to introduce new nodes into a 176 6tisch network that does not involve any direct manipulation of the 177 nodes themselves. This act has been called "zero-touch" 178 provisioning, and it does not occur by chance, but requires 179 coordination between the manufacturer of the node, the service 180 operator running the LLN, and the installers actually taking the 181 devices out of the shipping boxes. 183 This document is a constrained profile of 184 [I-D.ietf-anima-bootstrapping-keyinfra]. The above document/protocol 185 is referred by by it's acronym: BRSKI. The pronounciation of which 186 is "brew-ski", a common north american slang for beer with a pseudo- 187 polish ending. This constrained protocol is called ZSJ (pronounced 188 zees-Jay). 190 This document follows the same structure as BRSKI in order to 191 emphasize the similarities, but specializes a number of things to 192 constrained networks of constrained devices. Like 193 [I-D.ietf-anima-bootstrapping-keyinfra], the networks which are in 194 scope for this protocol are deployed by a professional operator. The 195 deterministic mechanisms which have been designed into 6tisch have 196 been created to satisfy the operational needs of industrial settings 197 where such an operator exists. 199 This document builds upon the "one-touch" provisioning described in 200 [I-D.ietf-6tisch-minimal-security], reusing the OSCOAP Join Request 201 mechanism when appropriate, but preceeding it with either the EDHOC 202 key agreement protocol, or a DTLS setup process. The [RFC7030] EST 203 protocol extended in [I-D.ietf-6tisch-minimal-security], has been 204 mapped by [I-D.ietf-ace-coap-est] into CoAP, and has the same 205 security profile as this protocol. 207 Whenever possible, this document does not introduce new protocols or 208 mechanisms, but rather integrates them from other documents. 210 Otherwise, this document follows BRSKI with the following high-level 211 changes: 213 o HTTP is replaced with CoAP. 215 o TLS (HTTPS) is replaced with either DTLS+CoAP, or EDHOC/ 216 OSCOAP+CoAP 218 o the domain-registrar anchor certificate is replaced with a Raw 219 Public Key (RPK) using [RFC7250]. 221 o the PKCS7 signed JSON voucher format is replaced with CWT 223 o the GRASP discovery mechanism for the Proxy is replaced with an 224 announcement in the Enhanced Beacon 225 [I-D.richardson-6tisch-join-enhanced-beacon] 227 o the TCP circuit proxy mechanism is not used. The IPIP mechanism 228 if mandatory to implement when deployed with DTLS, while the CoAP 229 based stateless proxy mechanism is used for OSCOAP/EDHOC. 231 o real time clocks are assumed to be unavailable, so expiry dates in 232 ownership vouchers are never used 234 o nonce-full vouchers are encouraged, but off-line nonce-less 235 operation is also supported, however, the resulting vouchers have 236 infinite life. 238 802.1AR Client Certificates (IDevID) are retained, but optionally are 239 specified by reference rather than value. 241 It is expected that the back-end network operator infrastructure 242 would be able to bootstrap ANIMA BRSKI-type devices over ethernet, 243 while also being able bootstrap 6tisch devices over 802.15.4 with few 244 changes. 246 NOTE TO RFC-EDITOR: during production of this document, it was 247 matched against [I-D.ietf-anima-bootstrapping-keyinfra] section by 248 section. This results in a few sections, such as IANA Considerations 249 where there is no requested activity. Those sections are marked "NO 250 ACTION, PLEASE REMOVE" and should be removed (along with this 251 paragraph) from the final document. Some sections are marked as "no 252 changes" and should be left in place so that the section numbering 253 remains consistent with [I-D.ietf-anima-bootstrapping-keyinfra]. 255 1.1. Prior Bootstrapping Approaches 257 Constrained devices as used in industrial control systems are usually 258 installed (or replaced) by technicians with expertise in the 259 equipment being serviced, not in secure enrollment of devices. 261 Devices therefore are typically pre-configured in advance, marked for 262 a particular factory, assembly line, or even down to the specific 263 machine. It is not uncommon for manufacturers to have a product code 264 (stock keeping unit -SKU) for each part, and for each customer as the 265 part will be loaded with customer specifc security configuration. 266 The resulting customer-specific parts are hard to inventory and 267 spare, and should parts be delivered to the wrong customer, 268 determining the reason for inability to configure is difficult and 269 time consuming. 271 End-user actions to configure the part at the time of installation, 272 aside from being error prone, also suffer from requiring a part that 273 has an interface. 275 1.2. Terminology 277 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 278 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 279 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 280 [RFC2119] and indicate requirement levels for compliant STuPiD 281 implementations. 283 The reader is expected to be familiar with the terms and concepts 284 defined in [I-D.ietf-6tisch-terminology], [RFC7252], 285 [I-D.ietf-core-object-security], and 286 [I-D.ietf-anima-bootstrapping-keyinfra]. The following terms are 287 imported: drop ship, imprint, enrollment, pledge, join proxy, 288 ownership voucher, join registrar/coordinator. The following terms 289 are repeated here for readability, but this document is not 290 authoritative for their definition: 292 pledge the prospective device, which has the identity provided to at 293 the factory. Neither the device nor the network knows if the 294 device yet knows if this device belongs with this network. 296 Joined Node the prospective device, after having completing the join 297 process, often just called a Node. 299 Join Proxy (JP): a stateless relay that provides connectivity 300 between the pledge and the join registrar/coordinator. 302 Join Registrar/Coordinator (JRC): central entity responsible for 303 authentication and authorization of joining nodes. 305 Audit Token A signed token from the manufacturer authorized signing 306 authority indicating that the bootstrapping event has been 307 successfully logged. This has been referred to as an 308 "authorization token" indicating that it authorizes bootstrapping 309 to proceed. 311 Ownership Voucher A signed voucher from the vendor vouching that a 312 specific domain "owns" the new entity as defined in 313 [I-D.ietf-anima-voucher]. 315 MIC manufacturer installed certificate. An [ieee802-1AR] identity. 316 Not to be confused with a (cryptographic) "Message Integrity 317 Check" 319 1.3. Scope of solution 321 The solution described in this document is appropriate to enrolling 322 between hundreds to hundreds of thousands of diverse devices into a 323 network without any prior contact with the devices. The devices 324 could be shipped by the manufacturer directly to the customer site 325 without ever being seen by the operator of the network. As described 326 in BRSKI, in the audit-mode of operation the device will be claimed 327 by the first network that sees it. In the tracked owner mode of 328 operation, sales channel integration provides a strong connection 329 that the operator of the network is the legitimate owner of the 330 device. 332 BRSKI describes a more general, more flexible approach for 333 bootstrapping devices into an ISP or Enterprise network. 335 [I-D.ietf-6tisch-minimal-security] provides an extremely streamlined 336 approach to enrolling from hundreds to thousands of devices into a 337 network, provided that a unique secret key can be installed in each 338 device. 340 1.3.1. Support environment 342 TBD 344 1.3.2. Constrained environments 346 TBD 348 1.3.3. Network Access Controls 350 TBD 352 1.4. Leveraging the new key infrastructure / next steps 354 In constrained networks, it is unlikely that an ACP be formed. This 355 document does not preclude such a thing, but it is not mandated. 357 The resulting secure channel MAY be used just to distribute network- 358 wide keys using a protocol such as 359 [I-D.ietf-6tisch-minimal-security]. (XXX - do we need to signal this 360 somehow?) 362 The resulting secure channel MAY be instead used to do an enrollment 363 of an LDevID as in BRSKI, but the resulting certificate is used to do 364 per-pair keying such as described by {{ieee802159}. 366 1.4.1. Key Distribution Process 368 In addition to being used for the initial enrollment process, the 369 secure channel may be kept open (and reversed) to use for network 370 rekeying. Such a process is out of scope of this document, please 371 see future work such as [I-D.richardson-6tisch-minimal-rekey]. 373 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices 375 TBD 377 2. Architectural Overview 379 Section 2 of BRSKI has a diagram with all of the components shown 380 together. There are no significant changes to the diagram. 382 The use of a circuit proxy is not mandated. Instead the IPIP 383 mechanism described in appendix C ("IPIP Join Proxy mechanism") 384 SHOULD be be used instead as it supports both DTLS, EDHOC and OSCOAP 385 protocols. 387 The CoAP proxy mechanism MAY be implemented instead: the decision 388 depends upon the capabilities of the Registrar and the proxy. A 389 mechanism is included for the Registrar to announce it's capabilities 390 (XXX) 392 2.1. Behavior of a Pledge 394 The pledge goes through a series of steps which are outlined here at 395 a high level. 397 +--------------+ 398 | Factory | 399 | default | 400 +------+-------+ 401 | 402 +------v-------+ 403 | (1) Discover | 404 +------------> | 405 | +------+-------+ 406 | | 407 | +------v-------+ 408 | | (2) Identity | 409 ^------------+ | 410 | rejected +------+-------+ 411 | | 412 | +------v-------+ 413 | | (3) Request | 414 | | Join | 415 | +------+-------+ 416 | | 417 | +------v-------+ 418 | | (4) Imprint | 419 ^------------+ | 420 | Bad MASA +------+-------+ 421 | response | send Voucher Status Telemetry 422 | +------v-------+ 423 | | (5) Enroll | 424 ^------------+ | 425 | Enroll +------+-------+ 426 | Failure | 427 | +------v-------+ 428 | | (6) Enrolled | 429 ^------------+ | 430 Factory +--------------+ 431 reset 433 State descriptions for the pledge are as follows: 435 1. Discover a communication channel to a Registrar. This is done by 436 listening for beacons as described by 437 [I-D.richardson-anima-6join-discovery] 439 2. Identify itself. This is done by presenting an X.509 IDevID 440 credential to the discovered Registrar (via the Proxy) in a DTLS 441 or EDHOC handshake. (The Registrar credentials are only 442 provisionally accepted at this time). 444 The registrar identifies itself using a raw public key, while the 445 the pledge identifies itself to the registrar using an IDevID 446 credential. 448 3. Requests to Join the discovered Registrar. A unique nonce can be 449 included ensuring that any responses can be associated with this 450 particular bootstrapping attempt. 452 4. Imprint on the Registrar. This requires verification of the 453 vendor service (MASA) provided voucher. A voucher contains 454 sufficient information for the Pledge to complete authentication 455 of a Registrar. The voucher is signed by the vendor (MASA) using 456 a raw public key, previously installed into the pledge at 457 manufacturing time. 459 5. Optionally Enroll. By accepting the domain specific information 460 from a Registrar, and by obtaining a domain certificate from a 461 Registrar using a standard enrollment protocol, e.g. Enrollment 462 over Secure Transport (EST) [RFC7030]. 464 6. The Pledge is now a member of, and can be managed by, the domain 465 and will only repeat the discovery aspects of bootstrapping if it 466 is returned to factory default settings. 468 2.2. Secure Imprinting using Vouchers 470 As in BRSKI, the format and cryptographic mechansim of vouchers is 471 described in detail in [I-D.ietf-anima-voucher]. As described in 472 section YYY, the physical format for vouchers in this document 473 differs from that of BRSKI, in that it uses 474 [I-D.ietf-ace-cbor-web-token] to encode the voucher and to sign it. 476 2.3. Initial Device Identifier 478 The essential component of the zero-touch operation is that the 479 pledge is provisioned with an 802.1AR (PKIX) certificate installed 480 during the manufacturing process. 482 It is expected that constrained devices will use a signature 483 algorithm corresponding to the hardware acceleration that they have, 484 if they have any. The anticipated algorithms are the ECDSA P-256 485 (secp256p1), and SHOULD be supported. Newer devices SHOULD begin to 486 appear using EdDSA curves using the 25519 curves. 488 The manufacturer will always know what algorithms are available in 489 the Pledge, and will use an appropriate one. The other components 490 that need to evaluate the IDevID (the Registrar and MASA) are 491 expected to support all common algorithms. 493 There are a number of simplications detailed later on in this 494 document designed to eliminate the need for an ASN.1 parser in the 495 pledge. 497 The pledge should consider it's 802.1AR certificate to be an opaque 498 blob of bytes, to be inserted into protocols at appropriate places. 499 The pledge SHOULD have access to it's public and private keys in the 500 most useable native format for computation. 502 The pledge MUST have the public key of the MASA built in a 503 manufacturer time. This is a seemingly identical requirement as for 504 BRSKI, but rather than being an abstract trust anchor that can be 505 augmented with a certificate chain, the pledge MUST be provided with 506 the Raw Public Key that the MASA will use to sign vouchers for that 507 pledge. 509 There are a number of security concerns with use of a single MASA 510 signing key, and section Section 10.1 addresses some of them with 511 some operational suggestions. 513 BRSKI places some clear requirements upon the contents of the IDevID, 514 but leaves the exact origin of the voucher serial-number open. This 515 document restricts the process to being the hwSerialNum OCTET STRING. 516 As CWT can handle binary formats, no base64 encoding is necessary. 518 The use of the MASA-URL extension is encouraged if the certificate is 519 sent at all. 521 EDNOTE: here belongs text about sending only a reference to the 522 IDevID rather than the entire certificate 524 2.3.1. Identification of the Pledge 526 TBD 528 2.3.2. MASA URI extension 530 TBD 532 2.4. Protocol Flow 534 The diagram from BRSKI is reproduced with some edits: 536 +--------+ +---------+ +------------+ +------------+ 537 | Pledge | | IPIP | | Domain | | Vendor | 538 | | | Proxy | | Registrar | | Service | 539 | | | | | (JRC) | | (MASA) | 540 +--------+ +---------+ +------------+ +------------+ 541 | | | | 542 |<-RFC4862 IPv6 adr | | | 543 | | | | 544 |<--------------------| | | 545 | Enhanced Beacon | | | 546 | periodic broadcast| | | 547 | | | | 548 |<------------------->C<----------------->| | 549 | DTLS via the IPIP Proxy | | 550 |<--Registrar DTLS server authentication--| | 551 [PROVISIONAL accept of server cert] | | 552 P---X.509 client authentication---------->| | 553 P | | | 554 P---Voucher Request (include nonce)------>| | 555 P | | | 556 P | | | 557 P | [accept device?] | 558 P | [contact Vendor] | 559 P | |--Pledge ID-------->| 560 P | |--Domain ID-------->| 561 P | |--nonce------------>| 562 P | | [extract DomainID] 563 P | | | 564 P | | [update audit log] 565 P | | | 566 P | | | 567 P | | | 568 P | | | 569 P | | | 570 P | |<-device audit log--| 571 P | |<- voucher ---------| 572 P | | | 573 P | | | 574 P | [verify audit log and voucher] | 575 P | | | 576 P<------voucher---------------------------| | 577 [verify voucher ] | | | 578 [verify provisional cert| | | 579 | | | | 580 |<--------------------------------------->| | 581 | Continue with RFC7030 enrollment | | 582 | using now bidirectionally authenticated | | 583 | DTLS session. | | | 584 | | | | 585 |<--------------------------------------->| | 586 | Use 6tisch-minimal-security join request | 588 Noteable changes are: 590 1. no IPv4 support/options. 592 2. no mDNS steps, 6tisch only uses Enhanced Beacon 594 3. nonce-full option is always mandatory 596 2.5. Architectural Components 598 The bootstrap process includes the following architectural 599 components: 601 2.5.1. Pledge 603 The Pledge is the device which is attempting to join. Until the 604 pledge completes the enrollment process, it has network connectivity 605 only to the Proxy. 607 2.5.2. Stateless IPIP Join Proxy 609 The stateless CoAP or DTLS Proxy provides CoAP or DTLS connectivity 610 (respectively) between the pledge and the registrar. The stateless 611 CoAP proxy mechanism is described in 612 [I-D.ietf-6tisch-minimal-security] section 5.1. 614 The stateless DTLS mechanism is not yet described (TBD). 616 2.5.3. Domain Registrar 618 The Domain Registrar (having the formal name Join Registrar/ 619 Coordinator (JRC)), operates as a CMC Registrar, terminating the EST 620 and BRSKI connections. The Registrar is manually configured or 621 distributed with a list of trust anchors necessary to authenticate 622 any Pledge device expected on the network. The Registrar 623 communicates with the Vendor supplied MASA to establish ownership. 625 The JRC is typically located on the 6LBR/DODAG root, but it may be 626 located elsewhere, provided IP level connectivity can be established. 627 The 6LBR may also provide a proxy or relay function to connect to the 628 actual registrar in addition to the IPIP proxy described above. The 629 existence of such an additional proxy is a private matter, and this 630 documents assumes without loss of generality that the registrar is 631 co-located with the 6LBR. 633 2.5.4. Manufacturer Service 635 The Manufacturer Service provides two logically seperate functions: 636 the Manufacturer Authorized Signing Authority (MASA), and an 637 ownership tracking/auditing function. This function is identical to 638 that used by BRSKI, except that a different format voucher is used. 640 2.5.5. Public Key Infrastructure (PKI) 642 TBD 644 2.6. Certificate Time Validation 646 2.6.1. Lack of realtime clock 648 For the constrained situation it is assumed that devices have no real 649 time clock. These nodes do have access to a monotonically increasing 650 clock that will not go backwards in the form of the Absolute Sequence 651 Number. Synchronization to the ASN is required in order to transmit/ 652 receive data and most nodes will maintain it in hardware. 654 The heuristic described in BRSKI under this section SHOULD be applied 655 if there are dates in the CWT format voucher. 657 Voucher requests SHOULD include a nonce. For devices intended for 658 off-line deployment, the vouchers will have been generated in advance 659 and no nonce-ful operation will not be possible. 661 2.6.2. Infinite Lifetime of IDevID 663 TBD 665 2.7. Cloud Registrar 667 In 6tisch, the pledge never has network connectivity until it is 668 enrolled, so no alternate registrar is ever possible. 670 2.8. Determining the MASA to contact 672 There are no changes from BRSKI: the IDevID provided by the pledge 673 will contain a MASA URL extension. 675 3. Voucher-Request artifact 677 The voucher-request artifact is defined in 678 [I-D.ietf-anima-constrained-voucher] section 6.1. 680 For the 6tisch ZSJ protocol defined in this document, only COSE 681 signed vouchers as described in [I-D.ietf-anima-constrained-voucher] 682 section 6.3.2 are supported. 684 4. Proxying details (Pledge - Proxy - Registrar) 686 The voucher-request artifact is defined in 687 [I-D.ietf-anima-constrained-voucher]. 689 The 6tisch use of the constrained version differs from the non- 690 constrained version in two ways: 692 1. it does not include the pinned-domain-cert, but rather than 693 pinned-domain-subjet-public-key-info entry. This accomodates the 694 use of a raw public key to identify the registrar. 696 2. the pledge voucher-request is never signed. 698 An appendix shows detailed examples of COSE format voucher requests. 700 5. Proxy details 702 The role of the Proxy is to facilitate communication. In the 703 constrained situation the proxy needs to be stateless as there is 704 very little ram to begin with, and none can be allocated to keep 705 state for an unlimited number of potential pledges. 707 5.1. Pledge discovery of Proxy 709 In BRSKI, the pledge discovers the proxy via use of a GRASP M_FLOOD 710 messages sent by the proxy. In 6tisch ZSJ, the existence of the 711 proxy is announced by the Enhanced Beacon message described in 712 [I-D.richardson-6tisch-enrollment-enhanced-beacon]. The proxy as 713 described by [I-D.ietf-6tisch-minimal-security] section 10 is to be 714 used in an identical fashion when EDHOC and OSCOAP are used. 716 When DTLS security is provided, then the proxy mechanism described in 717 TBD must be used. 719 5.2. CoAP connection to Registrar 721 In BRSKI CoAP is future work. This document represents this work. 723 5.3. HTTPS proxy connection to Registrar 725 HTTPS connections are not used between the Pledge, Proxy and 726 Registrar. The Proxy relays CoAP or DTLS packets and does not 727 interpret or terminate either CoAP or DTLS connections. (HTTPS is 728 still used between the Registrar and MASA) 730 5.4. Proxy discovery of Registrar 732 In BRSKI, the proxy autonomically discovers the Registrar by 733 listening for GRASP messages. 735 In the constrained network, the proxies are optionally configured 736 with the address of the JRC by the Join Response in in 737 [I-D.ietf-6tisch-minimal-security] section 9.3.2. (As described in 738 that section, the address of the registrar otherwise defaults to be 739 that of the DODAG root) 741 Whether or not a 6LR will announce itself as a possible Join Proxy is 742 outside the scope of this document. 744 6. Protocol Details (Pledge - Registrar - MASA) 746 BRSKI is specified to run over HTTPS. This document respecifies it 747 to run over CoAP with either DTLS or EDHOC-provided OSCOAP security. 749 BRSKI introduces the concept of a provisional state for EST. 751 The same situation must also be added to DTLS: a situation where the 752 connection is active but the identity of the Registar has not yet 753 been confirmed. The DTLS MUST validate that the exchange has been 754 signed by the Raw Public Key that is presented by the Server, even 755 though there is as yet no trust in that key. Such a key is often 756 available through APIs that provide for channel binding, such as 757 described in [RFC5056]. 759 There is an emerging (hybrid) possibility of DTLS-providing the 760 OSCOAP security, but such a specification does not yet exist, and 761 this document does at this point specify it. 763 [I-D.ietf-ace-coap-est] specifies that CoAP specifies the use of CoAP 764 Block-Wise Transfer ("Block") [RFC7959] to fragment EST messages at 765 the application layer. 767 BRSKI introduces the concept of a provisional state for EST. The 768 same situation must also be added to DTLS: a situation where the 769 connection is active but the identity of the Registar has not yet 770 been confirmed. 772 The DTLS MUST validate that the exchange has been signed by the Raw 773 Public Key that is presented by the Server, even though there is as 774 yet no trust in that key. Such a key is often available through APIs 775 that provide for channel binding, such as described in [RFC5056]. 777 As in [I-D.ietf-ace-coap-est], support for Observe CoAP options 778 [RFC7641] with BRSKI is not supported in the current BRSKI/EST 779 message flows. 781 Observe options could be used by the server to notify clients about a 782 change in the cacerts or csr attributes (resources) and might be an 783 area of future work. 785 Redirection as described in [RFC7030] section 3.2.1 is NOT supported. 787 6.1. BRSKI-EST (D)TLS establishment details 789 6tisch ZSJ does not use TLS. The connection is either CoAP over 790 DTLS, or CoAP with EDHOC security. 792 6.1.1. BRSKI-EST CoAP/DTLS estasblishment details 794 The details in the BRSKI document apply directly to use of DTLS. 796 The registrar SHOULD authenticate itself with a raw public key. A 797 256 bit ECDSA raw public key is RECOMMENDED. Pledges SHOULD support 798 EDDSA keys if they contain hardware that supports doing so 799 efficiently. 801 TBD: the Pledge needs to signal what kind of Raw Public Key it 802 supports before the Registrar sends its ServerCertificate. Can SNI 803 be used to do this? 805 The pledge SHOULD authenticate itself with the built-in IDevID 806 certificate as a ClientCertificate. 808 6.1.2. BRSKI-EST CoAP/EDHOC estasblishment details 810 [I-D.selander-ace-cose-ecdhe] details how to use EDHOC. The EDHOC 811 description identifiers a party U (the initiator), and a party V. 812 The Pledge is the party U, and the JRC is the party V. 814 The communication from the Pledge is via CoAP via the Join Proxy. 815 The Join proxy relays traffic to the JRC, and using the mechanism 816 described in [I-D.ietf-6tisch-minimal-security] section 5.1. This is 817 designed so that the Join Proxy does not need to know if it is 818 performing the one-touch enrollment described in 819 [I-D.ietf-6tisch-minimal-security] or the zero-touch enrollment 820 protocol described in this document. A network could consist of a 821 mix of nodes of each type. 823 As generating ephemeral keys is expensive for a low-resource Pledge, 824 the use of a common E_U by the Pledge for multiple enrollment 825 attempts (should the first turn out to be the wrong network) is 826 encouraged. 828 The first communication detailed in [I-D.ietf-ace-coap-est] is to 829 query the "/.well-known/core" resource to request the Link for EST. 830 This is where the initial CoAP request is to sent. 832 The JRC MAY replace it's E_V ephermal key on a periodic basis, or 833 even for every communication session. 835 The Pledge's ID_U is the Pledge's IDevID. It is transmitted in an 836 x5bag [I-D.schaad-cose-x509]. An x5u (URL) MAY be used. An x5t 837 (hash) MAY also be used and would be the smallest, but the Registrar 838 may not know where to find the Pledge's IDevID unless the JRC has 839 been preloaded will all the IDevIDs via out-of-band mechanism. It is 840 impossible for the Pledge to know if the JRC has been loaded in such 841 a way so x5t is discouraged for general use. 843 The JRC's ID_V is the JRC's Raw Public Key. It is transmitted as a 844 key in COSE's YYY parameter. 846 The initial Mandatory to Implement (MTI) of an HKDF of SHA2-256, an 847 AEAD based upon AES-CCM-16-64-128, a signature verification of BBBB, 848 and signature generation of BBBB. The Pledge proposes a set of 849 algorithms that it supports, and Pledge need not support more than 850 one combination. 852 JRCs are expected to run on non-constrained servers, and are expected 853 to support the above initial MTI, and any subsequent ones that become 854 common. A JRC SHOULD support all available algorithms for a 855 significant amount of time. Even when algorithms become weak or 856 suspect, it is likely that it will still have to perform secure join 857 for older devices. A JRC that responds to such an older device might 858 not in the end accept the device into the network, but it is 859 important that it be able to audit the event and communicate the 860 event to an operator. 862 While EDHOC supports sending additional data in the message_3, in the 863 constrained network situation, it is anticipated that the size of the 864 this message will already be large, and no additional data is to be 865 sent. 867 A COAP confirmable message SHOULD be used. 869 [I-D.ietf-6tisch-minimal-security] section 6 details how to setup 870 OSCORE context given a shared key derived by EDHOC. 872 The registrar SHOULD authenticate itself with a raw public key. 874 The pledge SHOULD authenticate itself with the built-in IDevID 875 certificate. 877 6.2. Pledge Requests Voucher from the Registrar 879 The voucher request and response as defined by BRSKI is modified 880 slightly. 882 In order to simplify the pledge, the use of a certificate (and chain) 883 for the Registrar is not supported. Instead the newly defined 884 pinned-domain-subject-public-key-info must contain the (raw) public 885 key info for the Registrar. It MUST be byte for byte identical to 886 that which is transmitted by the Registrar during the TLS 887 ServerCertificate handshake. 889 BRSKI permits the voucher request to be signed or unsigned. This 890 document defines the voucher request to be unsigned. 892 6.3. BRSKI-MASA TLS establishment details 894 There are no changes. The connection from the Registrar to MASA is 895 still HTTPS. 897 6.4. Registrar Requests Voucher from MASA 899 There are no change from BRSKI, as this step is between two non- 900 constrained devices. 902 The format of the voucher is COSE, which implies changes to both the 903 Registrar and the MASA, but semantically the content is the same. 905 The format of the voucher is COSE, which implies changes to both the 906 Registrar and the MASA, but semantically the content is the same. 908 The manufacturer will know what algorithms are supported by the 909 pledge, and will issue a 406 (Conflict) error to the Registrar if the 910 Registar's public key format is not supported by the pledge. It is 911 however, too late for the Registar to use a different key, but at 912 least it can log a reason for a failure. It is likely that the ZSJ- 913 BRSKI-EST connection has already failed, and this step is never 914 reached. 916 6.4.1. MASA renewal of expired vouchers 918 There are assumed to be no useful real-time clocks on constrained 919 devices, so all vouchers are in effect infinite duration. Pledges 920 will use nonces for freshness, and a request for a new voucher with a 921 new voucher for the same Registrar is not unusual. A token-bucket 922 system SHOULD be used such that no more than 24 vouchers are issued 923 per-day, but more than one voucher can be issued in a one hour 924 period. Tokens should not accumulate for more than one day! 926 6.4.2. MASA verification of voucher-request signature consistency 928 The voucher-request is signed by the Registrar using it's Raw Public 929 Key. There is no additional certificate authority to sign this key. 930 The MASA MAY have this key via sales-channel integration, but in most 931 cases it will be seeing the key for the first time. 933 XXX-should the TLS connection from Registrar to MASA have a 934 ClientCertificate? If so, then should it use the same Public Key? 935 Or a different one? 937 6.4.3. MASA authentication of registrar (certificate) 939 IDEA: The MASA SHOULD pin the Raw Public Key (RPK) to the IP address 940 that was first used to make a request with it. Should the RPK <-> IP 941 address relationship be 1:1, 1:N, N:1? Should we take IP address to 942 mean, "IP subnet", essentially the IPv4/24, and IPv6/64? The value 943 of doing is about DDoS mitigation? 945 Should above mapping be on a per-Pledge basis? 947 6.4.4. MASA revocation checking of registrar (certificate) 949 As the Registrar has a Raw Public Key as an identity, there is no 950 meaningful standard revocation checking that can be done. The MASA 951 SHOULD have a blacklist table, and a way to add entries, but this 952 process is out of scope. 954 6.4.5. MASA verification of pledge prior-signed-voucher-request 956 The MASA will know whether or not the Pledge is capable of producing 957 a signed voucher-request for inclusion by the Registrar. In the case 958 where the Pledge can sign the voucher-request to the Registrar, then 959 the Registrar will have put it in the 'prior-signed-voucher-request'. 960 The MASA can verify the signature from the Pledge using the MASA's 961 copy of the Pledge's IDevID public key. 963 In many cases, the Pledge will not be capable of doing signatures in 964 real time, so no 'prior-signed-voucher-request' will be present. The 965 MASA will have rely on the audit log as a history function to 966 determine if the Pledge has previously been claimed, and to identify 967 situations where the claim from the Registrar is fraudulent. 969 6.4.6. MASA pinning of registrar 971 When the MASA creates a voucher, it puts the Registrar's Raw Public 972 Key into the 'pinned-domain-subject-public-key-info' leaf of the 973 voucher. 975 The MASA does not include the 'pinned-domain-cert' field. 977 6.4.7. MASA nonce handling 979 Use of nonces is highly RECOMMENDED, but there are situations where 980 not all components are connected at the same time in which the nonce 981 will not be present. 983 There are no significant changes from BRSKI. 985 6.5. MASA Voucher Response 987 As exaplained in [I-D.ietf-anima-constrained-voucher] section 6.3.2, 988 when a voucher is returned by the MASA to the JRC, a public key or 989 certificate container that will verify the voucher SHOULD also be 990 returned. 992 In order to do this, the MASA MAY return a multipart/mixed return, 993 within that body, two items SHOULD be returned: 995 1. An application/voucher-cose+cbor body. 997 2. An application/pkcs7-mime; smime-type=certs-only, or an 998 application/SOMETHING containing a Raw Public Key. 1000 A MASA is not obligated to return the public key, and MAY return only 1001 the application/voucher-cose+cbor object. In that case, the JRC will 1002 be unable to validate it. 1004 6.5.1. Pledge voucher verification 1006 The Pledge receives the voucher from the Registrar over it's CoAP 1007 connection. It verifies the signature using the MASA anchor built 1008 in, as in the BRSKI case. 1010 6.5.2. Pledge authentication of provisional TLS connection 1012 The BRSKI process uses the pinned-domain-cert field of the voucher to 1013 validate the registrar's ServerCertificate. In the ZeroTouch case, 1014 the voucher will contain a pinned-domain-subject-public-key-info 1015 field containing the raw public key of the certificate. It should 1016 match, byte-to-byte with the raw public key ServerCertificate. 1018 6.6. Pledge Voucher Status Telemetry 1020 The voucher status telemetry report is communicated from the pledge 1021 to the registrar over CoAP channel. The shortened URL is as 1022 described in table QQQ. 1024 6.7. Registrar audit log request 1026 There are no changes to the Registrar audit log request. 1028 6.7.1. MASA audit log response 1030 There are no changes to the MASA audit log response. 1032 6.7.2. Registrar audit log verification 1034 There are no changes to how the Registrar verifies the audit log. 1036 6.8. EST Integration for PKI bootstrapping 1038 TBD. 1040 6.8.1. EST Distribution of CA Certificates 1042 TBD. 1044 6.8.2. EST CSR Attributes 1046 In 6tisch, no Autonomic Control Plane will be created, so none of the 1047 criteria for SubjectAltname found in 1048 [I-D.ietf-anima-autonomic-control-plane] apply. 1050 The CSR Attributes request SHOULD NOT be performed. 1052 6.8.3. EST Client Certificate Request 1054 6tisch will use a certificate to: 1056 1. to authenticate an 802.15.9 key agreement protocol. 1058 2. to terminate an incoming DTLS or EDHOC key agreement as part of 1059 application data protection. 1061 It is recommended that the requested subjectAltName contain only the 1062 [RFC4514] hwSerialNum. 1064 6.8.4. Enrollment Status Telemetry 1066 There are no changes to the status telemetry between Registrar and 1067 MASA. 1069 6.8.5. Multiple certificates 1071 Multiple certificates are not supported. 1073 6.8.6. EST over CoAP 1075 This document and [I-D.ietf-ace-coap-est] detail how to run EST over 1076 CoAP. 1078 6.9. Use of Secure Transport for Minimal Join 1080 Rather than bootstrap to a public key infrastructure, the secure 1081 channel MAY instead be for the minimal security join process 1082 described in [I-D.ietf-6tisch-minimal-security]. 1084 The desire to do a minimal-security join process is signaled by the 1085 Registrar in it's voucher-request by including a 'join-process' value 1086 of 'minimal'. The MASA copies this value into the voucher that is 1087 creates, and also logs this to the audit log. 1089 When the secure channel was created with EDHOC, then the keys setup 1090 by EDHOC are simply used by OSCORE exactly as if they had been Pre- 1091 Shared. The keys derived by EDHOC SHOULD be stored by both Registrar 1092 and Pledge as their long term key should the join process need to be 1093 repeated. 1095 7. Reduced security operational modes 1097 This document defines a specific reduced security operational mode, 1098 specifically: 1100 1. X 1102 2. Y 1104 3. Z 1106 7.1. Trust Model 1108 TBD 1110 7.2. Pledge security reductions 1112 TBD 1114 7.3. Registrar security reductions 1116 TBD 1118 7.4. MASA security reductions 1120 TBD 1122 8. IANA Considerations 1124 XXX 1126 8.1. Well-known EST registration 1128 XXX 1130 8.2. PKIX Registry 1132 TBD 1134 8.3. Voucher Status Telemetry 1136 TBD 1138 8.4. DNS Service Names 1140 TBD 1142 8.5. MUD File Extension for the MASA server 1144 TBD 1146 9. Privacy Considerations 1148 [I-D.ietf-6lo-privacy-considerations] details a number of privacy 1149 considerations important in Resource Constrained nodes. There are 1150 two networks and three sets of constrained nodes to consider. They 1151 are: 1. the production nodes on the production network. 2. the new 1152 pledges, which have yet to enroll, and which are on a join network. 1153 3. the production nodes which are also acting as proxy nodes. 1155 9.1. Privacy Considerations for Production network 1157 The details of this are out of scope for this document. 1159 9.2. Privacy Considerations for New Pledges 1161 New Pledges do not yet receive Router Advertisements with PIO 1162 options, and so configure link-local addresses only based upon 1163 layer-2 addresses using the normal SLAAC mechanisms described in 1164 [RFC4191]. 1166 These link-local addresses are visible to any on-link eavesdropper 1167 (who is synchronized to the same Join Assistant), so regardless of 1168 what is chosen they can be seen. This link-layer traffic is 1169 encapsulated by the Join Proxy into IPIP packets and carried to the 1170 JRC. The traffic SHOULD never leave the operator's network, will be 1171 kept confidential by the layer-2 keys inside the LLN. As no outside 1172 traffic can enter the join network, to do any ICMP scanning as 1173 described in [I-D.ietf-6lo-privacy-considerations]. 1175 The join process described herein requires that some identifier 1176 meaningful to the network operator be communicated to the JRC. The 1177 join request with this object occurs within a secured CoAP channel, 1178 although the link-local address configured by the pledge will be 1179 visible in either the CoAP stateless proxy option (section 5.1 of 1180 [I-D.ietf-6tisch-minimal-security]), or in the equivalent DTLS 1181 stateless proxy option (reference TBD). 1183 This need not be a manufacturer created EUI-64 as assigned by IEEE; 1184 it could be another value with higher entropy and less interesting 1185 vendor/device information. Regardless of what is chosen, it can be 1186 used to track where the device attaches. 1188 For most constrained device, network attachment occurs very 1189 infrequently, often only once in their lifetime, so tracking 1190 opportunities may be rare. Once connected, the long 8-byte EUI64 1191 layer-2 address is usually replaced with a short JRC assigned 2-byte 1192 address. 1194 Additionally, during the enrollment process, a DTLS connection or 1195 EDHOC connection will be created. TLS1.3 will keep contents of the 1196 certificates transmitted private while TLS 1.2 will not. If the 1197 client certificate can be observed, then the device identity will be 1198 visible to passive observers in the 802.11AR IDevID certificate that 1199 is sent. 1201 Even when TLS 1.3 is used, an active attacker could collect the 1202 information by creating a rogue proxy. 1204 The use of a manufacturer assigned EUI64 (whether derived from IEEE 1205 assignment or created through another process during manufacturing 1206 time) is encouraged. 1208 9.2.1. EUI-64 derived address for join time IID 1210 The IID used in the link-local address used during the join process 1211 be a vendor assigned EUI-64. After the join process has concluded, 1212 the device SHOULD be assigned a unique randomly generated long 1213 address, and a unique short address (not based upon the vendor EUI- 1214 64) for use at link-layer address. At that point, all layer-3 1215 content is encrypted by the layer-2 key. 1217 9.3. Privacy Considerations for Join Proxy 1219 TBD. 1221 10. Security Considerations 1223 TBD 1225 10.1. Security of MASA voucher signing key(s) 1227 TBD 1229 11. Acknowledgements 1231 Kristofer Pister helped with many non-IETF references. 1233 12. References 1235 12.1. Normative References 1237 [cullenCiscoPhoneDeploy] 1238 Jennings, C., "Transitive Trust Enrollment for Constrained 1239 Devices", 2012, . 1242 [I-D.ietf-6lo-privacy-considerations] 1243 Thaler, D., "Privacy Considerations for IPv6 Adaptation 1244 Layer Mechanisms", draft-ietf-6lo-privacy- 1245 considerations-04 (work in progress), October 2016. 1247 [I-D.ietf-6tisch-minimal] 1248 Vilajosana, X., Pister, K., and T. Watteyne, "Minimal 1249 6TiSCH Configuration", draft-ietf-6tisch-minimal-21 (work 1250 in progress), February 2017. 1252 [I-D.ietf-6tisch-minimal-security] 1253 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 1254 "Minimal Security Framework for 6TiSCH", draft-ietf- 1255 6tisch-minimal-security-06 (work in progress), May 2018. 1257 [I-D.ietf-6tisch-terminology] 1258 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1259 "Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e", 1260 draft-ietf-6tisch-terminology-10 (work in progress), March 1261 2018. 1263 [I-D.ietf-ace-cbor-web-token] 1264 Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 1265 "CBOR Web Token (CWT)", draft-ietf-ace-cbor-web-token-15 1266 (work in progress), March 2018. 1268 [I-D.ietf-ace-coap-est] 1269 Stok, P., Kampanakis, P., Kumar, S., Richardson, M., 1270 Furuhed, M., and S. Raza, "EST over secure CoAP (EST- 1271 coaps)", draft-ietf-ace-coap-est-06 (work in progress), 1272 October 2018. 1274 [I-D.ietf-anima-bootstrapping-keyinfra] 1275 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1276 S., and K. Watsen, "Bootstrapping Remote Secure Key 1277 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1278 keyinfra-16 (work in progress), June 2018. 1280 [I-D.ietf-anima-constrained-voucher] 1281 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 1282 Voucher Artifacts for Bootstrapping Protocols", draft- 1283 ietf-anima-constrained-voucher-02 (work in progress), 1284 September 2018. 1286 [I-D.ietf-anima-grasp] 1287 Bormann, C., Carpenter, B., and B. Liu, "A Generic 1288 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 1289 grasp-15 (work in progress), July 2017. 1291 [I-D.ietf-anima-voucher] 1292 Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1293 "Voucher Profile for Bootstrapping Protocols", draft-ietf- 1294 anima-voucher-07 (work in progress), January 2018. 1296 [I-D.ietf-core-comi] 1297 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 1298 Management Interface", draft-ietf-core-comi-03 (work in 1299 progress), June 2018. 1301 [I-D.ietf-core-object-security] 1302 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1303 "Object Security for Constrained RESTful Environments 1304 (OSCORE)", draft-ietf-core-object-security-15 (work in 1305 progress), August 2018. 1307 [I-D.ietf-core-yang-cbor] 1308 Veillette, M., Pelov, A., Somaraju, A., Turner, R., and A. 1309 Minaburo, "CBOR Encoding of Data Modeled with YANG", 1310 draft-ietf-core-yang-cbor-07 (work in progress), September 1311 2018. 1313 [I-D.ietf-netconf-keystore] 1314 Watsen, K., "YANG Data Model for a Centralized Keystore 1315 Mechanism", draft-ietf-netconf-keystore-06 (work in 1316 progress), September 2018. 1318 [I-D.richardson-6tisch-enrollment-enhanced-beacon] 1319 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 1320 Element encapsulation of 6tisch Join and Enrollment 1321 Information", draft-richardson-6tisch-enrollment-enhanced- 1322 beacon-01 (work in progress), April 2018. 1324 [I-D.richardson-6tisch-join-enhanced-beacon] 1325 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 1326 Element encapsulation of 6tisch Join Information", draft- 1327 richardson-6tisch-join-enhanced-beacon-03 (work in 1328 progress), January 2018. 1330 [I-D.richardson-6tisch-minimal-rekey] 1331 Richardson, M., "Minimal Security rekeying mechanism for 1332 6TiSCH", draft-richardson-6tisch-minimal-rekey-02 (work in 1333 progress), August 2017. 1335 [I-D.richardson-anima-6join-discovery] 1336 Richardson, M., "GRASP discovery of Registrar by Join 1337 Assistant", draft-richardson-anima-6join-discovery-00 1338 (work in progress), October 2016. 1340 [I-D.schaad-cose-x509] 1341 Schaad, J., "CBOR Object Signing and Encryption (COSE): 1342 Headers for carrying and referencing X.509 certificates", 1343 draft-schaad-cose-x509-02 (work in progress), July 2018. 1345 [I-D.selander-ace-cose-ecdhe] 1346 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 1347 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 1348 cose-ecdhe-10 (work in progress), September 2018. 1350 [iec62591] 1351 IEC, ., "62591:2016 Industrial networks - Wireless 1352 communication network and communication profiles - 1353 WirelessHART", 2016, 1354 . 1356 [ieee802-1AR] 1357 IEEE Standard, ., "IEEE 802.1AR Secure Device Identifier", 1358 2009, . 1361 [ieee802154] 1362 IEEE Standard, ., "802.15.4-2015 - IEEE Standard for Low- 1363 Rate Wireless Personal Area Networks (WPANs)", 2015, 1364 . 1367 [ieee802159] 1368 IEEE Standard, ., "802.15.9-2016 - IEEE Approved Draft 1369 Recommended Practice for Transport of Key Management 1370 Protocol (KMP) Datagrams", 2016, 1371 . 1374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1375 Requirement Levels", BCP 14, RFC 2119, 1376 DOI 10.17487/RFC2119, March 1997, 1377 . 1379 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol 1380 (LDAP): String Representation of Distinguished Names", 1381 RFC 4514, DOI 10.17487/RFC4514, June 2006, 1382 . 1384 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 1385 Bormann, "Neighbor Discovery Optimization for IPv6 over 1386 Low-Power Wireless Personal Area Networks (6LoWPANs)", 1387 RFC 6775, DOI 10.17487/RFC6775, November 2012, 1388 . 1390 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1391 "Enrollment over Secure Transport", RFC 7030, 1392 DOI 10.17487/RFC7030, October 2013, 1393 . 1395 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1396 Interface Identifiers with IPv6 Stateless Address 1397 Autoconfiguration (SLAAC)", RFC 7217, 1398 DOI 10.17487/RFC7217, April 2014, 1399 . 1401 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1402 Constrained-Node Networks", RFC 7228, 1403 DOI 10.17487/RFC7228, May 2014, 1404 . 1406 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1407 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1408 Transport Layer Security (TLS) and Datagram Transport 1409 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1410 June 2014, . 1412 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1413 Application Protocol (CoAP)", RFC 7252, 1414 DOI 10.17487/RFC7252, June 2014, 1415 . 1417 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 1418 the Constrained Application Protocol (CoAP)", RFC 7959, 1419 DOI 10.17487/RFC7959, August 2016, 1420 . 1422 12.2. Informative References 1424 [duckling] 1425 Stajano, F. and R. Anderson, "The resurrecting duckling: 1426 security issues for ad-hoc wireless networks", 1999, 1427 . 1430 [I-D.ietf-ace-actors] 1431 Gerdes, S., Seitz, L., Selander, G., and C. Bormann, "An 1432 architecture for authorization in constrained 1433 environments", draft-ietf-ace-actors-07 (work in 1434 progress), October 2018. 1436 [I-D.ietf-anima-autonomic-control-plane] 1437 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 1438 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 1439 plane-18 (work in progress), August 2018. 1441 [I-D.ietf-core-sid] 1442 Veillette, M. and A. Pelov, "YANG Schema Item iDentifier 1443 (SID)", draft-ietf-core-sid-04 (work in progress), June 1444 2018. 1446 [I-D.ietf-roll-useofrplinfo] 1447 Robles, I., Richardson, M., and P. Thubert, "When to use 1448 RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- 1449 useofrplinfo-23 (work in progress), May 2018. 1451 [ISA100] "The Technology Behind the ISA100.11a Standard", June 1452 2010, . 1455 [PFS] Wikipedia, ., "Forward Secrecy", August 2016, 1456 . 1459 [pledge-word] 1460 Dictionary.com, ., "Dictionary.com Unabridged", 2015, 1461 . 1463 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 1464 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 1465 November 2005, . 1467 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1468 Element (PCE)-Based Architecture", RFC 4655, 1469 DOI 10.17487/RFC4655, August 2006, 1470 . 1472 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1473 Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, 1474 . 1476 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 1477 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 1478 Internet of Things (IoT): Problem Statement", RFC 7554, 1479 DOI 10.17487/RFC7554, May 2015, 1480 . 1482 [RFC7641] Hartke, K., "Observing Resources in the Constrained 1483 Application Protocol (CoAP)", RFC 7641, 1484 DOI 10.17487/RFC7641, September 2015, 1485 . 1487 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 1488 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 1489 February 2016, . 1491 Appendix A. Extra text 1493 The following text is from previous versions of this document. The 1494 document has been re-organized to match the flow of 1495 [I-D.ietf-anima-bootstrapping-keyinfra]. 1497 A.1. Assumptions 1499 A.1.1. One-Touch Assumptions 1501 This document interacts with the one-touch solution described in 1502 [I-D.ietf-6tisch-minimal-security]. 1504 A.1.2. Factory provided credentials (if any) 1506 When a manufacturer installed certificate is provided as the IDevID, 1507 it SHOULD contain a number of fields. 1508 [I-D.ietf-anima-bootstrapping-keyinfra] provides a detailed set of 1509 requirements. 1511 A manufacturer unique serial number MUST be provided in the 1512 serialNumber SubjectAltName extension, and MAY be repeated in the 1513 Common Name. There are no sequential or numeric requirements on the 1514 serialNumber, it may be any unique value that the manufacturer wants 1515 to use. The serialNumber SHOULD be printed on the packaging and/or 1516 on the device in a discrete way so that failures can be physically 1517 traced to the relevant device. 1519 A.1.3. Credentials to be introduced 1521 The goal of the bootstrap process is to introduce one or more new 1522 locally relevant credentials: 1524 1. a certificate signed by a local certificate authority/registrar. 1525 This is the LDevID of [ieee802-1AR]. 1527 2. alternatively, a network-wide key to be used to secure L2 1528 traffic. 1530 3. alternatively, a network-wide key to be used to authenticate per- 1531 peer keying of L2 traffic using a mechanism such as provided by 1532 [ieee802159]. 1534 A.2. Network Assumptions 1536 This document is about enrollment of constrained devices [RFC7228] to 1537 a constrained network. Constrained networks is such as [ieee802154], 1538 and in particular the time-slotted, channel hopping (tsch) mode, 1539 feature low bandwidths, and limited opportunities to transmit. A key 1540 feature of these networks is that receivers are only listening at 1541 certain times. 1543 A.2.1. Security above and below IP 1545 802.15.4 networks have three kinds of layer-2 security: 1547 o a network key that is shared with all nodes and is used for 1548 unicast and multicast. The key may be used for privacy, and it 1549 may be used in some cases for authentication only (in the case of 1550 enhanced beacons). 1552 o a series of network keys that are shared (agreed to) between pairs 1553 of nodes (the per-peer key) 1555 o a network key that is shared with all nodes (through a group key 1556 management system), and is used for multicast traffic only, while 1557 a per-pair key is used for unicast traffic 1559 Setting up the credentials to bootstrap one of these kinds of 1560 security, (or directly configuring the key itself for the first case) 1561 is required. This is the security below the IP layer. 1563 Security is required above the IP layer: there are three aspects 1564 which the credentials in the previous section are to be used. 1566 o to provide for secure connection with a Path Computation Element 1567 [RFC4655], or other LLC (see ({RFC7554}} section 3). 1569 o to initiate a connection between a Resource Server (RS) and an 1570 application layer Authorization Server (AS and CAS from 1571 [I-D.ietf-ace-actors]). 1573 A.2.1.1. Perfect Forward Secrecy 1575 Perfert Forward Secrecy (PFS) is the property of a protocol such that 1576 complete knowledge of the crypto state (for instance, via a memory 1577 dump) at time X does not imply that data from a disjoint time Y can 1578 also be recovered. ([PFS]). 1580 PFS is important for two reasons: one is that it offers protection 1581 against the compromise of a node. It does this by changing the keys 1582 in a non-deterministic way. This second property also makes it much 1583 easier to remove a node from the network, as any node which has not 1584 participated in the key changing process will find itself no longer 1585 connected. 1587 A.2.2. Join network assumptions 1589 The network which the new pledge will connect to will have to have 1590 the following properties: 1592 o a known PANID. The PANID 0xXXXX where XXXX is the assigned RFC# 1593 for this document is suggested. 1595 o a minimal schedule with some Aloha time. This is usually in the 1596 same slotframe as the Enhanced Beacon, but a pledge MUST listen 1597 for an unencrypted Enhanced Beacon to so that it can synchronize. 1599 A.2.3. Number and cost of round trips 1601 TBD. 1603 A.2.4. Size of packets, number of fragments 1605 TBD 1607 A.3. Target end-state for join process 1609 At the end of the zero-touch join process there will be a symmetric 1610 key protected channel between the Join Registrar/Coordinator and the 1611 pledge, now known as a Joined Node. This channel may be rekeyed via 1612 new exchange of asymmetric exponents (ECDH for instance), 1613 authenticated using the domain specific credentials created during 1614 the join process. 1616 This channel is in the form of an OSCOAP protected connection with 1617 [I-D.ietf-core-comi] encoded objects. This document includes 1618 definition of a [I-D.ietf-netconf-keystore] compatible objects for 1619 encoding of the relevant [I-D.ietf-anima-bootstrapping-keyinfra] 1620 objects. 1622 Appendix B. Join Protocol 1624 The pledge join protocol state machine is described in 1625 [I-D.ietf-6tisch-minimal-security], in section XYZ. The pledge 1626 recognizes that it is in zero-touch configuration by the following 1627 situation: 1629 o no PSK has been configured for the network in which it has joined. 1631 o the pledge has no locally defined certificate (no LDevID), only an 1632 IDevID. 1634 o the network asserts an identity that the pledge does not 1635 recognize. 1637 All of these conditions MUST be true. If any of these are not true, 1638 then the pledge has either been connected to the wrong network, or it 1639 has already been bootstrapped into a different network, and it should 1640 wait until it finds that network. 1642 The zero-touch process consists of three stages: 1644 1. the key agreement process 1646 2. the provisional enrollment process 1647 3. the key distribution process 1649 B.1. Key Agreement process 1651 The key agreement process is identical to 1652 [I-D.ietf-6tisch-minimal-security]. The process uses EDHOC with 1653 certificates. 1655 The pledge will have to trust the JRC provisionally, as described in 1656 [I-D.ietf-anima-bootstrapping-keyinfra], section 3.1.2, and in 1657 section 4.1.1 of [RFC7030]. 1659 The JRC will be able to validate the IDevID of the pledge using the 1660 manufacturer's CA. 1662 The pledge may not know if it is in a zero-touch or one-touch 1663 situation: the pledge may be able to verify the JRC based upon trust 1664 anchors that were installed at manufacturing time. In that case, the 1665 pledge runs the simplified one-touch process. 1667 The pledge signals in the EDHOC message_2 if it has accepted the JRC 1668 certificate. The JRC will in general, not trust the pledge with the 1669 network keys until it has provided the pledge with a voucher. The 1670 pledge will notice the absence of the provisioning keys. 1672 XXX - there could be some disconnect here. May need additional 1673 signals here. 1675 B.2. Provisional Enrollment process 1677 When the pledge determines that it can not verify the certificate of 1678 the JRC using built-in trust anchors, then it enters a provisional 1679 state. In this state, it keeps the channel created by EDHOC open. 1681 A new EDHOC key derivation is done by the JRC and pledge using a new 1682 label, "6tisch-provisional". 1684 The pledge runs as a passive CoMI server, leaving the JRC to drive 1685 the enrollment process. The JRC can interrogate the pledge in a 1686 variety of fashions as shown below: the process terminates when the 1687 JRC provides the pledge with an ownership voucher and the pledge 1688 leaves the provisional state. 1690 A typical interaction involves the following requests: 1692 +-----------+ +----------+ +-----------+ +----------+ 1693 | | | | | Circuit | | New | 1694 | Vendor | | Registrar| | Proxy | | Entity | 1695 | (MASA) | | | | | | | 1696 ++----------+ +--+-------+ +-----------+ +----------+ 1697 | | GET request voucher | 1698 | |--------------------------------> 1699 | <----------voucher-token---------| 1700 |/requestvoucher| | 1701 <---------------+ | 1702 +---------------> | 1703 |/requestlog | | 1704 <---------------+ | 1705 +---------------> | 1706 | | POST voucher | 1707 | |--------------------------------> 1708 | <------------2.05 OK ------------+ 1709 | | | 1710 | | POST csr attributes | 1711 | |--------------------------------> 1712 | <------------2.05 OK ------------+ 1713 | | | 1714 | | GET cert request | 1715 | |--------------------------------> 1716 | ???? <------------2.05 OK ------------+ 1717 |<--------------| CSR | 1718 |-------------->| | 1719 | | POST certificate | 1720 | |--------------------------------> 1721 | <------------2.05 OK ------------+ 1722 | | | 1724 Appendix C. IANA Considerations 1726 This document allocates one value from the subregistry "Address 1727 Registration Option Status Values": ND_NS_JOIN_DECLINED Join 1728 Assistant, JOIN DECLINED (TBD-AA) 1730 Appendix D. Protocol Definition 1732 D.1. Discovery 1734 Only IPv6 operations using Link-Local addresses are supported. Use 1735 of a temporary address is NOT encouraged as the critial resource on 1736 the Proxy device is the number of Neighbour Cache Entries that can be 1737 used for untrusted pledge entries. 1739 D.1.1. Proxy Discovery Protocol Details 1741 The Proxy is discovered using the enhanced beacon defined in 1742 [I-D.richardson-6tisch-join-enhanced-beacon]. 1744 D.1.2. Registrar Discovery Protocol Details 1746 The Registrar is not discovered by the Proxy. Any device that is 1747 expected to be able to operate as a Registrar MAY be told the address 1748 of the Registrar when that device joins the network. The address MAY 1749 be included in the [I-D.ietf-6tisch-minimal-security] Join Response. 1750 If the address is NOT included, then Proxy may assume that the 1751 Registrar can be found at the DODAG root, which is well known in the 1752 6tisch's use of the RPL protocol. 1754 Author's Address 1756 Michael Richardson 1757 Sandelman Software Works 1759 Email: mcr+ietf@sandelman.ca