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