idnits 2.17.1 draft-ietf-anima-bootstrapping-keyinfra-30.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 17, 2019) is 1615 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) == Missing Reference: 'GRASP' is mentioned on line 1609, but not defined == Missing Reference: 'RFC5246' is mentioned on line 1895, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Missing Reference: 'RFC2131' is mentioned on line 4521, but not defined == Missing Reference: 'HEX DUMP' is mentioned on line 5415, but not defined == Unused Reference: 'ITU.X690.1994' is defined on line 4180, but no explicit reference was found in the text == Unused Reference: 'RFC5386' is defined on line 4249, but no explicit reference was found in the text == Unused Reference: 'RFC5660' is defined on line 4258, but no explicit reference was found in the text == Unused Reference: 'RFC6066' is defined on line 4262, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-stable-connectivity' is defined on line 4382, but no explicit reference was found in the text == Unused Reference: 'RFC8572' is defined on line 4472, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-20 -- Possible downref: Non-RFC (?) normative reference: ref. 'IDevID' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.1994' -- Possible downref: Non-RFC (?) normative reference: ref. 'REST' ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 8368 == Outdated reference: A later version (-18) exists of draft-ietf-ace-coap-est-16 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-05 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-14 == Outdated reference: A later version (-03) exists of draft-richardson-anima-state-for-joinrouter-02 -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 7 errors (**), 0 flaws (~~), 17 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG M. Pritikin 3 Internet-Draft Cisco 4 Intended status: Standards Track M. Richardson 5 Expires: May 20, 2020 Sandelman 6 T. Eckert 7 Futurewei USA 8 M. Behringer 10 K. Watsen 11 Watsen Networks 12 November 17, 2019 14 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 15 draft-ietf-anima-bootstrapping-keyinfra-30 17 Abstract 19 This document specifies automated bootstrapping of an Autonomic 20 Control Plane. To do this a Secure Key Infrastructure is 21 bootstrapped. This is done using manufacturer-installed X.509 22 certificates, in combination with a manufacturer's authorizing 23 service, both online and offline. We call this process the 24 Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. 25 Bootstrapping a new device can occur using a routable address and a 26 cloud service, or using only link-local connectivity, or on limited/ 27 disconnected networks. Support for deployment models with less 28 stringent security requirements is included. Bootstrapping is 29 complete when the cryptographic identity of the new key 30 infrastructure is successfully deployed to the device. The 31 established secure connection can be used to deploy a locally issued 32 certificate to the device as well. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 20, 2020. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.1. Prior Bootstrapping Approaches . . . . . . . . . . . . . 6 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 70 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 10 71 1.3.1. Support environment . . . . . . . . . . . . . . . . . 11 72 1.3.2. Constrained environments . . . . . . . . . . . . . . 11 73 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 12 74 1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 12 75 1.4. Leveraging the new key infrastructure / next steps . . . 12 76 1.5. Requirements for Autonomic Network Infrastructure (ANI) 77 devices . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 13 79 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 15 80 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 16 81 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 17 82 2.3.1. Identification of the Pledge . . . . . . . . . . . . 18 83 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 18 84 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 20 85 2.5. Architectural Components . . . . . . . . . . . . . . . . 23 86 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 23 87 2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 23 88 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 23 89 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 23 90 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 24 91 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 24 92 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 24 93 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 24 94 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 25 95 2.8. Determining the MASA to contact . . . . . . . . . . . . . 25 97 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 26 98 3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 27 99 3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27 100 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 27 101 3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 29 102 4. Proxying details (Pledge - Proxy - 103 Registrar) . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 33 105 4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 35 106 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 36 107 4.3. Proxy discovery and communication of Registrar . . . . . 36 108 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 38 109 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 39 110 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 40 111 5.3. Registrar Authorization of 112 Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 42 113 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 43 114 5.4.1. MASA authentication of 115 customer Registrar . . . . . . . . . . . . . . . . . 43 116 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 44 117 5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 46 118 5.5.2. MASA pinning of registrar . . . . . . . . . . . . . . 46 119 5.5.3. MASA checking of voucher request signature . . . . . 46 120 5.5.4. MASA verification of domain registrar . . . . . . . . 47 121 5.5.5. MASA verification of pledge prior-signed-voucher- 122 request . . . . . . . . . . . . . . . . . . . . . . . 48 123 5.5.6. MASA nonce handling . . . . . . . . . . . . . . . . . 48 124 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 48 125 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 51 126 5.6.2. Pledge authentication of provisional TLS connection . 52 127 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 53 128 5.8. Registrar audit-log request . . . . . . . . . . . . . . . 54 129 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 55 130 5.8.2. Calculation of domainID . . . . . . . . . . . . . . . 58 131 5.8.3. Registrar audit log verification . . . . . . . . . . 58 132 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 60 133 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 60 134 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 60 135 5.9.3. EST Client Certificate Request . . . . . . . . . . . 61 136 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 61 137 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 62 138 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 63 139 6. Clarification of transfer-encoding . . . . . . . . . . . . . 63 140 7. Reduced security operational modes . . . . . . . . . . . . . 63 141 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 64 142 7.2. Pledge security reductions . . . . . . . . . . . . . . . 64 143 7.3. Registrar security reductions . . . . . . . . . . . . . . 65 144 7.4. MASA security reductions . . . . . . . . . . . . . . . . 66 145 7.4.1. Issuing Nonceless vouchers . . . . . . . . . . . . . 67 146 7.4.2. Trusting Owners on First Use . . . . . . . . . . . . 67 147 7.4.3. Updating or extending voucher trust anchors . . . . . 68 148 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 149 8.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 69 150 8.2. Well-known EST registration . . . . . . . . . . . . . . . 69 151 8.3. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 69 152 8.4. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 70 153 8.5. DNS Service Names . . . . . . . . . . . . . . . . . . . . 70 154 8.6. MUD File Extension for the MASA . . . . . . . . . . . . . 70 155 9. Applicability to the Autonomic Control Plane (ACP) . . . . . 70 156 9.1. Operational Requirements . . . . . . . . . . . . . . . . 72 157 9.1.1. MASA Operational Requirements . . . . . . . . . . . . 72 158 9.1.2. Domain Owner Operational Requirements . . . . . . . . 73 159 9.1.3. Device Operational Requirements . . . . . . . . . . . 73 160 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 74 161 10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 74 162 10.2. What BRSKI-EST reveals . . . . . . . . . . . . . . . . . 74 163 10.3. What BRSKI-MASA reveals to the manufacturer . . . . . . 75 164 10.4. Manufacturers and Used or Stolen Equipment . . . . . . . 77 165 10.5. Manufacturers and Grey market equipment . . . . . . . . 78 166 10.6. Some mitigations for meddling by manufacturers . . . . . 79 167 10.7. Death of a manufacturer . . . . . . . . . . . . . . . . 80 168 11. Security Considerations . . . . . . . . . . . . . . . . . . . 81 169 11.1. Denial of Service (DoS) against MASA . . . . . . . . . . 81 170 11.2. DomainID must be resistant to second-preimage attacks . 82 171 11.3. Availability of good random numbers . . . . . . . . . . 82 172 11.4. Freshness in Voucher-Requests . . . . . . . . . . . . . 83 173 11.5. Trusting manufacturers . . . . . . . . . . . . . . . . . 84 174 11.6. Manufacturer Maintenance of trust anchors . . . . . . . 85 175 11.6.1. Compromise of Manufacturer IDevID signing keys . . . 86 176 11.6.2. Compromise of MASA signing keys . . . . . . . . . . 87 177 11.6.3. Compromise of MASA web service . . . . . . . . . . . 89 178 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 89 179 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 180 13.1. Normative References . . . . . . . . . . . . . . . . . . 90 181 13.2. Informative References . . . . . . . . . . . . . . . . . 93 182 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 97 183 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 97 184 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 97 185 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 97 186 Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 98 187 Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 100 188 D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 100 189 D.1.1. MASA key pair for voucher signatures . . . . . . . . 100 190 D.1.2. Manufacturer key pair for IDevID signatures . . . . . 100 191 D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 101 192 D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 103 194 D.2. Example process . . . . . . . . . . . . . . . . . . . . . 104 195 D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 105 196 D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 108 197 D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 113 198 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 117 200 1. Introduction 202 The Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol 203 provides a solution for secure zero-touch (automated) bootstrap of 204 new (unconfigured) devices that are called pledges in this document. 205 Pledges have an IDevID installed in them at the factory. 207 "BRSKI" is pronounced like "brewski", a colloquial term for beer in 208 Canada and parts of the US-midwest. [brewski] 210 This document primarily provides for the needs of the ISP and 211 Enterprise focused ANIMA Autonomic Control Plane (ACP) 212 [I-D.ietf-anima-autonomic-control-plane]. This bootstrap process 213 satisfies the [RFC7575] requirements of section 3.3 of making all 214 operations secure by default. Other users of the BRSKI protocol will 215 need to provide separate applicability statements that include 216 privacy and security considerations appropriate to that deployment. 217 Section 9 explains the detailed applicability for this the ACP usage. 219 The BRSKI protocol requires a significant amount of communication 220 between manufacturer and owner: in its default modes it provides a 221 cryptographic transfer of control to the initial owner. In its 222 strongest modes, it leverages sales channel information to identify 223 the owner in advance. Resale of devices is possible, provided that 224 the manufacturer is willing to authorize the transfer. Mechanisms to 225 enable transfers of ownership without manufacturer authorization are 226 not included in this version of the protocol, but could be designed 227 into future versions. 229 This document describes how pledges discover (or are discovered by) 230 an element of the network domain to which the pledge belongs that 231 will perform the bootstrap. This element (device) is called the 232 registrar. Before any other operation, pledge and registrar need to 233 establish mutual trust: 235 1. Registrar authenticating the pledge: "Who is this device? What 236 is its identity?" 238 2. Registrar authorizing the pledge: "Is it mine? Do I want it? 239 What are the chances it has been compromised?" 241 3. Pledge authenticating the registrar: "What is this registrar's 242 identity?" 244 4. Pledge authorizing the registrar: "Should I join this network?" 246 This document details protocols and messages to answer the above 247 questions. It uses a TLS connection and an PKIX-shaped (X.509v3) 248 certificate (an IEEE 802.1AR [IDevID] IDevID) of the pledge to answer 249 points 1 and 2. It uses a new artifact called a "voucher" that the 250 registrar receives from a "Manufacturer Authorized Signing Authority" 251 (MASA) and passes to the pledge to answer points 3 and 4. 253 A proxy provides very limited connectivity between the pledge and the 254 registrar. 256 The syntactic details of vouchers are described in detail in 257 [RFC8366]. This document details automated protocol mechanisms to 258 obtain vouchers, including the definition of a 'voucher-request' 259 message that is a minor extension to the voucher format (see 260 Section 3) defined by [RFC8366]. 262 BRSKI results in the pledge storing an X.509 root certificate 263 sufficient for verifying the registrar identity. In the process a 264 TLS connection is established that can be directly used for 265 Enrollment over Secure Transport (EST). In effect BRSKI provides an 266 automated mechanism for the "Bootstrap Distribution of CA 267 Certificates" described in [RFC7030] Section 4.1.1 wherein the pledge 268 "MUST [...] engage a human user to authorize the CA certificate using 269 out-of-band" information. With BRSKI the pledge now can automate 270 this process using the voucher. Integration with a complete EST 271 enrollment is optional but trivial. 273 BRSKI is agile enough to support bootstrapping alternative key 274 infrastructures, such as a symmetric key solutions, but no such 275 system is described in this document. 277 1.1. Prior Bootstrapping Approaches 279 To literally "pull yourself up by the bootstraps" is an impossible 280 action. Similarly the secure establishment of a key infrastructure 281 without external help is also an impossibility. Today it is commonly 282 accepted that the initial connections between nodes are insecure, 283 until key distribution is complete, or that domain-specific keying 284 material (often pre-shared keys, including mechanisms like SIM cards) 285 is pre-provisioned on each new device in a costly and non-scalable 286 manner. Existing automated mechanisms are known as non-secured 287 'Trust on First Use' (TOFU) [RFC7435], 'resurrecting duckling' 288 [Stajano99theresurrecting] or 'pre-staging'. 290 Another prior approach has been to try and minimize user actions 291 during bootstrapping, but not eliminate all user-actions. The 292 original EST protocol [RFC7030] does reduce user actions during 293 bootstrap but does not provide solutions for how the following 294 protocol steps can be made autonomic (not involving user actions): 296 o using the Implicit Trust Anchor [RFC7030] database to authenticate 297 an owner specific service (not an autonomic solution because the 298 URL must be securely distributed), 300 o engaging a human user to authorize the CA certificate using out- 301 of-band data (not an autonomic solution because the human user is 302 involved), 304 o using a configured Explicit TA database (not an autonomic solution 305 because the distribution of an explicit TA database is not 306 autonomic), 308 o and using a Certificate-Less TLS mutual authentication method (not 309 an autonomic solution because the distribution of symmetric key 310 material is not autonomic). 312 These "touch" methods do not meet the requirements for zero-touch. 314 There are "call home" technologies where the pledge first establishes 315 a connection to a well known manufacturer service using a common 316 client-server authentication model. After mutual authentication, 317 appropriate credentials to authenticate the target domain are 318 transferred to the pledge. This creates several problems and 319 limitations: 321 o the pledge requires realtime connectivity to the manufacturer 322 service, 324 o the domain identity is exposed to the manufacturer service (this 325 is a privacy concern), 327 o the manufacturer is responsible for making the authorization 328 decisions (this is a liability concern), 330 BRSKI addresses these issues by defining extensions to the EST 331 protocol for the automated distribution of vouchers. 333 1.2. Terminology 335 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 336 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 337 "OPTIONAL" in this document are to be interpreted as described in BCP 338 14 [RFC2119] [RFC8174] when, and only when, they appear in all 339 capitals, as shown here. 341 The following terms are defined for clarity: 343 ANI: The Autonomic Network Infrastructure as defined by 344 [I-D.ietf-anima-reference-model]. Section 9 details specific 345 requirements for pledges, proxies and registrars when they are 346 part of an ANI. 348 Circuit Proxy: A stateful implementation of the join proxy. This is 349 the assumed type of proxy. 351 drop-ship: The physical distribution of equipment containing the 352 "factory default" configuration to a final destination. In zero- 353 touch scenarios there is no staging or pre-configuration during 354 drop-ship. 356 Domain: The set of entities that share a common local trust anchor. 357 This includes the proxy, registrar, Domain Certificate Authority, 358 Management components and any existing entity that is already a 359 member of the domain. 361 domainID: The domain IDentity is a unique value based upon the 362 Registrar CA's certificate. Section 5.8.2 specifies how it is 363 calculated. 365 Domain CA: The domain Certification Authority (CA) provides 366 certification functionalities to the domain. At a minimum it 367 provides certification functionalities to a registrar and manages 368 the private key that defines the domain. Optionally, it certifies 369 all elements. 371 enrollment: The process where a device presents key material to a 372 network and acquires a network-specific identity. For example 373 when a certificate signing request is presented to a certification 374 authority and a certificate is obtained in response. 376 imprint: The process where a device obtains the cryptographic key 377 material to identify and trust future interactions with a network. 378 This term is taken from Konrad Lorenz's work in biology with new 379 ducklings: during a critical period, the duckling would assume 380 that anything that looks like a mother duck is in fact their 381 mother. An equivalent for a device is to obtain the fingerprint 382 of the network's root certification authority certificate. A 383 device that imprints on an attacker suffers a similar fate to a 384 duckling that imprints on a hungry wolf. Securely imprinting is a 385 primary focus of this document [imprinting]. The analogy to 386 Lorenz's work was first noted in [Stajano99theresurrecting]. 388 IDevID: An Initial Device Identity X.509 certificate installed by 389 the vendor on new equipment. This is a term from 802.1AR [IDevID] 391 IPIP Proxy: A stateless proxy alternative. 393 Join Proxy: A domain entity that helps the pledge join the domain. 394 A join proxy facilitates communication for devices that find 395 themselves in an environment where they are not provided 396 connectivity until after they are validated as members of the 397 domain. For simplicity this document sometimes uses the term of 398 'proxy' to indicate the join proxy. The pledge is unaware that 399 they are communicating with a proxy rather than directly with a 400 registrar. 402 Join Registrar (and Coordinator): A representative of the domain 403 that is configured, perhaps autonomically, to decide whether a new 404 device is allowed to join the domain. The administrator of the 405 domain interfaces with a "join registrar (and coordinator)" to 406 control this process. Typically a join registrar is "inside" its 407 domain. For simplicity this document often refers to this as just 408 "registrar". Within [I-D.ietf-anima-reference-model] this is 409 referred to as the "join registrar autonomic service agent". 410 Other communities use the abbreviation "JRC". 412 LDevID: A Local Device Identity X.509 certificate installed by the 413 owner of the equipment. This is a term from 802.1AR [IDevID] 415 manufacturer: the term manufacturer is used throughout this document 416 to be the entity that created the device. This is typically the 417 "original equipment manufacturer" or OEM, but in more complex 418 situations it could be a "value added retailer" (VAR), or possibly 419 even a systems integrator. In general, it a goal of BRSKI to 420 eliminate small distinctions between different sales channels. 421 The reason for this is that it permits a single device, with a 422 uniform firmware load, to be shipped directly to all customers. 423 This eliminates costs for the manufacturer. This also reduces the 424 number of products supported in the field increasing the chance 425 that firmware will be more up to date. 427 MASA Audit-Log: An anonymized list of previous owners maintained by 428 the MASA on a per device (per pledge) basis. Described in 429 Section 5.8.1. 431 MASA Service: A third-party Manufacturer Authorized Signing 432 Authority (MASA) service on the global Internet. The MASA signs 433 vouchers. It also provides a repository for audit-log information 434 of privacy protected bootstrapping events. It does not track 435 ownership. 437 nonced: a voucher (or request) that contains a nonce (the normal 438 case). 440 nonceless: a voucher (or request) that does not contain a nonce, 441 relying upon accurate clocks for expiration, or which does not 442 expire. 444 offline: When an architectural component cannot perform realtime 445 communications with a peer, either due to network connectivity or 446 because the peer is turned off, the operation is said to be 447 occurring offline. 449 Ownership Tracker: An Ownership Tracker service on the global 450 Internet. The Ownership Tracker uses business processes to 451 accurately track ownership of all devices shipped against domains 452 that have purchased them. Although optional, this component 453 allows vendors to provide additional value in cases where their 454 sales and distribution channels allow for accurate tracking of 455 such ownership. Ownership tracking information is indicated in 456 vouchers as described in [RFC8366] 458 Pledge: The prospective (unconfigured) device, which has an identity 459 installed at the factory. 461 (Public) Key Infrastructure: The collection of systems and processes 462 that sustain the activities of a public key system. The registrar 463 acts as an [RFC5280] and [RFC5272] (see section 7) "Registration 464 Authority". 466 TOFU: Trust on First Use. Used similarly to [RFC7435]. This is 467 where a pledge device makes no security decisions but rather 468 simply trusts the first registrar it is contacted by. This is 469 also known as the "resurrecting duckling" model. 471 Voucher: A signed artifact from the MASA that indicates to a pledge 472 the cryptographic identity of the registrar it should trust. 473 There are different types of vouchers depending on how that trust 474 is asserted. Multiple voucher types are defined in [RFC8366] 476 1.3. Scope of solution 477 1.3.1. Support environment 479 This solution (BRSKI) can support large router platforms with multi- 480 gigabit inter-connections, mounted in controlled access data centers. 481 But this solution is not exclusive to large equipment: it is intended 482 to scale to thousands of devices located in hostile environments, 483 such as ISP provided CPE devices which are drop-shipped to the end 484 user. The situation where an order is fulfilled from distributed 485 warehouse from a common stock and shipped directly to the target 486 location at the request of a domain owner is explicitly supported. 487 That stock ("SKU") could be provided to a number of potential domain 488 owners, and the eventual domain owner will not know a-priori which 489 device will go to which location. 491 The bootstrapping process can take minutes to complete depending on 492 the network infrastructure and device processing speed. The network 493 communication itself is not optimized for speed; for privacy reasons, 494 the discovery process allows for the pledge to avoid announcing its 495 presence through broadcasting. 497 Nomadic or mobile devices often need to acquire credentials to access 498 the network at the new location. An example of this is mobile phone 499 roaming among network operators, or even between cell towers. This 500 is usually called handoff. BRSKI does not provide a low-latency 501 handoff which is usually a requirement in such situations. For these 502 solutions BRSKI can be used to create a relationship (an LDevID) with 503 the "home" domain owner. The resulting credentials are then used to 504 provide credentials more appropriate for a low-latency handoff. 506 1.3.2. Constrained environments 508 Questions have been posed as to whether this solution is suitable in 509 general for Internet of Things (IoT) networks. This depends on the 510 capabilities of the devices in question. The terminology of 511 [RFC7228] is best used to describe the boundaries. 513 The solution described in this document is aimed in general at non- 514 constrained (i.e., class 2+ [RFC7228]) devices operating on a non- 515 Challenged network. The entire solution as described here is not 516 intended to be useable as-is by constrained devices operating on 517 challenged networks (such as 802.15.4 Low-power Lossy Networks 518 (LLN)s). 520 Specifically, there are protocol aspects described here that might 521 result in congestion collapse or energy-exhaustion of intermediate 522 battery powered routers in an LLN. Those types of networks should 523 not use this solution. These limitations are predominately related 524 to the large credential and key sizes required for device 525 authentication. Defining symmetric key techniques that meet the 526 operational requirements is out-of-scope but the underlying protocol 527 operations (TLS handshake and signing structures) have sufficient 528 algorithm agility to support such techniques when defined. 530 The imprint protocol described here could, however, be used by non- 531 energy constrained devices joining a non-constrained network (for 532 instance, smart light bulbs are usually mains powered, and speak 533 802.11). It could also be used by non-constrained devices across a 534 non-energy constrained, but challenged network (such as 802.15.4). 535 The certificate contents, and the process by which the four questions 536 above are resolved do apply to constrained devices. It is simply the 537 actual on-the-wire imprint protocol that could be inappropriate. 539 1.3.3. Network Access Controls 541 This document presumes that network access control has either already 542 occurred, is not required, or is integrated by the proxy and 543 registrar in such a way that the device itself does not need to be 544 aware of the details. Although the use of an X.509 Initial Device 545 Identity is consistent with IEEE 802.1AR [IDevID], and allows for 546 alignment with 802.1X network access control methods, its use here is 547 for pledge authentication rather than network access control. 548 Integrating this protocol with network access control, perhaps as an 549 Extensible Authentication Protocol (EAP) method (see [RFC3748]), is 550 out-of-scope. 552 1.3.4. Bootstrapping is not Booting 554 This document describes "bootstrapping" as the protocol used to 555 obtain a local trust anchor. It is expected that this trust anchor, 556 along with any additional configuration information subsequently 557 installed, is persisted on the device across system restarts 558 ("booting"). Bootstrapping occurs only infrequently such as when a 559 device is transferred to a new owner or has been reset to factory 560 default settings. 562 1.4. Leveraging the new key infrastructure / next steps 564 As a result of the protocol described herein, the bootstrapped 565 devices have the Domain CA trust anchor in common. An end entity 566 certificate has optionally been issued from the Domain CA. This 567 makes it possible to securely deploy functionalities across the 568 domain, e.g: 570 o Device management. 572 o Routing authentication. 574 o Service discovery. 576 The major intended benefit is that it possible to use the credentials 577 deployed by this protocol to secure the Autonomic Control Plane (ACP) 578 ([I-D.ietf-anima-autonomic-control-plane]). 580 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices 582 The BRSKI protocol can be used in a number of environments. Some of 583 the options in this document are the result of requirements that are 584 out of the ANI scope. This section defines the base requirements for 585 ANI devices. 587 For devices that intend to become part of an Autonomic Network 588 Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes 589 an Autonomic Control Plane 590 ([I-D.ietf-anima-autonomic-control-plane]), the BRSKI protocol MUST 591 be implemented. 593 The pledge must perform discovery of the proxy as described in 594 Section 4.1 using Generic Autonomic Signaling Protocol (GRASP)'s DULL 595 [I-D.ietf-anima-grasp] M_FLOOD announcements. 597 Upon successfully validating a voucher artifact, a status telemetry 598 MUST be returned. See Section 5.7. 600 An ANIMA ANI pledge MUST implement the EST automation extensions 601 described in Section 5.9. They supplement the [RFC7030] EST to 602 better support automated devices that do not have an end user. 604 The ANI Join Registrar Autonomic Service Agent (ASA) MUST support all 605 the BRSKI and above listed EST operations. 607 All ANI devices SHOULD support the BRSKI proxy function, using 608 circuit proxies over the ACP. (See Section 4.3) 610 2. Architectural Overview 612 The logical elements of the bootstrapping framework are described in 613 this section. Figure 1 provides a simplified overview of the 614 components. 616 +------------------------+ 617 +--------------Drop Ship----------------| Vendor Service | 618 | +------------------------+ 619 | | M anufacturer| | 620 | | A uthorized |Ownership| 621 | | S igning |Tracker | 622 | | A uthority | | 623 | +--------------+---------+ 624 | ^ 625 | | BRSKI- 626 V | MASA 627 +-------+ ............................................|... 628 | | . | . 629 | | . +------------+ +-----------+ | . 630 | | . | | | | | . 631 |Pledge | . | Join | | Domain <-------+ . 632 | | . | Proxy | | Registrar | . 633 | <-------->............<-------> (PKI RA) | . 634 | | | BRSKI-EST | | . 635 | | . | | +-----+-----+ . 636 |IDevID | . +------------+ | e.g. RFC7030 . 637 | | . +-----------------+----------+ . 638 | | . | Key Infrastructure | . 639 | | . | (e.g., PKI Certificate | . 640 +-------+ . | Authority) | . 641 . +----------------------------+ . 642 . . 643 ................................................ 644 "Domain" components 646 Figure 1: Architecture Overview 648 We assume a multi-vendor network. In such an environment there could 649 be a Manufacturer Service for each manufacturer that supports devices 650 following this document's specification, or an integrator could 651 provide a generic service authorized by multiple manufacturers. It 652 is unlikely that an integrator could provide Ownership Tracking 653 services for multiple manufacturers due to the required sales channel 654 integrations necessary to track ownership. 656 The domain is the managed network infrastructure with a Key 657 Infrastructure the pledge is joining. The domain provides initial 658 device connectivity sufficient for bootstrapping through a proxy. 659 The domain registrar authenticates the pledge, makes authorization 660 decisions, and distributes vouchers obtained from the Manufacturer 661 Service. Optionally the registrar also acts as a PKI Certification 662 Authority. 664 2.1. Behavior of a Pledge 666 The pledge goes through a series of steps, which are outlined here at 667 a high level. 669 ------------ 670 / Factory \ 671 \ default / 672 -----+------ 673 | 674 +------v-------+ 675 | (1) Discover | 676 +------------> | 677 | +------+-------+ 678 | | 679 | +------v-------+ 680 | | (2) Identify | 681 ^------------+ | 682 | rejected +------+-------+ 683 | | 684 | +------v-------+ 685 | | (3) Request | 686 | | Join | 687 | +------+-------+ 688 | | 689 | +------v-------+ 690 | | (4) Imprint | 691 ^------------+ | 692 | Bad MASA +------+-------+ 693 | response | send Voucher Status Telemetry 694 | +------v-------+ 695 | | (5) Enroll |<---+ (non-error HTTP codes ) 696 ^------------+ |\___/ (e.g. 202 'Retry-After') 697 | Enroll +------+-------+ 698 | Failure | 699 | -----v------ 700 | / Enrolled \ 701 ^------------+ | 702 Factory \------------/ 703 reset 705 Figure 2: Pledge State Diagram 707 State descriptions for the pledge are as follows: 709 1. Discover a communication channel to a registrar. 711 2. Identify itself. This is done by presenting an X.509 IDevID 712 credential to the discovered registrar (via the proxy) in a TLS 713 handshake. (The registrar credentials are only provisionally 714 accepted at this time). 716 3. Request to join the discovered registrar. A unique nonce is 717 included ensuring that any responses can be associated with this 718 particular bootstrapping attempt. 720 4. Imprint on the registrar. This requires verification of the 721 manufacturer-service-provided voucher. A voucher contains 722 sufficient information for the pledge to complete authentication 723 of a registrar. This document details this step in depth. 725 5. Enroll. After imprint an authenticated TLS (HTTPS) connection 726 exists between pledge and registrar. Enrollment over Secure 727 Transport (EST) [RFC7030] can then be used to obtain a domain 728 certificate from a registrar. 730 The pledge is now a member of, and can be managed by, the domain and 731 will only repeat the discovery aspects of bootstrapping if it is 732 returned to factory default settings. 734 This specification details integration with EST enrollment so that 735 pledges can optionally obtain a locally issued certificate, although 736 any Representational State Transfer (REST) (see [REST]) interface 737 could be integrated in future work. 739 2.2. Secure Imprinting using Vouchers 741 A voucher is a cryptographically protected artifact (using a digital 742 signature) to the pledge device authorizing a zero-touch imprint on 743 the registrar domain. 745 The format and cryptographic mechanism of vouchers is described in 746 detail in [RFC8366]. 748 Vouchers provide a flexible mechanism to secure imprinting: the 749 pledge device only imprints when a voucher can be validated. At the 750 lowest security levels the MASA can indiscriminately issue vouchers 751 and log claims of ownership by domains. At the highest security 752 levels issuance of vouchers can be integrated with complex sales 753 channel integrations that are beyond the scope of this document. The 754 sales channel integration would verify actual (legal) ownership of 755 the pledge by the domain. This provides the flexibility for a number 756 of use cases via a single common protocol mechanism on the pledge and 757 registrar devices that are to be widely deployed in the field. The 758 MASA services have the flexibility to leverage either the currently 759 defined claim mechanisms or to experiment with higher or lower 760 security levels. 762 Vouchers provide a signed but non-encrypted communication channel 763 among the pledge, the MASA, and the registrar. The registrar 764 maintains control over the transport and policy decisions, allowing 765 the local security policy of the domain network to be enforced. 767 2.3. Initial Device Identifier 769 Pledge authentication and pledge voucher-request signing is via a 770 PKIX-shaped certificate installed during the manufacturing process. 771 This is the 802.1AR Initial Device Identifier (IDevID), and it 772 provides a basis for authenticating the pledge during the protocol 773 exchanges described here. There is no requirement for a common root 774 PKI hierarchy. Each device manufacturer can generate its own root 775 certificate. Specifically, the IDevID enables: 777 1. Uniquely identifying the pledge by the Distinguished Name (DN) 778 and subjectAltName (SAN) parameters in the IDevID. The unique 779 identification of a pledge in the voucher objects are derived 780 from those parameters as described below. Section 10.3 discusses 781 privacy implications of the identifier. 783 2. Provides a cryptographic authentication of the pledge to the 784 Registrar (see Section 5.3). 786 3. Secure auto-discovery of the pledge's MASA by the registrar (see 787 Section 2.8). 789 4. Signing of voucher-request by the pledge's IDevID (see 790 Section 3). 792 5. Provides a cryptographic authentication of the pledge to the MASA 793 (see Section 5.5.5). 795 Section 7.2.13 (2009 edition) and section 8.10.3 (2018 edition) of 796 [IDevID] discusses keyUsage and extendedKeyUsage extensions in the 797 IDevID certificate. [IDevID] acknowledges that adding restrictions 798 in the certificate limits applicability of these long-lived 799 certificates. This specification emphasizes this point, and 800 therefore RECOMMENDS that no key usage restrictions be included. 801 This is consistent with [RFC5280] section 4.2.1.3, which does not 802 require key usage restrictions for end entity certificates. 804 2.3.1. Identification of the Pledge 806 In the context of BRSKI, pledges have a 1:1 relationship with a 807 "serial-number". This serial-number is used both in the "serial- 808 number" field of voucher or voucher-requests (see Section 3) and in 809 local policies on registrar or MASA (see Section 5). 811 The serialNumber field is defined in [RFC5280]. That specification 812 allows for the field to be omitted if there is a good technical 813 reason. IDevID certificates for use with this protocol are REQUIRED 814 to include the "serialNumber" attribute with the device's unique 815 serial number (from [IDevID] section 7.2.8, and [RFC5280] section 816 4.1.2.2's list of standard attributes). 818 The serialNumber field is used as follows by the pledge to build the 819 "serial-number" that is placed in the voucher-request. In order to 820 build it, the fields need to be converted into a serial-number of 821 "type string". 823 An example of a printable form of the "serialNumber" field is 824 provided in [RFC4519] section 2.31 ("WI-3005"). That section further 825 provides equality and syntax attributes. 827 Due to the reality of existing device identity provisioning 828 processes, some manufacturers have stored serial-numbers in other 829 fields. Registrar's SHOULD be configurable, on a per-manufacturer 830 basis, to look for serial-number equivalents in other fields. 832 As explained in Section 5.5 the Registrar MUST extract the serial- 833 number again itself from the pledge's TLS certificate. It can 834 consult the serial-number in the pledge-request if there are any 835 possible confusion about the source of the serial-number. 837 2.3.2. MASA URI extension 839 This document defines a new PKIX non-critical certificate extension 840 to carry the MASA URI. This extension is intended to be used in the 841 IDevID certificate. The URI is represented as described in 842 Section 7.4 of [RFC5280]. 844 The URI provides the authority information. The BRSKI "/.well-known" 845 tree ([RFC5785]) is described in Section 5. 847 A complete URI MAY be in this extension, including the 'scheme', 848 'authority', and 'path', The complete URI will typically be used in 849 diagnostic or experimental situations. Typically, (and in 850 consideration to constrained systems), this SHOULD be reduced to only 851 the 'authority', in which case a scheme of "https://" ([RFC7230] 852 section 2.7.3) and 'path' of "/.well-known/est" is to be assumed. 854 The registrar can assume that only the 'authority' is present in the 855 extension, if there are no slash ("/") characters in the extension. 857 Section 7.4 of [RFC5280] calls out various schemes that MUST be 858 supported, including LDAP, HTTP and FTP. However, the registrar MUST 859 use HTTPS for the BRSKI-MASA connection. 861 The new extension is identified as follows: 863 865 MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) 866 internet(1) security(5) mechanisms(5) pkix(7) 867 id-mod(0) id-mod-MASAURLExtn2016(TBD) } 869 DEFINITIONS IMPLICIT TAGS ::= BEGIN 871 -- EXPORTS ALL -- 873 IMPORTS 874 EXTENSION 875 FROM PKIX-CommonTypes-2009 876 { iso(1) identified-organization(3) dod(6) internet(1) 877 security(5) mechanisms(5) pkix(7) id-mod(0) 878 id-mod-pkixCommon-02(57) } 880 id-pe FROM PKIX1Explicit-2009 881 { iso(1) identified-organization(3) dod(6) internet(1) 882 security(5) mechanisms(5) pkix(7) id-mod(0) 883 id-mod-pkix1-explicit-02(51) } ; 885 MASACertExtensions EXTENSION ::= { ext-MASAURL, ... } 886 ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax 887 IDENTIFIED BY id-pe-masa-url } 889 id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe TBD } 891 MASAURLSyntax ::= IA5String 893 END 895 897 Figure 3: MASAURL ASN.1 Module 899 The choice of id-pe is based on guidance found in Section 4.2.2 of 900 [RFC5280], "These extensions may be used to direct applications to 901 on-line information about the issuer or the subject". The MASA URL 902 is precisely that: online information about the particular subject. 904 2.4. Protocol Flow 906 A representative flow is shown in Figure 4 907 +--------+ +---------+ +------------+ +------------+ 908 | Pledge | | Circuit | | Domain | | Vendor | 909 | | | Join | | Registrar | | Service | 910 | | | Proxy | | (JRC) | | (MASA) | 911 +--------+ +---------+ +------------+ +------------+ 912 | | | Internet | 913 [discover] | | | 914 |<-RFC4862 IPv6 addr | | | 915 |<-RFC3927 IPv4 addr | Appendix A | Legend | 916 |-++++++++++++++++++->| | C - circuit | 917 | optional: mDNS query| Appendix B | join proxy | 918 | RFC6763/RFC6762 (+) | | P - provisional | 919 |<-++++++++++++++++++-| | TLS connection | 920 | GRASP M_FLOOD | | | 921 | periodic broadcast| | | 922 [identity] | | | 923 |<------------------->C<----------------->| | 924 | TLS via the Join Proxy | | 925 |<--Registrar TLS server authentication---| | 926 [PROVISIONAL accept of server cert] | | 927 P---X.509 client authentication---------->| | 928 [request join] | | 929 P---Voucher Request(w/nonce for voucher)->| | 930 P /------------------- | | 931 P | [accept device?] | 932 P | [contact Vendor] | 933 P | |--Pledge ID-------->| 934 P | |--Domain ID-------->| 935 P | |--optional:nonce--->| 936 P optional: | [extract DomainID] 937 P can occur in advance | [update audit log] 938 P if nonceleess | | 939 P | |<- voucher ---------| 940 P \------------------- | w/nonce if provided| 941 P<------voucher---------------------------| | 942 [imprint] | | 943 |-------voucher status telemetry--------->| | 944 | |<-device audit log--| 945 | [verify audit log and voucher] | 946 |<--------------------------------------->| | 947 [enroll] | | 948 | Continue with RFC7030 enrollment | | 949 | using now bidirectionally authenticated | | 950 | TLS session. | | 951 [enrolled] | | 953 Figure 4: Protocol Time Sequence Diagram 955 On initial bootstrap, a new device (the pledge) uses a local service 956 autodiscovery (GRASP or mDNS) to locate a join proxy. The join proxy 957 connects the pledge to a local registrar (the JRC). 959 Having found a candidate registrar, the fledgling pledge sends some 960 information about itself to the registrar, including its serial 961 number in the form of a voucher request and its device identity 962 certificate (IDevID) as part of the TLS session. 964 The registrar can determine whether it expected such a device to 965 appear, and locates a MASA. The location of the MASA is usually 966 found in an extension in the IDevID. Having determined that the MASA 967 is suitable, the entire information from the initial voucher request 968 (including device serial number) is transmitted over the internet in 969 a TLS protected channel to the manufacturer, along with information 970 about the registrar/owner. 972 The manufacturer can then apply policy based on the provided 973 information, as well as other sources of information (such as sales 974 records), to decide whether to approve the claim by the registrar to 975 own the device; if the claim is accepted, a voucher is issued that 976 directs the device to accept its new owner. 978 The voucher is returned to the registrar, but not immediately to the 979 device -- the registrar has an opportunity to examine the voucher, 980 the MASA's audit-logs, and other sources of information to determine 981 whether the device has been tampered with, and whether the bootstrap 982 should be accepted. 984 No filtering of information is possible in the signed voucher, so 985 this is a binary yes-or-no decision. If the registrar accepts the 986 voucher as a proper one for its device, the voucher is returned to 987 the pledge for imprinting. 989 The voucher also includes a trust anchor that the pledge uses as 990 representing the owner. This is used to successfully bootstrap from 991 an environment where only the manufacturer has built-in trust by the 992 device into an environment where the owner now has a PKI footprint on 993 the device. 995 When BRSKI is followed with EST this single footprint is further 996 leveraged into the full owner's PKI and a LDevID for the device. 997 Subsequent reporting steps provide flows of information to indicate 998 success/failure of the process. 1000 2.5. Architectural Components 1002 2.5.1. Pledge 1004 The pledge is the device that is attempting to join. The pledge is 1005 assumed to talk to the Join Proxy using link-local network 1006 connectivity. In most cases, the pledge has no other connectivity 1007 until the pledge completes the enrollment process and receives some 1008 kind of network credential. 1010 2.5.2. Join Proxy 1012 The join proxy provides HTTPS connectivity between the pledge and the 1013 registrar. A circuit proxy mechanism is described in Section 4. 1014 Additional mechanisms, including a CoAP mechanism and a stateless 1015 IPIP mechanism are the subject of future work. 1017 2.5.3. Domain Registrar 1019 The domain's registrar operates as the BRSKI-MASA client when 1020 requesting vouchers from the MASA (see Section 5.4). The registrar 1021 operates as the BRSKI-EST server when pledges request vouchers (see 1022 Section 5.1). The registrar operates as the BRSKI-EST server 1023 "Registration Authority" if the pledge requests an end entity 1024 certificate over the BRSKI-EST connection (see Section 5.9). 1026 The registrar uses an Implicit Trust Anchor database for 1027 authenticating the BRSKI-MASA connection's MASA TLS Server 1028 Certificate. Configuration or distribution of trust anchors is out- 1029 of-scope for this specification. 1031 The registrar uses a different Implicit Trust Anchor database for 1032 authenticating the BRSKI-EST connection's Pledge TLS Client 1033 Certificate. Configuration or distribution of the BRSKI-EST client 1034 trust anchors is out-of-scope of this specification. Note that the 1035 trust anchors in/excluded from the database will affect which 1036 manufacturers' devices are acceptable to the registrar as pledges, 1037 and can also be used to limit the set of MASAs that are trusted for 1038 enrollment. 1040 2.5.4. Manufacturer Service 1042 The Manufacturer Service provides two logically separate functions: 1043 the Manufacturer Authorized Signing Authority (MASA) described in 1044 Section 5.5 and Section 5.6, and an ownership tracking/auditing 1045 function described in Section 5.7 and Section 5.8. 1047 2.5.5. Public Key Infrastructure (PKI) 1049 The Public Key Infrastructure (PKI) administers certificates for the 1050 domain of concern, providing the trust anchor(s) for it and allowing 1051 enrollment of pledges with domain certificates. 1053 The voucher provides a method for the distribution of a single PKI 1054 trust anchor (as the "pinned-domain-cert"). A distribution of the 1055 full set of current trust anchors is possible using the optional EST 1056 integration. 1058 The domain's registrar acts as an [RFC5272] Registration Authority, 1059 requesting certificates for pledges from the Key Infrastructure. 1061 The expectations of the PKI are unchanged from EST [RFC7030]. This 1062 document does not place any additional architectural requirements on 1063 the Public Key Infrastructure. 1065 2.6. Certificate Time Validation 1067 2.6.1. Lack of realtime clock 1069 Many devices when bootstrapping do not have knowledge of the current 1070 time. Mechanisms such as Network Time Protocols cannot be secured 1071 until bootstrapping is complete. Therefore bootstrapping is defined 1072 with a framework that does not require knowledge of the current time. 1073 A pledge MAY ignore all time stamps in the voucher and in the 1074 certificate validity periods if it does not know the current time. 1076 The pledge is exposed to dates in the following five places: 1077 registrar certificate notBefore, registrar certificate notAfter, 1078 voucher created-on, and voucher expires-on. Additionally, CMS 1079 signatures contain a signingTime. 1081 A pledge with a real time clock in which it has confidence in, MUST 1082 check the above time fields in all certificates and signatures that 1083 it processes. 1085 If the voucher contains a nonce then the pledge MUST confirm the 1086 nonce matches the original pledge voucher-request. This ensures the 1087 voucher is fresh. See Section 5.2. 1089 2.6.2. Infinite Lifetime of IDevID 1091 [RFC5280] explains that long lived pledge certificates "SHOULD be 1092 assigned the GeneralizedTime value of 99991231235959Z" for the 1093 notAfter field. 1095 Some deployed IDevID management systems are not compliant with the 1096 802.1AR requirement for infinite lifetimes, and put in typical <= 3 1097 year certificate lifetimes. Registrars SHOULD be configurable on a 1098 per-manufacturer basis to ignore pledge lifetimes when the pledge did 1099 not follow the RFC5280 recommendations. 1101 2.7. Cloud Registrar 1103 There exist operationally open networks wherein devices gain 1104 unauthenticated access to the Internet at large. In these use cases 1105 the management domain for the device needs to be discovered within 1106 the larger Internet. The case where a device can boot and get access 1107 to larger Internet are less likely within the ANIMA ACP scope but may 1108 be more important in the future. In the ANIMA ACP scope, new devices 1109 will be quarantined behind a Join Proxy. 1111 There are additionally some greenfield situations involving an 1112 entirely new installation where a device may have some kind of 1113 management uplink that it can use (such as via 3G network for 1114 instance). In such a future situation, the device might use this 1115 management interface to learn that it should configure itself to 1116 become the local registrar. 1118 In order to support these scenarios, the pledge MAY contact a well 1119 known URI of a cloud registrar if a local registrar cannot be 1120 discovered or if the pledge's target use cases do not include a local 1121 registrar. 1123 If the pledge uses a well known URI for contacting a cloud registrar 1124 a manufacturer-assigned Implicit Trust Anchor database (see 1125 [RFC7030]) MUST be used to authenticate that service as described in 1126 [RFC6125]. The use of a DNS-ID for validation is appropriate, and it 1127 may include wildcard components on the left-mode side. This is 1128 consistent with the human user configuration of an EST server URI in 1129 [RFC7030] which also depends on RFC6125. 1131 2.8. Determining the MASA to contact 1133 The registrar needs to be able to contact a MASA that is trusted by 1134 the pledge in order to obtain vouchers. There are three mechanisms 1135 described: 1137 The device's Initial Device Identifier (IDevID) will normally contain 1138 the MASA URL as detailed in Section 2.3. This is the RECOMMENDED 1139 mechanism. 1141 If the registrar is integrated with [RFC8520] and the pledge IDevID 1142 contains the id-pe-mud-url then the registrar MAY attempt to obtain 1143 the MASA URL from the MUD file. The MUD file extension for the MASA 1144 URL is defined in Appendix C. 1146 It can be operationally difficult to ensure the necessary X.509 1147 extensions are in the pledge's IDevID due to the difficulty of 1148 aligning current pledge manufacturing with software releases and 1149 development. As a final fallback the registrar MAY be manually 1150 configured or distributed with a MASA URL for each manufacturer. 1151 Note that the registrar can only select the configured MASA URL based 1152 on the trust anchor -- so manufacturers can only leverage this 1153 approach if they ensure a single MASA URL works for all pledges 1154 associated with each trust anchor. 1156 3. Voucher-Request artifact 1158 Voucher-requests are how vouchers are requested. The semantics of 1159 the voucher-request are described below, in the YANG model. 1161 A pledge forms the "pledge voucher-request", signs it with it's 1162 IDevID and submits it to the registrar. 1164 The registrar in turn forms the "registrar voucher-request", signs it 1165 with it's Registrar keypair and submits it to the MASA. 1167 The "proximity-registrar-cert" leaf is used in the pledge voucher- 1168 requests. This provides a method for the pledge to assert the 1169 registrar's proximity. 1171 This network proximity results from the following properties in the 1172 ACP context: the pledge is connected to the Join Proxy (Section 4) 1173 using a Link-Local IPv6 connection. While the Join Proxy does not 1174 participate in any meaningful sense in the cryptography of the TLS 1175 connection (such as via a Channel Binding), the Registrar can observe 1176 that the connection is via the private ACP (ULA) address of the join 1177 proxy, and could not come from outside the ACP. The Pledge must 1178 therefore be at most one IPv6 Link-Local hop away from an existing 1179 node on the ACP. 1181 Other users of BRSKI will need to define other kinds of assertions if 1182 the network proximity described above does not match their needs. 1184 The "prior-signed-voucher-request" leaf is used in registrar voucher- 1185 requests. If present, it is the signed pledge voucher-request 1186 artifact. This provides a method for the registrar to forward the 1187 pledge's signed request to the MASA. This completes transmission of 1188 the signed "proximity-registrar-cert" leaf. 1190 Unless otherwise signaled (outside the voucher-request artifact), the 1191 signing structure is as defined for vouchers, see [RFC8366]. 1193 3.1. Nonceless Voucher Requests 1195 A registrar MAY also retrieve nonceless vouchers by sending nonceless 1196 voucher-requests to the MASA in order to obtain vouchers for use when 1197 the registrar does not have connectivity to the MASA. No "prior- 1198 signed-voucher-request" leaf would be included. The registrar will 1199 also need to know the serial number of the pledge. This document 1200 does not provide a mechanism for the registrar to learn that in an 1201 automated fashion. Typically this will be done via scanning of bar- 1202 code or QR-code on packaging, or via some sales channel integration. 1204 3.2. Tree Diagram 1206 The following tree diagram illustrates a high-level view of a 1207 voucher-request document. The voucher-request builds upon the 1208 voucher artifact described in [RFC8366]. The tree diagram is 1209 described in [RFC8340]. Each node in the diagram is fully described 1210 by the YANG module in Section 3.4. Please review the YANG module for 1211 a detailed description of the voucher-request format. 1213 module: ietf-voucher-request 1215 grouping voucher-request-grouping 1216 +---- voucher 1217 +---- created-on? yang:date-and-time 1218 +---- expires-on? yang:date-and-time 1219 +---- assertion? enumeration 1220 +---- serial-number string 1221 +---- idevid-issuer? binary 1222 +---- pinned-domain-cert? binary 1223 +---- domain-cert-revocation-checks? boolean 1224 +---- nonce? binary 1225 +---- last-renewal-date? yang:date-and-time 1226 +---- prior-signed-voucher-request? binary 1227 +---- proximity-registrar-cert? binary 1229 Figure 5: YANG Tree diagram for Voucher-Request 1231 3.3. Examples 1233 This section provides voucher-request examples for illustration 1234 purposes. These examples show the JSON prior to CMS wrapping. JSON 1235 encoding rules specify that any binary content by base64 encoded 1236 ([RFC4648]). The contents of the certificate have been elided to 1237 save space. For detailed examples, see Appendix D.2. These examples 1238 conform to the encoding rules defined in [RFC7951]. 1240 Example (1) The following example illustrates a pledge voucher- 1241 request. The assertion leaf is indicated as 'proximity' 1242 and the registrar's TLS server certificate is included 1243 in the 'proximity-registrar-cert' leaf. See 1244 Section 5.2. 1246 { 1247 "ietf-voucher-request:voucher": { 1248 "assertion": "proximity", 1249 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1250 "serial-number" : "JADA123456789", 1251 "created-on": "2017-01-01T00:00:00.000Z", 1252 "proximity-registrar-cert": "base64encodedvalue==" 1253 } 1254 } 1256 Figure 6: JSON representation of example Voucher-Request 1258 Example (2) The following example illustrates a registrar voucher- 1259 request. The 'prior-signed-voucher-request' leaf is 1260 populated with the pledge's voucher-request (such as the 1261 prior example). The pledge's voucher-request is a 1262 binary CMS signed object. In the JSON encoding used 1263 here it must be base64 encoded. The nonce and assertion 1264 have been carried forward from the pledge request to the 1265 registrar request. The serial-number is extracted from 1266 the pledge's Client Certificate from the TLS connection. 1267 See Section 5.5. 1269 { 1270 "ietf-voucher-request:voucher": { 1271 "assertion" : "proximity", 1272 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1273 "created-on": "2017-01-01T00:00:02.000Z", 1274 "idevid-issuer": "base64encodedvalue==", 1275 "serial-number": "JADA123456789", 1276 "prior-signed-voucher-request": "base64encodedvalue==" 1277 } 1278 } 1280 Figure 7: JSON representation of example Prior-Signed Voucher-Request 1282 Example (3) The following example illustrates a registrar voucher- 1283 request. The 'prior-signed-voucher-request' leaf is not 1284 populated with the pledge's voucher-request nor is the 1285 nonce leaf. This form might be used by a registrar 1286 requesting a voucher when the pledge can not communicate 1287 with the registrar (such as when it is powered down, or 1288 still in packaging), and therefore could not submit a 1289 nonce. This scenario is most useful when the registrar 1290 is aware that it will not be able to reach the MASA 1291 during deployment. See Section 5.5. 1293 { 1294 "ietf-voucher-request:voucher": { 1295 "created-on": "2017-01-01T00:00:02.000Z", 1296 "idevid-issuer": "base64encodedvalue==", 1297 "serial-number": "JADA123456789" 1298 } 1299 } 1301 Figure 8: JSON representation of Offline Voucher-Request 1303 3.4. YANG Module 1305 Following is a YANG [RFC7950] module formally extending the [RFC8366] 1306 voucher into a voucher-request. 1308 file "ietf-voucher-request@2018-02-14.yang" 1309 module ietf-voucher-request { 1310 yang-version 1.1; 1312 namespace 1313 "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; 1314 prefix "vcr"; 1316 import ietf-restconf { 1317 prefix rc; 1318 description "This import statement is only present to access 1319 the yang-data extension defined in RFC 8040."; 1320 reference "RFC 8040: RESTCONF Protocol"; 1321 } 1323 import ietf-voucher { 1324 prefix vch; 1325 description "This module defines the format for a voucher, 1326 which is produced by a pledge's manufacturer or 1327 delegate (MASA) to securely assign a pledge to 1328 an 'owner', so that the pledge may establish a secure 1329 connection to the owner's network infrastructure"; 1331 reference "RFC 8366: Voucher Profile for Bootstrapping Protocols"; 1332 } 1333 organization 1334 "IETF ANIMA Working Group"; 1336 contact 1337 "WG Web: 1338 WG List: 1339 Author: Kent Watsen 1340 1341 Author: Michael H. Behringer 1342 1343 Author: Toerless Eckert 1344 1345 Author: Max Pritikin 1346 1347 Author: Michael Richardson 1348 "; 1350 description 1351 "This module defines the format for a voucher request. 1352 It is a superset of the voucher itself. 1353 It provides content to the MASA for consideration 1354 during a voucher request. 1356 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 1357 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 1358 'MAY', and 'OPTIONAL' in this document are to be interpreted as 1359 described in BCP 14 RFC2119 RFC8174 when, and only when, they 1360 appear in all capitals, as shown here. 1362 Copyright (c) 2019 IETF Trust and the persons identified as 1363 authors of the code. All rights reserved. 1365 Redistribution and use in source and binary forms, with or without 1366 modification, is permitted pursuant to, and subject to the license 1367 terms contained in, the Simplified BSD License set forth in Section 1368 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 1369 (http://trustee.ietf.org/license-info). 1371 This version of this YANG module is part of RFC XXXX; see the RFC 1372 itself for full legal notices."; 1374 revision "2018-02-14" { 1375 description 1376 "Initial version"; 1377 reference 1378 "RFC XXXX: Voucher Profile for Bootstrapping Protocols"; 1379 } 1380 // Top-level statement 1381 rc:yang-data voucher-request-artifact { 1382 uses voucher-request-grouping; 1383 } 1385 // Grouping defined for future usage 1386 grouping voucher-request-grouping { 1387 description 1388 "Grouping to allow reuse/extensions in future work."; 1390 uses vch:voucher-artifact-grouping { 1391 refine "voucher/created-on" { 1392 mandatory false; 1393 } 1395 refine "voucher/pinned-domain-cert" { 1396 mandatory false; 1397 } 1399 refine "voucher/domain-cert-revocation-checks" { 1400 description "The domain-cert-revocation-checks field 1401 is not valid in a voucher request, and 1402 any occurence MUST be ignored"; 1403 } 1405 refine "voucher/assertion" { 1406 mandatory false; 1407 description "Any assertion included in registrar voucher 1408 requests SHOULD be ignored by the MASA."; 1409 } 1411 augment "voucher" { 1412 description 1413 "Adds leaf nodes appropriate for requesting vouchers."; 1415 leaf prior-signed-voucher-request { 1416 type binary; 1417 description 1418 "If it is necessary to change a voucher, or re-sign and 1419 forward a voucher that was previously provided along a 1420 protocol path, then the previously signed voucher SHOULD be 1421 included in this field. 1423 For example, a pledge might sign a voucher request 1424 with a proximity-registrar-cert, and the registrar 1425 then includes it as the prior-signed-voucher-request field. 1426 This is a simple mechanism for a chain of trusted 1427 parties to change a voucher request, while 1428 maintaining the prior signature information. 1430 The Registrar and MASA MAY examine the prior signed 1431 voucher information for the 1432 purposes of policy decisions. For example this information 1433 could be useful to a MASA to determine that both pledge and 1434 registrar agree on proximity assertions. The MASA SHOULD 1435 remove all prior-signed-voucher-request information when 1436 signing a voucher for imprinting so as to minimize the 1437 final voucher size."; 1438 } 1440 leaf proximity-registrar-cert { 1441 type binary; 1442 description 1443 "An X.509 v3 certificate structure as specified by RFC 5280, 1444 Section 4 encoded using the ASN.1 distinguished encoding 1445 rules (DER), as specified in ITU-T X.690. 1447 The first certificate in the Registrar TLS server 1448 certificate_list sequence (the end-entity TLS certificate, 1449 see [RFC8446]) presented by the Registrar to the Pledge. 1450 This MUST be populated in a Pledge's voucher request when a 1451 proximity assertion is requested."; 1452 } 1453 } 1454 } 1455 } 1457 } 1459 1461 Figure 9: YANG module for Voucher-Request 1463 4. Proxying details (Pledge - Proxy - Registrar) 1465 This section is normative for uses with an ANIMA ACP. The use of 1466 GRASP mechanism is part of the ACP. Other users of BRSKI will need 1467 to define an equivalent proxy mechanism, and an equivalent mechanism 1468 to configure the proxy. 1470 The role of the proxy is to facilitate communications. The proxy 1471 forwards packets between the pledge and a registrar that has been 1472 provisioned to the proxy via full GRASP ACP discovery. 1474 This section defines a stateful proxy mechanism which is referred to 1475 as a "circuit" proxy. This is a form of Application Level Gateway 1476 ([RFC2663] section 2.9). 1478 The proxy does not terminate the TLS handshake: it passes streams of 1479 bytes onward without examination. A proxy MUST NOT assume any 1480 specific TLS version. Please see [RFC8446] section 9.3 for details 1481 on TLS invariants. 1483 A Registrar can directly provide the proxy announcements described 1484 below, in which case the announced port can point directly to the 1485 Registrar itself. In this scenario the pledge is unaware that there 1486 is no proxying occurring. This is useful for Registrars which are 1487 servicing pledges on directly connected networks. 1489 As a result of the proxy Discovery process in Section 4.1.1, the port 1490 number exposed by the proxy does not need to be well known, or 1491 require an IANA allocation. 1493 During the discovery of the Registrar by the Join Proxy, the Join 1494 Proxy will also learn which kinds of proxy mechanisms are available. 1495 This will allow the Join Proxy to use the lowest impact mechanism 1496 which the Join Proxy and Registrar have in common. 1498 In order to permit the proxy functionality to be implemented on the 1499 maximum variety of devices the chosen mechanism should use the 1500 minimum amount of state on the proxy device. While many devices in 1501 the ANIMA target space will be rather large routers, the proxy 1502 function is likely to be implemented in the control plane CPU of such 1503 a device, with available capabilities for the proxy function similar 1504 to many class 2 IoT devices. 1506 The document [I-D.richardson-anima-state-for-joinrouter] provides a 1507 more extensive analysis and background of the alternative proxy 1508 methods. 1510 4.1. Pledge discovery of Proxy 1512 The result of discovery is a logical communication with a registrar, 1513 through a proxy. The proxy is transparent to the pledge. The 1514 communication between the pledge and Join Proxy is over IPv6 Link- 1515 Local addresses. 1517 To discover the proxy the pledge performs the following actions: 1519 1. MUST: Obtains a local address using IPv6 methods as described in 1520 [RFC4862] IPv6 Stateless Address AutoConfiguration. Use of 1521 [RFC4941] temporary addresses is encouraged. To limit pervasive 1522 monitoring ( [RFC7258]), a new temporary address MAY use a short 1523 lifetime (that is, set TEMP_PREFERRED_LIFETIME to be short). 1524 Pledges will generally prefer use of IPv6 Link-Local addresses, 1525 and discovery of proxy will be by Link-Local mechanisms. IPv4 1526 methods are described in Appendix A 1528 2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) 1529 announcements of the objective: "AN_Proxy". See section 1530 Section 4.1.1 for the details of the objective. The pledge MAY 1531 listen concurrently for other sources of information, see 1532 Appendix B. 1534 Once a proxy is discovered the pledge communicates with a registrar 1535 through the proxy using the bootstrapping protocol defined in 1536 Section 5. 1538 While the GRASP M_FLOOD mechanism is passive for the pledge, the non- 1539 normative other methods (mDNS, and IPv4 methods) described in 1540 Appendix B are active. The pledge SHOULD run those methods in 1541 parallel with listening to for the M_FLOOD. The active methods 1542 SHOULD back-off by doubling to a maximum of one hour to avoid 1543 overloading the network with discovery attempts. Detection of change 1544 of physical link status (Ethernet carrier for instance) SHOULD reset 1545 the back off timers. 1547 The pledge could discover more than one proxy on a given physical 1548 interface. The pledge can have a multitude of physical interfaces as 1549 well: a layer-2/3 Ethernet switch may have hundreds of physical 1550 ports. 1552 Each possible proxy offer SHOULD be attempted up to the point where a 1553 valid voucher is received: while there are many ways in which the 1554 attempt may fail, it does not succeed until the voucher has been 1555 validated. 1557 The connection attempts via a single proxy SHOULD exponentially back- 1558 off to a maximum of one hour to avoid overloading the network 1559 infrastructure. The back-off timer for each MUST be independent of 1560 other connection attempts. 1562 Connection attempts SHOULD be run in parallel to avoid head of queue 1563 problems wherein an attacker running a fake proxy or registrar could 1564 perform protocol actions intentionally slowly. Connection attempts 1565 to different proxies SHOULD be sent with an interval of 3 to 5s. The 1566 pledge SHOULD continue to listen to for additional GRASP M_FLOOD 1567 messages during the connection attempts. 1569 Each connection attempt through a distinct Join Proxy MUST have a 1570 unique nonce in the voucher-request. 1572 Once a connection to a registrar is established (e.g. establishment 1573 of a TLS session key) there are expectations of more timely 1574 responses, see Section 5.2. 1576 Once all discovered services are attempted (assuming that none 1577 succeeded) the device MUST return to listening for GRASP M_FLOOD. It 1578 SHOULD periodically retry any manufacturer-specific mechanisms. The 1579 pledge MAY prioritize selection order as appropriate for the 1580 anticipated environment. 1582 4.1.1. Proxy GRASP announcements 1584 A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself. 1585 This announcement can be within the same message as the ACP 1586 announcement detailed in [I-D.ietf-anima-autonomic-control-plane]. 1588 The formal Concise Data Definition Language (CDDL) [RFC8610] 1589 definition is: 1591 flood-message = [M_FLOOD, session-id, initiator, ttl, 1592 +[objective, (locator-option / [])]] 1594 objective = ["AN_Proxy", objective-flags, loop-count, 1595 objective-value] 1597 ttl = 180000 ; 180,000 ms (3 minutes) 1598 initiator = ACP address to contact Registrar 1599 objective-flags = sync-only ; as in GRASP spec 1600 sync-only = 4 ; M_FLOOD only requires synchronization 1601 loop-count = 1 ; one hop only 1602 objective-value = any ; none 1604 locator-option = [ O_IPv6_LOCATOR, ipv6-address, 1605 transport-proto, port-number ] 1606 ipv6-address = the v6 LL of the Proxy 1607 $transport-proto /= IPPROTO_TCP ; note this can be any value from the 1608 ; IANA protocol registry, as per 1609 ; [GRASP] section 2.9.5.1, note 3. 1610 port-number = selected by Proxy 1612 Figure 10: CDDL definition of Proxy Discovery message 1614 Here is an example M_FLOOD announcing a proxy at fe80::1, on TCP port 1615 4443. 1617 [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, 1618 ["AN_Proxy", 4, 1, ""], 1619 [O_IPv6_LOCATOR, 1620 h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]] 1622 Figure 11: Example of Proxy Discovery message 1624 On a small network the Registrar MAY include the GRASP M_FLOOD 1625 announcements to locally connected networks. 1627 The $transport-proto above indicates the method that the pledge- 1628 proxy-registrar will use. The TCP method described here is 1629 mandatory, and other proxy methods, such as CoAP methods not defined 1630 in this document are optional. Other methods MUST NOT be enabled 1631 unless the Join Registrar ASA indicates support for them in it's own 1632 announcement. 1634 4.2. CoAP connection to Registrar 1636 The use of CoAP to connect from pledge to registrar is out of scope 1637 for this document, and is described in future work. See 1638 [I-D.ietf-anima-constrained-voucher]. 1640 4.3. Proxy discovery and communication of Registrar 1642 The registrar SHOULD announce itself so that proxies can find it and 1643 determine what kind of connections can be terminated. 1645 The registrar announces itself using ACP instance of GRASP using 1646 M_FLOOD messages. A registrar may announce any convenient port 1647 number, including using a stock port 443. ANI proxies MUST support 1648 GRASP discovery of registrars. 1650 The M_FLOOD is formatted as follows: 1652 [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000, 1653 ["AN_join_registrar", 4, 255, "EST-TLS"], 1654 [O_IPv6_LOCATOR, 1655 h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 8443]] 1657 Figure 12: An example of a Registrar announcement message 1659 The formal CDDL definition is: 1661 flood-message = [M_FLOOD, session-id, initiator, ttl, 1662 +[objective, (locator-option / [])]] 1664 objective = ["AN_join_registrar", objective-flags, loop-count, 1665 objective-value] 1667 initiator = ACP address to contact Registrar 1668 objective-flags = sync-only ; as in GRASP spec 1669 sync-only = 4 ; M_FLOOD only requires synchronization 1670 loop-count = 255 ; mandatory maximum 1671 objective-value = text ; name of the (list of) of supported 1672 ; protocols: "EST-TLS" for RFC7030. 1674 Figure 13: CDDL definition for Registrar announcement message 1676 The M_FLOOD message MUST be sent periodically. The default period 1677 SHOULD be 60 seconds, the value SHOULD be operator configurable but 1678 SHOULD NOT be smaller than 60 seconds. The frequency of sending MUST 1679 be such that the aggregate amount of periodic M_FLOODs from all 1680 flooding sources cause only negligible traffic across the ACP. 1682 Here are some examples of locators for illustrative purposes. Only 1683 the first one ($transport-protocol = 6, TCP) is defined in this 1684 document and is mandatory to implement. 1686 locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] 1687 locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] 1688 locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] 1690 A protocol of 6 indicates that TCP proxying on the indicated port is 1691 desired. 1693 Registrars MUST announce the set of protocols that they support. 1694 They MUST support TCP traffic. 1696 Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated. 1698 Registrars MUST support ANI TLS circuit proxy and therefore BRSKI 1699 across HTTPS/TLS native across the ACP. 1701 In the ANI, the Autonomic Control Plane (ACP) secured instance of 1702 GRASP ([I-D.ietf-anima-grasp]) MUST be used for discovery of ANI 1703 registrar ACP addresses and ports by ANI proxies. The TCP leg of the 1704 proxy connection between ANI proxy and ANI registrar therefore also 1705 runs across the ACP. 1707 5. Protocol Details (Pledge - Registrar - MASA) 1709 The pledge MUST initiate BRSKI after boot if it is unconfigured. The 1710 pledge MUST NOT automatically initiate BRSKI if it has been 1711 configured or is in the process of being configured. 1713 BRSKI is described as extensions to EST [RFC7030]. The goal of these 1714 extensions is to reduce the number of TLS connections and crypto 1715 operations required on the pledge. The registrar implements the 1716 BRSKI REST interface within the same "/.well-known" URI tree as the 1717 existing EST URIs as described in EST [RFC7030] section 3.2.2. The 1718 communication channel between the pledge and the registrar is 1719 referred to as "BRSKI-EST" (see Figure 1). 1721 The communication channel between the registrar and MASA is similarly 1722 described as extensions to EST within the same "/.well-known" tree. 1723 For clarity this channel is referred to as "BRSKI-MASA". (See 1724 Figure 1). 1726 The MASA URI is "https://" authority "/.well-known/est". 1728 BRSKI uses existing CMS message formats for existing EST operations. 1729 BRSKI uses JSON [RFC8259] for all new operations defined here, and 1730 voucher formats. In all places where a binary value must be carried 1731 in a JSON string, the use of base64 format ([RFC4648] section 4) is 1732 to be used, as per [RFC7951] section 6.6. 1734 While EST section 3.2 does not insist upon use of HTTP persistent 1735 connections ([RFC7230] section 6.3), BRSKI-EST connections SHOULD use 1736 persistent connections. The intention of this guidance is to ensure 1737 the provisional TLS state occurs only once, and that the subsequent 1738 resolution of the provision state is not subject to a MITM attack 1739 during a critical phase. 1741 If non-persistent connections are used, then both the pledge and the 1742 registrar MUST remember the certificates seen, and also sent for the 1743 first connection. They MUST check each subsequent connections for 1744 the same certificates, and each end MUST use the same certificates as 1745 well. This places a difficult restriction on rolling certificates on 1746 the Registrar. 1748 Summarized automation extensions for the BRSKI-EST flow are: 1750 o The pledge either attempts concurrent connections via each 1751 discovered proxy, or it times out quickly and tries connections in 1752 series, as explained at the end of Section 5.1. 1754 o The pledge provisionally accepts the registrar certificate during 1755 the TLS handshake as detailed in Section 5.1. 1757 o The pledge requests a voucher using the new REST calls described 1758 below. This voucher is then validated. 1760 o The pledge completes authentication of the server certificate as 1761 detailed in Section 5.6.1. This moves the BRSKI-EST TLS 1762 connection out of the provisional state. 1764 o Mandatory bootstrap steps conclude with voucher status telemetry 1765 (see Section 5.7). 1767 The BRSKI-EST TLS connection can now be used for EST enrollment. 1769 The extensions for a registrar (equivalent to EST server) are: 1771 o Client authentication is automated using Initial Device Identity 1772 (IDevID) as per the EST certificate based client authentication. 1773 The subject field's DN encoding MUST include the "serialNumber" 1774 attribute with the device's unique serial number as explained in 1775 Section 2.3.1 1777 o The registrar requests and validates the voucher from the MASA. 1779 o The registrar forwards the voucher to the pledge when requested. 1781 o The registrar performs log verifications (described in 1782 Section 5.8.3) in addition to local authorization checks before 1783 accepting optional pledge device enrollment requests. 1785 5.1. BRSKI-EST TLS establishment details 1787 The pledge establishes the TLS connection with the registrar through 1788 the circuit proxy (see Section 4) but the TLS handshake is with the 1789 registrar. The BRSKI-EST pledge is the TLS client and the BRSKI-EST 1790 registrar is the TLS server. All security associations established 1791 are between the pledge and the registrar regardless of proxy 1792 operations. 1794 Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is 1795 REQUIRED on the Pledge side. TLS 1.3 (or newer) SHOULD be available 1796 on the Registrar server interface, and the Registrar client 1797 interface, but TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be 1798 available on the MASA server interface, but TLS 1.2 MAY be used. 1800 Establishment of the BRSKI-EST TLS connection is as specified in EST 1801 [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" 1803 [RFC7030] wherein the client is authenticated with the IDevID 1804 certificate, and the EST server (the registrar) is provisionally 1805 authenticated with an unverified server certificate. Configuration 1806 or distribution of the trust anchor database used for validating the 1807 IDevID certificate is out-of-scope of this specification. Note that 1808 the trust anchors in/excluded from the database will affect which 1809 manufacturers' devices are acceptable to the registrar as pledges, 1810 and can also be used to limit the set of MASAs that are trusted for 1811 enrollment. 1813 The signatures in the certificate MUST be validated even if a signing 1814 key can not (yet) be validated. The certificate (or chain) MUST be 1815 retained for later validation. 1817 A self-signed certificate for the Registrar is acceptable as the 1818 voucher can validate it upon successful enrollment. 1820 The pledge performs input validation of all data received until a 1821 voucher is verified as specified in Section 5.6.1 and the TLS 1822 connection leaves the provisional state. Until these operations are 1823 complete the pledge could be communicating with an attacker. 1825 The pledge code needs to be written with the assumption that all data 1826 is being transmitted at this point to an unauthenticated peer, and 1827 that received data, while inside a TLS connection, MUST be considered 1828 untrusted. This particularly applies to HTTP headers and CMS 1829 structures that make up the voucher. 1831 A pledge that can connect to multiple Registrars concurrently SHOULD 1832 do so. Some devices may be unable to do so for lack of threading, or 1833 resource issues. Concurrent connections defeat attempts by a 1834 malicious proxy from causing a TCP Slowloris-like attack (see 1835 [slowloris]). 1837 A pledge that can not maintain as many connections as there are 1838 eligible proxies will need to rotate among the various choices, 1839 terminating connections that do not appear to be making progress. If 1840 no connection is making progress after 5 seconds then the pledge 1841 SHOULD drop the oldest connection and go on to a different proxy: the 1842 proxy that has been communicated with least recently. If there were 1843 no other proxies discovered, the pledge MAY continue to wait, as long 1844 as it is concurrently listening for new proxy announcements. 1846 5.2. Pledge Requests Voucher from the Registrar 1848 When the pledge bootstraps it makes a request for a voucher from a 1849 registrar. 1851 This is done with an HTTPS POST using the operation path value of 1852 "/.well-known/est/requestvoucher". 1854 The pledge voucher-request Content-Type is: 1856 application/voucher-cms+json [RFC8366] defines a "YANG-defined JSON 1857 document that has been signed using a CMS structure", and the 1858 voucher-request described in Section 3 is created in the same way. 1859 The media type is the same as defined in [RFC8366]. This is also 1860 used for the pledge voucher-request. The pledge MUST sign the 1861 request using the Section 2.3 credential. 1863 Registrar implementations SHOULD anticipate future media types but of 1864 course will simply fail the request if those types are not yet known. 1866 The pledge SHOULD include an [RFC7231] section 5.3.2 "Accept" header 1867 field indicating the acceptable media type for the voucher response. 1868 The "application/voucher-cms+json" media type is defined in [RFC8366] 1869 but constrained voucher formats are expected in the future. 1870 Registrars and MASA are expected to be flexible in what they accept. 1872 The pledge populates the voucher-request fields as follows: 1874 created-on: Pledges that have a realtime clock are RECOMMENDED to 1875 populate this field with the current date and time in yang:date- 1876 and-time format. This provides additional information to the 1877 MASA. Pledges that have no real-time clocks MAY omit this field. 1879 nonce: The pledge voucher-request MUST contain a cryptographically 1880 strong random or pseudo-random number nonce (see [RFC4086] section 1881 6.2). As the nonce is usually generated very early in the boot 1882 sequence there is a concern that the same nonce might generated 1883 across multiple boots, or after a factory reset. Difference 1884 nonces MUST NOT generated for each bootstrapping attempt, whether 1885 in series or concurrently. The freshness of this nonce mitigates 1886 against the lack of real-time clock as explained in Section 2.6.1. 1888 assertion: The pledge indicates support for the mechanism described 1889 in this document, by putting the value "proximity" in the voucher- 1890 request, and MUST include the "proximity-registrar-cert" field 1891 (below). 1893 proximity-registrar-cert: In a pledge voucher-request this is the 1894 first certificate in the TLS server 'certificate_list' sequence 1895 (see [RFC5246]) presented by the registrar to the pledge. That 1896 is, it is the end-entity certificate. This MUST be populated in a 1897 pledge voucher-request. 1899 serial-number The serial number of the pledge is included in the 1900 voucher-request from the Pledge. This value is included as a 1901 sanity check only, but it is not to be forwarded by the Registrar 1902 as described in Section 5.5. 1904 All other fields MAY be omitted in the pledge voucher-request. 1906 An example JSON payload of a pledge voucher-request is in Section 3.3 1907 Example 1. 1909 The registrar confirms that the assertion is 'proximity' and that 1910 pinned 'proximity-registrar-cert' is the Registrar's certificate. If 1911 this validation fails, then there is an On-Path Attacker (MITM), and 1912 the connection MUST be closed after the returning an HTTP 401 error 1913 code. 1915 5.3. Registrar Authorization of Pledge 1917 In a fully automated network all devices must be securely identified 1918 and authorized to join the domain. 1920 A Registrar accepts or declines a request to join the domain, based 1921 on the authenticated identity presented. For different networks, 1922 examples of automated acceptance may include: 1924 o allow any device of a specific type (as determined by the X.509 1925 IDevID), 1927 o allow any device from a specific vendor (as determined by the 1928 X.509 IDevID), 1930 o allow a specific device from a vendor (as determined by the X.509 1931 IDevID) against a domain white list. (The mechanism for checking 1932 a shared white list potentially used by multiple Registrars is out 1933 of scope). 1935 If validation fails the registrar SHOULD respond with the HTTP 404 1936 error code. If the voucher-request is in an unknown format, then an 1937 HTTP 406 error code is more appropriate. A situation that could be 1938 resolved with administrative action (such as adding a vendor to a 1939 whitelist) MAY be responded with an 403 HTTP error code. 1941 If authorization is successful the registrar obtains a voucher from 1942 the MASA service (see Section 5.5) and returns that MASA signed 1943 voucher to the pledge as described in Section 5.6. 1945 5.4. BRSKI-MASA TLS establishment details 1947 The BRSKI-MASA TLS connection is a 'normal' TLS connection 1948 appropriate for HTTPS REST interfaces. The registrar initiates the 1949 connection and uses the MASA URL obtained as described in 1950 Section 2.8. The mechanisms in [RFC6125] SHOULD be used in 1951 authentication of the MASA using a DNS-ID that matches that which is 1952 found in the IDevID. Registrars MAY include a mechanism to override 1953 the MASA URL on a manufacturer-by-manufacturer basis, and within that 1954 override it is appropriate to provide alternate anchors. This will 1955 typically used by some vendors to establish explicit (or private) 1956 trust anchors for validating their MASA that is part of a sales 1957 channel integration. 1959 Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is 1960 REQUIRED. TLS 1.3 (or newer) SHOULD be available. 1962 As described in [RFC7030], the MASA and the registrars SHOULD be 1963 prepared to support TLS client certificate authentication and/or HTTP 1964 Basic or Digest authentication. This connection MAY also have no 1965 client authentication at all. 1967 Registrars SHOULD permit trust anchors to be pre-configured on a per- 1968 vendor(MASA) basis. Registrars SHOULD include the ability to 1969 configure a TLS ClientCertificate on a per-MASA basis, or to use no 1970 client certificate. Registrars SHOULD also permit HTTP Basic and 1971 Digest authentication to be configured. 1973 The authentication of the BRSKI-MASA connection does not change the 1974 voucher-request process, as voucher-requests are already signed by 1975 the registrar. Instead, this authentication provides access control 1976 to the audit-log as described in Section 5.8. 1978 Implementors are advised that contacting the MASA is to establish a 1979 secured API connection with a web service and that there are a number 1980 of authentication models being explored within the industry. 1981 Registrars are RECOMMENDED to fail gracefully and generate useful 1982 administrative notifications or logs in the advent of unexpected HTTP 1983 401 (Unauthorized) responses from the MASA. 1985 5.4.1. MASA authentication of customer Registrar 1987 Providing per-customer options requires that the customer's registrar 1988 be uniquely identified. This can be done by any stateless method 1989 that HTTPS supports such as with HTTP Basic or Digest authentication 1990 (that is using a password), but the use of TLS Client Certificate 1991 authentication is RECOMMENDED. 1993 Stateful methods involving API tokens, or HTTP Cookies, are not 1994 recommended. 1996 It is expected that the setup and configuration of per-customer 1997 Client Certificates is done as part of a sales ordering process. 1999 The use of public PKI (i.e. WebPKI) End-Entity Certificates to 2000 identify the Registrar is reasonable, and if done universally this 2001 would permit a MASA to identify a customers' Registrar simply by a 2002 FQDN. 2004 The use of DANE records in DNSSEC signed zones would also permit use 2005 of a FQDN to identify customer Registrars. 2007 A third (and simplest, but least flexible) mechanism would be for the 2008 MASA to simply store the Registrar's certificate pinned in a 2009 database. 2011 A MASA without any supply chain integration can simply accept 2012 Registrars without any authentication, or can accept them on a blind 2013 Trust-on-First-Use basis as described in Section 7.4.2. 2015 This document does not make a specific recommendation on how the MASA 2016 authenticates the Registrar as there are likely different tradeoffs 2017 in different environments and product values. Even within the ANIMA 2018 ACP applicability, there is a significant difference between supply 2019 chain logistics for $100 CPE devices and $100,000 core routers. 2021 5.5. Registrar Requests Voucher from MASA 2023 When a registrar receives a pledge voucher-request it in turn submits 2024 a registrar voucher-request to the MASA service via an HTTPS 2025 interface ([RFC7231]). 2027 This is done with an HTTP POST using the operation path value of 2028 "/.well-known/est/requestvoucher". 2030 The voucher media type "application/voucher-cms+json" is defined in 2031 [RFC8366] and is also used for the registrar voucher-request. It is 2032 a JSON document that has been signed using a CMS structure. The 2033 registrar MUST sign the registrar voucher-request. The entire 2034 registrar certificate chain, up to and including the Domain CA, MUST 2035 be included in the CMS structure. 2037 MASA impementations SHOULD anticipate future media types but of 2038 course will simply fail the request if those types are not yet known. 2040 The Registrar SHOULD include an [RFC7231] section 5.3.2 "Accept" 2041 header field indicating the response media types that are acceptable. 2042 This list SHOULD be the entire list presented to the Registrar in the 2043 Pledge's original request (see Section 5.2) but MAY be a subset. 2044 MASA's are expected to be flexible in what they accept. 2046 The registrar populates the voucher-request fields as follows: 2048 created-on: The Registrars SHOULD populate this field with the 2049 current date and time when the Registrar formed this voucher 2050 request. This field provides additional information to the MASA. 2052 nonce: This value, if present, is copied from the pledge voucher- 2053 request. The registrar voucher-request MAY omit the nonce as per 2054 Section 3.1. 2056 serial-number: The serial number of the pledge the registrar would 2057 like a voucher for. The registrar determines this value by 2058 parsing the authenticated pledge IDevID certificate. See 2059 Section 2.3. The registrar MUST verify that the serial number 2060 field it parsed matches the serial number field the pledge 2061 provided in its voucher-request. This provides a sanity check 2062 useful for detecting error conditions and logging. The registrar 2063 MUST NOT simply copy the serial number field from a pledge voucher 2064 request as that field is claimed but not certified. 2066 idevid-issuer: The Issuer value from the pledge IDevID certificate 2067 is included to ensure unique interpretation of the serial-number. 2068 In the case of nonceless (offline) voucher-request, then an 2069 appropriate value needs to be configured from the same out-of-band 2070 source as the serial-number. 2072 prior-signed-voucher-request: The signed pledge voucher-request 2073 SHOULD be included in the registrar voucher-request. The entire 2074 CMS signed structure is to be included, base64 encoded for 2075 transport in the JSON structure. 2077 A nonceless registrar voucher-request MAY be submitted to the MASA. 2078 Doing so allows the registrar to request a voucher when the pledge is 2079 offline, or when the registrar anticipates not being able to connect 2080 to the MASA while the pledge is being deployed. Some use cases 2081 require the registrar to learn the appropriate IDevID SerialNumber 2082 field and appropriate 'Accept header field' values from the physical 2083 device labeling or from the sales channel (out-of-scope for this 2084 document). 2086 All other fields MAY be omitted in the registrar voucher-request. 2088 The "proximity-registrar-cert" field MUST NOT be present in the 2089 registrar voucher-request. 2091 Example JSON payloads of registrar voucher-requests are in 2092 Section 3.3 Examples 2 through 4. 2094 The MASA verifies that the registrar voucher-request is internally 2095 consistent but does not necessarily authenticate the registrar 2096 certificate since the registrar MAY be unknown to the MASA in 2097 advance. The MASA performs the actions and validation checks 2098 described in the following sub-sections before issuing a voucher. 2100 5.5.1. MASA renewal of expired vouchers 2102 As described in [RFC8366] vouchers are normally short lived to avoid 2103 revocation issues. If the request is for a previous (expired) 2104 voucher using the same registrar (that is, a Registrar with the same 2105 Domain CA) then the request for a renewed voucher SHOULD be 2106 automatically authorized. The MASA has sufficient information to 2107 determine this by examining the request, the registrar 2108 authentication, and the existing audit-log. The issuance of a 2109 renewed voucher is logged as detailed in Section 5.6. 2111 To inform the MASA that existing vouchers are not to be renewed one 2112 can update or revoke the registrar credentials used to authorize the 2113 request (see Section 5.5.4 and Section 5.5.3). More flexible methods 2114 will likely involve sales channel integration and authorizations 2115 (details are out-of-scope of this document). 2117 5.5.2. MASA pinning of registrar 2119 The registrar's certificate chain is extracted from the signature 2120 method. The entire registrar certificate chain was included in the 2121 CMS structure, as specified in Section 5.5. This CA certificate will 2122 be used to populate the "pinned-domain-cert" of the voucher being 2123 issued. 2125 If this domain CA is unknown to the MASA, then it is to be considered 2126 a temporary trust anchor for the rest of the steps in this section. 2127 The intention is not to authenticate the message as having come from 2128 a fully validated origin, but to establish the consistency of the 2129 domain PKI. 2131 5.5.3. MASA checking of voucher request signature 2133 As described in Section 5.5.2, the MASA has extracted Registrar's 2134 domain CA. This is used to validate the CMS signature ([RFC5652]) on 2135 the voucher-request. 2137 Normal PKIX revocation checking is assumed during voucher-request 2138 signature validation. This CA certificate MAY have Certificate 2139 Revocation List distribution points, or Online Certificate Status 2140 Protocol (OCSP) information ([RFC6960]). If they are present, the 2141 MASA MUST be able to reach the relevant servers belonging to the 2142 Registrar's domain CA to perform the revocation checks. 2144 The use of OCSP Stapling is preferred. 2146 5.5.4. MASA verification of domain registrar 2148 The MASA MUST verify that the registrar voucher-request is signed by 2149 a registrar. This is confirmed by verifying that the id-kp-cmcRA 2150 extended key usage extension field (as detailed in EST RFC7030 2151 section 3.6.1) exists in the certificate of the entity that signed 2152 the registrar voucher-request. This verification is only a 2153 consistency check that the unauthenticated domain CA intended the 2154 voucher-request signer to be a registrar. Performing this check 2155 provides value to the domain PKI by assuring the domain administrator 2156 that the MASA service will only respect claims from authorized 2157 Registration Authorities of the domain. 2159 Even when a domain CA is authenticated to the MASA, and there is 2160 strong sales channel integration to understand who the legitimate 2161 owner is, the above cmcRC check prevents arbitrary End-Entity 2162 certificates (such as an LDevID certificate) from having vouchers 2163 issued against them. 2165 Other cases of inappropriate voucher issuance are detected by 2166 examination of the audit log. 2168 If a nonceless voucher-request is submitted the MASA MUST 2169 authenticate the registrar as described in either EST [RFC7030] 2170 section 3.2.3, section 3.3.2, or by validating the registrar's 2171 certificate used to sign the registrar voucher-request using a 2172 configured trust anchor. Any of these methods reduce the risk of 2173 DDoS attacks and provide an authenticated identity as an input to 2174 sales channel integration and authorizations (details are out-of- 2175 scope of this document). 2177 In the nonced case, validation of the Registrar's identity (via TLS 2178 Client Certificate or HTTP authentication) MAY be omitted if the 2179 device policy is to accept audit-only vouchers. 2181 5.5.5. MASA verification of pledge prior-signed-voucher-request 2183 The MASA MAY verify that the registrar voucher-request includes the 2184 'prior-signed-voucher-request' field. If so the prior-signed- 2185 voucher-request MUST include a 'proximity-registrar-cert' that is 2186 consistent with the certificate used to sign the registrar voucher- 2187 request. Additionally the voucher-request serial-number leaf MUST 2188 match the pledge serial-number that the MASA extracts from the 2189 signing certificate of the prior-signed-voucher-request. The 2190 consistency check described above is checking that the 'proximity- 2191 registrar-cert' SPKI fingerprint exists within the registrar voucher- 2192 request CMS signature's certificate chain. This is substantially the 2193 same as the pin validation described in in [RFC7469] section 2.6, 2194 paragraph three. 2196 If these checks succeed the MASA updates the voucher and audit-log 2197 assertion leafs with the "proximity" assertion, as defined by 2198 [RFC8366] section 5.3. 2200 5.5.6. MASA nonce handling 2202 The MASA does not verify the nonce itself. If the registrar voucher- 2203 request contains a nonce, and the prior-signed-voucher-request 2204 exists, then the MASA MUST verify that the nonce is consistent. 2205 (Recall from above that the voucher-request might not contain a 2206 nonce, see Section 5.5 and Section 5.5.4). 2208 The MASA populates the audit-log with the nonce that was verified. 2209 If a nonceless voucher is issued, then the audit-log is to be 2210 populated with the JSON value "null". 2212 5.6. MASA and Registrar Voucher Response 2214 The MASA voucher response to the registrar is forwarded without 2215 changes to the pledge; therefore this section applies to both the 2216 MASA and the registrar. The HTTP signaling described applies to both 2217 the MASA and registrar responses. 2219 When a voucher request arrives at the registrar, if it has a cached 2220 response from the MASA for the corresponding registrar voucher- 2221 request, that cached response can be used according to local policy; 2222 otherwise the registrar constructs a new registrar voucher-request 2223 and sends it to the MASA. 2225 Registrar evaluation of the voucher itself is purely for transparency 2226 and audit purposes to further inform log verification (see 2227 Section 5.8.3) and therefore a registrar could accept future voucher 2228 formats that are opaque to the registrar. 2230 If the voucher-request is successful, the server (MASA responding to 2231 registrar or registrar responding to pledge) response MUST contain an 2232 HTTP 200 response code. The server MUST answer with a suitable 4xx 2233 or 5xx HTTP [RFC7230] error code when a problem occurs. In this 2234 case, the response data from the MASA MUST be a plaintext human- 2235 readable (UTF-8) error message containing explanatory information 2236 describing why the request was rejected. 2238 The registrar MAY respond with an HTTP 202 ("the request has been 2239 accepted for processing, but the processing has not been completed") 2240 as described in EST [RFC7030] section 4.2.3 wherein the client "MUST 2241 wait at least the specified 'Retry-After' time before repeating the 2242 same request". (see [RFC7231] section 6.6.4) The pledge is 2243 RECOMMENDED to provide local feedback (blinked LED etc) during this 2244 wait cycle if mechanisms for this are available. To prevent an 2245 attacker registrar from significantly delaying bootstrapping the 2246 pledge MUST limit the 'Retry-After' time to 60 seconds. Ideally the 2247 pledge would keep track of the appropriate Retry-After header field 2248 values for any number of outstanding registrars but this would 2249 involve a state table on the pledge. Instead the pledge MAY ignore 2250 the exact Retry-After value in favor of a single hard coded value (a 2251 registrar that is unable to complete the transaction after the first 2252 60 seconds has another chance a minute later). A pledge SHOULD only 2253 maintain a 202 retry-state for up to 4 days, which is longer than a 2254 long weekend, after which time the enrollment attempt fails and the 2255 pledge returns to discovery state. 2257 A pledge that retries a request after receiving a 202 message MUST 2258 resend the same voucher-request. It MUST NOT sign a new voucher- 2259 request each time, and in particular, it MUST NOT change the nonce 2260 value. 2262 In order to avoid infinite redirect loops, which a malicious 2263 registrar might do in order to keep the pledge from discovering the 2264 correct registrar, the pledge MUST NOT follow more than one 2265 redirection (3xx code) to another web origins. EST supports 2266 redirection but requires user input; this change allows the pledge to 2267 follow a single redirection without a user interaction. 2269 A 403 (Forbidden) response is appropriate if the voucher-request is 2270 not signed correctly, stale, or if the pledge has another outstanding 2271 voucher that cannot be overridden. 2273 A 404 (Not Found) response is appropriate when the request is for a 2274 device that is not known to the MASA. 2276 A 406 (Not Acceptable) response is appropriate if a voucher of the 2277 desired type or using the desired algorithms (as indicated by the 2278 Accept: header fields, and algorithms used in the signature) cannot 2279 be issued such as because the MASA knows the pledge cannot process 2280 that type. The registrar SHOULD use this response if it determines 2281 the pledge is unacceptable due to inventory control, MASA audit-logs, 2282 or any other reason. 2284 A 415 (Unsupported Media Type) response is appropriate for a request 2285 that has a voucher-request or Accept: value that is not understood. 2287 The voucher response format is as indicated in the submitted Accept 2288 header fields or based on the MASA's prior understanding of proper 2289 format for this Pledge. Only the [RFC8366] "application/voucher- 2290 cms+json" media type is defined at this time. The syntactic details 2291 of vouchers are described in detail in [RFC8366]. Figure 14 shows a 2292 sample of the contents of a voucher. 2294 { 2295 "ietf-voucher:voucher": { 2296 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 2297 "assertion": "logged", 2298 "pinned-domain-cert": "base64encodedvalue==", 2299 "serial-number": "JADA123456789" 2300 } 2301 } 2303 Figure 14: An example voucher 2305 The MASA populates the voucher fields as follows: 2307 nonce: The nonce from the pledge if available. See Section 5.5.6. 2309 assertion: The method used to verify the relationship between pledge 2310 and registrar. See Section 5.5.5. 2312 pinned-domain-cert: The domain CA cert. See Section 5.5.2. This 2313 figure is illustrative, for an example, see Appendix D.2 2315 serial-number: The serial-number as provided in the voucher-request. 2316 Also see Section 5.5.5. 2318 domain-cert-revocation-checks: Set as appropriate for the pledge's 2319 capabilities and as documented in [RFC8366]. The MASA MAY set 2320 this field to 'false' since setting it to 'true' would require 2321 that revocation information be available to the pledge and this 2322 document does not make normative requirements for [RFC6961] or 2323 equivalent integrations. 2325 expires-on: This is set for nonceless vouchers. The MASA ensures 2326 the voucher lifetime is consistent with any revocation or pinned- 2327 domain-cert consistency checks the pledge might perform. See 2328 section Section 2.6.1. There are three times to consider: (a) a 2329 configured voucher lifetime in the MASA, (b) the expiry time for 2330 the registrar's certificate, (c) any certificate revocation 2331 information (CRL) lifetime. The expires-on field SHOULD be before 2332 the earliest of these three values. Typically (b) will be some 2333 significant time in the future, but (c) will typically be short 2334 (on the order of a week or less). The RECOMMENDED period for (a) 2335 is on the order of 20 minutes, so it will typically determine the 2336 lifespan of the resulting voucher. 20 minutes is sufficient time 2337 to reach the post-provisional state in the pledge, at which point 2338 there is an established trust relationship between pledge and 2339 registrar. The subsequent operations can take as long as required 2340 from that point onwards. The lifetime of the voucher has no 2341 impact on the lifespan of the ownership relationship. 2343 Whenever a voucher is issued the MASA MUST update the audit-log 2344 sufficiently to generate the response as described in Section 5.8.1. 2345 The internal state requirements to maintain the audit-log are out-of- 2346 scope. 2348 5.6.1. Pledge voucher verification 2350 The pledge MUST verify the voucher signature using the manufacturer- 2351 installed trust anchor(s) associated with the manufacturer's MASA 2352 (this is likely included in the pledge's firmware). Management of 2353 the manufacturer-installed trust anchor(s) is out-of-scope of this 2354 document; this protocol does not update these trust anchor(s). 2356 The pledge MUST verify the serial-number field of the signed voucher 2357 matches the pledge's own serial-number. 2359 The pledge MUST verify the nonce information in the voucher. If 2360 present, the nonce in the voucher must match the nonce the pledge 2361 submitted to the registrar; vouchers with no nonce can also be 2362 accepted (according to local policy, see Section 7.2. 2364 The pledge MUST be prepared to parse and fail gracefully from a 2365 voucher response that does not contain a 'pinned-domain-cert' field. 2366 Such a thing indicates a failure to enroll in this domain, and the 2367 pledge MUST attempt joining with other available Join Proxy. 2369 The pledge MUST be prepared to ignore additional fields that it does 2370 not recognize. 2372 5.6.2. Pledge authentication of provisional TLS connection 2374 The 'pinned-domain-cert' element of the voucher contains the domain 2375 CA's public key. The pledge MUST use the 'pinned-domain-cert' trust 2376 anchor to immediately complete authentication of the provisional TLS 2377 connection. 2379 If a registrar's credentials cannot be verified using the pinned- 2380 domain-cert trust anchor from the voucher then the TLS connection is 2381 immediately discarded and the pledge abandons attempts to bootstrap 2382 with this discovered registrar. The pledge SHOULD send voucher 2383 status telemetry (described below) before closing the TLS connection. 2384 The pledge MUST attempt to enroll using any other proxies it has 2385 found. It SHOULD return to the same proxy again after unsuccessful 2386 attempts with other proxies. Attempts should be made repeated at 2387 intervals according to the backoff timer described earlier. Attempts 2388 SHOULD be repeated as failure may be the result of a temporary 2389 inconsistency (an inconsistently rolled registrar key, or some other 2390 mis-configuration). The inconsistency could also be the result an 2391 active MITM attack on the EST connection. 2393 The registrar MUST use a certificate that chains to the pinned- 2394 domain-cert as its TLS server certificate. 2396 The pledge's PKIX path validation of a registrar certificate's 2397 validity period information is as described in Section 2.6.1. Once 2398 the PKIX path validation is successful the TLS connection is no 2399 longer provisional. 2401 The pinned-domain-cert MAY be installed as an trust anchor for future 2402 operations such as enrollment (e.g. [RFC7030] as recommended) or 2403 trust anchor management or raw protocols that do not need full PKI 2404 based key management. It can be used to authenticate any dynamically 2405 discovered EST server that contain the id-kp-cmcRA extended key usage 2406 extension as detailed in EST RFC7030 section 3.6.1; but to reduce 2407 system complexity the pledge SHOULD avoid additional discovery 2408 operations. Instead the pledge SHOULD communicate directly with the 2409 registrar as the EST server. The 'pinned-domain-cert' is not a 2410 complete distribution of the [RFC7030] section 4.1.3 CA Certificate 2411 Response, which is an additional justification for the recommendation 2412 to proceed with EST key management operations. Once a full CA 2413 Certificate Response is obtained it is more authoritative for the 2414 domain than the limited 'pinned-domain-cert' response. 2416 5.7. Pledge BRSKI Status Telemetry 2418 The domain is expected to provide indications to the system 2419 administrators concerning device lifecycle status. To facilitate 2420 this it needs telemetry information concerning the device's status. 2422 To indicate pledge status regarding the voucher, the pledge MUST post 2423 a status message to the Registrar. 2425 The posted data media type: application/json 2427 The client sends an HTTP POST to the server at the URI ".well- 2428 known/est/voucher_status". 2430 The format and semantics described below are for version 1. A 2431 version field is included to permit significant changes to this 2432 feedback in the future. A Registrar that receives a status message 2433 with a version larger than it knows about SHOULD log the contents and 2434 alert a human. 2436 The Status field indicates if the voucher was acceptable. Boolean 2437 values are acceptable, where "true" indicates the voucher was 2438 acceptable. 2440 If the voucher was not acceptable the Reason string indicates why. 2441 In the failure case this message may be sent to an unauthenticated, 2442 potentially malicious registrar and therefore the Reason string 2443 SHOULD NOT provide information beneficial to an attacker. The 2444 operational benefit of this telemetry information is balanced against 2445 the operational costs of not recording that an voucher was ignored by 2446 a client the registrar expected to continue joining the domain. 2448 The reason-context attribute is an arbitrary JSON object (literal 2449 value or hash of values) which provides additional information 2450 specific to this pledge. The contents of this field are not subject 2451 to standardization. 2453 The version and status fields MUST be present. The Reason field 2454 SHOULD be present whenever the status field is false. The Reason- 2455 Context field is optional. 2457 The keys to this JSON object are case-sensitive and MUST be 2458 lowercase. Figure 15 shows an example JSON. 2460 { 2461 "version":"1", 2462 "status":false, 2463 "reason":"Informative human readable message", 2464 "reason-context": { "additional" : "JSON" } 2465 } 2467 Figure 15: Example Status Telemetry 2469 The server SHOULD respond with an HTTP 200 but MAY simply fail with 2470 an HTTP 404 error. The client ignores any response. Within the 2471 server logs the server SHOULD capture this telemetry information. 2473 Additional standard JSON fields in this POST MAY be added, see 2474 Section 8.4. A server that sees unknown fields should log them, but 2475 otherwise ignore them. 2477 5.8. Registrar audit-log request 2479 After receiving the pledge status telemetry Section 5.7, the 2480 registrar SHOULD request the MASA audit-log from the MASA service. 2482 This is done with an HTTP POST using the operation path value of 2483 "/.well-known/est/requestauditlog". 2485 The registrar SHOULD HTTP POST the same registrar voucher-request as 2486 it did when requesting a voucher (using the same Content-Type). It 2487 is posted to the /requestauditlog URI instead. The "idevid-issuer" 2488 and "serial-number" informs the MASA which log is requested so the 2489 appropriate log can be prepared for the response. Using the same 2490 media type and message minimizes cryptographic and message operations 2491 although it results in additional network traffic. The relying MASA 2492 implementation MAY leverage internal state to associate this request 2493 with the original, and by now already validated, voucher-request so 2494 as to avoid an extra crypto validation. 2496 A registrar MAY request logs at future times. If the registrar 2497 generates a new request then the MASA is forced to perform the 2498 additional cryptographic operations to verify the new request. 2500 A MASA that receives a request for a device that does not exist, or 2501 for which the requesting owner was never an owner returns an HTTP 404 2502 ("Not found") code. 2504 It is reasonable for a Registrar, that the MASA does not believe to 2505 be the current owner, to request the audit-log. There are probably 2506 reasons for this which are hard to predict in advance. For instance, 2507 such a registrar may not be aware that the device has been resold; it 2508 may be that the device has been resold inappropriately, and this is 2509 how the original owner will learn of the occurance. It is also 2510 possible that the device legitimately spends time in two different 2511 networks. 2513 Rather than returning the audit-log as a response to the POST (with a 2514 return code 200), the MASA MAY instead return a 201 ("Created") 2515 response ([RFC7231] sections 6.3.2 and 7.1), with the URL to the 2516 prepared (and idempotent, therefore cachable) audit response in the 2517 Location: header field. 2519 In order to avoid enumeration of device audit-logs, MASA that return 2520 URLs SHOULD take care to make the returned URL unguessable. 2521 [W3C.WD-capability-urls-20140218] provides very good additional 2522 guidance. For instance, rather than returning URLs containing a 2523 database number such as https://example.com/auditlog/1234 or the EUI 2524 of the device such https://example.com/auditlog/10-00-00-11-22-33, 2525 the MASA SHOULD return a randomly generated value (a "slug" in web 2526 parlance). The value is used to find the relevant database entry. 2528 A MASA that returns a code 200 MAY also include a Location: header 2529 for future reference by the registrar. 2531 5.8.1. MASA audit log response 2533 A log data file is returned consisting of all log entries associated 2534 with the device selected by the IDevID presented in the request. The 2535 audit log may be abridged by removal of old or repeated values as 2536 explained below. The returned data is in JSON format ([RFC8259]), 2537 and the Content-Type SHOULD be "application/json". 2539 The following CDDL ([RFC8610]) explains the structure of the JSON 2540 format audit-log response: 2542 audit-log-response = { 2543 "version": uint, 2544 "events": [ + event ] 2545 "truncation": { 2546 ? "nonced duplicates": uint, 2547 ? "nonceless duplicates": uint, 2548 ? "arbitrary": uint, 2549 } 2550 } 2552 event = { 2553 "date": text, 2554 "domainID": text, 2555 "nonce": text / null, 2556 "assertion": "verified" / "logged" / "proximity", 2557 ? "truncated": uint, 2558 } 2560 Figure 16: CDDL for audit-log response 2562 An example: 2564 { 2565 "version":"1", 2566 "events":[ 2567 { 2568 "date":"2019-05-15T17:25:55.644-04:00", 2569 "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=", 2570 "nonce":"VOUFT-WwrEv0NuAQEHoV7Q", 2571 "assertion":"proximity", 2572 "truncated":"0" 2573 }, 2574 { 2575 "date":"2017-05-15T17:25:55.644-04:00", 2576 "domainID":"BduJhdHPpfhQLyponf48JzXSGZ8=", 2577 "nonce":"f4G6Vi1t8nKo/FieCVgpBg==", 2578 "assertion":"proximity" 2579 } 2580 ], 2581 "truncation": { 2582 "nonced duplicates": "0", 2583 "nonceless duplicates": "1", 2584 "arbitrary": "2" 2585 } 2586 } 2588 Figure 17: Example of audit-log response 2590 The domainID is a binary SubjectKeyIdentifier value calculated 2591 according to Section 5.8.2. It is encoded once in base64 in order to 2592 be transported in this JSON container. 2594 The date is in [RFC3339] format, which is consistent with typical 2595 JavaScript usage of JSON. 2597 The truncation structure MAY be omitted if all values are zero. Any 2598 counter missing from the truncation structure is the be assumed to be 2599 zero. 2601 The nonce is a string, as provided in the voucher-request, and used 2602 in the voucher. If no nonce was placed in the resulting voucher, 2603 then a value of null SHOULD be used in preference to omitting the 2604 entry. While the nonce is often created as a base64 encoded random 2605 series of bytes, this should not be assumed. 2607 Distribution of a large log is less than ideal. This structure can 2608 be optimized as follows: Nonced or Nonceless entries for the same 2609 domainID MAY be abridged from the log leaving only the single most 2610 recent nonced or nonceless entry for that domainID. In the case of 2611 truncation the 'event' truncation value SHOULD contain a count of the 2612 number of events for this domainID that were omitted. The log SHOULD 2613 NOT be further reduced but there could exist operational situation 2614 where maintaining the full log is not possible. In such situations 2615 the log MAY be arbitrarily abridged for length, with the number of 2616 removed entries indicated as 'arbitrary'. 2618 If the truncation count exceeds 1024 then the MASA MAY use this value 2619 without further incrementing it. 2621 A log where duplicate entries for the same domain have been omitted 2622 ("nonced duplicates" and/or "nonceless duplicates) could still be 2623 acceptable for informed decisions. A log that has had "arbitrary" 2624 truncations is less acceptable but manufacturer transparency is 2625 better than hidden truncations. 2627 A registrar that sees a version value greater than 1 indicates an 2628 audit log format that has been enhanced with additional information. 2629 No information will be removed in future versions; should an 2630 incompatible change be desired in the future, then a new HTTP end 2631 point will be used. 2633 This document specifies a simple log format as provided by the MASA 2634 service to the registrar. This format could be improved by 2635 distributed consensus technologies that integrate vouchers with 2636 technologies such as block-chain or hash trees or optimized logging 2637 approaches. Doing so is out of the scope of this document but is an 2638 anticipated improvement for future work. As such, the registrar 2639 SHOULD anticipate new kinds of responses, and SHOULD provide operator 2640 controls to indicate how to process unknown responses. 2642 5.8.2. Calculation of domainID 2644 The domainID is a binary value (a BIT STRING) that uniquely 2645 identifies a Registrar by the "pinned-domain-cert" 2647 If the "pinned-domain-cert" certificate includes the 2648 SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be 2649 used as the domainID. If not, the SPKI Fingerprint as described in 2650 [RFC7469] section 2.4 is to be used. This value needs to be 2651 calculated by both MASA (to populate the audit-log), and by the 2652 Registrar (to recognize itself in the audit log). 2654 [RFC5280] section 4.2.1.2 does not mandate that the 2655 SubjectKeyIdentifier extension be present in non-CA certificates. It 2656 is RECOMMENDED that Registrar certificates (even if self-signed), 2657 always include the SubjectKeyIdentifier to be used as a domainID. 2659 The domainID is determined from the certificate chain associated with 2660 the pinned-domain-cert and is used to update the audit-log. 2662 5.8.3. Registrar audit log verification 2664 Each time the Manufacturer Authorized Signing Authority (MASA) issues 2665 a voucher, it appends details of the assignment to an internal audit 2666 log for that device. The internal audit log is processed when 2667 responding to requests for details as described in Section 5.8. The 2668 contents of the audit log can express a variety of trust levels, and 2669 this section explains what kind of trust a registrar can derive from 2670 the entries. 2672 While the audit log provides a list of vouchers that were issued by 2673 the MASA, the vouchers are issued in response to voucher-requests, 2674 and it is the contents of the voucher-requests which determines how 2675 meaningful the audit log entries are. 2677 A registrar SHOULD use the log information to make an informed 2678 decision regarding the continued bootstrapping of the pledge. The 2679 exact policy is out of scope of this document as it depends on the 2680 security requirements within the registrar domain. Equipment that is 2681 purchased pre-owned can be expected to have an extensive history. 2682 The following discussion is provided to help explain the value of 2683 each log element: 2685 date: The date field provides the registrar an opportunity to divide 2686 the log around known events such as the purchase date. Depending 2687 on context known to the registrar or administrator events before/ 2688 after certain dates can have different levels of importance. For 2689 example for equipment that is expected to be new, and thus have no 2690 history, it would be a surprise to find prior entries. 2692 domainID: If the log includes an unexpected domainID then the pledge 2693 could have imprinted on an unexpected domain. The registrar can 2694 be expected to use a variety of techniques to define "unexpected" 2695 ranging from white lists of prior domains to anomaly detection 2696 (e.g. "this device was previously bound to a different domain than 2697 any other device deployed"). Log entries can also be compared 2698 against local history logs in search of discrepancies (e.g. "this 2699 device was re-deployed some number of times internally but the 2700 external audit log shows additional re-deployments our internal 2701 logs are unaware of"). 2703 nonce: Nonceless entries mean the logged domainID could 2704 theoretically trigger a reset of the pledge and then take over 2705 management by using the existing nonceless voucher. 2707 assertion: The assertion leaf in the voucher and audit log indicates 2708 why the MASA issued the voucher. A "verified" entry means that 2709 the MASA issued the associated voucher as a result of positive 2710 verification of ownership. However, this entry does not indicate 2711 whether the pledge was actually deployed in the prior domain, or 2712 not. A "logged" assertion informs the registrar that the prior 2713 vouchers were issued with minimal verification. A "proximity" 2714 assertion assures the registrar that the pledge was truly 2715 communicating with the prior domain and thus provides assurance 2716 that the prior domain really has deployed the pledge. 2718 A relatively simple policy is to white list known (internal or 2719 external) domainIDs, and require all vouchers to have a nonce. An 2720 alternative is to require that all nonceless vouchers be from a 2721 subset (e.g. only internal) of domainIDs. If the policy is violated 2722 a simple action is to revoke any locally issued credentials for the 2723 pledge in question or to refuse to forward the voucher. The 2724 Registrar MUST then refuse any EST actions, and SHOULD inform a human 2725 via a log. A registrar MAY be configured to ignore (i.e. override 2726 the above policy) the history of the device but it is RECOMMENDED 2727 that this only be configured if hardware assisted (i.e. TPM 2728 anchored) Network Endpoint Assessment (NEA) [RFC5209] is supported. 2730 5.9. EST Integration for PKI bootstrapping 2732 The pledge SHOULD follow the BRSKI operations with EST enrollment 2733 operations including "CA Certificates Request", "CSR Attributes" and 2734 "Client Certificate Request" or "Server-Side Key Generation", etc. 2735 This is a relatively seamless integration since BRSKI API calls 2736 provide an automated alternative to the manual bootstrapping method 2737 described in [RFC7030]. As noted above, use of HTTP persistent 2738 connections simplifies the pledge state machine. 2740 Although EST allows clients to obtain multiple certificates by 2741 sending multiple Certificate Signing Requests (CSR) requests, BRSKI 2742 does not support this mechanism directly. This is because BRSKI 2743 pledges MUST use the CSR Attributes request ([RFC7030] section 4.5). 2744 The registrar MUST validate the CSR against the expected attributes. 2745 This implies that client requests will "look the same" and therefore 2746 result in a single logical certificate being issued even if the 2747 client were to make multiple requests. Registrars MAY contain more 2748 complex logic but doing so is out-of-scope of this specification. 2749 BRSKI does not signal any enhancement or restriction to this 2750 capability. 2752 5.9.1. EST Distribution of CA Certificates 2754 The pledge SHOULD request the full EST Distribution of CA 2755 Certificates message. See RFC7030, section 4.1. 2757 This ensures that the pledge has the complete set of current CA 2758 certificates beyond the pinned-domain-cert (see Section 5.6.2 for a 2759 discussion of the limitations inherent in having a single certificate 2760 instead of a full CA Certificates response.) Although these 2761 limitations are acceptable during initial bootstrapping, they are not 2762 appropriate for ongoing PKIX end entity certificate validation. 2764 5.9.2. EST CSR Attributes 2766 Automated bootstrapping occurs without local administrative 2767 configuration of the pledge. In some deployments it is plausible 2768 that the pledge generates a certificate request containing only 2769 identity information known to the pledge (essentially the X.509 2770 IDevID information) and ultimately receives a certificate containing 2771 domain specific identity information. Conceptually the CA has 2772 complete control over all fields issued in the end entity 2773 certificate. Realistically this is operationally difficult with the 2774 current status of PKI certificate authority deployments, where the 2775 CSR is submitted to the CA via a number of non-standard protocols. 2776 Even with all standardized protocols used, it could operationally be 2777 problematic to expect that service specific certificate fields can be 2778 created by a CA that is likely operated by a group that has no 2779 insight into different network services/protocols used. For example, 2780 the CA could even be outsourced. 2782 To alleviate these operational difficulties, the pledge MUST request 2783 the EST "CSR Attributes" from the EST server and the EST server needs 2784 to be able to reply with the attributes necessary for use of the 2785 certificate in its intended protocols/services. This approach allows 2786 for minimal CA integrations and instead the local infrastructure (EST 2787 server) informs the pledge of the proper fields to include in the 2788 generated CSR (such as rfc822Name). This approach is beneficial to 2789 automated bootstrapping in the widest number of environments. 2791 In networks using the BRSKI enrolled certificate to authenticate the 2792 ACP (Autonomic Control Plane), the EST CSR attributes MUST include 2793 the ACP Domain Information Fields defined in 2794 [I-D.ietf-anima-autonomic-control-plane] section 6.1.1. 2796 The registrar MUST also confirm that the resulting CSR is formatted 2797 as indicated before forwarding the request to a CA. If the registrar 2798 is communicating with the CA using a protocol such as full CMC, which 2799 provides mechanisms to override the CSR attributes, then these 2800 mechanisms MAY be used even if the client ignores CSR Attribute 2801 guidance. 2803 5.9.3. EST Client Certificate Request 2805 The pledge MUST request a new client certificate. See RFC7030, 2806 section 4.2. 2808 5.9.4. Enrollment Status Telemetry 2810 For automated bootstrapping of devices, the administrative elements 2811 providing bootstrapping also provide indications to the system 2812 administrators concerning device lifecycle status. This might 2813 include information concerning attempted bootstrapping messages seen 2814 by the client. The MASA provides logs and status of credential 2815 enrollment. [RFC7030] assumes an end user and therefore does not 2816 include a final success indication back to the server. This is 2817 insufficient for automated use cases. 2819 In order to communicate this indicator, the client HTTP POSTs a JSON 2820 dictionary with a number of attributes described below to the new EST 2821 endpoint at "/.well-known/est/enrollstatus". 2823 When indicating a successful enrollment the client SHOULD first re- 2824 establish the EST TLS session using the newly obtained credentials. 2825 TLS 1.2 supports doing this in-band, but TLS 1.3 does not. The 2826 client SHOULD therefore always close the existing TLS connection, and 2827 start a new one. 2829 In the case of a FAIL, the same TLS connection MUST be used. The 2830 Reason string indicates why the most recent enrollment failed. 2832 The reason-context attribute is an arbitrary JSON object (literal 2833 value or hash of values) which provides additional information 2834 specific to the failure to unroll from this pledge. The contents of 2835 this field are not subject to standardization. This is represented 2836 by the group-socket "$$arbitrary-map" in the CDDL. 2838 In the case of a SUCCESS the Reason string is omitted. 2840 enrollstatus-post = { 2841 "version": uint, 2842 "status": bool, 2843 "reason": text, 2844 ? "reason-context" : { $$arbitrary-map } 2845 } 2846 } 2848 Figure 18: CDDL for enrollment status POST 2850 An example status report can be seen below. It is sent with with the 2851 media type: application/json 2853 { 2854 "version":"1", 2855 "status":true, 2856 "reason":"Informative human readable message", 2857 "reason-context": { "additional" : "JSON" } 2858 } 2860 Figure 19: Example of enrollment status POST 2862 The server SHOULD respond with an HTTP 200 but MAY simply fail with 2863 an HTTP 404 error. 2865 Within the server logs the server MUST capture if this message was 2866 received over an TLS session with a matching client certificate. 2868 5.9.5. Multiple certificates 2870 Pledges that require multiple certificates could establish direct EST 2871 connections to the registrar. 2873 5.9.6. EST over CoAP 2875 This document describes extensions to EST for the purposes of 2876 bootstrapping of remote key infrastructures. Bootstrapping is 2877 relevant for CoAP enrollment discussions as well. The definition of 2878 EST and BRSKI over CoAP is not discussed within this document beyond 2879 ensuring proxy support for CoAP operations. Instead it is 2880 anticipated that a definition of CoAP mappings will occur in 2881 subsequent documents such as [I-D.ietf-ace-coap-est] and that CoAP 2882 mappings for BRSKI will be discussed either there or in future work. 2884 6. Clarification of transfer-encoding 2886 [RFC7030] defines its endpoints to include a "Content-Transfer- 2887 Encoding" heading, and the payloads to be [RFC4648] Base64 encoded 2888 DER. 2890 When used within BRSKI, the original RFC7030 EST endpoints remain 2891 Base64 encoded, but the new BRSKI end points which send and receive 2892 binary artifacts (specifically, "/.well-known/est/requestvoucher") 2893 are binary. That is, no encoding is used. 2895 In the BRSKI context, the EST "Content-Transfer-Encoding" header 2896 field if present, SHOULD be ignored. This header field does not need 2897 to be included. 2899 7. Reduced security operational modes 2901 A common requirement of bootstrapping is to support less secure 2902 operational modes for support specific use cases. This section 2903 suggests a range of mechanisms that would alter the security 2904 assurance of BRSKI to accommodate alternative deployment 2905 architectures and mitigate lifecycle management issues identified in 2906 Section 10. They are presented here as informative (non-normative) 2907 design guidance for future standardization activities. Section 9 2908 provides standardization applicability statements for the ANIMA ACP. 2909 Other users would be expected that subsets of these mechanisms could 2910 be profiled with an accompanying applicability statements similar to 2911 the one described in Section 9. 2913 This section is considered non-normative in the generality of the 2914 protocol. Use of the suggested mechanisms here MUST be detailed in 2915 specific profiles of BRSKI, such as in Section 9. 2917 7.1. Trust Model 2919 This section explains the trust relationships detailed in 2920 Section 2.4: 2922 +--------+ +---------+ +------------+ +------------+ 2923 | Pledge | | Join | | Domain | |Manufacturer| 2924 | | | Proxy | | Registrar | | Service | 2925 | | | | | | | (Internet) | 2926 +--------+ +---------+ +------------+ +------------+ 2928 Figure 10 2930 Pledge: The pledge could be compromised and providing an attack 2931 vector for malware. The entity is trusted to only imprint using 2932 secure methods described in this document. Additional endpoint 2933 assessment techniques are RECOMMENDED but are out-of-scope of this 2934 document. 2936 Join Proxy: Provides proxy functionalities but is not involved in 2937 security considerations. 2939 Registrar: When interacting with a MASA a registrar makes all 2940 decisions. For Ownership Audit Vouchers (see [RFC8366]) the 2941 registrar is provided an opportunity to accept MASA decisions. 2943 Vendor Service, MASA: This form of manufacturer service is trusted 2944 to accurately log all claim attempts and to provide authoritative 2945 log information to registrars. The MASA does not know which 2946 devices are associated with which domains. These claims could be 2947 strengthened by using cryptographic log techniques to provide 2948 append only, cryptographic assured, publicly auditable logs. 2950 Vendor Service, Ownership Validation: This form of manufacturer 2951 service is trusted to accurately know which device is owned by 2952 which domain. 2954 7.2. Pledge security reductions 2956 The following is a list of alternative behaviours that the pledge can 2957 be programmed to implement. These behaviours are not mutually 2958 exclusive, nor are they dependent upon each other. Some of these 2959 methods enable offline and emergency (touch based) deployment use 2960 cases. Normative language is used as these behaviours are referenced 2961 in later sections in a normative fashion. 2963 1. The pledge MUST accept nonceless vouchers. This allows for a use 2964 case where the registrar can not connect to the MASA at the 2965 deployment time. Logging and validity periods address the 2966 security considerations of supporting these use cases. 2968 2. Many devices already support "trust on first use" for physical 2969 interfaces such as console ports. This document does not change 2970 that reality. Devices supporting this protocol MUST NOT support 2971 "trust on first use" on network interfaces. This is because 2972 "trust on first use" over network interfaces would undermine the 2973 logging based security protections provided by this 2974 specification. 2976 3. The pledge MAY have an operational mode where it skips voucher 2977 validation one time. For example if a physical button is 2978 depressed during the bootstrapping operation. This can be useful 2979 if the manufacturer service is unavailable. This behavior SHOULD 2980 be available via local configuration or physical presence methods 2981 (such as use of a serial/craft console) to ensure new entities 2982 can always be deployed even when autonomic methods fail. This 2983 allows for unsecured imprint. 2985 4. A craft/serial console could include a command such as "est- 2986 enroll [2001:db8:0:1]:443" that begins the EST process from the 2987 point after the voucher is validated. This process SHOULD 2988 include server certificate verification using an on-screen 2989 fingerprint. 2991 It is RECOMMENDED that "trust on first use" or any method of skipping 2992 voucher validation (including use of craft serial console) only be 2993 available if hardware assisted Network Endpoint Assessment (NEA: 2994 [RFC5209]) is supported. This recommendation ensures that domain 2995 network monitoring can detect inappropriate use of offline or 2996 emergency deployment procedures when voucher-based bootstrapping is 2997 not used. 2999 7.3. Registrar security reductions 3001 A registrar can choose to accept devices using less secure methods. 3002 They MUST NOT be the default behavior. These methods may be 3003 acceptable in situations where threat models indicate that low 3004 security is adequate. This includes situations where security 3005 decisions are being made by the local administrator: 3007 1. A registrar MAY choose to accept all devices, or all devices of a 3008 particular type, at the administrator's discretion. This could 3009 occur when informing all registrars of unique identifiers of new 3010 entities might be operationally difficult. 3012 2. A registrar MAY choose to accept devices that claim a unique 3013 identity without the benefit of authenticating that claimed 3014 identity. This could occur when the pledge does not include an 3015 X.509 IDevID factory installed credential. New Entities without 3016 an X.509 IDevID credential MAY form the Section 5.2 request using 3017 the Section 5.5 format to ensure the pledge's serial number 3018 information is provided to the registrar (this includes the 3019 IDevID AuthorityKeyIdentifier value, which would be statically 3020 configured on the pledge.) The pledge MAY refuse to provide a 3021 TLS client certificate (as one is not available.) The pledge 3022 SHOULD support HTTP-based or certificate-less TLS authentication 3023 as described in EST RFC7030 section 3.3.2. A registrar MUST NOT 3024 accept unauthenticated New Entities unless it has been configured 3025 to do so by an administrator that has verified that only expected 3026 new entities can communicate with a registrar (presumably via a 3027 physically secured perimeter.) 3029 3. A registrar MAY submit a nonceless voucher-requests to the MASA 3030 service (by not including a nonce in the voucher-request.) The 3031 resulting vouchers can then be stored by the registrar until they 3032 are needed during bootstrapping operations. This is for use 3033 cases where the target network is protected by an air gap and 3034 therefore cannot contact the MASA service during pledge 3035 deployment. 3037 4. A registrar MAY ignore unrecognized nonceless log entries. This 3038 could occur when used equipment is purchased with a valid history 3039 being deployed in air gap networks that required offline 3040 vouchers. 3042 5. A registrar MAY accept voucher formats of future types that can 3043 not be parsed by the Registrar. This reduces the Registrar's 3044 visibility into the exact voucher contents but does not change 3045 the protocol operations. 3047 7.4. MASA security reductions 3049 Lower security modes chosen by the MASA service affect all device 3050 deployments unless the lower-security behavior is tied to specific 3051 device identities. The modes described below can be applied to 3052 specific devices via knowledge of what devices were sold. They can 3053 also be bound to specific customers (independent of the device 3054 identity) by authenticating the customer's Registrar. 3056 7.4.1. Issuing Nonceless vouchers 3058 A MASA has the option of not including a nonce in the voucher, and/or 3059 not requiring one to be present in the voucher-request. This results 3060 in distribution of a voucher that may never expire and in effect 3061 makes the specified Domain an always trusted entity to the pledge 3062 during any subsequent bootstrapping attempts. That a nonceless 3063 voucher was issued is captured in the log information so that the 3064 registrar can make appropriate security decisions when a pledge joins 3065 the Domain. Nonceless vouchers are useful to support use cases where 3066 registrars might not be online during actual device deployment. 3068 While a nonceless voucher may include an expiry date, a typical use 3069 for a nonceless voucher is for it to be long-lived. If the device 3070 can be trusted to have an accurate clock (the MASA will know), then a 3071 nonceless voucher CAN be issued with a limited lifetime. 3073 A more typical case for a nonceless voucher is for use with offline 3074 onboarding scenarios where it is not possible to pass a fresh 3075 voucher-request to the MASA. The use of a long-lived voucher also 3076 eliminates concern about the availability of the MASA many years in 3077 the future. Thus many nonceless vouchers will have no expiry dates. 3079 Thus, the long lived nonceless voucher does not require the proof 3080 that the device is online. Issuing such a thing is only accepted 3081 when the registrar is authenticated by the MASA and the MASA is 3082 authorized to provide this functionality to this customer. The MASA 3083 is RECOMMENDED to use this functionality only in concert with an 3084 enhanced level of ownership tracking, the details of which are out of 3085 scope for this document. 3087 If the pledge device is known to have a real-time-clock that is set 3088 from the factory, use of a voucher validity period is RECOMMENDED. 3090 7.4.2. Trusting Owners on First Use 3092 A MASA has the option of not verifying ownership before responding 3093 with a voucher. This is expected to be a common operational model 3094 because doing so relieves the manufacturer providing MASA services 3095 from having to track ownership during shipping and supply chain and 3096 allows for a very low overhead MASA service. A registrar uses the 3097 audit log information as a defense in depth strategy to ensure that 3098 this does not occur unexpectedly (for example when purchasing new 3099 equipment the registrar would throw an error if any audit log 3100 information is reported.) The MASA SHOULD verify the 'prior-signed- 3101 voucher-request' information for pledges that support that 3102 functionality. This provides a proof-of-proximity check that reduces 3103 the need for ownership verification. The proof-of-proximity comes 3104 from the assumption that the pledge and Join Proxy are on the same 3105 link-local connection. 3107 A MASA that practices Trust-on-First-Use (TOFU) for Registrar 3108 identity may wish to annotate the origin of the connection by IP 3109 address or netblock, and restrict future use of that identity from 3110 other locations. A MASA that does this SHOULD take care to not 3111 create nuisance situations for itself when a customer has multiple 3112 registrars, or uses outgoing IPv4 NAT44 connections that change 3113 frequently. 3115 7.4.3. Updating or extending voucher trust anchors 3117 This section deals with the problem of a MASA that is no longer 3118 available due to a failed business, or the situation where a MASA is 3119 uncooperative to a secondary sale. 3121 A manufacturer could offer a management mechanism that allows the 3122 list of voucher verification trust anchors to be extended. 3123 [I-D.ietf-netconf-keystore] is one such interface that could be 3124 implemented using YANG. Pretty much any configuration mechanism used 3125 today could be extended to provide the needed additional update. A 3126 manufacturer could even decide to install the domain CA trust anchors 3127 received during the EST "cacerts" step as voucher verification 3128 anchors. Some additional signals will be needed to clearly identify 3129 which keys have voucher validation authority from among those signed 3130 by the domain CA. This is future work. 3132 With the above change to the list of anchors, vouchers can be issued 3133 by an alternate MASA. This could be the previous owner (the seller), 3134 or some other trusted third party who is mediating the sale. If it 3135 was a third party, then the seller would need to have taken steps to 3136 introduce the third party configuration to the device prior 3137 disconnection. The third party (e.g. a wholesaler of used equipment) 3138 could however use a mechanism described in Section 7.2 to take 3139 control of the device after receiving it physically. This would 3140 permit the third party to act as the MASA for future onboarding 3141 actions. As the IDevID certificate probably can not be replaced, the 3142 new owner's Registrar would have to support an override of the MASA 3143 URL. 3145 To be useful for resale or other transfers of ownership one of two 3146 situations will need to occur. The simplest is that the device is 3147 not put through any kind of factory default/reset before going 3148 through onboarding again. Some other secure, physical signal would 3149 be needed to initiate it. This is most suitable for redeploying a 3150 device within the same Enterprise. This would entail having previous 3151 configuration in the system until entirely replaced by the new owner, 3152 and represents some level of risk. 3154 The second mechanism is that there would need to be two levels of 3155 factory reset. One would take the system back entirely to 3156 manufacturer state, including removing any added trust anchors, and 3157 the second (more commonly used) one would just restore the 3158 configuration back to a known default without erasing trust anchors. 3159 This weaker factory reset might leave valuable credentials on the 3160 device and this may be unacceptable to some owners. 3162 As a third option, the manufacturer's trust anchors could be entirely 3163 overwritten with local trust anchors. A factory default would never 3164 restore those anchors. This option comes with a lot of power, but 3165 also a lot of responsibility: if access to the private part of the 3166 new anchors are lost the manufacturer may be unable to help. 3168 8. IANA Considerations 3170 This document requires the following IANA actions: 3172 8.1. The IETF XML Registry 3174 This document registers a URI in the "IETF XML Registry" [RFC3688]. 3175 IANA has registered the following: 3177 URI: urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa 3178 Registrant Contact: The ANIMA WG of the IETF. 3179 XML: N/A, the requested URI is an XML namespace. 3181 8.2. Well-known EST registration 3183 This document extends the definitions of "est" (so far defined via 3184 RFC7030) in the "https://www.iana.org/assignments/well-known-uris/ 3185 well-known-uris.xhtml" registry. IANA is asked to change the 3186 registration of "est" to include RFC7030 and this document. 3188 8.3. PKIX Registry 3190 IANA is requested to register the following: 3192 This document requests a number for id-mod-MASAURLExtn2016(TBD) from 3193 the pkix(7) id-mod(0) Registry. 3195 This document has received an early allocation from the id-pe 3196 registry (SMI Security for PKIX Certificate Extension) for id-pe- 3197 masa-url with the value 32, resulting in an OID of 3198 1.3.6.1.5.5.7.1.32. 3200 8.4. Pledge BRSKI Status Telemetry 3202 IANA is requested to create a new Registry entitled: "BRSKI 3203 Parameters", and within that Registry to create a table called: 3204 "Pledge BRSKI Status Telemetry Attributes". New items can be added 3205 using the Specification Required. The following items are to be in 3206 the initial registration, with this document (Section 5.7) as the 3207 reference: 3209 o version 3211 o Status 3213 o Reason 3215 o reason-context 3217 8.5. DNS Service Names 3219 IANA is requested to register the following Service Names: 3221 Service Name: brski-proxy 3222 Transport Protocol(s): tcp 3223 Assignee: IESG . 3224 Contact: IESG 3225 Description: The Bootstrapping Remote Secure Key 3226 Infrastructures Proxy 3227 Reference: [This document] 3229 Service Name: brski-registrar 3230 Transport Protocol(s): tcp 3231 Assignee: IESG . 3232 Contact: IESG 3233 Description: The Bootstrapping Remote Secure Key 3234 Infrastructures Registrar 3235 Reference: [This document] 3237 8.6. MUD File Extension for the MASA 3239 The IANA is requested to list the name "masa" in the MUD extensions 3240 registry defined in [RFC8520]. Its use is documented in Appendix C. 3242 9. Applicability to the Autonomic Control Plane (ACP) 3244 This document provides a solution to the requirements for secure 3245 bootstrap set out in Using an Autonomic Control Plane for Stable 3246 Connectivity of Network Operations, Administration, and Maintenance 3247 [RFC8368], A Reference Model for Autonomic Networking 3249 [I-D.ietf-anima-reference-model] and specifically the An Autonomic 3250 Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane], section 3251 3.2 (Secure Bootstrap), and section 6.1 (ACP Domain, Certificate and 3252 Network). 3254 The protocol described in this document has appeal in a number of 3255 other non-ANIMA use cases. Such uses of the protocol will be 3256 deploying into other environments with different tradeoffs of 3257 privacy, security, reliability and autonomy from manufacturers. As 3258 such those use cases will need to provide their own applicability 3259 statements, and will need to address unique privacy and security 3260 considerations for the environments in which they are used. 3262 The autonomic control plane (ACP) that is bootstrapped by the BRSKI 3263 protocol is typically used in medium to large Internet Service 3264 Provider organizations. Equivalent enterprises that have significant 3265 layer-3 router connectivity also will find significant benefit, 3266 particularly if the Enterprise has many sites. (A network consisting 3267 of primarily layer-2 is not excluded, but the adjacencies that the 3268 ACP will create and maintain will not reflect the topology until all 3269 devices participate in the ACP). 3271 In the ACP, the Join Proxy is found to be proximal because 3272 communication between the pledge and the join proxy is exclusively on 3273 IPv6 Link-Local addresses. The proximity of the Join Proxy to the 3274 Registrar is validated by the Registrar using ANI ACP IPv6 Unique 3275 Local Addresses (ULA). ULAs are not routable over the Internet, so 3276 as long as the Join Proxy is operating correctly the proximity 3277 asssertion is satisfied. Other uses of BRSKI will need make similar 3278 analysis if they use proximity assertions. 3280 As specified in the ANIMA charter, this work "..focuses on 3281 professionally-managed networks." Such a network has an operator and 3282 can do things like install, configure and operate the Registrar 3283 function. The operator makes purchasing decisions and is aware of 3284 what manufacturers it expects to see on its network. 3286 Such an operator is also capable of performing bootstrapping of a 3287 device using a serial-console (craft console). The zero-touch 3288 mechanism presented in this and the ACP document 3289 [I-D.ietf-anima-autonomic-control-plane] represents a significiant 3290 efficiency: in particular it reduces the need to put senior experts 3291 on airplanes to configure devices in person. 3293 There is a recognition as the technology evolves that not every 3294 situation may work out, and occasionally a human may still have to 3295 visit. In recognition of this, some mechanisms are presented in 3296 Section 7.2. The manufacturer MUST provide at least one of the one- 3297 touch mechanisms described that permit enrollment to be proceed 3298 without availability of any manufacturer server (such as the MASA). 3300 The BRSKI protocol is going into environments where there have 3301 already been quite a number of vendor proprietary management systems. 3302 Those are not expected to go away quickly, but rather to leverage the 3303 secure credentials that are provisioned by BRSKI. The connectivity 3304 requirements of said management systems are provided by the ACP. 3306 9.1. Operational Requirements 3308 This section collects operational requirements based upon the three 3309 roles involved in BRSKI: The Manufacturer Authorized Signing 3310 Authority (MASA), the (Domain) Owner and the Device. It should be 3311 recognized that the manufacturer may be involved in two roles, as it 3312 creates the software/firmware for the device, and also may be the 3313 operator of the MASA. 3315 The requirements in this section are presented using BCP14 3316 ([RFC2119], [RFC8174]) language. These do not represent new 3317 normative statements, just a review of a few such things in one place 3318 by role. They also apply specifically to the ANIMA ACP use case. 3319 Other use cases likely have similar, but MAY different requirements. 3321 9.1.1. MASA Operational Requirements 3323 The manufacturer MUST arrange for an online service to be available 3324 called the MASA. It MUST be available at the URL which is encoded in 3325 the IDevID certificate extensions described in Section 2.3.2. 3327 The online service MUST have access to a private key with which to 3328 sign [RFC8366] format voucher artifacts. The public key, 3329 certificate, or certificate chain MUST be built in to the device as 3330 part of the firmware. 3332 It is RECOMMENDED that the manufacturer arrange for this signing key 3333 (or keys) to be escrowed according to typical software source code 3334 escrow practices [softwareescrow]. 3336 The MASA accepts voucher requests from Domain Owners according to an 3337 operational practice appropriate for the device. This can range from 3338 any domain owner (first-come first-served, on a TOFU-like basis), to 3339 full sales channel integration where Domain Owners need to be 3340 positively identified by TLS Client Certicate pinned, or HTTP 3341 Authentication process. The MASA creates signed voucher artifacts 3342 according to a it's internally defined policies. 3344 The MASA MUST operate an audit log for devices that is accessible. 3345 The audit log is designed to be easily cacheable and the MASA MAY 3346 find it useful to put this content on a CDN. 3348 9.1.2. Domain Owner Operational Requirements 3350 The domain owner MUST operate an EST ([RFC7030]) server with the 3351 extensions described in this document. This is the JRC or Registrar. 3352 This JRC/EST server MUST announce itself using GRASP within the ACP. 3353 This EST server will typically reside with the Network Operations 3354 Center for the organization. 3356 The domain owner MAY operate an internal certificate authority (CA) 3357 that is seperate from the EST server, or it MAY combine all 3358 activities into a single device. The determination of the 3359 architecture depends upon the scale and resiliency requirements of 3360 the organization. Multiple JRC instances MAY be announced into the 3361 ACP from multiple locations to achieve an appropriate level of 3362 redundancy. 3364 In order to recognize which devices and which manufacturers are 3365 welcome on the domain owner's network, the domain owner SHOULD 3366 maintain a white list of manufacturers. This MAY extend to 3367 integration with purchasing departments to know the serial numbers of 3368 devices. 3370 The domain owner SHOULD use the resulting overlay ACP network to 3371 manage devices, replacing legacy out-of-band mechanisms. 3373 The domain owner SHOULD operate one or more EST servers which can be 3374 used to renew the domain certificates (LDevIDs) which are deployed to 3375 devices. These servers MAY be the same as the JRC, or MAY be a 3376 distinct set of devices, as approriate for resiliency. 3378 The organization MUST take appropriate precautions against loss of 3379 access to the certificate authority private key. Hardware security 3380 modules and/or secret splitting are appropriate. 3382 9.1.3. Device Operational Requirements 3384 Devices MUST come with built-in trust anchors that permit the device 3385 to validate vouchers from the MASA. 3387 Device MUST come with (unique, per-device) IDevID certificates that 3388 include their serial numbers, and the MASA URL extension. 3390 Devices are expected to find Join Proxies using GRASP, and then 3391 connect to the JRC using the protocol described in this document. 3393 Once a domain owner has been validated with the voucher, devices are 3394 expected to enroll into the domain using EST. Devices are then 3395 expected to form ACPs using IPsec over IPv6 Link-Local addresses as 3396 described in [I-D.ietf-anima-autonomic-control-plane] 3398 Once a device has been enrolled it SHOULD listen for the address of 3399 the JRC using GRASP, and it SHOULD enable itself as a Join Proxy, and 3400 announce itself on all links/interfaces using GRASP DULL. 3402 Devices are expected to renew their certificates before they expire. 3404 10. Privacy Considerations 3406 10.1. MASA audit log 3408 The MASA audit log includes the domainID for each domain a voucher 3409 has been issued to. This information is closely related to the 3410 actual domain identity. A MASA may need additional defenses against 3411 Denial of Service attacks (Section 11.1), and this may involve 3412 collecting additional (unspecified here) information. This could 3413 provide sufficient information for the MASA service to build a 3414 detailed understanding the devices that have been provisioned within 3415 a domain. 3417 There are a number of design choices that mitigate this risk. The 3418 domain can maintain some privacy since it has not necessarily been 3419 authenticated and is not authoritatively bound to the supply chain. 3421 Additionally the domainID captures only the unauthenticated subject 3422 key identifier of the domain. A privacy sensitive domain could 3423 theoretically generate a new domainID for each device being deployed. 3424 Similarly a privacy sensitive domain would likely purchase devices 3425 that support proximity assertions from a manufacturer that does not 3426 require sales channel integrations. This would result in a 3427 significant level of privacy while maintaining the security 3428 characteristics provided by Registrar based audit log inspection. 3430 10.2. What BRSKI-EST reveals 3432 During the provisional phase of the BRSKI-EST connection between the 3433 Pledge and the Registrar, each party reveals its certificates to each 3434 other. For the Pledge, this includes the serialNumber attribute, the 3435 MASA URL, and the identity that signed the IDevID certificate. 3437 TLS 1.2 reveals the certificate identities to on-path observers, 3438 including the Join Proxy. 3440 TLS 1.3 reveals the certificate identities only to the end parties, 3441 but as the connection is provisional, an on-path attacker (MTIM) can 3442 see the certificates. This includes not just malicious attackers, 3443 but also Registrars that are visible to the Pledge, but which are not 3444 part of the intended domain. 3446 The certificate of the Registrar is rather arbitrary from the point 3447 of view of the BRSKI protocol. As no [RFC6125] validations are 3448 expected to be done, the contents could be easily pseudonymized. Any 3449 device that can see a join proxy would be able to connect to the 3450 Registrar and learn the identity of the network in question. Even if 3451 the contents of the certificate are pseudonymized, it would be 3452 possible to correlate different connections in different locations 3453 belong to the same entity. This is unlikely to present a significant 3454 privacy concern to ANIMA ACP uses of BRSKI, but may be a concern to 3455 other users of BRSKI. 3457 The certificate of the Pledge could be revealed by a malicious Join 3458 Proxy that performed a MITM attack on the provisional TLS connection. 3459 Such an attacker would be able to reveal the identity of the Pledge 3460 to third parties if it chose to so. 3462 Research into a mechanism to do multi-step, multi-party authenticated 3463 key agreement, incorporating some kind of zero-knowledge proof would 3464 be valuable. Such a mechanism would ideally avoid disclosing 3465 identities until pledge, registrar and MASA agree to the transaction. 3466 Such a mechanism would need to discover the location of the MASA 3467 without knowing the identity of the pledge, or the identity of the 3468 MASA. This part of the problem may be unsolveable. 3470 10.3. What BRSKI-MASA reveals to the manufacturer 3472 With consumer-oriented devices, the "call-home" mechanism in IoT 3473 devices raises significant privacy concerns. See [livingwithIoT] and 3474 [IoTstrangeThings] for exemplars. The Autonomic Control Plane (ACP) 3475 usage of BRSKI is not targeted at individual usage of IoT devices, 3476 but rather at the Enterprise and ISP creation of networks in a zero- 3477 touch fashion where the "call-home" represents a different class of 3478 privacy and lifecycle management concerns. 3480 As the Autonomic Control Plane (ACP) usage of BRSKI is not targeted 3481 at individual usage of IoT devices, but rather at the Enterprise and 3482 ISP creation of networks in a zero-touch fashion, the "call-home" 3483 represents a different kind of concern. 3485 It needs to be re-iterated that the BRSKI-MASA mechanism only occurs 3486 once during the commissioning of the device. It is well defined, and 3487 although encrypted with TLS, it could in theory be made auditable as 3488 the contents are well defined. This connection does not occur when 3489 the device powers on or is restarted for normal routines. (It is 3490 conceivable, but remarkably unusual, that a device could be forced to 3491 go through a full factory reset during an exceptional firmware update 3492 situation, after which enrollment would have be repeated, and a new 3493 connection would occur) 3495 The BRSKI call-home mechanism is mediated via the owner's Registrar, 3496 and the information that is transmitted is directly auditable by the 3497 device owner. This is in stark contrast to many "call-home" 3498 protocols where the device autonomously calls home and uses an 3499 undocumented protocol. 3501 While the contents of the signed part of the pledge voucher request 3502 can not be changed, they are not encrypted at the registrar. The 3503 ability to audit the messages by the owner of the network is a 3504 mechanism to defend against exfiltration of data by a nefarious 3505 pledge. Both are, to re-iterate, encrypted by TLS while in transit. 3507 The BRSKI-MASA exchange reveals the following information to the 3508 manufacturer: 3510 o the identity of the device being enrolled. This is revealed by 3511 transmission of a signed voucher-request containing the serial- 3512 number. The manufacturer can usually link the serial number to a 3513 device model. 3515 o an identity of the domain owner in the form of the domain trust 3516 anchor. However, this is not a global PKI anchored name within 3517 the WebPKI, so this identity could be pseudonymous. If there is 3518 sales channel integration, then the MASA will have authenticated 3519 the domain owner, either via pinned certificate, or perhaps 3520 another HTTP authentication method, as per Section 5.5.4. 3522 o the time the device is activated, 3524 o the IP address of the domain Owner's Registrar. For ISPs and 3525 Enterprises, the IP address provides very clear geolocation of the 3526 owner. No amount of IP address privacy extensions ([RFC4941]) can 3527 do anything about this, as a simple whois lookup likely identifies 3528 the ISP or Enterprise from the upper bits anyway. A passive 3529 attacker who observes the connection definitely may conclude that 3530 the given enterprise/ISP is a customer of the particular equipment 3531 vendor. The precise model that is being enrolled will remain 3532 private. 3534 Based upon the above information, the manufacturer is able to track a 3535 specific device from pseudonymous domain identity to the next 3536 pseudonymous domain identity. If there is sales-channel integration, 3537 then the identities are not pseudonymous. 3539 The manufacturer knows the IP address of the Registrar, but it can 3540 not see the IP address of the device itself. The manufacturer can 3541 not track the device to a detailed physical or network location, only 3542 to the location of the Registrar. That is likely to be at the 3543 Enterprise or ISPs headquarters. 3545 The above situation is to be distinguished from a residential/ 3546 individual person who registers a device from a manufacturer. 3547 Individuals do not tend to have multiple offices, and their registrar 3548 is likely on the same network as the device. A manufacturer that 3549 sells switching/routing products to enterprises should hardly be 3550 surprised if additional purchases switching/routing products are 3551 made. Deviations from a historical trend or an establish baseline 3552 would, however, be notable. 3554 The situation is not improved by the enterprise/ISP using 3555 anonymization services such as ToR [Dingledine2004], as a TLS 1.2 3556 connection will reveal the ClientCertificate used, clearly 3557 identifying the enterprise/ISP involved. TLS 1.3 is better in this 3558 regard, but an active attacker can still discover the parties 3559 involved by performing a Man-In-The-Middle-Attack on the first 3560 attempt (breaking/killing it with a TCP RST), and then letting 3561 subsequent connection pass through. 3563 A manufacturer could attempt to mix the BRSKI-MASA traffic in with 3564 general traffic their site by hosting the MASA behind the same (set) 3565 of load balancers that the companies normal marketing site is hosted 3566 behind. This makes lots of sense from a straight capacity planning 3567 point of view as the same set of services (and the same set of 3568 Distributed Denial of Service mitigations) may be used. 3569 Unfortunately, as the BRSKI-MASA connections include TLS 3570 ClientCertificate exchanges, this may easily be observed in TLS 1.2, 3571 and a traffic analysis may reveal it even in TLS 1.3. This does not 3572 make such a plan irrelevant. There may be other organizational 3573 reasons to keep the marketing site (which is often subject to 3574 frequent re-designs, outsourcing, etc.) separate from the MASA, which 3575 may need to operate reliably for decades. 3577 10.4. Manufacturers and Used or Stolen Equipment 3579 As explained above, the manufacturer receives information each time 3580 that a device which is in factory-default mode does a zero-touch 3581 bootstrap, and attempts to enroll into a domain owner's registrar. 3583 The manufacturer is therefore in a position to decline to issue a 3584 voucher if it detects that the new owner is not the same as the 3585 previous owner. 3587 1. This can be seen as a feature if the equipment is believed to 3588 have been stolen. If the legitimate owner notifies the 3589 manufacturer of the theft, then when the new owner brings the 3590 device up, if they use the zero-touch mechanism, the new 3591 (illegitimate) owner reveals their location and identity. 3593 2. In the case of Used equipment, the initial owner could inform the 3594 manufacturer of the sale, or the manufacturer may just permit 3595 resales unless told otherwise. In which case, the transfer of 3596 ownership simply occurs. 3598 3. A manufacturer could however decide not to issue a new voucher in 3599 response to a transfer of ownership. This is essentially the 3600 same as the stolen case, with the manufacturer having decided 3601 that the sale was not legitimate. 3603 4. There is a fourth case, if the manufacturer is providing 3604 protection against stolen devices. The manufacturer then has a 3605 responsibility to protect the legitimate owner against fraudulent 3606 claims that the equipment was stolen. In the absence of such 3607 manufacturer protection, such a claim would cause the 3608 manufacturer to refuse to issue a new voucher. Should the device 3609 go through a deep factory reset (for instance, replacement of a 3610 damaged main board component, the device would not bootstrap. 3612 5. Finally, there is a fifth case: the manufacturer has decided to 3613 end-of-line the device, or the owner has not paid a yearly 3614 support amount, and the manufacturer refuses to issue new 3615 vouchers at that point. This last case is not new to the 3616 industry: many license systems are already deployed that have 3617 significantly worse effect. 3619 This section has outlined five situations in which a manufacturer 3620 could use the voucher system to enforce what are clearly license 3621 terms. A manufacturer that attempted to enforce license terms via 3622 vouchers would find it rather ineffective as the terms would only be 3623 enforced when the device is enrolled, and this is not (to repeat), a 3624 daily or even monthly occurrence. 3626 10.5. Manufacturers and Grey market equipment 3628 Manufacturers of devices often sell different products into different 3629 regional markets. Which product is available in which market can be 3630 driven by price differentials, support issues (some markets may 3631 require manuals and tech-support to be done in the local language), 3632 government export regulation (such as whether strong crypto is 3633 permitted to be exported, or permitted to be used in a particular 3634 market). When an domain owner obtains a device from a different 3635 market (they can be new) and transfers it to a different location, 3636 this is called a Grey Market. 3638 A manufacturer could decide not to issue a voucher to an enterprise/ 3639 ISP based upon their location. There are a number of ways which this 3640 could be determined: from the geolocation of the registrar, from 3641 sales channel knowledge about the customer, and what products are 3642 (un-)available in that market. If the device has a GPS the 3643 coordinates of the device could even be placed into an extension of 3644 the voucher. 3646 The above actions are not illegal, and not new. Many manufacturers 3647 have shipped crypto-weak (exportable) versions of firmware as the 3648 default on equipment for decades. The first task of an enterprise/ 3649 ISP has always been to login to a manufacturer system, show one's 3650 "entitlement" (country information, proof that support payments have 3651 been made), and receive either a new updated firmware, or a license 3652 key that will activate the correct firmware. 3654 BRSKI permits the above process to automated (in an autonomic 3655 fashion), and therefore perhaps encourages this kind of 3656 differentiation by reducing the cost of doing it. 3658 An issue that manufacturers will need to deal with in the above 3659 automated process is when a device is shipped to one country with one 3660 set of rules (or laws or entitlements), but the domain registry is in 3661 another one. Which rules apply is something will have to be worked 3662 out: the manufacturer could come to believe they are dealing with 3663 Grey market equipment, when it is simply dealing with a global 3664 enterprise. 3666 10.6. Some mitigations for meddling by manufacturers 3668 The most obvious mitigation is not to buy the product. Pick 3669 manufacturers that are up-front about their policies, who do not 3670 change them gratuitously. 3672 Section 7.4.3 describes some ways in which a manufacturer could 3673 provide a mechanism to manage the trust anchors and built-in 3674 certificates (IDevID) as an extension. There are a variety of 3675 mechanism, and some may take a substantial amount of work to get 3676 exactly correct. These mechanisms do not change the flow of the 3677 protocol described here, but rather allow the starting trust 3678 assumptions to be changed. This is an area for future 3679 standardization work. 3681 Replacement of the voucher validation anchors (usually pointing to 3682 the original manufacturer's MASA) with those of the new owner permits 3683 the new owner to issue vouchers to subsequent owners. This would be 3684 done by having the selling (old) owner to run a MASA. 3686 The BRSKI protocol depends upon a trust anchor on the device and an 3687 identity on the device. Management of these entities facilitates a 3688 few new operational modes without making any changes to the BRSKI 3689 protocol. Those modes include: offline modes where the domain owner 3690 operates an internal MASA for all devices, resell modes where the 3691 first domain owner becomes the MASA for the next (resold-to) domain 3692 owner, and services where an aggregator acquires a large variety of 3693 devices, and then acts as a pseudonymized MASA for a variety of 3694 devices from a variety of manufacturers. 3696 Although replacement of the IDevID is not required for all modes 3697 described above, a manufacturers could support such a thing. Some 3698 may wish to consider replacement of the IDevID as an indication that 3699 the device's warrantee is terminated. For others, the privacy 3700 requirements of some deployments might consider this a standard 3701 operating practice. 3703 As discussed at the end of Section 5.8.1, new work could be done to 3704 use a distributed consensus technology for the audit log. This would 3705 permit the audit log to continue to be useful, even when there is a 3706 chain of MASA due to changes of ownership. 3708 10.7. Death of a manufacturer 3710 A common concern has been that a manufacturer could go out of 3711 business, leaving owners of devices unable to get new vouchers for 3712 existing products. Said products might have been previously 3713 deployed, but need to be re-initialized, they might have been 3714 purchased used, or they might have kept in a warehouse as long-term 3715 spares. 3717 The MASA was named the Manufacturer *Authorized* Signing Authority to 3718 emphasize that it need not be the manufacturer itself that performs 3719 this. It is anticipated that specialist service providers will come 3720 to exist that deal with the creation of vouchers in much the same way 3721 that many companies have outsourced email, advertising and janitorial 3722 services. 3724 Further, it is expected that as part of any service agreement that 3725 the manufacturer would arrange to escrow appropriate private keys 3726 such that a MASA service could be provided by a third party. This 3727 has routinely been done for source code for decades. 3729 11. Security Considerations 3731 This document details a protocol for bootstrapping that balances 3732 operational concerns against security concerns. As detailed in the 3733 introduction, and touched on again in Section 7, the protocol allows 3734 for reduced security modes. These attempt to deliver additional 3735 control to the local administrator and owner in cases where less 3736 security provides operational benefits. This section goes into more 3737 detail about a variety of specific considerations. 3739 To facilitate logging and administrative oversight, in addition to 3740 triggering Registrar verification of MASA logs, the pledge reports on 3741 voucher parsing status to the registrar. In the case of a failure, 3742 this information is informative to a potentially malicious registrar. 3743 This is mandated anyway because of the operational benefits of an 3744 informed administrator in cases where the failure is indicative of a 3745 problem. The registrar is RECOMMENDED to verify MASA logs if voucher 3746 status telemetry is not received. 3748 To facilitate truly limited clients EST RFC7030 section 3.3.2 3749 requirements that the client MUST support a client authentication 3750 model have been reduced in Section 7 to a statement that the 3751 registrar "MAY" choose to accept devices that fail cryptographic 3752 authentication. This reflects current (poor) practices in shipping 3753 devices without a cryptographic identity that are NOT RECOMMENDED. 3755 During the provisional period of the connection the pledge MUST treat 3756 all HTTP header and content data as untrusted data. HTTP libraries 3757 are regularly exposed to non-secured HTTP traffic: mature libraries 3758 should not have any problems. 3760 Pledges might chose to engage in protocol operations with multiple 3761 discovered registrars in parallel. As noted above they will only do 3762 so with distinct nonce values, but the end result could be multiple 3763 vouchers issued from the MASA if all registrars attempt to claim the 3764 device. This is not a failure and the pledge choses whichever 3765 voucher to accept based on internal logic. The registrars verifying 3766 log information will see multiple entries and take this into account 3767 for their analytics purposes. 3769 11.1. Denial of Service (DoS) against MASA 3771 There are uses cases where the MASA could be unavailable or 3772 uncooperative to the Registrar. They include active DoS attacks, 3773 planned and unplanned network partitions, changes to MASA policy, or 3774 other instances where MASA policy rejects a claim. These introduce 3775 an operational risk to the Registrar owner in that MASA behavior 3776 might limit the ability to bootstrap a pledge device. For example 3777 this might be an issue during disaster recovery. This risk can be 3778 mitigated by Registrars that request and maintain long term copies of 3779 "nonceless" vouchers. In that way they are guaranteed to be able to 3780 bootstrap their devices. 3782 The issuance of nonceless vouchers themselves creates a security 3783 concern. If the Registrar of a previous domain can intercept 3784 protocol communications then it can use a previously issued nonceless 3785 voucher to establish management control of a pledge device even after 3786 having sold it. This risk is mitigated by recording the issuance of 3787 such vouchers in the MASA audit log that is verified by the 3788 subsequent Registrar and by Pledges only bootstrapping when in a 3789 factory default state. This reflects a balance between enabling MASA 3790 independence during future bootstrapping and the security of 3791 bootstrapping itself. Registrar control over requesting and auditing 3792 nonceless vouchers allows device owners to choose an appropriate 3793 balance. 3795 The MASA is exposed to DoS attacks wherein attackers claim an 3796 unbounded number of devices. Ensuring a registrar is representative 3797 of a valid manufacturer customer, even without validating ownership 3798 of specific pledge devices, helps to mitigate this. Pledge 3799 signatures on the pledge voucher-request, as forwarded by the 3800 registrar in the prior-signed-voucher-request field of the registrar 3801 voucher-request, significantly reduce this risk by ensuring the MASA 3802 can confirm proximity between the pledge and the registrar making the 3803 request. Supply chain integration ("know your customer") is an 3804 additional step that MASA providers and device vendors can explore. 3806 11.2. DomainID must be resistant to second-preimage attacks 3808 The domainID is used as the reference in the audit log to the domain. 3809 The domainID is expected to be calculated by a hash that is resistant 3810 to a second-preimage attack. The consequences of such an attack 3811 would allow a second registrar to create audit log entries that are 3812 fake. 3814 11.3. Availability of good random numbers 3816 The nonce used by the Pledge in the voucher-request SHOULD be 3817 generated by a Strong Cryptographic Sequence ([RFC4086] section 6.2). 3818 TLS has a similar requirement. 3820 In particular implementations should pay attention to the advance in 3821 [RFC4086] section 3, particularly section 3.4. Devices which are 3822 reset to factory default in order to perform a second bootstrap with 3823 a new owner MUST NOT use idential seeds. 3825 11.4. Freshness in Voucher-Requests 3827 A concern has been raised that the pledge voucher-request should 3828 contain some content (a nonce) provided by the registrar and/or MASA 3829 in order for those actors to verify that the pledge voucher-request 3830 is fresh. 3832 There are a number of operational problems with getting a nonce from 3833 the MASA to the pledge. It is somewhat easier to collect a random 3834 value from the registrar, but as the registrar is not yet vouched 3835 for, such a registrar nonce has little value. There are privacy and 3836 logistical challenges to addressing these operational issues, so if 3837 such a thing were to be considered, it would have to provide some 3838 clear value. This section examines the impacts of not having a fresh 3839 pledge voucher-request. 3841 Because the registrar authenticates the pledge, a full Man-in-the- 3842 Middle attack is not possible, despite the provisional TLS 3843 authentication by the pledge (see Section 5.) Instead we examine the 3844 case of a fake registrar (Rm) that communicates with the pledge in 3845 parallel or in close time proximity with the intended registrar. 3846 (This scenario is intentionally supported as described in 3847 Section 4.1.) 3849 The fake registrar (Rm) can obtain a voucher signed by the MASA 3850 either directly or through arbitrary intermediaries. Assuming that 3851 the MASA accepts the registrar voucher-request (either because Rm is 3852 collaborating with a legitimate registrar according to supply chain 3853 information, or because the MASA is in audit-log only mode), then a 3854 voucher linking the pledge to the registrar Rm is issued. 3856 Such a voucher, when passed back to the pledge, would link the pledge 3857 to registrar Rm, and would permit the pledge to end the provisional 3858 state. It now trusts Rm and, if it has any security vulnerabilities 3859 leveragable by an Rm with full administrative control, can be assumed 3860 to be a threat against the intended registrar. 3862 This flow is mitigated by the intended registrar verifying the audit 3863 logs available from the MASA as described in Section 5.8. Rm might 3864 chose to collect a voucher-request but wait until after the intended 3865 registrar completes the authorization process before submitting it. 3866 This pledge voucher-request would be 'stale' in that it has a nonce 3867 that no longer matches the internal state of the pledge. In order to 3868 successfully use any resulting voucher the Rm would need to remove 3869 the stale nonce or anticipate the pledge's future nonce state. 3871 Reducing the possibility of this is why the pledge is mandated to 3872 generate a strong random or pseudo-random number nonce. 3874 Additionally, in order to successfully use the resulting voucher the 3875 Rm would have to attack the pledge and return it to a bootstrapping 3876 enabled state. This would require wiping the pledge of current 3877 configuration and triggering a re-bootstrapping of the pledge. This 3878 is no more likely than simply taking control of the pledge directly 3879 but if this is a consideration the target network is RECOMMENDED to 3880 take the following steps: 3882 o Ongoing network monitoring for unexpected bootstrapping attempts 3883 by pledges. 3885 o Retrieval and examination of MASA log information upon the 3886 occurrence of any such unexpected events. Rm will be listed in 3887 the logs along with nonce information for analysis. 3889 11.5. Trusting manufacturers 3891 The BRSKI extensions to EST permit a new pledge to be completely 3892 configured with domain specific trust anchors. The link from built- 3893 in manufacturer-provided trust anchors to domain-specific trust 3894 anchors is mediated by the signed voucher artifact. 3896 If the manufacturer's IDevID signing key is not properly validated, 3897 then there is a risk that the network will accept a pledge that 3898 should not be a member of the network. As the address of the 3899 manufacturer's MASA is provided in the IDevID using the extension 3900 from Section 2.3, the malicious pledge will have no problem 3901 collaborating with it's MASA to produce a completely valid voucher. 3903 BRSKI does not, however, fundamentally change the trust model from 3904 domain owner to manufacturer. Assuming that the pledge used its 3905 IDevID with RFC7030 EST and BRSKI, the domain (registrar) still needs 3906 to trust the manufacturer. 3908 Establishing this trust between domain and manufacturer is outside 3909 the scope of BRSKI. There are a number of mechanisms that can 3910 adopted including: 3912 o Manually configuring each manufacturer's trust anchor. 3914 o A Trust-On-First-Use (TOFU) mechanism. A human would be queried 3915 upon seeing a manufacturer's trust anchor for the first time, and 3916 then the trust anchor would be installed to the trusted store. 3917 There are risks with this; even if the key to name mapping is 3918 validated using something like the WebPKI, there remains the 3919 possibility that the name is a look alike: e.g, dem0.example. vs 3920 demO.example. 3922 o scanning the trust anchor from a QR code that came with the 3923 packaging (this is really a manual TOFU mechanism) 3925 o some sales integration process where trust anchors are provided as 3926 part of the sales process, probably included in a digital packing 3927 "slip", or a sales invoice. 3929 o consortium membership, where all manufacturers of a particular 3930 device category (e.g, a light bulb, or a cable-modem) are signed 3931 by an certificate authority specifically for this. This is done 3932 by CableLabs today. It is used for authentication and 3933 authorization as part of TR-79: [docsisroot] and [TR069]. 3935 The existing WebPKI provides a reasonable anchor between manufacturer 3936 name and public key. It authenticates the key. It does not provide 3937 a reasonable authorization for the manufacturer, so it is not 3938 directly useable on it's own. 3940 11.6. Manufacturer Maintenance of trust anchors 3942 BRSKI depends upon the manufacturer building in trust anchors to the 3943 pledge device. The voucher artifact which is signed by the MASA will 3944 be validated by the pledge using that anchor. This implies that the 3945 manufacturer needs to maintain access to a signing key that the 3946 pledge can validate. 3948 The manufacturer will need to maintain the ability to make signatures 3949 that can be validated for the lifetime that the device could be 3950 onboarded. Whether this onboarding lifetime is less than the device 3951 lifetime depends upon how the device is used. An inventory of 3952 devices kept in a warehouse as spares might not be onboarded for many 3953 decades. 3955 There are good cryptographic hygiene reasons why a manufacturer would 3956 not want to maintain access to a private key for many decades. A 3957 manufacturer in that situation can leverage a long-term certificate 3958 authority anchor, built-in to the pledge, and then a certificate 3959 chain may be incorporated using the normal CMS certificate set. This 3960 may increase the size of the voucher artifacts, but that is not a 3961 significant issues in non-constrained environments. 3963 There are a few other operational variations that manufacturers could 3964 consider. For instance, there is no reason that every device need 3965 have the same set of trust anchors pre-installed. Devices built in 3966 different factories, or on different days, or any other consideration 3967 could have different trust anchors built in, and the record of which 3968 batch the device is in would be recorded in the asset database. The 3969 manufacturer would then know which anchor to sign an artifact 3970 against. 3972 Aside from the concern about long-term access to private keys, a 3973 major limiting factor for the shelf-life of many devices will be the 3974 age of the cryptographic algorithms included. A device produced in 3975 2019 will have hardware and software capable of validating algorithms 3976 common in 2019, and will have no defense against attacks (both 3977 quantum and von-neuman brute force attacks) which have not yet been 3978 invented. This concern is orthogonal to the concern about access to 3979 private keys, but this concern likely dominates and limits the 3980 lifespan of a device in a warehouse. If any update to firmware to 3981 support new cryptographic mechanism were possible (while the device 3982 was in a warehouse), updates to trust anchors would also be done at 3983 the same time. 3985 The set of standard operating procedures for maintaining high value 3986 private keys is well documented. For instance, the WebPKI provides a 3987 number of options for audits at [cabforumaudit], and the DNSSEC root 3988 operations are well documented at [dnssecroot]. 3990 It is not clear if Manufacturers will take this level of precaution, 3991 or how strong the economic incentives are to maintain an appropriate 3992 level of security. 3994 This next section examines the risk due to a compromised manufacturer 3995 IDevID signing key. This is followed by examination of the risk due 3996 to a compromised MASA key. The third section sections below examines 3997 the situation where MASA web server itself is under attacker control, 3998 but that the MASA signing key itself is safe in a not-directly 3999 connected hardware module. 4001 11.6.1. Compromise of Manufacturer IDevID signing keys 4003 An attacker that has access to the key that the manufacturer uses to 4004 sign IDevID certificates can create counterfeit devices. Such 4005 devices can claim to be from a particular manufacturer, but be 4006 entirely different devices: Trojan horses in effect. 4008 As the attacker controls the MASA URL in the certificate, the 4009 registrar can be convinced to talk to the attackers' MASA. The 4010 Registrar does not need to be in any kind of promiscuous mode to be 4011 vulnerable. 4013 In addition to creating fake devices, the attacker may also be able 4014 to issue revocations for existing certificates if the IDevID 4015 certificate process relies upon CRL lists that are distributed. 4017 There does not otherwise seem to be any risk from this compromise to 4018 devices which are already deployed, or which are sitting locally in 4019 boxes waiting for deployment (local spares). The issue is that 4020 operators will be unable to trust devices which have been in an 4021 uncontrolled warehouse as they do not know if those are real devices. 4023 11.6.2. Compromise of MASA signing keys 4025 There are two periods of time in which to consider: when the MASA key 4026 has fallen into the hands of an attacker, and after the MASA 4027 recognizes that the key has been compromised. 4029 11.6.2.1. Attacker opportunties with compromised MASA key 4031 An attacker that has access to the MASA signing key could create 4032 vouchers. These vouchers could be for existing deployed devices, or 4033 for devices which are still in a warehouse. In order to exploit 4034 these vouchers two things need to occur: the device has to go through 4035 a factory default boot cycle, and the registrar has to be convinced 4036 to contact the attacker's MASA. 4038 If the attacker controls a Registrar which is visible to the device, 4039 then there is no difficulty in delivery of the false voucher. A 4040 possible practical example of an attack like this would be in a data 4041 center, at an ISP peering point (whether a public IX, or a private 4042 peering point). In such a situation, there are already cables 4043 attached to the equipment that lead to other devices (the peers at 4044 the IX), and through those links, the false voucher could be 4045 delivered. The difficult part would be get the device put through a 4046 factory reset. This might be accomplished through social engineering 4047 of data center staff. Most locked cages have ventilation holes, and 4048 possibly a long "paperclip" could reach through to depress a factory 4049 reset button. Once such a piece of ISP equipment has been 4050 compromised, it could be used to compromise equipment that was 4051 connected to (through long haul links even), assuming that those 4052 pieces of equipment could also be forced through a factory reset. 4054 The above scenario seems rather unlikely as it requires some element 4055 of physical access; but were there a remote exploit that did not 4056 cause a direct breach, but rather a fault that resulted in a factory 4057 reset, this could provide a reasonable path. 4059 The above deals with ANI uses of BRSKI. For cases where 802.11 or 4060 802.15.4 is involved, the need to connect directly to the device is 4061 eliminated, but the need to do a factory reset is not. Physical 4062 possession of the device is not required as above, provided that 4063 there is some way to force a factory reset. With some consumers 4064 devices with low overall implementation quality, the end users might 4065 be familiar with needing to reset the device regularly. 4067 The authors are unable to come up with an attack scenario where a 4068 compromised voucher signature enables an attacker to introduce a 4069 compromised pledge into an existing operator's network. This is the 4070 case because the operator controls the communication between 4071 Registrar and MASA, and there is no opportunity to introduce the fake 4072 voucher through that conduit. 4074 11.6.2.2. Risks after key compromise is known 4076 Once the operator of the MASA realizes that the voucher signing key 4077 has been compromised it has to do a few things. 4079 First, it MUST issue a firmware update to all devices that had that 4080 key as a trust anchor, such that they will no longer trust vouchers 4081 from that key. This will affect devices in the field which are 4082 operating, but those devices, being in operation, are not performing 4083 onboarding operations, so this is not a critical patch. 4085 Devices in boxes (in warehouses) are vulnerable, and remain 4086 vulnerable until patched. An operator would be prudent to unbox the 4087 devices, onboard them in a safe environment, and then perform 4088 firmware updates. This does not have to be done by the end-operator; 4089 it could be done by a distributor that stores the spares. A 4090 recommended practice for high value devices (which typically have a 4091 <4hr service window) may be to validate the device operation on a 4092 regular basis anyway. 4094 If the onboarding process includes attestations about firmware 4095 versions, then through that process the operator would be advised to 4096 upgrade the firmware before going into production. Unfortunately, 4097 this does not help against situations where the attacker operates 4098 their own Registrar (as listed above). 4100 [RFC8366] section 6.1 explains the need for short-lived vouchers. 4101 The nonce guarantees freshness, and the short-lived nature of the 4102 voucher means that the window to deliver a fake voucher is very 4103 short. A nonceless, long-lived voucher would be the only option for 4104 the attacker, and devices in the warehouse would be vulnerable to 4105 such a thing. 4107 A key operational recommendation is for manufacturers to sign 4108 nonceless, long-lived vouchers with a different key that they sign 4109 short-lived vouchers. That key needs significantly better 4110 protection. If both keys come from a common trust-anchor (the 4111 manufacturer's CA), then a compromise of the manufacturer's CA would 4112 compromise both keys. Such a compromise of the manufacturer's CA 4113 likely compromises all keys outlined in this section. 4115 11.6.3. Compromise of MASA web service 4117 An attacker that takes over the MASA web service has a number of 4118 attacks. The most obvious one is simply to take the database listing 4119 customers and devices and to sell this data to other attackers who 4120 will now know where to find potentially vulnerable devices. 4122 The second most obvious thing that the attacker can do is to kill the 4123 service, or make it operate unreliably, making customers frustrated. 4124 This could have a serious affect on ability to deploy new services by 4125 customers, and would be a significant issue during disaster recovery. 4127 While the compromise of the MASA web service may lead to the 4128 compromise of the MASA voucher signing key, if the signing occurs 4129 offboard (such as in a hardware signing module, HSM), then the key 4130 may well be safe, but control over it resides with the attacker. 4132 Such an attacker can issue vouchers for any device presently in 4133 service. Said device still needs to be convinced to do through a 4134 factory reset process before an attack. 4136 If the attacker has access to a key that is trusted for long-lived 4137 nonceless vouchers, then they could issue vouchers for devices which 4138 are not yet in service. This attack may be very hard to verify and 4139 as it would involve doing firmware updates on every device in 4140 warehouses (a potentially ruinously expensive process), a 4141 manufacturer might be reluctant to admit this possibility. 4143 12. Acknowledgements 4145 We would like to thank the various reviewers for their input, in 4146 particular William Atwood, Brian Carpenter, Fuyu Eleven, Eliot Lear, 4147 Sergey Kasatkin, Anoop Kumar, Markus Stenberg, Peter van der Stok, 4148 and Thomas Werner 4150 Significant reviews were done by Jari Arko, Christian Huitema and 4151 Russ Housley. 4153 Henk Birkholz contributed the CDDL for the audit log response. 4155 This document started it's life as a two-page idea from Steinthor 4156 Bjarnason. 4158 In addition, significant review comments were received by many IESG 4159 members, including Adam Roach, Alexey Melnikov, Alissa Cooper, 4160 Benjamin Kaduk, Eric Vyncke, Roman Danyliw, and Magnus Westerlund. 4162 13. References 4164 13.1. Normative References 4166 [I-D.ietf-anima-autonomic-control-plane] 4167 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 4168 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 4169 plane-20 (work in progress), July 2019. 4171 [I-D.ietf-anima-grasp] 4172 Bormann, C., Carpenter, B., and B. Liu, "A Generic 4173 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 4174 grasp-15 (work in progress), July 2017. 4176 [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009, 4177 . 4180 [ITU.X690.1994] 4181 International Telecommunications Union, "Information 4182 Technology - ASN.1 encoding rules: Specification of Basic 4183 Encoding Rules (BER), Canonical Encoding Rules (CER) and 4184 Distinguished Encoding Rules (DER)", ITU-T Recommendation 4185 X.690, 1994. 4187 [REST] Fielding, R., "Architectural Styles and the Design of 4188 Network-based Software Architectures", 2000, 4189 . 4192 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4193 Requirement Levels", BCP 14, RFC 2119, 4194 DOI 10.17487/RFC2119, March 1997, 4195 . 4197 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 4198 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 4199 . 4201 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 4202 DOI 10.17487/RFC3688, January 2004, 4203 . 4205 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 4206 Levkowetz, Ed., "Extensible Authentication Protocol 4207 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 4208 . 4210 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 4211 Configuration of IPv4 Link-Local Addresses", RFC 3927, 4212 DOI 10.17487/RFC3927, May 2005, 4213 . 4215 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 4216 "Randomness Requirements for Security", BCP 106, RFC 4086, 4217 DOI 10.17487/RFC4086, June 2005, 4218 . 4220 [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol 4221 (LDAP): Schema for User Applications", RFC 4519, 4222 DOI 10.17487/RFC4519, June 2006, 4223 . 4225 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 4226 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 4227 . 4229 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 4230 Address Autoconfiguration", RFC 4862, 4231 DOI 10.17487/RFC4862, September 2007, 4232 . 4234 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 4235 Extensions for Stateless Address Autoconfiguration in 4236 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 4237 . 4239 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 4240 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 4241 . 4243 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 4244 Housley, R., and W. Polk, "Internet X.509 Public Key 4245 Infrastructure Certificate and Certificate Revocation List 4246 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 4247 . 4249 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 4250 Security: An Unauthenticated Mode of IPsec", RFC 5386, 4251 DOI 10.17487/RFC5386, November 2008, 4252 . 4254 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 4255 RFC 5652, DOI 10.17487/RFC5652, September 2009, 4256 . 4258 [RFC5660] Williams, N., "IPsec Channels: Connection Latching", 4259 RFC 5660, DOI 10.17487/RFC5660, October 2009, 4260 . 4262 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 4263 Extensions: Extension Definitions", RFC 6066, 4264 DOI 10.17487/RFC6066, January 2011, 4265 . 4267 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 4268 Verification of Domain-Based Application Service Identity 4269 within Internet Public Key Infrastructure Using X.509 4270 (PKIX) Certificates in the Context of Transport Layer 4271 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 4272 2011, . 4274 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 4275 DOI 10.17487/RFC6762, February 2013, 4276 . 4278 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 4279 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 4280 . 4282 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 4283 "Enrollment over Secure Transport", RFC 7030, 4284 DOI 10.17487/RFC7030, October 2013, 4285 . 4287 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 4288 Protocol (HTTP/1.1): Message Syntax and Routing", 4289 RFC 7230, DOI 10.17487/RFC7230, June 2014, 4290 . 4292 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 4293 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 4294 DOI 10.17487/RFC7231, June 2014, 4295 . 4297 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 4298 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 4299 2015, . 4301 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 4302 RFC 7950, DOI 10.17487/RFC7950, August 2016, 4303 . 4305 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 4306 RFC 7951, DOI 10.17487/RFC7951, August 2016, 4307 . 4309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 4310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 4311 May 2017, . 4313 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 4314 Interchange Format", STD 90, RFC 8259, 4315 DOI 10.17487/RFC8259, December 2017, 4316 . 4318 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 4319 "A Voucher Artifact for Bootstrapping Protocols", 4320 RFC 8366, DOI 10.17487/RFC8366, May 2018, 4321 . 4323 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 4324 Control Plane for Stable Connectivity of Network 4325 Operations, Administration, and Maintenance (OAM)", 4326 RFC 8368, DOI 10.17487/RFC8368, May 2018, 4327 . 4329 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 4330 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 4331 . 4333 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 4334 Definition Language (CDDL): A Notational Convention to 4335 Express Concise Binary Object Representation (CBOR) and 4336 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 4337 June 2019, . 4339 13.2. Informative References 4341 [brewski] "Urban Dictionary: Brewski", October 2019, 4342 . 4344 [cabforumaudit] 4345 "Information for Auditors and Assessors", August 2019, 4346 . 4349 [Dingledine2004] 4350 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the 4351 second-generation onion router", 2004, 4352 . 4354 [dnssecroot] 4355 "DNSSEC Practice Statement for the Root Zone ZSK 4356 Operator", December 2017, 4357 . 4360 [docsisroot] 4361 "CableLabs Digital Certificate Issuance Service", February 4362 2018, . 4365 [I-D.ietf-ace-coap-est] 4366 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 4367 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 4368 est-16 (work in progress), October 2019. 4370 [I-D.ietf-anima-constrained-voucher] 4371 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 4372 Voucher Artifacts for Bootstrapping Protocols", draft- 4373 ietf-anima-constrained-voucher-05 (work in progress), July 4374 2019. 4376 [I-D.ietf-anima-reference-model] 4377 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 4378 and J. Nobre, "A Reference Model for Autonomic 4379 Networking", draft-ietf-anima-reference-model-10 (work in 4380 progress), November 2018. 4382 [I-D.ietf-anima-stable-connectivity] 4383 Eckert, T. and M. Behringer, "Using Autonomic Control 4384 Plane for Stable Connectivity of Network OAM", draft-ietf- 4385 anima-stable-connectivity-10 (work in progress), February 4386 2018. 4388 [I-D.ietf-netconf-keystore] 4389 Watsen, K., "A YANG Data Model for a Keystore", draft- 4390 ietf-netconf-keystore-14 (work in progress), November 4391 2019. 4393 [I-D.richardson-anima-state-for-joinrouter] 4394 Richardson, M., "Considerations for stateful vs stateless 4395 join router in ANIMA bootstrap", draft-richardson-anima- 4396 state-for-joinrouter-02 (work in progress), January 2018. 4398 [imprinting] 4399 "Wikipedia article: Imprinting", July 2015, 4400 . 4402 [IoTstrangeThings] 4403 "IoT of toys stranger than fiction: Cybersecurity and data 4404 privacy update (accessed 2018-12-02)", March 2017, 4405 . 4408 [livingwithIoT] 4409 "What is it actually like to live in a house filled with 4410 IoT devices? (accessed 2018-12-02)", February 2018, 4411 . 4414 [openssl] "OpenSSL X509 utility", September 2019, 4415 . 4418 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 4419 Translator (NAT) Terminology and Considerations", 4420 RFC 2663, DOI 10.17487/RFC2663, August 1999, 4421 . 4423 [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. 4424 Tardo, "Network Endpoint Assessment (NEA): Overview and 4425 Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, 4426 . 4428 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 4429 Uniform Resource Identifiers (URIs)", RFC 5785, 4430 DOI 10.17487/RFC5785, April 2010, 4431 . 4433 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 4434 Galperin, S., and C. Adams, "X.509 Internet Public Key 4435 Infrastructure Online Certificate Status Protocol - OCSP", 4436 RFC 6960, DOI 10.17487/RFC6960, June 2013, 4437 . 4439 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 4440 Multiple Certificate Status Request Extension", RFC 6961, 4441 DOI 10.17487/RFC6961, June 2013, 4442 . 4444 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 4445 Constrained-Node Networks", RFC 7228, 4446 DOI 10.17487/RFC7228, May 2014, 4447 . 4449 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 4450 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 4451 2014, . 4453 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 4454 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 4455 December 2014, . 4457 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 4458 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 4459 Networking: Definitions and Design Goals", RFC 7575, 4460 DOI 10.17487/RFC7575, June 2015, 4461 . 4463 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 4464 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 4465 . 4467 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 4468 Description Specification", RFC 8520, 4469 DOI 10.17487/RFC8520, March 2019, 4470 . 4472 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 4473 Touch Provisioning (SZTP)", RFC 8572, 4474 DOI 10.17487/RFC8572, April 2019, 4475 . 4477 [slowloris] 4478 "Slowloris (computer security)", February 2019, 4479 . 4482 [softwareescrow] 4483 "Wikipedia article: Software Escrow", October 2019, 4484 . 4486 [Stajano99theresurrecting] 4487 Stajano, F. and R. Anderson, "The resurrecting duckling: 4488 security issues for ad-hoc wireless networks", 1999, 4489 . 4492 [TR069] "TR-69: CPE WAN Management Protocol", February 2018, 4493 . 4496 [W3C.WD-capability-urls-20140218] 4497 Tennison, J., "Good Practices for Capability URLs", World 4498 Wide Web Consortium WD WD-capability-urls-20140218, 4499 February 2014, 4500 . 4502 Appendix A. IPv4 and non-ANI operations 4504 The secification of BRSKI in Section 4 intentionally only covers the 4505 mechanisms for an IPv6 pledge using Link-Local addresses. This 4506 section describes non-normative extensions that can be used in other 4507 environments. 4509 A.1. IPv4 Link Local addresses 4511 Instead of an IPv6 link-local address, an IPv4 address may be 4512 generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local 4513 Addresses. 4515 In the case that an IPv4 Link-Local address is formed, then the 4516 bootstrap process would continue as in the IPv6 case by looking for a 4517 (circuit) proxy. 4519 A.2. Use of DHCPv4 4521 The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP 4522 provided parameters for the Domain Name System can be used to perform 4523 DNS operations if all local discovery attempts fail. 4525 Appendix B. mDNS / DNSSD proxy discovery options 4527 Pledge discovery of the proxy (Section 4.1) MAY be performed with 4528 DNS-based Service Discovery [RFC6763] over Multicast DNS [RFC6762] to 4529 discover the proxy at "_brski-proxy._tcp.local.". 4531 Proxy discovery of the registrar (Section 4.3) MAY be performed with 4532 DNS-based Service Discovery over Multicast DNS to discover registrars 4533 by searching for the service "_brski-registrar._tcp.local.". 4535 To prevent unaccceptable levels of network traffic, when using mDNS, 4536 the congestion avoidance mechanisms specified in [RFC6762] section 7 4537 MUST be followed. The pledge SHOULD listen for an unsolicited 4538 broadcast response as described in [RFC6762]. This allows devices to 4539 avoid announcing their presence via mDNS broadcasts and instead 4540 silently join a network by watching for periodic unsolicited 4541 broadcast responses. 4543 Discovery of registrar MAY also be performed with DNS-based service 4544 discovery by searching for the service "_brski- 4545 registrar._tcp.". In this case the domain "example.com" is 4546 discovered as described in [RFC6763] section 11 (Appendix A.2 4547 suggests the use of DHCP parameters). 4549 If no local proxy or registrar service is located using the GRASP 4550 mechanisms or the above mentioned DNS-based Service Discovery 4551 methods, the pledge MAY contact a well known manufacturer provided 4552 bootstrapping server by performing a DNS lookup using a well known 4553 URI such as "brski-registrar.manufacturer.example.com". The details 4554 of the URI are manufacturer specific. Manufacturers that leverage 4555 this method on the pledge are responsible for providing the registrar 4556 service. Also see Section 2.7. 4558 The current DNS services returned during each query are maintained 4559 until bootstrapping is completed. If bootstrapping fails and the 4560 pledge returns to the Discovery state, it picks up where it left off 4561 and continues attempting bootstrapping. For example, if the first 4562 Multicast DNS _bootstrapks._tcp.local response doesn't work then the 4563 second and third responses are tried. If these fail the pledge moves 4564 on to normal DNS-based Service Discovery. 4566 Appendix C. MUD Extension 4568 The following extension augments the MUD model to include a single 4569 node, as described in [RFC8520] section 3.6, using the following 4570 sample module that has the following tree structure: 4572 module: ietf-mud-brski-masa 4573 augment /ietf-mud:mud: 4574 +--rw masa-server? inet:uri 4576 The model is defined as follows: 4578 file "ietf-mud-brski-masaurl-extension@2018-02-14.yang" 4579 module ietf-mud-brski-masa { 4580 yang-version 1.1; 4581 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa"; 4582 prefix ietf-mud-brski-masa; 4583 import ietf-mud { 4584 prefix ietf-mud; 4585 } 4586 import ietf-inet-types { 4587 prefix inet; 4588 } 4590 organization 4591 "IETF ANIMA (Autonomic Networking Integrated Model and 4592 Approach) Working Group"; 4593 contact 4594 "WG Web: http://tools.ietf.org/wg/anima/ 4595 WG List: anima@ietf.org 4596 "; 4597 description 4598 "BRSKI extension to a MUD file to indicate the 4599 MASA URL."; 4601 revision 2018-02-14 { 4602 description 4603 "Initial revision."; 4604 reference 4605 "RFC XXXX: Manufacturer Usage Description 4606 Specification"; 4607 } 4609 augment "/ietf-mud:mud" { 4610 description 4611 "BRSKI extension to a MUD file to indicate the 4612 MASA URL."; 4613 leaf masa-server { 4614 type inet:uri; 4615 description 4616 "This value is the URI of the MASA server"; 4617 } 4618 } 4619 } 4620 4622 The MUD extensions string "masa" is defined, and MUST be included in 4623 the extensions array of the mud container of a MUD file when this 4624 extension is used. 4626 Appendix D. Example Vouchers 4628 Three entities are involved in a voucher: the MASA issues (signs) it, 4629 the registrar's public key is mentioned in the voucher, and the 4630 pledge validates it. In order to provide reproduceable examples the 4631 public and private keys for an example MASA and registrar are first 4632 listed. 4634 D.1. Keys involved 4636 The Manufacturer has a Certificate Authority that signs the pledge's 4637 IDevID. In addition the Manufacturer's signing authority (the MASA) 4638 signs the vouchers, and that certificate must distributed to the 4639 devices at manufacturing time so that vouchers can be validated. 4641 D.1.1. MASA key pair for voucher signatures 4643 This private key signs vouchers: 4645 -----BEGIN EC PRIVATE KEY----- 4646 MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho 4647 r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA 4648 zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz 4649 Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= 4650 -----END EC PRIVATE KEY----- 4652 This public key validates vouchers: 4654 -----BEGIN CERTIFICATE----- 4655 MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 4656 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 4657 IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw 4658 EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU 4659 BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R 4660 b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf 4661 w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO 4662 MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O 4663 DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd 4664 MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= 4665 -----END CERTIFICATE----- 4667 D.1.2. Manufacturer key pair for IDevID signatures 4669 This private key signs IDevID certificates: 4671 -----BEGIN EC PRIVATE KEY----- 4672 MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho 4673 r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA 4674 zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz 4675 Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= 4676 -----END EC PRIVATE KEY----- 4678 This public key validates IDevID certificates: 4680 -----BEGIN CERTIFICATE----- 4681 MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 4682 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 4683 IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw 4684 EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU 4685 BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R 4686 b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf 4687 w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO 4688 MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O 4689 DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd 4690 MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= 4691 -----END CERTIFICATE----- 4693 D.1.3. Registrar key pair 4695 The registrar key (or chain) is the representative of the domain 4696 owner. This key signs registrar voucher-requests: 4698 -----BEGIN EC PRIVATE KEY----- 4699 MHcCAQEEIF+obiToYYYeMifPsZvrjWJ0yFsCJwIFhpokmT/TULmXoAoGCCqGSM49 4700 AwEHoUQDQgAENWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g 4701 6W/P6boTmyTGdFOh/8HwKUerL5bpneK8sg== 4702 -----END EC PRIVATE KEY----- 4704 The public key is indicated in a pledge voucher-request to show 4705 proximity. 4707 -----BEGIN CERTIFICATE----- 4708 MIIBrjCCATOgAwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQBGRYC 4709 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5n 4710 IEZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQzES 4711 MBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRIw 4712 EAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ1ZA7N 4713 w0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8/puhObJMZ0U6H/ 4714 wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM49BAMDA2kAMGYCMQC3 4715 /iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nuNifVKtyaara3F30AIkKSEC 4716 MQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdDCR54TrSFNLgxvt1lyFM+0fYpYR 4717 c3o= 4718 -----END CERTIFICATE----- 4719 The registrar public certificate as decoded by openssl's x509 4720 utility. Note that the registrar certificate is marked with the 4721 cmcRA extension. 4723 Certificate: 4724 Data: 4725 Version: 3 (0x2) 4726 Serial Number: 3 (0x3) 4727 Signature Algorithm: ecdsa-with-SHA384 4728 Issuer: DC = ca, DC = sandelman, CN = Unstrung Fount 4729 ain CA 4730 Validity 4731 Not Before: Sep 5 01:12:45 2017 GMT 4732 Not After : Sep 5 01:12:45 2019 GMT 4733 Subject: DC = ca, DC = sandelman, CN = localhost 4734 Subject Public Key Info: 4735 Public Key Algorithm: id-ecPublicKey 4736 Public-Key: (256 bit) 4737 pub: 4738 04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7 4739 8:17: 4740 34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5 4741 3:3e: 4742 03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e 4743 9:ba: 4744 13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2 4745 f:96: 4746 e9:9d:e2:bc:b2 4747 ASN1 OID: prime256v1 4748 NIST CURVE: P-256 4749 X509v3 extensions: 4750 X509v3 Basic Constraints: 4751 CA:FALSE 4752 Signature Algorithm: ecdsa-with-SHA384 4753 30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78: 4754 5b: 4755 9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e: 4756 b6: 4757 9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21: 4758 02: 4759 31:00:e2:db:d7:9f:6d:32:db:76:d0:e4:de:d7:9c:63:fa: 4760 c3: 4761 ed:5e:fb:5d:a2:7a:9d:80:a6:74:30:91:e7:84:eb:48:53: 4762 4b: 4763 83:1b:ed:d6:5c:85:33:ed:1f:62:96:11:73:7a 4765 D.1.4. Pledge key pair 4767 The pledge has an IDevID key pair built in at manufacturing time: 4769 -----BEGIN EC PRIVATE KEY----- 4770 MHcCAQEEIBgR6SV+uEvWfl5zCQWZxWjYbMhXPyNqdHJ3KPh11mm4oAoGCCqGSM49 4771 AwEHoUQDQgAEWi/jqPpRJ0JgWghZRgeZlLKutbXVjmnHb+1AYaEF/YQjE2g5FZV8 4772 KjiR/bkEl+l8M4onIC7KHaXKKkuag9S6Tw== 4773 -----END EC PRIVATE KEY----- 4775 The public key is used by the registrar to find the MASA. The MASA 4776 URL is in an extension described in Section 2.3. 4778 -----BEGIN CERTIFICATE----- 4779 MIICBDCCAYugAwIBAgIECe20qTAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQB 4780 GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3Ry 4781 dW5nIEhpZ2h3YXkgQ0EwIBcNMTkwNDI0MDIxNjU4WhgPMjk5OTEyMzEwMDAwMDBa 4782 MBwxGjAYBgNVBAUMETAwLWQwLWU1LTAyLTAwLTJkMFkwEwYHKoZIzj0CAQYIKoZI 4783 zj0DAQcDQgAEWi/jqPpRJ0JgWghZRgeZlLKutbXVjmnHb+1AYaEF/YQjE2g5FZV8 4784 KjiR/bkEl+l8M4onIC7KHaXKKkuag9S6T6OBhzCBhDAdBgNVHQ4EFgQUj8KYdUoE 4785 OvJ0kcOIbjEWwgWdDYkwCQYDVR0TBAIwADArBgNVHREEJDAioCAGCSsGAQQBgu5S 4786 AaATDBEwMC1EMC1FNS0wMi0wMC0yRDArBgkrBgEEAYLuUgIEHgwcbWFzYS5ob25l 4787 eWR1a2VzLnNhbmRlbG1hbi5jYTAKBggqhkjOPQQDAgNnADBkAjAmvMjmNgjypDhc 4788 fynMV3kMuIpSKrYzRWr4g3PtTwXDsAe0oitTTj4QtU1bajhOfTkCMGMNbsW2Q41F 4789 z9t6PDVdtOKabBbAP1RVoFTlDQuO9nmLzb5kU+cUqCtPRFZBUXP3kg== 4790 -----END CERTIFICATE----- 4792 The pledge public certificate as decoded by openssl's x509 utility so 4793 that the extensions can be seen. This was version 1.1.1c of the 4794 [openssl] library and utility. There is a second Custom Extension is 4795 included to provided to contain the EUI48/EUI64 that the pledge will 4796 configure as it's layer-2 address (this is non-normative). 4798 Certificate: 4799 Data: 4800 Version: 3 (0x2) 4801 Serial Number: 166573225 (0x9edb4a9) 4802 Signature Algorithm: ecdsa-with-SHA256 4803 Issuer: DC = ca, DC = sandelman, CN = Unstrung Highway CA 4804 Validity 4805 Not Before: Apr 24 02:16:58 2019 GMT 4806 Not After : Dec 31 00:00:00 2999 GMT 4807 Subject: serialNumber = 00-d0-e5-02-00-2d 4808 Subject Public Key Info: 4809 Public Key Algorithm: id-ecPublicKey 4810 Public-Key: (256 bit) 4811 pub: 4812 04:5a:2f:e3:a8:fa:51:27:42:60:5a:08:59:46:07: 4813 99:94:b2:ae:b5:b5:d5:8e:69:c7:6f:ed:40:61:a1: 4814 05:fd:84:23:13:68:39:15:95:7c:2a:38:91:fd:b9: 4815 04:97:e9:7c:33:8a:27:20:2e:ca:1d:a5:ca:2a:4b: 4816 9a:83:d4:ba:4f 4817 ASN1 OID: prime256v1 4818 NIST CURVE: P-256 4819 X509v3 extensions: 4820 X509v3 Subject Key Identifier: 4821 8F:C2:98:75:4A:04:3A:F2:74:91:C3:88:6E:31:16:C2:05:9D:0D:89 4822 X509v3 Basic Constraints: 4823 CA:FALSE 4824 X509v3 Subject Alternative Name: 4825 othername: 4826 1.3.6.1.4.1.46930.2: 4827 ..masa.honeydukes.sandelman.ca 4828 Signature Algorithm: ecdsa-with-SHA256 4829 30:64:02:30:26:bc:c8:e6:36:08:f2:a4:38:5c:7f:29:cc:57: 4830 79:0c:b8:8a:52:2a:b6:33:45:6a:f8:83:73:ed:4f:05:c3:b0: 4831 07:b4:a2:2b:53:4e:3e:10:b5:4d:5b:6a:38:4e:7d:39:02:30: 4832 63:0d:6e:c5:b6:43:8d:45:cf:db:7a:3c:35:5d:b4:e2:9a:6c: 4833 16:c0:3f:54:55:a0:54:e5:0d:0b:8e:f6:79:8b:cd:be:64:53: 4834 e7:14:a8:2b:4f:44:56:41:51:73:f7:92 4836 D.2. Example process 4838 The JSON examples below are wrapped at 60 columns. This results in 4839 strings that have newlines in them, which makes them invalid JSON as 4840 is. The strings would otherwise be too long, so they need to be 4841 unwrapped before processing. 4843 D.2.1. Pledge to Registrar 4845 As described in Section 5.2, the pledge will sign a pledge voucher- 4846 request containing the registrar's public key in the proximity- 4847 registrar-cert field. The base64 has been wrapped at 60 characters 4848 for presentation reasons. 4850 -----BEGIN CMS----- 4851 MIIGtQYJKoZIhvcNAQcCoIIGpjCCBqICAQExDTALBglghkgBZQMEAgEwggNRBgkq 4852 hkiG9w0BBwGgggNCBIIDPnsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6 4853 eyJhc3NlcnRpb24iOiJwcm94aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAxOS0wNS0x 4854 NVQxNzoyNTo1NS42NDQtMDQ6MDAiLCJzZXJpYWwtbnVtYmVyIjoiMDAtZDAtZTUt 4855 MDItMDAtMmQiLCJub25jZSI6IlZPVUZULVd3ckV2ME51QVFFSG9WN1EiLCJwcm94 4856 aW1pdHktcmVnaXN0cmFyLWNlcnQiOiJNSUlCMFRDQ0FWYWdBd0lCQWdJQkFqQUtC 4857 Z2dxaGtqT1BRUURBekJ4TVJJd0VBWUtDWkltaVpQeUxHUUJHUllDWTJFeEdUQVhC 4858 Z29Ka2lhSmsvSXNaQUVaRmdsellXNWtaV3h0WVc0eFFEQStCZ05WQkFNTU55TThV 4859 M2x6ZEdWdFZtRnlhV0ZpYkdVNk1IZ3dNREF3TURBd05HWTVNVEZoTUQ0Z1ZXNXpk 4860 SEoxYm1jZ1JtOTFiblJoYVc0Z1EwRXdIaGNOTVRjeE1UQTNNak0wTlRJNFdoY05N 4861 VGt4TVRBM01qTTBOVEk0V2pCRE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhH 4862 VEFYQmdvSmtpYUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhFakFRQmdOVkJBTU1D 4863 V3h2WTJGc2FHOXpkREJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFC 4864 SlpsVUhJMHVwL2wzZVpmOXZDQmIrbElub0VNRWdjN1JvK1haQ3RqQUkwQ0QxZkpm 4865 SlIvaEl5eURtSFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFqRFRBTE1Ba0dB 4866 MVVkRXdRQ01BQXdDZ1lJS29aSXpqMEVBd01EYVFBd1pnSXhBTFFNTnVyZjh0djUw 4867 bFJPRDVEUVhIRU9KSk5XM1FWMmc5UUVkRFNrMk1ZK0FvU3JCU21HU05qaDRvbEVP 4868 aEV1TGdJeEFKNG5XZk53K0JqYlptS2lJaVVFY1R3SE1oR1ZYYU1IWS9GN24zOXd3 4869 S2NCQlNPbmROUHFDcE9FTGw2YnEzQ1pxUT09In19oIICCDCCAgQwggGLoAMCAQIC 4870 BAnttKkwCgYIKoZIzj0EAwIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZIm 4871 iZPyLGQBGRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdod2F5IENB 4872 MCAXDTE5MDQyNDAyMTY1OFoYDzI5OTkxMjMxMDAwMDAwWjAcMRowGAYDVQQFDBEw 4873 MC1kMC1lNS0wMi0wMC0yZDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABFov46j6 4874 USdCYFoIWUYHmZSyrrW11Y5px2/tQGGhBf2EIxNoORWVfCo4kf25BJfpfDOKJyAu 4875 yh2lyipLmoPUuk+jgYcwgYQwHQYDVR0OBBYEFI/CmHVKBDrydJHDiG4xFsIFnQ2J 4876 MAkGA1UdEwQCMAAwKwYDVR0RBCQwIqAgBgkrBgEEAYLuUgGgEwwRMDAtRDAtRTUt 4877 MDItMDAtMkQwKwYJKwYBBAGC7lICBB4MHG1hc2EuaG9uZXlkdWtlcy5zYW5kZWxt 4878 YW4uY2EwCgYIKoZIzj0EAwIDZwAwZAIwJrzI5jYI8qQ4XH8pzFd5DLiKUiq2M0Vq 4879 +INz7U8Fw7AHtKIrU04+ELVNW2o4Tn05AjBjDW7FtkONRc/bejw1XbTimmwWwD9U 4880 VaBU5Q0LjvZ5i82+ZFPnFKgrT0RWQVFz95IxggErMIIBJwIBATBVME0xEjAQBgoJ 4881 kiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEcMBoGA1UE 4882 AwwTVW5zdHJ1bmcgSGlnaHdheSBDQQIECe20qTALBglghkgBZQMEAgGgaTAYBgkq 4883 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA1MTUyMTI1 4884 NTVaMC8GCSqGSIb3DQEJBDEiBCAQN2lP7aqwyhmj9qUHt6Qk/SbOTOPXFOwn1wv2 4885 5YGYgDAKBggqhkjOPQQDAgRHMEUCIEYQhHToU0rrhPyQv2fR0TwWePTx2Z1DEhR4 4886 tTl/Dr/ZAiEA47u9+bIz/p6nFJ+wctKHER+ycUzYQF56h9odMo+Ilkc= 4887 -----END CMS----- 4889 file: examples/vr_00-D0-E5-02-00-2D.pkcs 4890 The ASN1 decoding of the artifact: 4892 0:d=0 hl=4 l=1717 cons: SEQUENCE 4893 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData 4894 15:d=1 hl=4 l=1702 cons: cont [ 0 ] 4895 19:d=2 hl=4 l=1698 cons: SEQUENCE 4896 23:d=3 hl=2 l= 1 prim: INTEGER :01 4897 26:d=3 hl=2 l= 13 cons: SET 4898 28:d=4 hl=2 l= 11 cons: SEQUENCE 4899 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 4900 41:d=3 hl=4 l= 849 cons: SEQUENCE 4901 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 4902 56:d=4 hl=4 l= 834 cons: cont [ 0 ] 4903 60:d=5 hl=4 l= 830 prim: OCTET STRING :{"ietf-voucher-request:v 4904 894:d=3 hl=4 l= 520 cons: cont [ 0 ] 4905 898:d=4 hl=4 l= 516 cons: SEQUENCE 4906 902:d=5 hl=4 l= 395 cons: SEQUENCE 4907 906:d=6 hl=2 l= 3 cons: cont [ 0 ] 4908 908:d=7 hl=2 l= 1 prim: INTEGER :02 4909 911:d=6 hl=2 l= 4 prim: INTEGER :09EDB4A9 4910 917:d=6 hl=2 l= 10 cons: SEQUENCE 4911 919:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 4912 929:d=6 hl=2 l= 77 cons: SEQUENCE 4913 931:d=7 hl=2 l= 18 cons: SET 4914 933:d=8 hl=2 l= 16 cons: SEQUENCE 4915 935:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 4916 947:d=9 hl=2 l= 2 prim: IA5STRING :ca 4917 951:d=7 hl=2 l= 25 cons: SET 4918 953:d=8 hl=2 l= 23 cons: SEQUENCE 4919 955:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 4920 967:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4921 978:d=7 hl=2 l= 28 cons: SET 4922 980:d=8 hl=2 l= 26 cons: SEQUENCE 4923 982:d=9 hl=2 l= 3 prim: OBJECT :commonName 4924 987:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Highway CA 4925 1008:d=6 hl=2 l= 32 cons: SEQUENCE 4926 1010:d=7 hl=2 l= 13 prim: UTCTIME :190424021658Z 4927 1025:d=7 hl=2 l= 15 prim: GENERALIZEDTIME :29991231000000Z 4928 1042:d=6 hl=2 l= 28 cons: SEQUENCE 4929 1044:d=7 hl=2 l= 26 cons: SET 4930 1046:d=8 hl=2 l= 24 cons: SEQUENCE 4931 1048:d=9 hl=2 l= 3 prim: OBJECT :serialNumber 4932 1053:d=9 hl=2 l= 17 prim: UTF8STRING :00-d0-e5-02-00-2d 4933 1072:d=6 hl=2 l= 89 cons: SEQUENCE 4934 1074:d=7 hl=2 l= 19 cons: SEQUENCE 4935 1076:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 4936 1085:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 4937 1095:d=7 hl=2 l= 66 prim: BIT STRING 4938 1163:d=6 hl=3 l= 135 cons: cont [ 3 ] 4939 1166:d=7 hl=3 l= 132 cons: SEQUENCE 4940 1169:d=8 hl=2 l= 29 cons: SEQUENCE 4941 1171:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident 4942 1176:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:04148FC298754A 4943 1200:d=8 hl=2 l= 9 cons: SEQUENCE 4944 1202:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 4945 1207:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 4946 1211:d=8 hl=2 l= 43 cons: SEQUENCE 4947 1213:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Alternati 4948 1218:d=9 hl=2 l= 36 prim: OCTET STRING [HEX DUMP]:3022A02006092B 4949 1256:d=8 hl=2 l= 43 cons: SEQUENCE 4950 1258:d=9 hl=2 l= 9 prim: OBJECT :1.3.6.1.4.1.46930.2 4951 1269:d=9 hl=2 l= 30 prim: OCTET STRING [HEX DUMP]:0C1C6D6173612E 4952 1301:d=5 hl=2 l= 10 cons: SEQUENCE 4953 1303:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 4954 1313:d=5 hl=2 l= 103 prim: BIT STRING 4955 1418:d=3 hl=4 l= 299 cons: SET 4956 1422:d=4 hl=4 l= 295 cons: SEQUENCE 4957 1426:d=5 hl=2 l= 1 prim: INTEGER :01 4958 1429:d=5 hl=2 l= 85 cons: SEQUENCE 4959 1431:d=6 hl=2 l= 77 cons: SEQUENCE 4960 1433:d=7 hl=2 l= 18 cons: SET 4961 1435:d=8 hl=2 l= 16 cons: SEQUENCE 4962 1437:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 4963 1449:d=9 hl=2 l= 2 prim: IA5STRING :ca 4964 1453:d=7 hl=2 l= 25 cons: SET 4965 1455:d=8 hl=2 l= 23 cons: SEQUENCE 4966 1457:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 4967 1469:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4968 1480:d=7 hl=2 l= 28 cons: SET 4969 1482:d=8 hl=2 l= 26 cons: SEQUENCE 4970 1484:d=9 hl=2 l= 3 prim: OBJECT :commonName 4971 1489:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Highway CA 4972 1510:d=6 hl=2 l= 4 prim: INTEGER :09EDB4A9 4973 1516:d=5 hl=2 l= 11 cons: SEQUENCE 4974 1518:d=6 hl=2 l= 9 prim: OBJECT :sha256 4975 1529:d=5 hl=2 l= 105 cons: cont [ 0 ] 4976 1531:d=6 hl=2 l= 24 cons: SEQUENCE 4977 1533:d=7 hl=2 l= 9 prim: OBJECT :contentType 4978 1544:d=7 hl=2 l= 11 cons: SET 4979 1546:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 4980 1557:d=6 hl=2 l= 28 cons: SEQUENCE 4981 1559:d=7 hl=2 l= 9 prim: OBJECT :signingTime 4982 1570:d=7 hl=2 l= 15 cons: SET 4983 1572:d=8 hl=2 l= 13 prim: UTCTIME :190515212555Z 4984 1587:d=6 hl=2 l= 47 cons: SEQUENCE 4985 1589:d=7 hl=2 l= 9 prim: OBJECT :messageDigest 4986 1600:d=7 hl=2 l= 34 cons: SET 4987 1602:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:1037694FEDAAB0 4988 1636:d=5 hl=2 l= 10 cons: SEQUENCE 4989 1638:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 4990 1648:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30450220461084 4992 The JSON contained in the voucher request: 4994 {"ietf-voucher-request:voucher":{"assertion":"proximity","cr 4995 eated-on":"2019-05-15T17:25:55.644-04:00","serial-number":"0 4996 0-d0-e5-02-00-2d","nonce":"VOUFT-WwrEv0NuAQEHoV7Q","proximit 4997 y-registrar-cert":"MIIB0TCCAVagAwIBAgIBAjAKBggqhkjOPQQDAzBxM 4998 RIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtY 4999 W4xQDA+BgNVBAMMNyM8U3lzdGVtVmFyaWFibGU6MHgwMDAwMDAwNGY5MTFhM 5000 D4gVW5zdHJ1bmcgRm91bnRhaW4gQ0EwHhcNMTcxMTA3MjM0NTI4WhcNMTkxM 5001 TA3MjM0NTI4WjBDMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZ 5002 AEZFglzYW5kZWxtYW4xEjAQBgNVBAMMCWxvY2FsaG9zdDBZMBMGByqGSM49A 5003 gEGCCqGSM49AwEHA0IABJZlUHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjA 5004 I0CD1fJfJR/hIyyDmHWyYiNFbRCH9fyarfkzgX4p0zTizqjDTALMAkGA1UdE 5005 wQCMAAwCgYIKoZIzj0EAwMDaQAwZgIxALQMNurf8tv50lROD5DQXHEOJJNW3 5006 QV2g9QEdDSk2MY+AoSrBSmGSNjh4olEOhEuLgIxAJ4nWfNw+BjbZmKiIiUEc 5007 TwHMhGVXaMHY/F7n39wwKcBBSOndNPqCpOELl6bq3CZqQ=="}} 5009 D.2.2. Registrar to MASA 5011 As described in Section 5.5 the registrar will sign a registrar 5012 voucher-request, and will include pledge's voucher request in the 5013 prior-signed-voucher-request. 5015 -----BEGIN CMS----- 5016 MIIPkwYJKoZIhvcNAQcCoIIPhDCCD4ACAQExDTALBglghkgBZQMEAgEwggnUBgkq 5017 hkiG9w0BBwGgggnFBIIJwXsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6 5018 eyJhc3NlcnRpb24iOiJwcm94aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAxOS0wNS0x 5019 NVQyMToyNTo1NS43NThaIiwic2VyaWFsLW51bWJlciI6IjAwLWQwLWU1LTAyLTAw 5020 LTJkIiwibm9uY2UiOiJWT1VGVC1Xd3JFdjBOdUFRRUhvVjdRIiwicHJpb3Itc2ln 5021 bmVkLXZvdWNoZXItcmVxdWVzdCI6Ik1JSUd0UVlKS29aSWh2Y05BUWNDb0lJR3Bq 5022 Q0NCcUlDQVFFeERUQUxCZ2xnaGtnQlpRTUVBZ0V3Z2dOUkJna3Foa2lHOXcwQkJ3 5023 R2dnZ05DQklJRFBuc2lhV1YwWmkxMmIzVmphR1Z5TFhKbGNYVmxjM1E2ZG05MVky 5024 aGxjaUk2ZXlKaGMzTmxjblJwYjI0aU9pSndjbTk0YVcxcGRIa2lMQ0pqY21WaGRH 5025 VmtMVzl1SWpvaU1qQXhPUzB3TlMweE5WUXhOem95TlRvMU5TNDJORFF0TURRNk1E 5026 QWlMQ0p6WlhKcFlXd3RiblZ0WW1WeUlqb2lNREF0WkRBdFpUVXRNREl0TURBdE1t 5027 UWlMQ0p1YjI1alpTSTZJbFpQVlVaVUxWZDNja1YyTUU1MVFWRkZTRzlXTjFFaUxD 5028 SndjbTk0YVcxcGRIa3RjbVZuYVhOMGNtRnlMV05sY25RaU9pSk5TVWxDTUZSRFEw 5029 RldZV2RCZDBsQ1FXZEpRa0ZxUVV0Q1oyZHhhR3RxVDFCUlVVUkJla0o0VFZKSmQw 5030 VkJXVXREV2tsdGFWcFFlVXhIVVVKSFVsbERXVEpGZUVkVVFWaENaMjlLYTJsaFNt 5031 c3ZTWE5hUVVWYVJtZHNlbGxYTld0YVYzaDBXVmMwZUZGRVFTdENaMDVXUWtGTlRV 5032 NTVUVGhWTTJ4NlpFZFdkRlp0Um5saFYwWnBZa2RWTmsxSVozZE5SRUYzVFVSQmQw 5033 NUhXVFZOVkVab1RVUTBaMVpYTlhwa1NFb3hZbTFqWjFKdE9URmlibEpvWVZjMFox 5034 RXdSWGRJYUdOT1RWUmplRTFVUVROTmFrMHdUbFJKTkZkb1kwNU5WR3Q0VFZSQk0w 5035 MXFUVEJPVkVrMFYycENSRTFTU1hkRlFWbExRMXBKYldsYVVIbE1SMUZDUjFKWlEx 5036 a3lSWGhIVkVGWVFtZHZTbXRwWVVwckwwbHpXa0ZGV2tabmJIcFpWelZyV2xkNGRG 5037 bFhOSGhGYWtGUlFtZE9Wa0pCVFUxRFYzaDJXVEpHYzJGSE9YcGtSRUphVFVKTlIw 5038 SjVjVWRUVFRRNVFXZEZSME5EY1VkVFRUUTVRWGRGU0VFd1NVRkNTbHBzVlVoSk1I 5039 VndMMnd6WlZwbU9YWkRRbUlyYkVsdWIwVk5SV2RqTjFKdksxaGFRM1JxUVVrd1Ew 5040 UXhaa3BtU2xJdmFFbDVlVVJ0U0ZkNVdXbE9SbUpTUTBnNVpubGhjbVpyZW1kWU5I 5041 QXdlbFJwZW5GcVJGUkJURTFCYTBkQk1WVmtSWGRSUTAxQlFYZERaMWxKUzI5YVNY 5042 cHFNRVZCZDAxRVlWRkJkMXBuU1hoQlRGRk5UblZ5WmpoMGRqVXdiRkpQUkRWRVVW 5043 aElSVTlLU2s1WE0xRldNbWM1VVVWa1JGTnJNazFaSzBGdlUzSkNVMjFIVTA1cWFE 5044 UnZiRVZQYUVWMVRHZEplRUZLTkc1WFprNTNLMEpxWWxwdFMybEphVlZGWTFSM1NF 5045 MW9SMVpZWVUxSVdTOUdOMjR6T1hkM1MyTkNRbE5QYm1ST1VIRkRjRTlGVEd3Mllu 5046 RXpRMXB4VVQwOUluMTlvSUlDQ0RDQ0FnUXdnZ0dMb0FNQ0FRSUNCQW50dEtrd0Nn 5047 WUlLb1pJemowRUF3SXdUVEVTTUJBR0NnbVNKb21UOGl4a0FSa1dBbU5oTVJrd0Z3 5048 WUtDWkltaVpQeUxHUUJHUllKYzJGdVpHVnNiV0Z1TVJ3d0dnWURWUVFEREJOVmJu 5049 TjBjblZ1WnlCSWFXZG9kMkY1SUVOQk1DQVhEVEU1TURReU5EQXlNVFkxT0ZvWUR6 5050 STVPVGt4TWpNeE1EQXdNREF3V2pBY01Sb3dHQVlEVlFRRkRCRXdNQzFrTUMxbE5T 5051 MHdNaTB3TUMweVpEQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJG 5052 b3Y0Nmo2VVNkQ1lGb0lXVVlIbVpTeXJyVzExWTVweDIvdFFHR2hCZjJFSXhOb09S 5053 V1ZmQ280a2YyNUJKZnBmRE9LSnlBdXloMmx5aXBMbW9QVXVrK2pnWWN3Z1lRd0hR 5054 WURWUjBPQkJZRUZJL0NtSFZLQkRyeWRKSERpRzR4RnNJRm5RMkpNQWtHQTFVZEV3 5055 UUNNQUF3S3dZRFZSMFJCQ1F3SXFBZ0Jna3JCZ0VFQVlMdVVnR2dFd3dSTURBdFJE 5056 QXRSVFV0TURJdE1EQXRNa1F3S3dZSkt3WUJCQUdDN2xJQ0JCNE1IRzFoYzJFdWFH 5057 OXVaWGxrZFd0bGN5NXpZVzVrWld4dFlXNHVZMkV3Q2dZSUtvWkl6ajBFQXdJRFp3 5058 QXdaQUl3SnJ6STVqWUk4cVE0WEg4cHpGZDVETGlLVWlxMk0wVnErSU56N1U4Rnc3 5059 QUh0S0lyVTA0K0VMVk5XMm80VG4wNUFqQmpEVzdGdGtPTlJjL2JlancxWGJUaW1t 5060 d1d3RDlVVmFCVTVRMExqdlo1aTgyK1pGUG5GS2dyVDBSV1FWRno5NUl4Z2dFck1J 5061 SUJKd0lCQVRCVk1FMHhFakFRQmdvSmtpYUprL0lzWkFFWkZnSmpZVEVaTUJjR0Nn 5062 bVNKb21UOGl4a0FSa1dDWE5oYm1SbGJHMWhiakVjTUJvR0ExVUVBd3dUVlc1emRI 5063 SjFibWNnU0dsbmFIZGhlU0JEUVFJRUNlMjBxVEFMQmdsZ2hrZ0JaUU1FQWdHZ2FU 5064 QVlCZ2txaGtpRzl3MEJDUU14Q3dZSktvWklodmNOQVFjQk1Cd0dDU3FHU0liM0RR 5065 RUpCVEVQRncweE9UQTFNVFV5TVRJMU5UVmFNQzhHQ1NxR1NJYjNEUUVKQkRFaUJD 5066 QVFOMmxQN2Fxd3lobWo5cVVIdDZRay9TYk9UT1BYRk93bjF3djI1WUdZZ0RBS0Jn 5067 Z3Foa2pPUFFRREFnUkhNRVVDSUVZUWhIVG9VMHJyaFB5UXYyZlIwVHdXZVBUeDJa 5068 MURFaFI0dFRsL0RyL1pBaUVBNDd1OStiSXovcDZuRkord2N0S0hFUit5Y1V6WVFG 5069 NTZoOW9kTW8rSWxrYz0ifX2gggRCMIIB0TCCAVagAwIBAgIBAjAKBggqhkjOPQQD 5070 AzBxMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxt 5071 YW4xQDA+BgNVBAMMNyM8U3lzdGVtVmFyaWFibGU6MHgwMDAwMDAwNGY5MTFhMD4g 5072 VW5zdHJ1bmcgRm91bnRhaW4gQ0EwHhcNMTcxMTA3MjM0NTI4WhcNMTkxMTA3MjM0 5073 NTI4WjBDMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5k 5074 ZWxtYW4xEjAQBgNVBAMMCWxvY2FsaG9zdDBZMBMGByqGSM49AgEGCCqGSM49AwEH 5075 A0IABJZlUHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHW 5076 yYiNFbRCH9fyarfkzgX4p0zTizqjDTALMAkGA1UdEwQCMAAwCgYIKoZIzj0EAwMD 5077 aQAwZgIxALQMNurf8tv50lROD5DQXHEOJJNW3QV2g9QEdDSk2MY+AoSrBSmGSNjh 5078 4olEOhEuLgIxAJ4nWfNw+BjbZmKiIiUEcTwHMhGVXaMHY/F7n39wwKcBBSOndNPq 5079 CpOELl6bq3CZqTCCAmkwggHvoAMCAQICAQMwCgYIKoZIzj0EAwIwbTESMBAGCgmS 5080 JomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMTwwOgYDVQQD 5081 DDNmb3VudGFpbi10ZXN0LmV4YW1wbGUuY29tIFVuc3RydW5nIEZvdW50YWluIFJv 5082 b3QgQ0EwHhcNMTkwMTEzMjI1NDQ0WhcNMjEwMTEyMjI1NDQ0WjBtMRIwEAYKCZIm 5083 iZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xPDA6BgNVBAMM 5084 M2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9v 5085 dCBDQTB2MBAGByqGSM49AgEGBSuBBAAiA2IABBt/WboXwxq8Zo2MbODD+jFxD2X2 5086 IpG9t1aAB9vfuHqlRU15ikaXGVmWMbGPaX0yvjzIPltjtUb2qNVvm/nA89O5FD9y 5087 R1Gkdt3S8L/1yo8wAX/4wl/T9SADRIuL8gdstKNjMGEwDwYDVR0TAQH/BAUwAwEB 5088 /zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLml9ssR4QekSSynCMZ8ELyHs3Qm 5089 MB8GA1UdIwQYMBaAFLml9ssR4QekSSynCMZ8ELyHs3QmMAoGCCqGSM49BAMCA2gA 5090 MGUCMAviLdbfd6AZdsOxNgf7D15WFmGC1JkHeEbT/0w4UXz6q/48S71/IMbSXRWH 5091 aNxiJwIxAOCRjtlN+VSmCLTvWwMTxnSpIuqMr/O1y2Z8rl459VRFphWPdbf4i0qE 5092 cwu0u4JzpDGCAUwwggFIAgEBMHYwcTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK 5093 CZImiZPyLGQBGRYJc2FuZGVsbWFuMUAwPgYDVQQDDDcjPFN5c3RlbVZhcmlhYmxl 5094 OjB4MDAwMDAwMDRmOTExYTA+IFVuc3RydW5nIEZvdW50YWluIENBAgECMAsGCWCG 5095 SAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF 5096 MQ8XDTE5MDUxNTIxMjU1NVowLwYJKoZIhvcNAQkEMSIEIFBQjMmWzZOEkRHXrVAS 5097 snJwgQ26goyvOAtUFYs3MstMMAoGCCqGSM49BAMCBEcwRQIgBthbhEmgbqZbYDkD 5098 zxHXLzJ5eusWplzHKqZyxNpzaR8CIQC3UtMu0QsXoUpYL016iTsbd7Eedi8IfnwQ 5099 akExfhh0ew== 5100 -----END CMS----- 5102 file: examples/parboiled_vr_00_D0-E5-02-00-2D.pkcs 5104 The ASN1 decoding of the artifact: 5106 0:d=0 hl=4 l=3987 cons: SEQUENCE 5107 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData 5108 15:d=1 hl=4 l=3972 cons: cont [ 0 ] 5109 19:d=2 hl=4 l=3968 cons: SEQUENCE 5110 23:d=3 hl=2 l= 1 prim: INTEGER :01 5111 26:d=3 hl=2 l= 13 cons: SET 5112 28:d=4 hl=2 l= 11 cons: SEQUENCE 5113 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 5114 41:d=3 hl=4 l=2516 cons: SEQUENCE 5115 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 5116 56:d=4 hl=4 l=2501 cons: cont [ 0 ] 5117 60:d=5 hl=4 l=2497 prim: OCTET STRING :{"ietf-voucher-request:v 5118 2561:d=3 hl=4 l=1090 cons: cont [ 0 ] 5119 2565:d=4 hl=4 l= 465 cons: SEQUENCE 5120 2569:d=5 hl=4 l= 342 cons: SEQUENCE 5121 2573:d=6 hl=2 l= 3 cons: cont [ 0 ] 5122 2575:d=7 hl=2 l= 1 prim: INTEGER :02 5123 2578:d=6 hl=2 l= 1 prim: INTEGER :02 5124 2581:d=6 hl=2 l= 10 cons: SEQUENCE 5125 2583:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA384 5126 2593:d=6 hl=2 l= 113 cons: SEQUENCE 5127 2595:d=7 hl=2 l= 18 cons: SET 5128 2597:d=8 hl=2 l= 16 cons: SEQUENCE 5129 2599:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 5130 2611:d=9 hl=2 l= 2 prim: IA5STRING :ca 5131 2615:d=7 hl=2 l= 25 cons: SET 5132 2617:d=8 hl=2 l= 23 cons: SEQUENCE 5133 2619:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 5134 2631:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 5135 2642:d=7 hl=2 l= 64 cons: SET 5136 2644:d=8 hl=2 l= 62 cons: SEQUENCE 5137 2646:d=9 hl=2 l= 3 prim: OBJECT :commonName 5138 2651:d=9 hl=2 l= 55 prim: UTF8STRING :#