idnits 2.17.1 draft-ietf-anima-bootstrapping-keyinfra-22.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 are 2 instances of too long lines in the document, the longest one being 758 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 17, 2019) is 1773 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC4514' is mentioned on line 787, but not defined == Missing Reference: 'RFC3987' is mentioned on line 811, but not defined == Missing Reference: 'GRASP' is mentioned on line 1474, but not defined == Missing Reference: 'RFC2616' is mentioned on line 1957, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Missing Reference: 'RFC5209' is mentioned on line 2575, but not defined == Missing Reference: 'RFC2131' is mentioned on line 3569, but not defined == Missing Reference: 'HEX DUMP' is mentioned on line 4449, but not defined == Unused Reference: 'RFC5386' is defined on line 3348, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 3353, but no explicit reference was found in the text == Unused Reference: 'RFC5660' is defined on line 3357, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-stable-connectivity' is defined on line 3433, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-zerotouch' is defined on line 3445, but no explicit reference was found in the text == Unused Reference: 'RFC2473' is defined on line 3476, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 3480, but no explicit reference was found in the text == Unused Reference: 'RFC6960' is defined on line 3490, but no explicit reference was found in the text == Unused Reference: 'RFC7217' is defined on line 3501, but no explicit reference was found in the text == Unused Reference: 'RFC7575' is defined on line 3525, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-19 -- Possible downref: Non-RFC (?) normative reference: ref. 'IDevID' ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Downref: Normative reference to an Informational RFC: RFC 8368 == Outdated reference: A later version (-18) exists of draft-ietf-ace-coap-est-12 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-03 == 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) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 7 errors (**), 0 flaws (~~), 22 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG M. Pritikin 3 Internet-Draft Cisco 4 Intended status: Standards Track M. Richardson 5 Expires: December 19, 2019 Sandelman 6 M. Behringer 8 S. Bjarnason 9 Arbor Networks 10 K. Watsen 11 Watsen Networks 12 June 17, 2019 14 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 15 draft-ietf-anima-bootstrapping-keyinfra-22 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 certificate, 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 is complete when 28 the cryptographic identity of the new key infrastructure is 29 successfully deployed to the device but 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 December 19, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . 10 73 1.3.3. Network Access Controls . . . . . . . . . . . . . . . 11 74 1.3.4. Bootstrapping is not Booting . . . . . . . . . . . . 11 75 1.4. Leveraging the new key infrastructure / next steps . . . 11 76 1.5. Requirements for Autonomic Network Infrastructure (ANI) 77 devices . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 12 79 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 14 80 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 15 81 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 16 82 2.3.1. Identification of the Pledge . . . . . . . . . . . . 16 83 2.3.2. MASA URI extension . . . . . . . . . . . . . . . . . 17 84 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 19 85 2.5. Architectural Components . . . . . . . . . . . . . . . . 21 86 2.5.1. Pledge . . . . . . . . . . . . . . . . . . . . . . . 21 87 2.5.2. Join Proxy . . . . . . . . . . . . . . . . . . . . . 21 88 2.5.3. Domain Registrar . . . . . . . . . . . . . . . . . . 21 89 2.5.4. Manufacturer Service . . . . . . . . . . . . . . . . 21 90 2.5.5. Public Key Infrastructure (PKI) . . . . . . . . . . . 21 91 2.6. Certificate Time Validation . . . . . . . . . . . . . . . 22 92 2.6.1. Lack of realtime clock . . . . . . . . . . . . . . . 22 93 2.6.2. Infinite Lifetime of IDevID . . . . . . . . . . . . . 22 94 2.7. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 22 95 2.8. Determining the MASA to contact . . . . . . . . . . . . . 23 96 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 23 97 3.1. Nonceless Voucher Requests . . . . . . . . . . . . . . . 24 98 3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 24 99 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 25 100 3.4. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 26 101 4. Proxying details (Pledge - Proxy - Registrar) . . . . . . . . 29 102 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 30 103 4.1.1. Proxy GRASP announcements . . . . . . . . . . . . . . 32 104 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 33 105 4.3. Proxy discovery and communication of Registrar . . . . . 33 106 5. Protocol Details (Pledge - Registrar - MASA) . . . . . . . . 34 107 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 36 108 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 36 109 5.3. Registrar Authorization of 110 Pledge . . . . . . . . . . . . . . . . . . . . . . . . . 37 111 5.4. BRSKI-MASA TLS establishment details . . . . . . . . . . 38 112 5.5. Registrar Requests Voucher from MASA . . . . . . . . . . 39 113 5.5.1. MASA renewal of expired vouchers . . . . . . . . . . 40 114 5.5.2. MASA verification of voucher-request signature 115 consistency . . . . . . . . . . . . . . . . . . . . . 41 116 5.5.3. MASA authentication of registrar (certificate) . . . 41 117 5.5.4. MASA revocation checking of registrar (certificate) . 41 118 5.5.5. MASA verification of pledge prior-signed-voucher- 119 request . . . . . . . . . . . . . . . . . . . . . . . 41 120 5.5.6. MASA pinning of registrar . . . . . . . . . . . . . . 42 121 5.5.7. MASA nonce handling . . . . . . . . . . . . . . . . . 42 122 5.6. MASA and Registrar Voucher Response . . . . . . . . . . . 42 123 5.6.1. Pledge voucher verification . . . . . . . . . . . . . 45 124 5.6.2. Pledge authentication of provisional TLS connection . 45 125 5.7. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 46 126 5.8. Registrar audit log request . . . . . . . . . . . . . . . 47 127 5.8.1. MASA audit log response . . . . . . . . . . . . . . . 48 128 5.8.2. Registrar audit log verification . . . . . . . . . . 49 129 5.9. EST Integration for PKI bootstrapping . . . . . . . . . . 50 130 5.9.1. EST Distribution of CA Certificates . . . . . . . . . 51 131 5.9.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 51 132 5.9.3. EST Client Certificate Request . . . . . . . . . . . 52 133 5.9.4. Enrollment Status Telemetry . . . . . . . . . . . . . 52 134 5.9.5. Multiple certificates . . . . . . . . . . . . . . . . 53 135 5.9.6. EST over CoAP . . . . . . . . . . . . . . . . . . . . 53 136 6. Clarification of transfer-encoding . . . . . . . . . . . . . 54 137 7. Reduced security operational modes . . . . . . . . . . . . . 54 138 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 54 139 7.2. Pledge security reductions . . . . . . . . . . . . . . . 55 140 7.3. Registrar security reductions . . . . . . . . . . . . . . 56 141 7.4. MASA security reductions . . . . . . . . . . . . . . . . 57 142 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 57 143 8.1. Well-known EST registration . . . . . . . . . . . . . . . 58 144 8.2. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 58 145 8.3. Pledge BRSKI Status Telemetry . . . . . . . . . . . . . . 58 146 8.4. DNS Service Names . . . . . . . . . . . . . . . . . . . . 58 147 8.5. MUD File Extension for the MASA . . . . . . . . . . . . . 59 148 9. Applicability to the Autonomic 149 Control Plane . . . . . . . . . . . . . . . . . . . . . . . . 59 150 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 60 151 10.1. MASA audit log . . . . . . . . . . . . . . . . . . . . . 60 152 10.2. What BRSKI-MASA reveals to the manufacturer . . . . . . 61 153 10.3. Manufacturers and Used or Stolen Equipment . . . . . . . 62 154 10.4. Manufacturers and Grey market equipment . . . . . . . . 63 155 10.5. Some mitigations for meddling by manufacturers . . . . . 64 156 11. Security Considerations . . . . . . . . . . . . . . . . . . . 65 157 11.1. DoS against MASA . . . . . . . . . . . . . . . . . . . . 66 158 11.2. Freshness in Voucher-Requests . . . . . . . . . . . . . 67 159 11.3. Trusting manufacturers . . . . . . . . . . . . . . . . . 68 160 11.4. Manufacturer Maintainance of trust anchors . . . . . . . 69 161 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 70 162 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 70 163 13.1. Normative References . . . . . . . . . . . . . . . . . . 70 164 13.2. Informative References . . . . . . . . . . . . . . . . . 73 165 Appendix A. IPv4 and non-ANI operations . . . . . . . . . . . . 76 166 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 76 167 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 76 168 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 77 169 Appendix C. MUD Extension . . . . . . . . . . . . . . . . . . . 77 170 Appendix D. Example Vouchers . . . . . . . . . . . . . . . . . . 80 171 D.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 80 172 D.1.1. MASA key pair for voucher signatures . . . . . . . . 80 173 D.1.2. Manufacturer key pair for IDevID signatures . . . . . 80 174 D.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 81 175 D.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 83 176 D.2. Example process . . . . . . . . . . . . . . . . . . . . . 84 177 D.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 84 178 D.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 88 179 D.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 93 180 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 97 182 1. Introduction 184 BRSKI provides a solution for secure zero-touch (automated) bootstrap 185 of new (unconfigured) devices that are called pledges in this 186 document. 188 This document primarily provides for the needs of the ISP and 189 Enterprise focused ANIMA Autonomic Control Plane (ACP) 190 [I-D.ietf-anima-autonomic-control-plane]. Other users of the BRSKI 191 protocol will need to provide separate applicability statements that 192 include privacy and security considerations appropriate to that 193 deployment. Section Section 9 explains the details applicability for 194 this the ACP usage. 196 This document describes how pledges discover (or be discovered by) an 197 element of the network domain to which the pledge belongs to perform 198 the bootstrap. This element (device) is called the registrar. 199 Before any other operation, pledge and registrar need to establish 200 mutual trust: 202 1. Registrar authenticating the pledge: "Who is this device? What 203 is its identity?" 205 2. Registrar authorizing the pledge: "Is it mine? Do I want it? 206 What are the chances it has been compromised?" 208 3. Pledge authenticating the registrar: "What is this registrar's 209 identity?" 211 4. Pledge authorizing the registrar: "Should I join it?" 213 This document details protocols and messages to answer the above 214 questions. It uses a TLS connection and an PKIX (X.509v3) 215 certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer 216 points 1 and 2. It uses a new artifact called a "voucher" that the 217 registrar receives from a "Manufacturer Authorized Signing Authority" 218 and passes to the pledge to answer points 3 and 4. 220 A proxy provides very limited connectivity between the pledge and the 221 registrar. 223 The syntactic details of vouchers are described in detail in 224 [RFC8366]. This document details automated protocol mechanisms to 225 obtain vouchers, including the definition of a 'voucher-request' 226 message that is a minor extension to the voucher format (see 227 Section 3) defined by [RFC8366]. 229 BRSKI results in the pledge storing an X.509 root certificate 230 sufficient for verifying the registrar identity. In the process a 231 TLS connection is established that can be directly used for 232 Enrollment over Secure Transport (EST). In effect BRSKI provides an 233 automated mechanism for the "Bootstrap Distribution of CA 234 Certificates" described in [RFC7030] Section 4.1.1 wherein the pledge 235 "MUST [...] engage a human user to authorize the CA certificate using 236 out-of-band" information". With BRSKI the pledge now can automate 237 this process using the voucher. Integration with a complete EST 238 enrollment is optional but trivial. 240 BRSKI is agile enough to support bootstrapping alternative key 241 infrastructures, such as a symmetric key solutions, but no such 242 system is described in this document. 244 1.1. Prior Bootstrapping Approaches 246 To literally "pull yourself up by the bootstraps" is an impossible 247 action. Similarly the secure establishment of a key infrastructure 248 without external help is also an impossibility. Today it is commonly 249 accepted that the initial connections between nodes are insecure, 250 until key distribution is complete, or that domain-specific keying 251 material (often pre-shared keys, including mechanisms like SIM cards) 252 is pre-provisioned on each new device in a costly and non-scalable 253 manner. Existing automated mechanisms are known as non-secured 254 'Trust on First Use' (TOFU) [RFC7435], 'resurrecting duckling' 255 [Stajano99theresurrecting] or 'pre-staging'. 257 Another prior approach has been to try and minimize user actions 258 during bootstrapping, but not eliminate all user-actions. The 259 original EST protocol [RFC7030] does reduce user actions during 260 bootstrap but does not provide solutions for how the following 261 protocol steps can be made autonomic (not involving user actions): 263 o using the Implicit Trust Anchor [RFC7030] database to authenticate 264 an owner specific service (not an autonomic solution because the 265 URL must be securely distributed), 267 o engaging a human user to authorize the CA certificate using out- 268 of-band data (not an autonomic solution because the human user is 269 involved), 271 o using a configured Explicit TA database (not an autonomic solution 272 because the distribution of an explicit TA database is not 273 autonomic), 275 o and using a Certificate-Less TLS mutual authentication method (not 276 an autonomic solution because the distribution of symmetric key 277 material is not autonomic). 279 These "touch" methods do not meet the requirements for zero-touch. 281 There are "call home" technologies where the pledge first establishes 282 a connection to a well known manufacturer service using a common 283 client-server authentication model. After mutual authentication, 284 appropriate credentials to authenticate the target domain are 285 transfered to the pledge. This creates serveral problems and 286 limitations: 288 o the pledge requires realtime connectivity to the manufacturer 289 service, 291 o the domain identity is exposed to the manufacturer service (this 292 is a privacy concern), 294 o the manufacturer is responsible for making the authorization 295 decisions (this is a liability concern), 297 BRSKI addresses these issues by defining extensions to the EST 298 protocol for the automated distribution of vouchers. 300 1.2. Terminology 302 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 303 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 304 "OPTIONAL" in this document are to be interpreted as described in 305 [RFC2119]. 307 The following terms are defined for clarity: 309 domainID: The domain IDentity is the 160-bit SHA-1 hash of the BIT 310 STRING of the subjectPublicKey of the pinned-domain-cert leaf, 311 i.e. the Registrars' certificate. This is consistent with the 312 subject key identifier (Section 4.2.1.2 [RFC5280]). 314 drop ship: The physical distribution of equipment containing the 315 "factory default" configuration to a final destination. In zero- 316 touch scenarios there is no staging or pre-configuration during 317 drop-ship. 319 imprint: The process where a device obtains the cryptographic key 320 material to identify and trust future interactions with a network. 321 This term is taken from Konrad Lorenz's work in biology with new 322 ducklings: during a critical period, the duckling would assume 323 that anything that looks like a mother duck is in fact their 324 mother. An equivalent for a device is to obtain the fingerprint 325 of the network's root certification authority certificate. A 326 device that imprints on an attacker suffers a similar fate to a 327 duckling that imprints on a hungry wolf. Securely imprinting is a 328 primary focus of this document [imprinting]. The analogy to 329 Lorenz's work was first noted in [Stajano99theresurrecting]. 331 enrollment: The process where a device presents key material to a 332 network and acquires a network specific identity. For example 333 when a certificate signing request is presented to a certification 334 authority and a certificate is obtained in response. 336 Pledge: The prospective device, which has an identity installed at 337 the factory. 339 Voucher: A signed artifact from the MASA that indicates to a pledge 340 the cryptographic identity of the registrar it should trust. 341 There are different types of vouchers depending on how that trust 342 is asserted. Multiple voucher types are defined in [RFC8366] 344 Domain: The set of entities that share a common local trust anchor. 345 This includes the proxy, registrar, Domain Certificate Authority, 346 Management components and any existing entity that is already a 347 member of the domain. 349 Domain CA: The domain Certification Authority (CA) provides 350 certification functionalities to the domain. At a minimum it 351 provides certification functionalities to a registrar and manages 352 the private key that defines the domain. Optionally, it certifies 353 all elements. 355 Join Registrar (and Coordinator): A representative of the domain 356 that is configured, perhaps autonomically, to decide whether a new 357 device is allowed to join the domain. The administrator of the 358 domain interfaces with a "join registrar (and coordinator)" to 359 control this process. Typically a join registrar is "inside" its 360 domain. For simplicity this document often refers to this as just 361 "registrar". Within [I-D.ietf-anima-reference-model] this is 362 refered to as the "join registrar autonomic service agent". Other 363 communities use the abbreviation "JRC". 365 (Public) Key Infrastructure: The collection of systems and processes 366 that sustain the activities of a public key system. The registrar 367 acts as an [RFC5280] and [RFC5272] (see section 7) "Registration 368 Authority". 370 Join Proxy: A domain entity that helps the pledge join the domain. 371 A join proxy facilitates communication for devices that find 372 themselves in an environment where they are not provided 373 connectivity until after they are validated as members of the 374 domain. For simplicity this document sometimes uses the term of 375 'proxy' to indicate the join proxy. The pledge is unaware that 376 they are communicating with a proxy rather than directly with a 377 registrar. 379 Circuit Proxy: A stateful implementation of the join proxy. This is 380 the assumed type of proxy. 382 IPIP Proxy: A stateless proxy alternative. 384 MASA Service: A third-party Manufacturer Authorized Signing 385 Authority (MASA) service on the global Internet. The MASA signs 386 vouchers. It also provides a repository for audit log information 387 of privacy protected bootstrapping events. It does not track 388 ownership. 390 Ownership Tracker: An Ownership Tracker service on the global 391 internet. The Ownership Tracker uses business processes to 392 accurately track ownership of all devices shipped against domains 393 that have purchased them. Although optional, this component 394 allows vendors to provide additional value in cases where their 395 sales and distribution channels allow for accurately tracking of 396 such ownership. Ownership tracking information is indicated in 397 vouchers as described in [RFC8366] 399 IDevID: An Initial Device Identity X.509 certificate installed by 400 the vendor on new equipment. 402 TOFU: Trust on First Use. Used similarly to [RFC7435]. This is 403 where a pledge device makes no security decisions but rather 404 simply trusts the first registrar it is contacted by. This is 405 also known as the "resurrecting duckling" model. 407 nonced: a voucher (or request) that contains a nonce (the normal 408 case). 410 nonceless: a voucher (or request) that does not contain a nonce, 411 relying upon accurate clocks for expiration, or which does not 412 expire. 414 manufacturer: the term manufacturer is used throughout this document 415 to be the entity that created the device. This is typically the 416 "original equipment manufacturer" or OEM, but in more complex 417 situations it could be a "value added retailer" (VAR), or possibly 418 even a systems integrator. In general, it a goal of BRSKI to 419 eliminate small distinctions between different sales channels. 420 The reason for this is that it permits a single device, with a 421 uniform firmware load, to be shipped directly to all customers. 422 This eliminates costs for the manufacturer. This also reduces the 423 number of products supported in the field increasing the chance 424 that firmware will be more up to date. 426 ANI: The Autonomic Network Infrastructure as defined by 427 [I-D.ietf-anima-reference-model]. This document details specific 428 requirements for pledges, proxies and registrars when they are 429 part of an ANI. 431 offline: When an architectural component cannot perform realtime 432 communications with a peer, either due to network connectivity or 433 because the peer is turned off, the operation is said to be 434 occurring offline. 436 1.3. Scope of solution 438 1.3.1. Support environment 440 This solution (BRSKI) can support large router platforms with multi- 441 gigabit inter-connections, mounted in controlled access data centers. 442 But this solution is not exclusive to large equipment: it is intended 443 to scale to thousands of devices located in hostile environments, 444 such as ISP provided CPE devices which are drop-shipped to the end 445 user. The situation where an order is fulfilled from distributed 446 warehouse from a common stock and shipped directly to the target 447 location at the request of a domain owner is explicitly supported. 448 That stock ("SKU") could be provided to a number of potential domain 449 owners, and the eventual domain owner will not know a-priori which 450 device will go to which location. 452 The bootstrapping process can take minutes to complete depending on 453 the network infrastructure and device processing speed. The network 454 communication itself is not optimized for speed; for privacy reasons, 455 the discovery process allows for the pledge to avoid announcing its 456 presence through broadcasting. 458 Nomadic or mobile devices often need to aquire credentials to access 459 the network at the new location. An example of this is mobile phone 460 roaming among network operators, or even between cell towers. This 461 is usually called handoff. BRSKI does not provide a low-latency 462 handoff which is usually a requirement in such situations. For these 463 solutions BRSKI can be used to create a relationship (an LDevID) with 464 the "home" domain owner. The resulting credentials are then used to 465 provide credentials more appropriate for a low-latency handoff. 467 1.3.2. Constrained environments 469 Questions have been posed as to whether this solution is suitable in 470 general for Internet of Things (IoT) networks. This depends on the 471 capabilities of the devices in question. The terminology of 472 [RFC7228] is best used to describe the boundaries. 474 The solution described in this document is aimed in general at non- 475 constrained (i.e., class 2+) devices operating on a non-Challenged 476 network. The entire solution as described here is not intended to be 477 useable as-is by constrained devices operating on challenged networks 478 (such as 802.15.4 LLNs). 480 Specifically, there are protocol aspects described here that might 481 result in congestion collapse or energy-exhaustion of intermediate 482 battery powered routers in an LLN. Those types of networks SHOULD 483 NOT use this solution. These limitations are predominately related 484 to the large credential and key sizes required for device 485 authentication. Defining symmetric key techniques that meet the 486 operational requirements is out-of-scope but the underlying protocol 487 operations (TLS handshake and signing structures) have sufficient 488 algorithm agility to support such techniques when defined. 490 The imprint protocol described here could, however, be used by non- 491 energy constrained devices joining a non-constrained network (for 492 instance, smart light bulbs are usually mains powered, and speak 493 802.11). It could also be used by non-constrained devices across a 494 non-energy constrained, but challenged network (such as 802.15.4). 495 The certificate contents, and the process by which the four questions 496 above are resolved do apply to constrained devices. It is simply the 497 actual on-the-wire imprint protocol that could be inappropriate. 499 1.3.3. Network Access Controls 501 This document presumes that network access control has either already 502 occurred, is not required, or is integrated by the proxy and 503 registrar in such a way that the device itself does not need to be 504 aware of the details. Although the use of an X.509 Initial Device 505 Identity is consistant with IEEE 802.1AR [IDevID], and allows for 506 alignment with 802.1X network access control methods, its use here is 507 for pledge authentication rather than network access control. 508 Integrating this protocol with network access control, perhaps as an 509 Extensible Authentication Protocol (EAP) method (see [RFC3748]), is 510 out-of-scope. 512 1.3.4. Bootstrapping is not Booting 514 This document describes "bootstrapping" as the protocol used to 515 obtain a local trust anchor. It is expected that this trust anchor, 516 along with any additional configuration information subsequently 517 installed, is persisted on the device across system restarts 518 ("booting"). Bootstrapping occurs only infrequently such as when a 519 device is transfered to a new owner or has been reset to factory 520 default settings. 522 1.4. Leveraging the new key infrastructure / next steps 524 As a result of the protocol described herein, the bootstrapped 525 devices have the Domain CA trust anchor in common. An end entity 526 certificate has optionally been issued from the Domain CA. This 527 makes it possible to securely deploy functionalities across the 528 domain, e.g: 530 o Device management. 532 o Routing authentication. 534 o Service discovery. 536 The major beneficiary is that it possible to use the credentials 537 deployed by this protocol to secure the Autonomic Control Plane (ACP) 538 ([I-D.ietf-anima-autonomic-control-plane]). 540 1.5. Requirements for Autonomic Network Infrastructure (ANI) devices 542 The BRSKI protocol can be used in a number of environments. Some of 543 the options in this document is the result of requirements that are 544 out of the ANI scope. This section defines the base requirements for 545 ANI devices. 547 For devices that intend to become part of an Autonomic Network 548 Infrastructure (ANI) ([I-D.ietf-anima-reference-model]) that includes 549 an Autonomic Control Plane 550 ([I-D.ietf-anima-autonomic-control-plane]), the BRSKI protocol MUST 551 be implemented. 553 The pledge must perform discovery of the proxy as described in 554 Section 4.1 using GRASP M_FLOOD announcements. 556 Upon successfully validating a voucher artiface, a status telemetry 557 MUST be returned. See Section 5.7. 559 An ANIMA ANI pledge MUST implement the EST automation extensions 560 described in Section 5.9. They supplement the [RFC7030] EST to 561 better support automated devices that do not have an end user. 563 The ANI Join Registrar ASA MUST support all the BRSKI and above 564 listed EST operations. 566 All ANI devices SHOULD support the BRSKI proxy function, using 567 circuit proxies over the ACP. (See Section 4.3) 569 2. Architectural Overview 571 The logical elements of the bootstrapping framework are described in 572 this section. Figure 1 provides a simplified overview of the 573 components. 575 +------------------------+ 576 +--------------Drop Ship--------------->| Vendor Service | 577 | +------------------------+ 578 | | M anufacturer| | 579 | | A uthorized |Ownership| 580 | | S igning |Tracker | 581 | | A uthority | | 582 | +--------------+---------+ 583 | ^ 584 | | BRSKI- 585 V | MASA 586 +-------+ ............................................|... 587 | | . | . 588 | | . +------------+ +-----------+ | . 589 | | . | | | | | . 590 |Pledge | . | Join | | Domain <-------+ . 591 | | . | Proxy | | Registrar | . 592 | <-------->............<-------> (PKI RA) | . 593 | | | BRSKI-EST | | . 594 | | . | | +-----+-----+ . 595 |IDevID | . +------------+ | e.g. RFC7030 . 596 | | . +-----------------+----------+ . 597 | | . | Key Infrastructure | . 598 | | . | (e.g., PKI Certificate | . 599 +-------+ . | Authority) | . 600 . +----------------------------+ . 601 . . 602 ................................................ 603 "Domain" components 605 Figure 1 607 We assume a multi-vendor network. In such an environment there could 608 be a Manufacturer Service for each manufacturer that supports devices 609 following this document's specification, or an integrator could 610 provide a generic service authorized by multiple manufacturers. It 611 is unlikely that an integrator could provide Ownership Tracking 612 services for multiple manufacturers due to the required sales channel 613 integrations necessary to track ownership. 615 The domain is the managed network infrastructure with a Key 616 Infrastructure the pledge is joining. The domain provides initial 617 device connectivity sufficient for bootstrapping through a proxy. 618 The domain registrar authenticates the pledge, makes authorization 619 decisions, and distributes vouchers obtained from the Manufacturer 620 Service. Optionally the registrar also acts as a PKI Registration 621 Authority. 623 2.1. Behavior of a Pledge 625 The pledge goes through a series of steps, which are outlined here at 626 a high level. 628 ------------ 629 / Factory \ 630 \ default / 631 -----+------ 632 | 633 +------v-------+ 634 | (1) Discover | 635 +------------> | 636 | +------+-------+ 637 | | 638 | +------v-------+ 639 | | (2) Identity | 640 ^------------+ | 641 | rejected +------+-------+ 642 | | 643 | +------v-------+ 644 | | (3) Request | 645 | | Join | 646 | +------+-------+ 647 | | 648 | +------v-------+ 649 | | (4) Imprint | 650 ^------------+ | 651 | Bad MASA +------+-------+ 652 | response | send Voucher Status Telemetry 653 | +------v-------+ 654 | | (5) Enroll |<---+ (non-error HTTP codes ) 655 ^------------+ |\___/ (e.g. 201 'Retry-After') 656 | Enroll +------+-------+ 657 | Failure | 658 | -----v------ 659 | / Enrolled \ 660 ^------------+ | 661 Factory \------------/ 662 reset 664 Figure 2: pledge state diagram 666 State descriptions for the pledge are as follows: 668 1. Discover a communication channel to a registrar. 670 2. Identify itself. This is done by presenting an X.509 IDevID 671 credential to the discovered registrar (via the proxy) in a TLS 672 handshake. (The registrar credentials are only provisionally 673 accepted at this time). 675 3. Request to join the discovered registrar. A unique nonce is 676 included ensuring that any responses can be associated with this 677 particular bootstrapping attempt. 679 4. Imprint on the registrar. This requires verification of the 680 manufacturer service provided voucher. A voucher contains 681 sufficient information for the pledge to complete authentication 682 of a registrar. This document details this step in depth. 684 5. Enroll. After imprint an authenticated TLS (HTTPS) connection 685 exists between pledge and registrar. Enrollment over Secure 686 Transport (EST) [RFC7030] is then used to obtain a domain 687 certificate from a registrar. 689 The pledge is now a member of, and can be managed by, the domain and 690 will only repeat the discovery aspects of bootstrapping if it is 691 returned to factory default settings. 693 This specification details integration with EST enrollment so that 694 pledges can optionally obtain a locally issued certificate, although 695 any REST interface could be integrated in future work. 697 2.2. Secure Imprinting using Vouchers 699 A voucher is a cryptographically protected artifact (a digital 700 signature) to the pledge device authorizing a zero-touch imprint on 701 the registrar domain. 703 The format and cryptographic mechanism of vouchers is described in 704 detail in [RFC8366]. 706 Vouchers provide a flexible mechanism to secure imprinting: the 707 pledge device only imprints when a voucher can be validated. At the 708 lowest security levels the MASA can indiscriminately issue vouchers 709 and log claims of ownership by domains. At the highest security 710 levels issuance of vouchers can be integrated with complex sales 711 channel integrations that are beyond the scope of this document. The 712 sales channel integration would verify actual (legal) ownership of 713 the pledge by the domain. This provides the flexibility for a number 714 of use cases via a single common protocol mechanism on the pledge and 715 registrar devices that are to be widely deployed in the field. The 716 MASA services have the flexibility to leverage either the currently 717 defined claim mechanisms or to experiment with higher or lower 718 security levels. 720 Vouchers provide a signed but non-encrypted communication channel 721 among the pledge, the MASA, and the registrar. The registrar 722 maintains control over the transport and policy decisions allowing 723 the local security policy of the domain network to be enforced. 725 2.3. Initial Device Identifier 727 Pledge authentication and pledge voucher-request signing is via a 728 PKIX certificate installed during the manufacturing process. This is 729 the 802.1AR Initial Device Identifier (IDevID), and it provides a 730 basis for authenticating the pledge during the protocol exchanges 731 described here. There is no requirement for a common root PKI 732 hierarchy. Each device manufacturer can generate its own root 733 certificate. Specifically, the IDevID enables: 735 1. Uniquely identifying the pledge by the Distinguished Name (DN) 736 and subjectAltName (SAN) parameters in the IDevID. The unique 737 identification of a pledge in the voucher objects are derived 738 from those parameters as described below. 740 2. Provides a cryptographic authentication of the pledge to the 741 Registrar (see Section 5.3). 743 3. Secure auto-discovery of the pledge's MASA by the registrar (see 744 Section 2.8). 746 4. Signing of voucher-request by the pledge's IDevID (see 747 Section 3). 749 5. Provides a cryptographic authentication of the pledge to the MASA 750 (see Section 5.5.5). 752 Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage 753 extensions in the IDevID certificate. Any restrictions included 754 reduce the utility of the IDevID and so this specification RECOMMENDS 755 that no key usage restrictions be included. Additionally, [RFC5280] 756 section 4.2.1.3 does not require key usage restrictions for end 757 entity certificates. 759 2.3.1. Identification of the Pledge 761 In the context of BRSKI, pledges are uniquely identified by a 762 "serial-number". This serial-number is used both in the "serial- 763 number" field of voucher or voucher-requests (see Section 3) and in 764 local policies on registrar or MASA (see Section 5). 766 The following fields are defined in [IDevID] and [RFC5280]: 768 o The subject field's DN encoding MUST include the "serialNumber" 769 attribute with the device's unique serial number. (from [IDevID] 770 section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard 771 attributes) 773 o The subject-alt field's encoding MAY include a non-critical 774 version of the RFC4108 defined HardwareModuleName. (from [IDevID] 775 section 7.2.9) If the IDevID is stored in a Trusted Platform 776 Module (TPM), then this field MAY contain the TPM identification 777 rather than the device's serial number. If both fields are 778 present, then the subject field takes precedence. 780 and they are used as follows by the pledge to build the "serial- 781 number" that is placed in the voucher-request. In order to build it, 782 the fields need to be converted into a serial-number of "type 783 string". The following methods are used depending on the first 784 available IDevID certificate field (attempted in this order): 786 1. [RFC4519] section 2.31 provides an example ("WI-3005") of the 787 Distinguished Name "serialNumber" attribute. [RFC4514] indicates 788 this is a printable string so no encoding is necessary. 790 2. The HardwareModuleName hwSerialNum OCTET STRING. This value is 791 base64 encoded to convert it to a printable string format. 793 The above process to locate the serial-number MUST be performed by 794 the pledge when filling out the voucher-request. Signed voucher- 795 requests are always passed up to the MASA. 797 As explained in Section 5.5 the Registrar MUST extract the serial- 798 number again itself from the pledge's TLS certificate. It can 799 consult the serial-number in the pledge-request if there are any 800 possible confusion about the source of the serial-number (hwSerialNum 801 vs serialNumber). 803 2.3.2. MASA URI extension 805 This docucment defines a new PKIX non-critical certificate extension 806 to carry the MASA URI. This extension is intended to be used in the 807 IDevID certificate. The URI is represented as described in 808 Section 7.4 of [RFC5280]. 810 Any Internationalized Resource Identifiers (IRIs) MUST be mapped to 811 URIs as specified in Section 3.1 of [RFC3987] before they are placed 812 in the certificate extension. The IRI provides the authority 813 information. The BRSKI "/.well-known" tree ([RFC5785]) is described 814 in Section 5. 816 As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in 817 this extension, including the scheme, iauthority, and ipath. As a 818 consideration to constrained systems, this MAY be reduced to only the 819 iauthority, in which case a scheme of "https://" and ipath of 820 "/.well-known/est" is to be assumed, as explained in section 821 Section 5. 823 The registrary can assume that only the iauthority is present in the 824 extension, if there are no slash ("/") characters in the extension. 826 Section 7.4 of [RFC5280] calls out various schemes that MUST be 827 supported, including ldap, http and ftp. However, the registrar MUST 828 use https for the BRSKI-MASA connection. 830 The new extension is identified as follows: 832 834 MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) 835 internet(1) security(5) mechanisms(5) pkix(7) 836 id-mod(0) id-mod-MASAURLExtn2016(TBD) } 838 DEFINITIONS IMPLICIT TAGS ::= BEGIN 840 -- EXPORTS ALL -- 842 IMPORTS 843 EXTENSION 844 FROM PKIX-CommonTypes-2009 845 { iso(1) identified-organization(3) dod(6) internet(1) 846 security(5) mechanisms(5) pkix(7) id-mod(0) 847 id-mod-pkixCommon-02(57) } 849 id-pe 850 FROM PKIX1Explicit-2009 851 { iso(1) identified-organization(3) dod(6) internet(1) 852 security(5) mechanisms(5) pkix(7) id-mod(0) 853 id-mod-pkix1-explicit-02(51) } ; 854 MASACertExtensions EXTENSION ::= { ext-MASAURL, ... } 855 ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax 856 IDENTIFIED BY id-pe-masa-url } 858 id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe TBD } 860 MASAURLSyntax ::= IA5String 862 END 864 866 The choice of id-pe is based on guidance found in Section 4.2.2 of 867 [RFC5280], "These extensions may be used to direct applications to 868 on-line information about the issuer or the subject". The MASA URL 869 is precisely that: online information about the particular subject. 871 2.4. Protocol Flow 873 A representative flow is shown in Figure 3: 875 +--------+ +---------+ +------------+ +------------+ 876 | Pledge | | Circuit | | Domain | | Vendor | 877 | | | Join | | Registrar | | Service | 878 | | | Proxy | | (JRC) | | (MASA) | 879 +--------+ +---------+ +------------+ +------------+ 880 | | | Internet | 881 [discover] | | | 882 |<-RFC4862 IPv6 addr | | | 883 |<-RFC3927 IPv4 addr | Appendix A | Legend | 884 |-------------------->| | C - circuit | 885 | optional: mDNS query| Appendix B | join proxy | 886 | RFC6763/RFC6762 | | P - provisional | 887 |<--------------------| | TLS connection | 888 | GRASP M_FLOOD | | | 889 | periodic broadcast| | | 890 [identity] | | | 891 |<------------------->C<----------------->| | 892 | TLS via the Join Proxy | | 893 |<--Registrar TLS server authentication---| | 894 [PROVISIONAL accept of server cert] | | 895 P---X.509 client authentication---------->| | 896 [request join] | | 897 P---Voucher Request(w/nonce for voucher)->| | 898 P /------------------- | | 899 P | [accept device?] | 900 P | [contact Vendor] | 901 P | |--Pledge ID-------->| 902 P | |--Domain ID-------->| 903 P | |--optional:nonce--->| 904 P optional: | [extract DomainID] 905 P can occur in advance | [update audit log] 906 P if nonceleess | | 907 P | |<- voucher ---------| 908 P \------------------- | w/nonce if provided| 909 P<------voucher---------------------------| | 910 [imprint] | | 911 |-------voucher status telemetry--------->| | 912 | |<-device audit log--| 913 | [verify audit log and voucher] | 914 |<--------------------------------------->| | 915 [enroll] | | 916 | Continue with RFC7030 enrollment | | 917 | using now bidirectionally authenticated | | 918 | TLS session. | | 919 [enrolled] | | 921 Figure 3 923 2.5. Architectural Components 925 2.5.1. Pledge 927 The pledge is the device that is attempting to join. Until the 928 pledge completes the enrollment process, it has link-local network 929 connectivity only to the proxy. 931 2.5.2. Join Proxy 933 The join proxy provides HTTPS connectivity between the pledge and the 934 registrar. A circuit proxy mechanism is described in Section 4. 935 Additional mechanisms, including a CoAP mechanism and a stateless 936 IPIP mechanism are the subject of future work. 938 2.5.3. Domain Registrar 940 The domain's registrar operates as the BRSKI-MASA client when 941 requesting vouchers from the MASA (see Section 5.4). The registrar 942 operates as the BRSKI-EST server when pledges request vouchers (see 943 Section 5.1). The registrar operates as the BRSKI-EST server 944 "Registration Authority" if the pledge requests an end entity 945 certificate over the BRSKI-EST connection (see Section 5.9). 947 The registrar uses an Implicit Trust Anchor database for 948 authenticating the BRSKI-MASA TLS connection MASA certificate. The 949 registrar uses a different Implicit Trust Anchor database for 950 authenticating the BRSKI-EST TLS connection pledge client 951 certificate. Configuration or distribution of these trust anchor 952 databases is out-of-scope of this specification. 954 2.5.4. Manufacturer Service 956 The Manufacturer Service provides two logically seperate functions: 957 the Manufacturer Authorized Signing Authority (MASA) described in 958 Section 5.5 and Section 5.6, and an ownership tracking/auditing 959 function described in Section 5.7 and Section 5.8. 961 2.5.5. Public Key Infrastructure (PKI) 963 The Public Key Infrastructure (PKI) administers certificates for the 964 domain of concerns, providing the trust anchor(s) for it and allowing 965 enrollment of pledges with domain certificates. 967 The voucher provides a method for the distribution of a single PKI 968 trust anchor (as the "pinned-domain-cert"). A distribution of the 969 full set of current trust anchors is possible using the optional EST 970 integration. 972 The domain's registrar acts as an [RFC5272] Registration Authority, 973 requesting certificates for pledges from the Key Infrastructure. 975 The expectations of the PKI are unchanged from EST [[RFC7030]]. This 976 document does not place any additional architectural requirements on 977 the Public Key Infrastructure. 979 2.6. Certificate Time Validation 981 2.6.1. Lack of realtime clock 983 Many devices when bootstrapping do not have knowledge of the current 984 time. Mechanisms such as Network Time Protocols cannot be secured 985 until bootstrapping is complete. Therefore bootstrapping is defined 986 in a method that does not require knowledge of the current time. A 987 pledge MAY ignore all time stamps in the voucher and in the 988 certificate validity periods if it does not know the current time. 990 The pledge is exposed to dates in the following five places: 991 registrar certificate notBefore, registrar certificiate notAfter, 992 voucher created-on, and voucher expires-on. Additionally, CMS 993 signatures contain a signingTime. 995 If the voucher contains a nonce then the pledge MUST confirm the 996 nonce matches the original pledge voucher-request. This ensures the 997 voucher is fresh. See Section 5.2. 999 2.6.2. Infinite Lifetime of IDevID 1001 [RFC5280] explains that long lived pledge certificates "SHOULD be 1002 assigned the GeneralizedTime value of 99991231235959Z". Registrars 1003 MUST support such lifetimes and SHOULD support ignoring pledge 1004 lifetimes if they did not follow the RFC5280 recommendations. 1006 For example, IDevID may have incorrect lifetime of N <= 3 years, 1007 rendering replacement pledges from storage useless after N years 1008 unless registrars support ignoring such a lifetime. 1010 2.7. Cloud Registrar 1012 There exist operationally open network wherein devices gain 1013 unauthenticated access to the internet at large. In these use cases 1014 the management domain for the device needs to be discovered within 1015 the larger internet. These are less likely within the anima scope 1016 but may be more important in the future. 1018 There are additionally some greenfield situations involving an 1019 entirely new installation where a device may have some kind of 1020 management uplink that it can use (such as via 3G network for 1021 instance). In such a future situation, the device might use this 1022 management interface to learn that it should configure itself to 1023 become the local registrar. 1025 In order to support these scenarios, the pledge MAY contact a well 1026 known URI of a cloud registrar if a local registrar cannot be 1027 discovered or if the pledge's target use cases do not include a local 1028 registrar. 1030 If the pledge uses a well known URI for contacting a cloud registrar 1031 an Implicit Trust Anchor database (see [RFC7030]) MUST be used to 1032 authenticate service as described in [RFC6125]. This is consistent 1033 with the human user configuration of an EST server URI in [RFC7030] 1034 which also depends on RFC6125. 1036 2.8. Determining the MASA to contact 1038 The registrar needs to be able to contact a MASA that is trusted by 1039 the pledge in order to obtain vouchers. There are three mechanisms 1040 described: 1042 The device's Initial Device Identifier (IDevID) will normally contain 1043 the MASA URL as detailed in Section 2.3. This is the RECOMMENDED 1044 mechanism. 1046 If the registrar is integrated with [I-D.ietf-opsawg-mud] and the 1047 pledge IDevID contains the id-pe-mud-url then the registrar MAY 1048 attempt to obtain the MASA URL from the MUD file. The MUD file 1049 extension for the MASA URL is defined in Appendix C. 1051 It can be operationally difficult to ensure the necessary X.509 1052 extensions are in the pledge's IDevID due to the difficulty of 1053 aligning current pledge manufacturing with software releases and 1054 development. As a final fallback the registrar MAY be manually 1055 configured or distributed with a MASA URL for each manufacturer. 1056 Note that the registrar can only select the configured MASA URL based 1057 on the trust anchor -- so manufacturers can only leverage this 1058 approach if they ensure a single MASA URL works for all pledge's 1059 associated with each trust anchor. 1061 3. Voucher-Request artifact 1063 Voucher-requests are how vouchers are requested. The semantics of 1064 the vouchers are described below, in the YANG model. 1066 A pledge forms the "pledge voucher-request" and submits it to the 1067 registrar. 1069 The registrar in turn forms the "registrar voucher-request", and 1070 submits it to the MASA. 1072 The "proximity-registrar-cert" leaf is used in the pledge voucher- 1073 requests. This provides a method for the pledge to assert the 1074 registrar's proximity. 1076 The "prior-signed-voucher-request" leaf is used in registrar voucher- 1077 requests. If present, it is the signed pledge voucher-request. This 1078 provides a method for the registrar to forward the pledge's signed 1079 request to the MASA. This completes transmission of the signed 1080 "proximity-registrar-cert" leaf. 1082 Unless otherwise signaled (outside the voucher-request artifact), the 1083 signing structure is as defined for vouchers, see [RFC8366]. 1085 3.1. Nonceless Voucher Requests 1087 A registrar MAY also retrieve nonceless vouchers by sending nonceless 1088 voucher-requests to the MASA in order to obtain vouchers for use when 1089 the registrar does not have connectivity to the MASA. No "prior- 1090 signed-voucher-request" leaf would be included. The registrar will 1091 also need to know the serial number of the pledge. This document 1092 does not provide a mechanism for the registrar to learn that in an 1093 automated fashion. Typically this will be done via scanning of bar- 1094 code or QR-code on packaging, or via some sales channel integration. 1096 3.2. Tree Diagram 1098 The following tree diagram illustrates a high-level view of a 1099 voucher-request document. The voucher-request builds upon the 1100 voucher artifact described in [RFC8366]. The tree diagram is 1101 described in [RFC8340]. Each node in the diagram is fully described 1102 by the YANG module in Section 3.4. Please review the YANG module for 1103 a detailed description of the voucher-request format. 1105 module: ietf-voucher-request 1107 grouping voucher-request-grouping 1108 +-- voucher 1109 +-- created-on? yang:date-and-time 1110 +-- expires-on? yang:date-and-time 1111 +-- assertion? enumeration 1112 +-- serial-number string 1113 +-- idevid-issuer? binary 1114 +-- pinned-domain-cert? binary 1115 +-- domain-cert-revocation-checks? boolean 1116 +-- nonce? binary 1117 +-- last-renewal-date? yang:date-and-time 1118 +-- prior-signed-voucher-request? binary 1119 +-- proximity-registrar-cert? binary 1121 3.3. Examples 1123 This section provides voucher-request examples for illustration 1124 purposes. For detailed examples, see Appendix D.2. These examples 1125 conform to the encoding rules defined in [RFC7951]. 1127 Example (1) The following example illustrates a pledge voucher- 1128 request. The assertion leaf is indicated as 'proximity' 1129 and the registrar's TLS server certificate is included 1130 in the 'proximity-registrar-cert' leaf. See 1131 Section 5.2. 1133 { 1134 "ietf-voucher-request:voucher": { 1135 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1136 "created-on": "2017-01-01T00:00:00.000Z", 1137 "proximity-registrar-cert": "base64encodedvalue==" 1138 } 1139 } 1141 Example (2) The following example illustrates a registrar voucher- 1142 request. The 'prior-signed-voucher-request' leaf is 1143 populated with the pledge's voucher-request (such as the 1144 prior example). The pledge's voucher-request is a 1145 binary object. In the JSON encoding used here it must 1146 be base64 encoded. The nonce, created-on and assertion 1147 is carried forward. The serial-number is extracted from 1148 the pledge's Client Certificate from the TLS connection. 1149 See Section 5.5. 1151 { 1152 "ietf-voucher-request:voucher": { 1153 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1154 "created-on": "2017-01-01T00:00:02.000Z", 1155 "idevid-issuer": "base64encodedvalue==" 1156 "serial-number": "JADA123456789" 1157 "prior-signed-voucher-request": "base64encodedvalue==" 1158 } 1159 } 1161 Example (3) The following example illustrates a registrar voucher- 1162 request. The 'prior-signed-voucher-request' leaf is not 1163 populated with the pledge's voucher-request nor is the 1164 nonce leaf. This form might be used by a registrar 1165 requesting a voucher when the pledge can not communicate 1166 with the registrar (such as when it is powered down, or 1167 still in packaging), and therefore could not submit a 1168 nonce. This scenario is most useful when the registrar 1169 is aware that it will not be able to reach the MASA 1170 during deployment. See Section 5.5. 1172 { 1173 "ietf-voucher-request:voucher": { 1174 "created-on": "2017-01-01T00:00:02.000Z", 1175 "idevid-issuer": "base64encodedvalue==" 1176 "serial-number": "JADA123456789" 1177 } 1178 } 1180 3.4. YANG Module 1182 Following is a YANG [RFC7950] module formally extending the [RFC8366] 1183 voucher into a voucher-request. 1185 file "ietf-voucher-request@2018-02-14.yang" 1186 module ietf-voucher-request { 1187 yang-version 1.1; 1189 namespace 1190 "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; 1191 prefix "vch"; 1193 import ietf-restconf { 1194 prefix rc; 1195 description "This import statement is only present to access 1196 the yang-data extension defined in RFC 8040."; 1197 reference "RFC 8040: RESTCONF Protocol"; 1198 } 1199 import ietf-voucher { 1200 prefix v; 1201 description "This module defines the format for a voucher, 1202 which is produced by a pledge's manufacturer or 1203 delegate (MASA) to securely assign a pledge to 1204 an 'owner', so that the pledge may establish a secure 1205 conn ection to the owner's network infrastructure"; 1207 reference "RFC YYYY: Voucher Profile for Bootstrapping Protocols"; 1208 } 1210 organization 1211 "IETF ANIMA Working Group"; 1213 contact 1214 "WG Web: 1215 WG List: 1216 Author: Kent Watsen 1217 1218 Author: Max Pritikin 1219 1220 Author: Michael Richardson 1221 1222 Author: Toerless Eckert 1223 "; 1225 description 1226 "This module defines the format for a voucher request. 1227 It is a superset of the voucher itself. 1228 It provides content to the MASA for consideration 1229 during a voucher request. 1231 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 1232 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in 1233 the module text are to be interpreted as described in RFC 2119. 1235 Copyright (c) 2017 IETF Trust and the persons identified as 1236 authors of the code. All rights reserved. 1238 Redistribution and use in source and binary forms, with or without 1239 modification, is permitted pursuant to, and subject to the license 1240 terms contained in, the Simplified BSD License set forth in Section 1241 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 1242 (http://trustee.ietf.org/license-info). 1244 This version of this YANG module is part of RFC XXXX; see the RFC 1245 itself for full legal notices."; 1247 revision "2018-02-14" { 1248 description 1249 "Initial version"; 1250 reference 1251 "RFC XXXX: Voucher Profile for Bootstrapping Protocols"; 1252 } 1254 // Top-level statement 1255 rc:yang-data voucher-request-artifact { 1256 uses voucher-request-grouping; 1257 } 1259 // Grouping defined for future usage 1260 grouping voucher-request-grouping { 1261 description 1262 "Grouping to allow reuse/extensions in future work."; 1264 uses v:voucher-artifact-grouping { 1265 refine "voucher/created-on" { 1266 mandatory false; 1267 } 1269 refine "voucher/pinned-domain-cert" { 1270 mandatory false; 1271 } 1273 refine "voucher/domain-cert-revocation-checks" { 1274 description "The domain-cert-revocation-checks field 1275 is not valid in a voucher request, and 1276 any occurance MUST be ignored"; 1277 } 1279 refine "voucher/assertion" { 1280 mandatory false; 1281 description "Any assertion included in voucher 1282 requests SHOULD be ignored by the MASA."; 1283 } 1285 augment "voucher" { 1286 description 1287 "Adds leaf nodes appropriate for requesting vouchers."; 1289 leaf prior-signed-voucher-request { 1290 type binary; 1291 description 1292 "If it is necessary to change a voucher, or re-sign and 1293 forward a voucher that was previously provided along a 1294 protocol path, then the previously signed voucher SHOULD be 1295 included in this field. 1297 For example, a pledge might sign a voucher request 1298 with a proximity-registrar-cert, and the registrar 1299 then includes it in the prior-signed-voucher-request field. 1300 This is a simple mechanism for a chain of trusted 1301 parties to change a voucher request, while 1302 maintaining the prior signature information. 1304 The Registrar and MASA MAY examine the prior signed 1305 voucher information for the 1306 purposes of policy decisions. For example this information 1307 could be useful to a MASA to determine that both pledge and 1308 registrar agree on proximity assertions. The MASA SHOULD 1309 remove all prior-signed-voucher-request information when 1310 signing a voucher for imprinting so as to minimize the 1311 final voucher size."; 1312 } 1314 leaf proximity-registrar-cert { 1315 type binary; 1316 description 1317 "An X.509 v3 certificate structure as specified by RFC 5280, 1318 Section 4 encoded using the ASN.1 distinguished encoding 1319 rules (DER), as specified in ITU-T X.690. 1321 The first certificate in the Registrar TLS server 1322 certificate_list sequence (see [RFC5246]) presented by 1323 the Registrar to the Pledge. This MUST be populated in a 1324 Pledge's voucher request if a proximity assertion is 1325 requested."; 1326 } 1327 } 1328 } 1329 } 1331 } 1333 1335 4. Proxying details (Pledge - Proxy - Registrar) 1337 The role of the proxy is to facilitate communications. The proxy 1338 forwards packets between the pledge and a registrar that has been 1339 provisioned to the proxy via GRASP discovery. 1341 This section defines a stateful proxy mechanism which is refered to 1342 as a "circuit" proxy. 1344 The proxy does not terminate the TLS handshake: it passes streams of 1345 bytes onward without examination. A proxy MUST NOT assume any 1346 specific TLS version. 1348 A Registrar can directly provide the proxy announcements described 1349 below, in which case the announced port can point directly to the 1350 Registrar itself. In this scenario the pledge is unaware that there 1351 is no proxing occuring. This is useful for Registrars servicing 1352 pledges on directly connected networks. 1354 As a result of the proxy Discovery process in Section 4.1.1, the port 1355 number exposed by the proxy does not need to be well known, or 1356 require an IANA allocation. 1358 During the discovery of the Registrar by the Join Proxy, the Join 1359 Proxy will also learn which kinds of proxy mechanisms are available. 1360 This will allow the Join Proxy to use the lowest impact mechanism 1361 which the Join Proxy and Registrar have in common. 1363 In order to permit the proxy functionality to be implemented on the 1364 maximum variety of devices the chosen mechanism SHOULD use the 1365 minimum amount of state on the proxy device. While many devices in 1366 the ANIMA target space will be rather large routers, the proxy 1367 function is likely to be implemented in the control plane CPU of such 1368 a device, with available capabilities for the proxy function similar 1369 to many class 2 IoT devices. 1371 The document [I-D.richardson-anima-state-for-joinrouter] provides a 1372 more extensive analysis and background of the alternative proxy 1373 methods. 1375 4.1. Pledge discovery of Proxy 1377 The result of discovery is a logical communication with a registrar, 1378 through a proxy. The proxy is transparent to the pledge. The 1379 communication between the pledge is over IPv6 Link-Local addresses. 1381 To discover the proxy the pledge performs the following actions: 1383 1. MUST: Obtains a local address using IPv6 methods as described in 1384 [RFC4862] IPv6 Stateless Address AutoConfiguration. Use of 1385 [RFC4941] temporary addresses is encouraged. To limit pervasive 1386 monitoring ( [RFC7258]), a new temporary address MAY use a short 1387 lifetime (that is, set TEMP_PREFERRED_LIFETIME to be short). 1388 Pledges will generally prefer use of IPv6 Link-Local addresses, 1389 and discovery of proxy will be by Link-Local mechanisms. IPv4 1390 methods are described in Appendix A 1392 2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) 1393 announcements of the objective: "AN_Proxy". See section 1394 Section 4.1.1 for the details of the objective. The pledge MAY 1395 listen concurrently for other sources of information, see 1396 Appendix B. 1398 Once a proxy is discovered the pledge communicates with a registrar 1399 through the proxy using the bootstrapping protocol defined in 1400 Section 5. 1402 While the GRASP M_FLOOD mechanism is passive for the pledge, the 1403 optional other methods (mDNS, and IPv4 methods) are active. The 1404 pledge SHOULD run those methods in parallel with listening to for the 1405 M_FLOOD. The active methods SHOULD exponentially back-off to a 1406 maximum of one hour to avoid overloading the network with discovery 1407 attempts. Detection of change of physical link status (ethernet 1408 carrier for instance) SHOULD reset the exponential back off. 1410 The pledge could discover more than one proxy on a given physical 1411 interface. The pledge can have a multitude of physical interfaces as 1412 well: a layer-2/3 ethernet switch may have hundreds of physical 1413 ports. 1415 Each possible proxy offer SHOULD be attempted up to the point where a 1416 voucher is received: while there are many ways in which the attempt 1417 may fail, it does not succeed until the voucher has been validated. 1419 The connection attempts via a single proxy SHOULD exponentially back- 1420 off to a maximum of one hour to avoid overloading the network 1421 infrastructure. The back-off timer for each MUST be independent of 1422 other connection attempts. 1424 Connection attempts SHOULD be run in parallel to avoid head of queue 1425 problems wherein an attacker running a fake proxy or registrar could 1426 perform protocol actions intentionally slowly. The pledge SHOULD 1427 continue to listen to for additional GRASP M_FLOOD messages during 1428 the connection attempts. 1430 Once a connection to a registrar is established (e.g. establishment 1431 of a TLS session key) there are expectations of more timely 1432 responses, see Section 5.2. 1434 Once all discovered services are attempted (assuming that none 1435 succeeded) the device MUST return to listening for GRASP M_FLOOD. It 1436 SHOULD periodically retry the manufacturer specific mechanisms. The 1437 pledge MAY prioritize selection order as appropriate for the 1438 anticipated environment. 1440 4.1.1. Proxy GRASP announcements 1442 A proxy uses the DULL GRASP M_FLOOD mechanism to announce itself. 1443 This announcement can be within the same message as the ACP 1444 announcement detailed in [I-D.ietf-anima-autonomic-control-plane]. 1445 The M_FLOOD is formatted as follows: 1447 [M_FLOOD, 12340815, h'fe800000000000000000000000000001', 180000, 1448 ["AN_Proxy", 4, 1, ""], 1449 [O_IPv6_LOCATOR, 1450 h'fe800000000000000000000000000001', IPPROTO_TCP, 4443]] 1452 Figure 6b: Proxy Discovery 1454 The formal CDDL [I-D.ietf-cbor-cddl] definition is: 1456 flood-message = [M_FLOOD, session-id, initiator, ttl, 1457 +[objective, (locator-option / [])]] 1459 objective = ["AN_Proxy", objective-flags, loop-count, 1460 objective-value] 1462 ttl = 180000 ; 180,000 ms (3 minutes) 1463 initiator = ACP address to contact Registrar 1464 objective-flags = sync-only ; as in GRASP spec 1465 sync-only = 4 ; M_FLOOD only requires synchronization 1466 loop-count = 1 ; one hop only 1467 objective-value = any ; none 1469 locator-option = [ O_IPv6_LOCATOR, ipv6-address, 1470 transport-proto, port-number ] 1471 ipv6-address = the v6 LL of the Proxy 1472 $transport-proto /= IPPROTO_TCP ; note this can be any value from the 1473 ; IANA protocol registry, as per 1474 ; [GRASP] section 2.9.5.1, note 3. 1475 port-number = selected by Proxy 1477 Figure 6c: AN_Proxy CDDL 1479 On a small network the Registrar MAY include the GRASP M_FLOOD 1480 announcements to locally connected networks. 1482 The $transport-proto above indicates the method that the pledge- 1483 proxy-registrar will use. The TCP method described here is 1484 mandatory, and other proxy methods, such as CoAP methods not defined 1485 in this document are optional. Other methods MUST NOT be enabled 1486 unless the Join Registrar ASA indicates support for them in it's own 1487 announcement. 1489 4.2. CoAP connection to Registrar 1491 The use of CoAP to connect from pledge to registrar is out of scope 1492 for this document, and is described in future work. See 1493 [I-D.ietf-anima-constrained-voucher]. 1495 4.3. Proxy discovery and communication of Registrar 1497 The registrar SHOULD announce itself so that proxies can find it and 1498 determine what kind of connections can be terminated. 1500 The registrar announces itself using ACP instance of GRASP using 1501 M_FLOOD messages. ANI proxies MUST support GRASP discovery of 1502 registrars. 1504 The M_FLOOD is formatted as follows: 1506 [M_FLOOD, 12340815, h'fda379a6f6ee00000200000064000001', 180000, 1507 ["AN_join_registrar", 4, 255, "EST-TLS"], 1508 [O_IPv6_LOCATOR, 1509 h'fda379a6f6ee00000200000064000001', IPPROTO_TCP, 80]] 1511 Figure 7a: Registrar Discovery 1513 The formal CDDL definition is: 1515 flood-message = [M_FLOOD, session-id, initiator, ttl, 1516 +[objective, (locator-option / [])]] 1518 objective = ["AN_join_registrar", objective-flags, loop-count, 1519 objective-value] 1521 initiator = ACP address to contact Registrar 1522 objective-flags = sync-only ; as in GRASP spec 1523 sync-only = 4 ; M_FLOOD only requires synchronization 1524 loop-count = 255 ; mandatory maximum 1525 objective-value = text ; name of the (list of) of supported 1526 ; protocols: "EST-TLS" for RFC7030. 1528 Figure 7: AN_join_registrar CDDL 1530 The M_FLOOD message MUST be sent periodically. The period is subject 1531 to network administrator policy (EST server configuration). It must 1532 be sufficiently low that the aggregate amount of periodic M_FLOODs 1533 from all EST servers causes negligible traffic across the ACP. 1535 Here are some examples of locators for illustrative purposes. Only 1536 the first one ($transport-protocol = 6, TCP) is defined in this 1537 document and is mandatory to implement. 1539 locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] 1540 locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] 1541 locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] 1543 A protocol of 6 indicates that TCP proxying on the indicated port is 1544 desired. 1546 Registrars MUST announce the set of protocols that they support. 1547 They MUST support TCP traffic. 1549 Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated. 1551 Registrars MUST support ANI TLS circuit proxy and therefore BRSKI 1552 across HTTPS/TLS native across the ACP. 1554 In the ANI, the Autonomic Control Plane (ACP) secured instance of 1555 GRASP ([I-D.ietf-anima-grasp]) MUST be used for discovery of ANI 1556 registrar ACP addresses and ports by ANI proxies. The TCP leg of the 1557 proxy connection between ANI proxy and ANI registrar therefore also 1558 runs across the ACP. 1560 5. Protocol Details (Pledge - Registrar - MASA) 1562 The pledge MUST initiate BRSKI after boot if it is unconfigured. The 1563 pledge MUST NOT automatically initiate BRSKI if it has been 1564 configured or is in the process of being configured. 1566 BRSKI is described as extensions to EST [RFC7030]. The goal of these 1567 extensions is to reduce the number of TLS connections and crypto 1568 operations required on the pledge. The registrar implements the 1569 BRSKI REST interface within the same "/.well-known" URI tree as the 1570 existing EST URIs as described in EST [RFC7030] section 3.2.2. The 1571 communication channel between the pledge and the registrar is 1572 referred to as "BRSKI-EST" (see Figure 1). 1574 The communication channel between the registrar and MASA is similarly 1575 described as extensions to EST within the same "/.well-known" tree. 1576 For clarity this channel is referred to as "BRSKI-MASA". (See 1577 Figure 1). 1579 MASA URI is "https://" iauthority "/.well-known/est". 1581 BRSKI uses existing CMS message formats for existing EST operations. 1582 BRSKI uses JSON [RFC7159] for all new operations defined here, and 1583 voucher formats. 1585 While EST section 3.2 does not insist upon use of HTTP 1.1 persistent 1586 connections, BRSKI-EST connections SHOULD use persistent connections. 1587 The intention of this guidance is to ensure the provisional TLS state 1588 occurs only once, and that the subsequent resolution of the provision 1589 state is not subject to a MITM attack during a critical phase. 1591 Summarized automation extensions for the BRSKI-EST flow are: 1593 o The pledge either attempts concurrent connections via each 1594 discovered proxy, or it times out quickly and tries connections in 1595 series, as explained at the end of Section 5.1. 1597 o The pledge provisionally accepts the registrar certificate during 1598 the TLS handshake as detailed in Section 5.1. 1600 o The pledge requests and validates a voucher using the new REST 1601 calls described below. 1603 o The pledge completes authentication of the server certificate as 1604 detailed in Section 5.6.1. This moves the BRSKI-EST TLS 1605 connection out of the provisional state. 1607 o Mandatory boostrap steps conclude with voucher status telemetry 1608 (see Section 5.7). 1610 The BRSKI-EST TLS connection can now be used for EST enrollment. 1612 The extensions for a registrar (equivalent to EST server) are: 1614 o Client authentication is automated using Initial Device Identity 1615 (IDevID) as per the EST certificate based client authentication. 1616 The subject field's DN encoding MUST include the "serialNumber" 1617 attribute with the device's unique serial number. 1619 o In the language of [RFC6125] this provides for a SERIALNUM-ID 1620 category of identifier that can be included in a certificate and 1621 therefore that can also be used for matching purposes. The 1622 SERIALNUM-ID whitelist is collated according to manufacturer trust 1623 anchor since serial numbers are not globally unique. 1625 o The registrar requests and validates the voucher from the MASA. 1627 o The registrar forwards the voucher to the pledge when requested. 1629 o The registrar performs log verifications in addition to local 1630 authorization checks before accepting optional pledge device 1631 enrollment requests. 1633 5.1. BRSKI-EST TLS establishment details 1635 The pledge establishes the TLS connection with the registrar through 1636 the circuit proxy (see Section 4) but the TLS handshake is with the 1637 registrar. The BRSKI-EST pledge is the TLS client and the BRSKI-EST 1638 registrar is the TLS server. All security associations established 1639 are between the pledge and the registrar regardless of proxy 1640 operations. 1642 Establishment of the BRSKI-EST TLS connection is as specified in EST 1643 [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" 1644 [RFC7030] wherein the client is authenticated with the IDevID 1645 certificate, and the EST server (the registrar) is provisionally 1646 authenticated with an unverified server certificate. 1648 The pledge maintains a security paranoia concerning the provisional 1649 state, and all data received, until a voucher is received and 1650 verified as specified in Section 5.6.1 1652 A Pledge that can connect to multiple registries concurrently, SHOULD 1653 do so. Some devices may be unable to do so for lack of threading, or 1654 resource issues. Concurrent connections defeat atttempts by a 1655 malicious proxy from causing a TCP Slowloris-like attack (see 1656 [slowloris]). 1658 A pledge that can not maintain as many connections as there are 1659 eligible proxies. If no connection is making process after 5 seconds 1660 then the pledge SHOULD drop the oldest connection and go on to a 1661 different proxy: the proxy that has been communicated with least 1662 recently. If there were no other proxies discovered, the pledge MAY 1663 continue to wait, as long as it is concurrently listening for new 1664 proxy announcements. 1666 5.2. Pledge Requests Voucher from the Registrar 1668 When the pledge bootstraps it makes a request for a voucher from a 1669 registrar. 1671 This is done with an HTTPS POST using the operation path value of 1672 "/.well-known/est/requestvoucher". 1674 The pledge voucher-request Content-Type is: 1676 application/voucher-cms+json The request is a "YANG-defined JSON 1677 document that has been signed using a CMS structure" as described 1678 in Section 3 using the JSON encoding described in [RFC7951]. This 1679 voucher media type is defined in [RFC8366] and is also used for 1680 the pledge voucher-request. The pledge SHOULD sign the request 1681 using the Section 2.3 credential. 1683 Registrar impementations SHOULD anticipate future media types but of 1684 course will simply fail the request if those types are not yet known. 1686 The pledge SHOULD include an [RFC7231] section 5.3.2 "Accept" header 1687 indicating the acceptable media type for the voucher response. The 1688 "application/voucher-cms+json" media type is defined in [RFC8366] but 1689 constrained voucher formats are expected in the future. Registrar's 1690 and MASA's are expected to be flexible in what they accept. 1692 The pledge populates the voucher-request fields as follows: 1694 created-on: Pledges that have a realtime clock are RECOMMENDED to 1695 populate this field. This provides additional information to the 1696 MASA. 1698 nonce: The pledge voucher-request MUST contain a cryptographically 1699 strong random or pseudo-random number nonce. (see [RFC4086]) Doing 1700 so ensures Section 2.6.1 functionality. The nonce MUST NOT be 1701 reused for multiple bootstrapping attempts. (The registrar 1702 voucher-request MAY omit the nonce as per Section 3.1) 1704 proximity-registrar-cert: In a pledge voucher-request this is the 1705 first certificate in the TLS server 'certificate_list' sequence 1706 (see [RFC5246]) presented by the registrar to the pledge. This 1707 MUST be populated in a pledge voucher-request if the "proximity" 1708 assertion is populated. 1710 All other fields MAY be omitted in the pledge voucher-request. 1712 An example JSON payload of a pledge voucher-request is in Section 3.3 1713 Example 1. 1715 The registrar validates the client identity as described in EST 1716 [RFC7030] section 3.3.2. The registrar confirms that the 'proximity' 1717 assertion and associated 'proximity-registrar-cert' are correct. 1719 5.3. Registrar Authorization of Pledge 1721 In a fully automated network all devices must be securely identified 1722 and authorized to join the domain. 1724 A Registrar accepts or declines a request to join the domain, based 1725 on the authenticated identity presented. Automated acceptance 1726 criteria include: 1728 o allow any device of a specific type (as determined by the X.509 1729 IDevID), 1731 o allow any device from a specific vendor (as determined by the 1732 X.509 IDevID), 1734 o allow a specific device from a vendor (as determined by the X.509 1735 IDevID) against a domain white list. (The mechanism for checking 1736 a shared white list potentially used by multiple Registrars is out 1737 of scope). 1739 If these validations fail the registrar SHOULD respond with an 1740 appropriate HTTP error code. 1742 If authorization is successful the registrar obtains a voucher from 1743 the MASA service (see Section 5.5) and returns that MASA signed 1744 voucher to the pledge as described in Section 5.6. 1746 5.4. BRSKI-MASA TLS establishment details 1748 The BRSKI-MASA TLS connection is a 'normal' TLS connection 1749 appropriate for HTTPS REST interfaces. The registrar initiates the 1750 connection and uses the MASA URL obtained as described in Section 2.8 1751 for [RFC6125] authentication of the MASA. 1753 The primary method of registrar "authentication" by the MASA is 1754 detailed in Section 5.5. As detailed in Section 11 the MASA might 1755 find it necessary to request additional registrar authentication. 1757 The MASA and the registrars SHOULD be prepared to support TLS client 1758 certificate authentication and/or HTTP Basic or Digest authentication 1759 as described in [RFC7030] for EST clients. This connection MAY also 1760 have no client authentication at all (Section 7.4) 1762 The authentication of the BRSKI-MASA connection does not affect the 1763 voucher-request process, as voucher-requests are already signed by 1764 the registrar. Instead, this authentication provides access control 1765 to the audit log. 1767 Implementors are advised that contacting the MASA is to establish a 1768 secured REST connection with a web service and that there are a 1769 number of authentication models being explored within the industry. 1770 Registrars are RECOMMENDED to fail gracefully and generate useful 1771 administrative notifications or logs in the advent of unexpected HTTP 1772 401 (Unauthorized) responses from the MASA. 1774 5.5. Registrar Requests Voucher from MASA 1776 When a registrar receives a pledge voucher-request it in turn submits 1777 a registrar voucher-request to the MASA service via an HTTPS RESTful 1778 interface ([RFC7231]). 1780 This is done with an HTTP POST using the operation path value of 1781 "/.well-known/est/requestvoucher". 1783 The voucher media type "application/voucher-cms+json" is defined in 1784 [RFC8366] and is also used for the registrar voucher-request. It is 1785 a JSON document that has been signed using a CMS structure. The 1786 registrar MUST sign the registrar voucher-request. The entire 1787 registrar certificate chain, up to and including the Domain CA, MUST 1788 be included in the CMS structure. 1790 MASA impementations SHOULD anticipate future media types but of 1791 course will simply fail the request if those types are not yet known. 1793 The Registrar SHOULD include an [RFC7231] section 5.3.2 "Accept" 1794 header indicating the response media types that are acceptable. This 1795 list SHOULD be the entire list presented to the Registrar in the 1796 Pledge's original request (see Section 5.2) but MAY be a subset. 1797 MASA's are expected to be flexible in what they accept. 1799 The registrar populates the voucher-request fields as follows: 1801 created-on: Registrars are RECOMMENDED to populate this field. This 1802 provides additional information to the MASA. 1804 nonce: This is the value from the pledge voucher-request. The 1805 registrar voucher-request MAY omit the nonce as per Section 3.1) 1807 serial-number: The serial number of the pledge the registrar would 1808 like a voucher for. The registrar determines this value by 1809 parsing the authenticated pledge IDevID certificate. See 1810 Section 2.3. The registrar MUST verify that the serial number 1811 field it parsed matches the serial number field the pledge 1812 provided in its voucher-request. This provides a sanity check 1813 useful for detecting error conditions and logging. The registrar 1814 MUST NOT simply copy the serial number field from a pledge voucher 1815 request as that field is claimed but not certified. 1817 idevid-issuer: The idevid-issuer value from the pledge certificate 1818 is included to ensure a statistically unique identity. 1820 prior-signed-voucher-request: The signed pledge voucher-request 1821 SHOULD be included in the registrar voucher-request. (NOTE: what 1822 is included is the complete pledge voucher-request, inclusive of 1823 the 'assertion', 'proximity-registrar-cert', etc wrapped by the 1824 pledge's original signature). If a signed voucher-request was not 1825 recieved from the pledge then this leaf is omitted from the 1826 registrar voucher request. 1828 A nonceless registrar voucher-request MAY be submitted to the MASA. 1829 Doing so allows the registrar to request a voucher when the pledge is 1830 offline, or when the registrar anticipates not being able to connect 1831 to the MASA while the pledge is being deployed. Some use cases 1832 require the registrar to learn the appropriate IDevID SerialNumber 1833 field and appropriate 'Accept header' field values from the physical 1834 device labeling or from the sales channel (out-of-scope for this 1835 document). 1837 All other fields MAY be omitted in the registrar voucher-request. 1839 Example JSON payloads of registrar voucher-requests are in 1840 Section 3.3 Examples 2 through 4. 1842 The MASA verifies that the registrar voucher-request is internally 1843 consistent but does not necessarily authenticate the registrar 1844 certificate since the registrar is not known to the MASA in advance. 1845 The MASA performs the actions and validation checks described in the 1846 following sub-sections before issuing a voucher. 1848 5.5.1. MASA renewal of expired vouchers 1850 As described in [RFC8366] vouchers are normally short lived to avoid 1851 revocation issues. If the request is for a previous (expired) 1852 voucher using the same registrar then the request for a renewed 1853 voucher SHOULD be automatically authorized. The MASA has sufficient 1854 information to determine this by examining the request, the registrar 1855 authentication, and the existing audit log. The issuance of a 1856 renewed voucher is logged as detailed in Section 5.6. 1858 To inform the MASA that existing vouchers are not to be renewed one 1859 can update or revoke the registrar credentials used to authorize the 1860 request (see Section 5.5.3 and Section 5.5.4). More flexible methods 1861 will likely involve sales channel integration and authorizations 1862 (details are out-of-scope of this document). 1864 5.5.2. MASA verification of voucher-request signature consistency 1866 The MASA MUST verify that the registrar voucher-request is signed by 1867 a registrar. This is confirmed by verifying that the id-kp-cmcRA 1868 extended key usage extension field (as detailed in EST RFC7030 1869 section 3.6.1) exists in the certificate of the entity that signed 1870 the registrar voucher-request. This verification is only a 1871 consistency check that the unauthenticated domain CA intended the 1872 voucher-request signer to be a registrar. Performing this check 1873 provides value to the domain PKI by assuring the domain administrator 1874 that the MASA service will only respect claims from authorized 1875 Registration Authorities of the domain. 1877 The MASA verifies that the domain CA certificate is included in the 1878 CMS structure as detailed in Section 5.5. 1880 5.5.3. MASA authentication of registrar (certificate) 1882 If a nonceless voucher-request is submitted the MASA MUST 1883 authenticate the registrar as described in either EST [RFC7030] 1884 section 3.2, section 3.3, or by validating the registrar's 1885 certificate used to sign the registrar voucher-request. Any of these 1886 methods reduce the risk of DDoS attacks and provide an authenticated 1887 identity as an input to sales channel integration and authorizations 1888 (details are out-of-scope of this document). 1890 In the nonced case, validation of the registrar MAY be omitted if the 1891 device policy is to accept audit-only vouchers. 1893 5.5.4. MASA revocation checking of registrar (certificate) 1895 As noted in Section 5.5.3 the MASA performs registrar authentication 1896 in a subset of situations (e.g. nonceless voucher requests). Normal 1897 PKIX revocation checking is assumed during either EST client 1898 authentication or voucher-request signature validation. Similarly, 1899 as noted in Section 5.5.2, the MASA performs normal PKIX revocation 1900 checking during signature consistency checks (a signature by a 1901 registrar certificate that has been revoked is an inconsistency). 1903 5.5.5. MASA verification of pledge prior-signed-voucher-request 1905 The MASA MAY verify that the registrar voucher-request includes the 1906 'prior-signed-voucher-request' field. If so the prior-signed- 1907 voucher-request MUST include a 'proximity-registrar-cert' that is 1908 consistent with the certificate used to sign the registrar voucher- 1909 request. Additionally the voucher-request serial-number leaf MUST 1910 match the pledge serial-number that the MASA extracts from the 1911 signing certificate of the prior-signed-voucher-request. The MASA is 1912 aware of which pledges support signing of their voucher requests and 1913 can use this information to confirm proximity of the pledge with the 1914 registrar, thus ensuring that the BRSKI-EST TLS connection has no 1915 man-in-the-middle. 1917 If these checks succeed the MASA updates the voucher and audit log 1918 assertion leafs with the "proximity" assertion. 1920 5.5.6. MASA pinning of registrar 1922 The registrar's certificate chain is extracted from the signature 1923 method. The chain includes the domain CA certificate as specified in 1924 Section 5.5. This certificate is used to populate the "pinned- 1925 domain-cert" of the voucher being issued. The domainID (e.g., hash 1926 of the root public key) is determined from the pinned-domain-cert and 1927 is used to update the audit log. 1929 5.5.7. MASA nonce handling 1931 The MASA does not verify the nonce itself. If the registrar voucher- 1932 request contains a nonce, and the prior-signed-voucher-request is 1933 exist, then the MASA MUST verify that the nonce is consistent. 1934 (Recall from above that the voucher-request might not contain a 1935 nonce, see Section 5.5 and Section 5.5.3). 1937 The MASA MUST use the nonce from the registrar voucher-request for 1938 the resulting voucher and audit log. The prior-signed-voucher- 1939 request nonce is ignored during this operation. 1941 5.6. MASA and Registrar Voucher Response 1943 The MASA voucher response to the registrar is forwarded without 1944 changes to the pledge; therefore this section applies to both the 1945 MASA and the registrar. The HTTP signaling described applies to both 1946 the MASA and registrar responses. A registrar either caches prior 1947 MASA responses or dynamically requests a new voucher based on local 1948 policy (it does not generate or sign a voucher). Registrar 1949 evaluation of the voucher itself is purely for transparency and audit 1950 purposes to further inform log verification (see Section 5.8.2) and 1951 therefore a registrar could accept future voucher formats that are 1952 opaque to the registrar. 1954 If the voucher-request is successful, the server (MASA responding to 1955 registrar or registrar responding to pledge) response MUST contain an 1956 HTTP 200 response code. The server MUST answer with a suitable 4xx 1957 or 5xx HTTP [RFC2616] error code when a problem occurs. In this 1958 case, the response data from the MASA MUST be a plaintext human- 1959 readable (ASCII, English) error message containing explanatory 1960 information describing why the request was rejected. 1962 The registrar MAY respond with an HTTP 202 ("the request has been 1963 accepted for processing, but the processing has not been completed") 1964 as described in EST [RFC7030] section 4.2.3 wherein the client "MUST 1965 wait at least the specified 'Retry-After' time before repeating the 1966 same request". (see [RFC7231] section 6.6.4) The pledge is 1967 RECOMMENDED to provide local feedback (blinked LED etc) during this 1968 wait cycle if mechanisms for this are available. To prevent an 1969 attacker registrar from significantly delaying bootstrapping the 1970 pledge MUST limit the 'Retry-After' time to 60 seconds. Ideally the 1971 pledge would keep track of the appropriate Retry-After header values 1972 for any number of outstanding registrars but this would involve a 1973 state table on the pledge. Instead the pledge MAY ignore the exact 1974 Retry-After value in favor of a single hard coded value (a registrar 1975 that is unable to complete the transaction after the first 60 seconds 1976 has another chance a minute later). A pledge SHOULD only maintain a 1977 202 retry-state for up to 4 days, which is longer than a long 1978 weekend, after which time the enrollment attempt fails and the pledge 1979 returns to discovery state. 1981 In order to avoid infinite redirect loops, which a malicious 1982 registrar might do in order to keep the pledge from discovering the 1983 correct registrar, the pledge MUST NOT follow more than one 1984 redirection (3xx code) to another web origins. EST supports 1985 redirection but requires user input; this change allows the pledge to 1986 follow a single redirection without a user interaction. 1988 A 403 (Forbidden) response is appropriate if the voucher-request is 1989 not signed correctly, stale, or if the pledge has another outstanding 1990 voucher that cannot be overridden. 1992 A 404 (Not Found) response is appropriate when the request is for a 1993 device that is not known to the MASA. 1995 A 406 (Not Acceptable) response is appropriate if a voucher of the 1996 desired type or using the desired algorithms (as indicated by the 1997 Accept: headers, and algorithms used in the signature) cannot be 1998 issued such as because the MASA knows the pledge cannot process that 1999 type. The registrar SHOULD use this response if it determines the 2000 pledge is unacceptable due to inventory control, MASA audit logs, or 2001 any other reason. 2003 A 415 (Unsupported Media Type) response is approriate for a request 2004 that has a voucher-request or accept encoding that is not understood. 2006 The voucher response format is as indicated in the submitted accept 2007 header or based on the MASA's prior understanding of proper format 2008 for this Pledge. Only the [RFC8366] "application/voucher-cms+json" 2009 media type is defined at this time. The syntactic details of 2010 vouchers are described in detail in [RFC8366]. For example, the 2011 voucher consists of: 2013 { 2014 "ietf-voucher:voucher": { 2015 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 2016 "assertion": "logging" 2017 "pinned-domain-cert": "base64encodedvalue==" 2018 "serial-number": "JADA123456789" 2019 } 2020 } 2022 The MASA populates the voucher fields as follows: 2024 nonce: The nonce from the pledge if available. See Section 5.5.7. 2026 assertion: The method used to verify assertion. See Section 5.5.5. 2028 pinned-domain-cert: The domain CA cert. See Section 5.5.6. This 2029 figure is illustrative, for an example, see Appendix D.2 2031 serial-number: The serial-number as provided in the voucher-request. 2032 Also see Section 5.5.5. 2034 domain-cert-revocation-checks: Set as appropriate for the pledge's 2035 capabilities and as documented in [RFC8366]. The MASA MAY set 2036 this field to 'false' since setting it to 'true' would require 2037 that revocation information be available to the pledge and this 2038 document does not make normative requirements for [RFC6961] or 2039 equivalent integrations. 2041 expires-on: This is set for nonceless vouchers. The MASA ensures 2042 the voucher lifetime is consistent with any revocation or pinned- 2043 domain-cert consistency checks the pledge might perform. See 2044 section Section 2.6.1. There are three times to consider: (a) a 2045 configured voucher lifetime in the MASA, (b) the expiry time for 2046 the registrar's certificate, (c) any certificate revocation 2047 information (CRL) lifetime. The expires-on field SHOULD be before 2048 the earliest of these three values. Typically (b) will be some 2049 significant time in the future, but (c) will typically be short 2050 (on the order of a week or less). The RECOMMENDED period for (a) 2051 is on the order of 20 minutes, so it will typically determine the 2052 lifespan of the resulting voucher. 20 minutes is sufficent time 2053 to reach the post-provisional state in the pledge, at which point 2054 there is an established trust relationship between pledge and 2055 registrar. The subsequent operations can take as long as required 2056 from that point onwards. The lifetime of the voucher has no 2057 impact on the lifespan of the ownership relationship. 2059 Whenever a voucher is issued the MASA MUST update the audit log 2060 appropriately. The internal state requirements to maintain the audit 2061 log are out-of-scope. See Section 5.8.1 for a discussion of 2062 reporting the log to a registrar. 2064 5.6.1. Pledge voucher verification 2066 The pledge MUST verify the voucher signature using the manufacturer 2067 installed trust anchor(s) associated with the manufacturer's MASA 2068 (this is likely included in the pledge's firmware). Management of 2069 the manufacter installed trust anchor(s) is out-of-scope of this 2070 document; this protocol does not update these trust anchor(s). 2072 The pledge MUST verify the serial-number field of the signed voucher 2073 matches the pledge's own serial-number. 2075 The pledge MUST verify that the voucher nonce field is accurate and 2076 matches the nonce the pledge submitted to this registrar, or that the 2077 voucher is nonceless (see Section 7.2). 2079 The pledge MUST be prepared to parse and fail gracefully from a 2080 voucher response that does not contain a 'pinned-domain-cert' field. 2081 The pledge MUST be prepared to ignore additional fields that it does 2082 not recognize. 2084 5.6.2. Pledge authentication of provisional TLS connection 2086 The 'pinned-domain-cert' element of the voucher contains the domain 2087 CA's public key. The pledge MUST use the 'pinned-domain-cert' trust 2088 anchor to immediately complete authentication of the provisional TLS 2089 connection. 2091 If a registrar's credentials cannot be verified using the pinned- 2092 domain-cert trust anchor from the voucher then the TLS connection is 2093 immediately discarded and the pledge abandons attempts to bootstrap 2094 with this discovered registrar. The pledge SHOULD send voucher 2095 status telemetry (described below) before closing the TLS connection. 2096 The pledge MUST attempt to enroll using any other proxies it has 2097 found. It SHOULD return to the same proxy again after attempting 2098 with other proxies. Attempts should be attempted in the exponential 2099 backoff described earlier. Attempts SHOULD be repeated as failure 2100 may be the result of a temporary inconsistently (an inconsistently 2101 rolled registrar key, or some other mis-configuration). The 2102 inconsistently could also be the result an active MITM attack on the 2103 EST connection. 2105 The registrar MUST use a certificate that chains to the pinned- 2106 domain-cert as its TLS server certificate. 2108 The pledge's PKIX path validation of a registrar certificate's 2109 validity period information is as described in Section 2.6.1. Once 2110 the PKIX path validation is successful the TLS connection is no 2111 longer provisional. 2113 The pinned-domain-cert MAY be installed as an trust anchor for future 2114 operations such as enrollment (e.g. [RFC7030] as recommended) or 2115 trust anchor management or raw protocols that do not need full PKI 2116 based key management. It can be used to authenticate any dynamically 2117 discovered EST server that contain the id-kp-cmcRA extended key usage 2118 extension as detailed in EST RFC7030 section 3.6.1; but to reduce 2119 system complexity the pledge SHOULD avoid additional discovery 2120 operations. Instead the pledge SHOULD communicate directly with the 2121 registrar as the EST server. The 'pinned-domain-cert' is not a 2122 complete distribution of the [RFC7030] section 4.1.3 CA Certificate 2123 Response, which is an additional justification for the recommendation 2124 to proceed with EST key management operations. Once a full CA 2125 Certificate Response is obtained it is more authoritative for the 2126 domain than the limited 'pinned-domain-cert' response. 2128 5.7. Pledge BRSKI Status Telemetry 2130 The domain is expected to provide indications to the system 2131 administrators concerning device lifecycle status. To facilitate 2132 this it needs telemetry information concerning the device's status. 2134 To indicate pledge status regarding the voucher, the pledge MUST post 2135 a status message. 2137 The posted data media type: application/json 2139 The client HTTP POSTs the following to the server at the EST well 2140 known URI "/voucher_status". The Status field indicates if the 2141 voucher was acceptable. If it was not acceptable the Reason string 2142 indicates why. In the failure case this message may be sent to an 2143 unauthenticated, potentially malicious registrar and therefore the 2144 Reason string SHOULD NOT provide information beneficial to an 2145 attacker. The operational benefit of this telemetry information is 2146 balanced against the operational costs of not recording that an 2147 voucher was ignored by a client the registrar expected to continue 2148 joining the domain. 2150 { 2151 "version":"1", 2152 "Status":FALSE /* TRUE=Success, FALSE=Fail" 2153 "Reason":"Informative human readable message" 2154 "reason-context": { additional JSON } 2155 } 2157 The server SHOULD respond with an HTTP 200 but MAY simply fail with 2158 an HTTP 404 error. The client ignores any response. Within the 2159 server logs the server SHOULD capture this telemetry information. 2161 The reason-context attribute is an arbitrary JSON object (literal 2162 value or hash of values) which provides additional information 2163 specific to this pledge. The contents of this field are not subject 2164 to standardization. 2166 Additional standard JSON fields in this POST MAY be added, see 2167 Section 8.3. 2169 5.8. Registrar audit log request 2171 After receiving the pledge status telemetry Section 5.7, the 2172 registrar SHOULD request the MASA audit log from the MASA service. 2174 This is done with an HTTP GET using the operation path value of 2175 "/.well-known/est/requestauditlog". 2177 The registrar SHOULD HTTP POST the same registrar voucher-request as 2178 it did when requesting a voucher (using the same Content-Type). It 2179 is posted to the /requestauditlog URI instead. The "idevid-issuer" 2180 and "serial-number" informs the MASA which log is requested so the 2181 appropriate log can be prepared for the response. Using the same 2182 media type and message minimizes cryptographic and message operations 2183 although it results in additional network traffic. The relying MASA 2184 implementation MAY leverage internal state to associate this request 2185 with the original, and by now already validated, voucher-request so 2186 as to avoid an extra crypto validation. 2188 A registrar MAY request logs at future times. If the registrar 2189 generates a new request then the MASA is forced to perform the 2190 additional cryptographic operations to verify the new request. 2192 A MASA that receives a request for a device that does not exist, or 2193 for which the requesting owner was never an owner returns an HTTP 404 2194 ("Not found") code. 2196 Rather than returning the audit log as a response to the POST (with a 2197 return code 200), the MASA MAY instead return a 201 ("Created") 2198 RESTful response ([RFC7231] section 7.1) containing a URL to the 2199 prepared (and easily cachable) audit response. 2201 In order to avoid enumeration of device audit logs, MASA that return 2202 URLs SHOULD take care to make the returned URL unguessable. For 2203 instance, rather than returning URLs containing a database number 2204 such as https://example.com/auditlog/1234 or the EUI of the device 2205 such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD 2206 return a randomly generated value (a "slug" in web parlance). The 2207 value is used to find the relevant database entry. 2209 A MASA that returns a code 200 MAY also include a Location: header 2210 for future reference by the registrar. 2212 5.8.1. MASA audit log response 2214 A log data file is returned consisting of all log entries associated 2215 with the the device selected by the IDevID presented in the request. 2216 The audit log may be truncated of old or repeated values as explained 2217 below. The returned data is in JSON format ([RFC7951]), and the 2218 Content-Type SHOULD be "application/json". For example: 2220 { 2221 "version":"1", 2222 "events":[ 2223 { 2224 "date":"", 2225 "domainID":"", 2226 "nonce":"" 2227 "assertion":"" 2228 "truncated":"" 2229 }, 2230 { 2231 "date":"", 2232 "domainID":"", 2233 "nonce":"" 2234 "assertion":"" 2235 } 2236 ], 2237 "truncation": { 2238 "nonced duplicates": "", 2239 "nonceless duplicates": "", 2240 "arbitrary": "" 2241 } 2242 } 2244 Distribution of a large log is less than ideal. This structure can 2245 be optimized as follows: Nonced or Nonceless entries for the same 2246 domainID MAY be truncated from the log leaving only the single most 2247 recent nonced or nonceless entry for that domainID. In the case of 2248 truncation the 'event' truncation value SHOULD contain a count of the 2249 number of events for this domainID that were truncated. The log 2250 SHOULD NOT be further reduced but there could exist operational 2251 situation where maintaining the full log is not possible. In such 2252 situations the log MAY be arbitrarily truncated for length, with the 2253 number of removed entries indicated as 'arbitrary'. 2255 If the truncation count exceeds 1024 then the MASA MAY use this value 2256 without further incrementing it. 2258 A log where duplicate entries for the same domain have been truncated 2259 ("nonced duplicates" and/or "nonceless duplicates) could still be 2260 acceptable for informed decisions. A log that has had "arbitrary" 2261 truncations is less acceptable but manufacturer transparency is 2262 better than hidden truncations. 2264 This document specifies a simple log format as provided by the MASA 2265 service to the registrar. This format could be improved by 2266 distributed consensus technologies that integrate vouchers with 2267 technologies such as block-chain or hash trees or optimized logging 2268 approaches. Doing so is out of the scope of this document but is an 2269 anticipated improvement for future work. As such, the registrar 2270 client SHOULD anticipate new kinds of responses, and SHOULD provide 2271 operator controls to indicate how to process unknown responses. 2273 5.8.2. Registrar audit log verification 2275 Each time the Manufacturer Authorized Signing Authority (MASA) issues 2276 a voucher, it places it into the audit log for that device. The 2277 details are described in Section 5.8. The contents of the audit log 2278 can express a variety of trust levels, and this section explains what 2279 kind of trust a registrar can derive from the entries. 2281 While the audit log provides a list of vouchers that were issued by 2282 the MASA, the vouchers are issued in response to voucher-requests, 2283 and it is the contents of the voucher-requests which determines how 2284 meaningful the audit log entries are. 2286 A registrar SHOULD use the log information to make an informed 2287 decision regarding the continued bootstrapping of the pledge. The 2288 exact policy is out of scope of this document as it depends on the 2289 security requirements within the registrar domain. Equipment that is 2290 purchased pre-owned can be expected to have an extensive history. 2291 The following dicussion is provided to help explain the value of each 2292 log element: 2294 date: The date field provides the registrar an opportunity to divide 2295 the log around known events such as the purchase date. Depending 2296 on context known to the registrar or administrator evens before/ 2297 after certain dates can have different levels of importance. For 2298 example for equipment that is expected to be new, and thus have no 2299 history, it would be a surprise to find prior entries. 2301 domainID: If the log includes an unexpected domainID then the pledge 2302 could have imprinted on an unexpected domain. The registrar can 2303 be expected to use a variety of techniques to define "unexpected" 2304 ranging from white lists of prior domains to anomoly detection 2305 (e.g. "this device was previously bound to a different domain than 2306 any other device deployed"). Log entries can also be compared 2307 against local history logs in search of discrepancies (e.g. "this 2308 device was re-deployed some number of times internally but the 2309 external audit log shows additional re-deployments our internal 2310 logs are unaware of"). 2312 nonce: Nonceless entries mean the logged domainID could 2313 theoretically trigger a reset of the pledge and then take over 2314 management by using the existing nonceless voucher. 2316 assertion: The assertion leaf in the voucher and audit log indicates 2317 why the MASA issued the voucher. A "verified" entry means that 2318 the MASA issued the associated voucher as a result of positive 2319 verification of ownership but this can still be problematic for 2320 registrar's that expected only new (not pre-owned) pledges. A 2321 "logged" assertion informs the registrar that the prior vouchers 2322 were issued with minimal verification. A "proximity" assertion 2323 assures the registrar that the pledge was truly communicating with 2324 the prior domain and thus provides assurance that the prior domain 2325 really has deployed the pledge. 2327 A relatively simple policy is to white list known (internal or 2328 external) domainIDs and to require all vouchers to have a nonce and/ 2329 or require that all nonceless vouchers be from a subset (e.g. only 2330 internal) domainIDs. A simple action is to revoke any locally issued 2331 credentials for the pledge in question or to refuse to forward the 2332 voucher. A registrar MAY be configured to ignore the history of the 2333 device but it is RECOMMENDED that this only be configured if hardware 2334 assisted NEA [RFC5209] is supported. 2336 5.9. EST Integration for PKI bootstrapping 2338 The pledge SHOULD follow the BRSKI operations with EST enrollment 2339 operations including "CA Certificates Request", "CSR Attributes" and 2340 "Client Certificate Request" or "Server-Side Key Generation", etc. 2341 This is a relatively seamless integration since BRSKI REST calls 2342 provide an automated alternative to the manual bootstrapping method 2343 described in [RFC7030]. As noted above, use of HTTP 1.1 persistent 2344 connections simplifies the pledge state machine. 2346 Although EST allows clients to obtain multiple certificates by 2347 sending multiple CSR requests BRSKI mandates use of the CSR 2348 Attributes request and mandates that the registrar validate the CSR 2349 against the expected attributes. This implies that client requests 2350 will "look the same" and therefore result in a single logical 2351 certificate being issued even if the client were to make multiple 2352 requests. Registrars MAY contain more complex logic but doing so is 2353 out-of-scope of this specification. BRSKI does not signal any 2354 enhancement or restriction to this capability. 2356 5.9.1. EST Distribution of CA Certificates 2358 The pledge SHOULD request the full EST Distribution of CA 2359 Certificates message. See RFC7030, section 4.1. 2361 This ensures that the pledge has the complete set of current CA 2362 certificates beyond the pinned-domain-cert (see Section 5.6.1 for a 2363 discussion of the limitations inherent in having a single certificate 2364 instead of a full CA Certificates response.) Although these 2365 limitations are acceptable during initial bootstrapping, they are not 2366 appropriate for ongoing PKIX end entity certificate validation. 2368 5.9.2. EST CSR Attributes 2370 Automated bootstrapping occurs without local administrative 2371 configuration of the pledge. In some deployments it is plausible 2372 that the pledge generates a certificate request containing only 2373 identity information known to the pledge (essentially the X.509 2374 IDevID information) and ultimately receives a certificate containing 2375 domain specific identity information. Conceptually the CA has 2376 complete control over all fields issued in the end entity 2377 certificate. Realistically this is operationally difficult with the 2378 current status of PKI certificate authority deployments, where the 2379 CSR is submitted to the CA via a number of non-standard protocols. 2380 Even with all standardized protocols used, it could operationally be 2381 problematic to expect that service specific certificate fields can be 2382 created by a CA that is likely operated by a group that has no 2383 insight into different network services/protocols used. For example, 2384 the CA could even be outsourced. 2386 To alleviate these operational difficulties, the pledge MUST request 2387 the EST "CSR Attributes" from the EST server and the EST server needs 2388 to be able to reply with the attributes necessary for use of the 2389 certificate in its intended protocols/services. This approach allows 2390 for minimal CA integrations and instead the local infrastructure (EST 2391 server) informs the pledge of the proper fields to include in the 2392 generated CSR. This approach is beneficial to automated boostrapping 2393 in the widest number of environments. 2395 If the hardwareModuleName in the X.509 IDevID is populated then it 2396 SHOULD by default be propagated to the LDevID along with the 2397 hwSerialNum. The EST server SHOULD support local policy concerning 2398 this functionality. 2400 In networks using the BRSKI enrolled certificate to authenticate the 2401 ACP (Autonomic Control Plane), the EST attributes MUST include the 2402 "ACP information" field. See 2403 [I-D.ietf-anima-autonomic-control-plane] for more details. 2405 The registrar MUST also confirm that the resulting CSR is formatted 2406 as indicated before forwarding the request to a CA. If the registrar 2407 is communicating with the CA using a protocol such as full CMC, which 2408 provides mechanisms to override the CSR attributes, then these 2409 mechanisms MAY be used even if the client ignores CSR Attribute 2410 guidance. 2412 5.9.3. EST Client Certificate Request 2414 The pledge MUST request a new client certificate. See RFC7030, 2415 section 4.2. 2417 5.9.4. Enrollment Status Telemetry 2419 For automated bootstrapping of devices, the adminstrative elements 2420 providing bootstrapping also provide indications to the system 2421 administrators concerning device lifecycle status. This might 2422 include information concerning attempted bootstrapping messages seen 2423 by the client, MASA provides logs and status of credential 2424 enrollment. [RFC7030] assumes an end user and therefore does not 2425 include a final success indication back to the server. This is 2426 insufficient for automated use cases. 2428 To indicate successful enrollment the client SHOULD re-negotiate the 2429 EST TLS session using the newly obtained credentials. This occurs by 2430 the client initiating a new TLS ClientHello message on the existing 2431 TLS connection. The client MAY simply close the old TLS session and 2432 start a new one. The server MUST support either model. 2434 In the case of a FAIL, the Reason string indicates why the most 2435 recent enrollment failed. The SubjectKeyIdentifier field MUST be 2436 included if the enrollment attempt was for a keypair that is locally 2437 known to the client. If EST /serverkeygen was used and failed then 2438 the field is omitted from the status telemetry. 2440 In the case of a SUCCESS the Reason string is omitted. The 2441 SubjectKeyIdentifier is included so that the server can record the 2442 successful certificate distribution. 2444 Status media type: application/json 2446 The client HTTP POSTs the following to the server at the new EST well 2447 known URI /enrollstatus. 2449 { 2450 "version":"1", 2451 "Status":TRUE /* TRUE=Success, FALSE=Fail" 2452 "Reason":"Informative human readable message" 2453 "reason-context": "Additional information" 2454 } 2456 The server SHOULD respond with an HTTP 200 but MAY simply fail with 2457 an HTTP 404 error. 2459 Within the server logs the server MUST capture if this message was 2460 received over an TLS session with a matching client certificate. 2461 This allows for clients that wish to minimize their crypto operations 2462 to simply POST this response without renegotiating the TLS session - 2463 at the cost of the server not being able to accurately verify that 2464 enrollment was truly successful. 2466 5.9.5. Multiple certificates 2468 Pledges that require multiple certificates could establish direct EST 2469 connections to the registrar. 2471 5.9.6. EST over CoAP 2473 This document describes extensions to EST for the purposes of 2474 bootstrapping of remote key infrastructures. Bootstrapping is 2475 relevant for CoAP enrollment discussions as well. The defintion of 2476 EST and BRSKI over CoAP is not discussed within this document beyond 2477 ensuring proxy support for CoAP operations. Instead it is 2478 anticipated that a definition of CoAP mappings will occur in 2479 subsequent documents such as [I-D.ietf-ace-coap-est] and that CoAP 2480 mappings for BRSKI will be discussed either there or in future work. 2482 6. Clarification of transfer-encoding 2484 [RFC7030] defines it's endpoints to include a "Content-Transfer- 2485 Encoding" heading, and the payloads to be [RFC4648] Base64 encoded 2486 DER. 2488 When used within BRSKI, the original RFC7030 EST endpoints remain 2489 Base64 encoded, but the new BRSKI end points which send and receive 2490 binary artifacts (specifically, ../voucherrequest) are binary. That 2491 is, no encoding is used. 2493 In the BRSKI context, the EST "Content-Transfer-Encoding" header if 2494 present, SHOULD be ignored. This header does not need to included. 2496 7. Reduced security operational modes 2498 A common requirement of bootstrapping is to support less secure 2499 operational modes for support specific use cases. The following 2500 sections detail specific ways that the pledge, registrar and MASA can 2501 be configured to run in a less secure mode for the indicated reasons. 2503 This section is considered non-normative: use suggested methods MUST 2504 be detailed in specific profiles of BRSKI. This is the subject for 2505 future work. 2507 7.1. Trust Model 2509 This section explains the trust relationships detailed in 2510 Section 2.4: 2512 +--------+ +---------+ +------------+ +------------+ 2513 | Pledge | | Join | | Domain | |Manufacturer| 2514 | | | Proxy | | Registrar | | Service | 2515 | | | | | | | (Internet) | 2516 +--------+ +---------+ +------------+ +------------+ 2518 Figure 10 2520 Pledge: The pledge could be compromised and providing an attack 2521 vector for malware. The entity is trusted to only imprint using 2522 secure methods described in this document. Additional endpoint 2523 assessment techniques are RECOMMENDED but are out-of-scope of this 2524 document. 2526 Join Proxy: Provides proxy functionalities but is not involved in 2527 security considerations. 2529 Registrar: When interacting with a MASA a registrar makes all 2530 decisions. For Ownership Audit Vouchers (see [RFC8366]) the 2531 registrar is provided an opportunity to accept MASA decisions. 2533 Vendor Service, MASA: This form of manufacturer service is trusted 2534 to accurately log all claim attempts and to provide authoritative 2535 log information to registrars. The MASA does not know which 2536 devices are associated with which domains. These claims could be 2537 strengthened by using cryptographic log techniques to provide 2538 append only, cryptographic assured, publicly auditable logs. 2539 Current text provides only for a trusted manufacturer. 2541 Vendor Service, Ownership Validation: This form of manufacturer 2542 service is trusted to accurately know which device is owned by 2543 which domain. 2545 7.2. Pledge security reductions 2547 The pledge can choose to accept vouchers using less secure methods. 2548 These methods enable offline and emergency (touch based) deployment 2549 use cases: 2551 1. The pledge MUST accept nonceless vouchers. This allows for a use 2552 case where the registrar can not connect to the MASA at the 2553 deployment time. Logging and validity periods address the 2554 security considerations of supporting these use cases. 2556 2. Many devices already support "trust on first use" for physical 2557 interfaces such as console ports. This document does not change 2558 that reality. Devices supporting this protocol MUST NOT support 2559 "trust on first use" on network interfaces. This is because 2560 "trust on first use" over network interfaces would undermine the 2561 logging based security protections provided by this 2562 specification. 2564 3. The pledge MAY have an operational mode where it skips voucher 2565 validation one time. For example if a physical button is 2566 depressed during the bootstrapping operation. This can be useful 2567 if the manufacturer service is unavailable. This behavior SHOULD 2568 be available via local configuration or physical presence methods 2569 (such as use of a serial/craft console) to ensure new entities 2570 can always be deployed even when autonomic methods fail. This 2571 allows for unsecured imprint. 2573 It is RECOMMENDED that "trust on first use" or any method of skipping 2574 voucher validation (including use of craft serial console) only be 2575 available if hardware assisted Network Endpoint Assessment [RFC5209] 2576 is supported. This recommendation ensures that domain network 2577 monitoring can detect innappropriate use of offline or emergency 2578 deployment procedures when voucher-based bootstrapping is not used. 2580 7.3. Registrar security reductions 2582 A registrar can choose to accept devices using less secure methods. 2583 These methods are acceptable when low security models are needed, as 2584 the security decisions are being made by the local administrator, but 2585 they MUST NOT be the default behavior: 2587 1. A registrar MAY choose to accept all devices, or all devices of a 2588 particular type, at the administrator's discretion. This could 2589 occur when informing all registrars of unique identifiers of new 2590 entities might be operationally difficult. 2592 2. A registrar MAY choose to accept devices that claim a unique 2593 identity without the benefit of authenticating that claimed 2594 identity. This could occur when the pledge does not include an 2595 X.509 IDevID factory installed credential. New Entities without 2596 an X.509 IDevID credential MAY form the Section 5.2 request using 2597 the Section 5.5 format to ensure the pledge's serial number 2598 information is provided to the registrar (this includes the 2599 IDevID AuthorityKeyIdentifier value, which would be statically 2600 configured on the pledge.) The pledge MAY refuse to provide a 2601 TLS client certificate (as one is not available.) The pledge 2602 SHOULD support HTTP-based or certificate-less TLS authentication 2603 as described in EST RFC7030 section 3.3.2. A registrar MUST NOT 2604 accept unauthenticated New Entities unless it has been configured 2605 to do so by an administrator that has verified that only expected 2606 new entities can communicate with a registrar (presumably via a 2607 physically secured perimeter.) 2609 3. A registrar MAY submit a nonceless voucher-requests to the MASA 2610 service (by not including a nonce in the voucher-request.) The 2611 resulting vouchers can then be stored by the registrar until they 2612 are needed during bootstrapping operations. This is for use 2613 cases where the target network is protected by an air gap and 2614 therefore cannot contact the MASA service during pledge 2615 deployment. 2617 4. A registrar MAY ignore unrecognized nonceless log entries. This 2618 could occur when used equipment is purchased with a valid history 2619 being deployed in air gap networks that required permanent 2620 vouchers. 2622 5. A registrar MAY accept voucher formats of future types that can 2623 not be parsed by the Registrar. This reduces the Registrar's 2624 visibility into the exact voucher contents but does not change 2625 the protocol operations. 2627 7.4. MASA security reductions 2629 Lower security modes chosen by the MASA service affect all device 2630 deployments unless bound to the specific device identities. In which 2631 case these modes can be provided as additional features for specific 2632 customers. The MASA service can choose to run in less secure modes 2633 by: 2635 1. Not enforcing that a nonce is in the voucher. This results in 2636 distribution of a voucher that never expires and in effect makes 2637 the Domain an always trusted entity to the pledge during any 2638 subsequent bootstrapping attempts. That this occurred is 2639 captured in the log information so that the registrar can make 2640 appropriate security decisions when a pledge joins the Domain. 2641 This is useful to support use cases where registrars might not be 2642 online during actual device deployment. Because this results in 2643 a long lived voucher and does not require the proof that the 2644 device is online, this is only accepted when the registrar is 2645 authenticated by the MASA and authorized to provide this 2646 functionality. The MASA is RECOMMENDED to use this functionality 2647 only in concert with an enhanced level of ownership tracking 2648 (out-of-scope.) If the pledge device is known to have a real- 2649 time-clock that is set from the factory, use of a voucher 2650 validity period is RECOMMENDED. 2652 2. Not verifying ownership before responding with a voucher. This 2653 is expected to be a common operational model because doing so 2654 relieves the manufacturer providing MASA services from having to 2655 track ownership during shipping and supply chain and allows for a 2656 very low overhead MASA service. A registrar uses the audit log 2657 information as a defense in depth strategy to ensure that this 2658 does not occur unexpectedly (for example when purchasing new 2659 equipment the registrar would throw an error if any audit log 2660 information is reported.) The MASA SHOULD verify the 'prior- 2661 signed-voucher-request' information for pledges that support that 2662 functionality. This provides a proof-of-proximity check that 2663 reduces the need for ownership verification. 2665 8. IANA Considerations 2667 This document requires the following IANA actions: 2669 8.1. Well-known EST registration 2671 This document extends the definitions of "est" (so far defined via 2672 RFC7030) in the "https://www.iana.org/assignments/well-known-uris/ 2673 well-known-uris.xhtml" registry as follows: 2675 o add /.well-known/est/requestvoucher (see Section 5.5 ) 2677 o add /.well-known/est/requestauditlog (see Section 5.7) 2679 8.2. PKIX Registry 2681 IANA is requested to register the following: 2683 This document requests a number for id-mod-MASAURLExtn2016(TBD) from 2684 the pkix(7) id-mod(0) Registry. 2686 This document has received an early allocation from the id-pe 2687 registry (SMI Security for PKIX Certificate Extension) for id-pe- 2688 masa-url with the value 32, resulting in an OID of 2689 1.3.6.1.5.5.7.1.32. 2691 8.3. Pledge BRSKI Status Telemetry 2693 IANA is requested to create a new Registry entitled: "BRSKI 2694 Parameters", and within that Registry to create a table called: 2695 "Pledge BRSKI Status Telemetry Attributes". New items can be added 2696 using the Specification Required. The following items are to be in 2697 the initial registration, with this document (Section 5.7) as the 2698 reference: 2700 o version 2702 o Status 2704 o Reason 2706 o reason-context 2708 8.4. DNS Service Names 2710 IANA is requested to register the following Service Names: 2712 Service Name: _brski-proxy 2713 Transport Protocol(s): tcp 2714 Assignee: IESG . 2715 Contact: IESG 2716 Description: The Bootstrapping Remote Secure Key 2717 Infrastructures Proxy 2718 Reference: [This document] 2720 Service Name: _brski-registrar 2721 Transport Protocol(s): tcp 2722 Assignee: IESG . 2723 Contact: IESG 2724 Description: The Bootstrapping Remote Secure Key 2725 Infrastructures Registrar 2726 Reference: [This document] 2728 8.5. MUD File Extension for the MASA 2730 The IANA is requested to list the name "masa" in the MUD extensions 2731 registry defined in [I-D.ietf-opsawg-mud]. Its use is documented in 2732 Appendix C. 2734 9. Applicability to the Autonomic Control Plane 2736 This document provides a solution to the requirements for secure 2737 bootstrap set out in Using an Autonomic Control Plane for Stable 2738 Connectivity of Network Operations, Administration, and Maintenance 2739 [RFC8368], A Reference Model for Autonomic Networking 2740 [I-D.ietf-anima-reference-model] and specifically the An Autonomic 2741 Control Plane (ACP) [I-D.ietf-anima-autonomic-control-plane], section 2742 3.2 (Secure Bootstrap), and section 6.1 (ACP Domain, Certificate and 2743 Network). 2745 The protocol described in this document has appeal in a number of 2746 other non-ANIMA use cases. Such uses of the protocol will be 2747 deploying into other environments with different tradeoffs of 2748 privacy, security, reliability and autonomy from manufacturers. As 2749 such those use cases will need to provide their own applicability 2750 statements, and will need to address unique privacy and security 2751 considerations for the environments in which they are used. 2753 The autonomic control plane that this document provides bootstrap for 2754 is typically a medium to large Internet Service Provider 2755 organization, or an equivalent Enterprise that has signficant layer-3 2756 router connectivity. (A network consistenting of primarily layer-2 2757 is not excluded, but the adjacencies that the ACP will create and 2758 maintain will not reflect the topology until all devices participate 2759 in the ACP). 2761 As specified in the ANIMA charter, this work "..focuses on 2762 professionally-managed networks." Such a network has an operator and 2763 can do things like like install, configure and operate the Registrar 2764 function. The operator makes purchasing decisions and is aware of 2765 what manufacturers it expects to see on it's network. 2767 Such an operator also is capable of performing the traditional (craft 2768 serial-console) based bootstrap of devices. The zero-touch mechanism 2769 presented in this and the ACP document represents a signficiant 2770 efficiency: in particular it reduces the need to put senior experts 2771 on airplanes to configure devices in person. There is a recognition 2772 as the technology evolves that not every situation may work out, and 2773 occasionally a human still still have to visit. 2775 The BRSKI protocol is going into environments where there have 2776 already been quite a number of vendor proprietary management systems. 2777 Those are not expected to go away quickly, but rather to leverage the 2778 secure credentials that are provisioned by BRSKI. The connectivity 2779 requirements of said management systems are provided by the ACP. 2781 10. Privacy Considerations 2783 10.1. MASA audit log 2785 The MASA audit log includes a hash of the domainID for each Registrar 2786 a voucher has been issued to. This information is closely related to 2787 the actual domain identity, especially when paired with the anti-DDoS 2788 authentication information the MASA might collect. This could 2789 provide sufficient information for the MASA service to build a 2790 detailed understanding the devices that have been provisioned within 2791 a domain. 2793 There are a number of design choices that mitigate this risk. The 2794 domain can maintain some privacy since it has not necessarily been 2795 authenticated and is not authoritatively bound to the supply chain. 2797 Additionally the domainID captures only the unauthenticated subject 2798 key identifier of the domain. A privacy sensitive domain could 2799 theoretically generate a new domainID for each device being deployed. 2800 Similarly a privacy sensitive domain would likely purchase devices 2801 that support proximity assertions from a manufacturer that does not 2802 require sales channel integrations. This would result in a 2803 significant level of privacy while maintaining the security 2804 characteristics provided by Registrar based audit log inspection. 2806 10.2. What BRSKI-MASA reveals to the manufacturer 2808 The so-called "call-home" mechanism that occurs as part of the BRSKI- 2809 MASA connection standardizes what has been deemed by some as a 2810 sinister mechanism for corporate oversight of individuals. 2811 ([livingwithIoT] and [IoTstrangeThings] for a small sample). 2813 As the Autonomic Control Plane (ACP) usage of BRSKI is not targetted 2814 at individual usage of IoT devices, but rather at the Enterprise and 2815 ISP creation of networks in a zero-touch fashion, the "call-home" 2816 represents a different kind of concern. 2818 It needs to be re-iterated that the BRSKI-MASA mechanism only occurs 2819 once during the comissioning of the device. It is well defined, and 2820 although encrypted with TLS, it could in theory be made auditable as 2821 the contents are well defined. This connection does not occur when 2822 the device powers on or is restarted for normal routines. It is 2823 conceivable that a device could be forced to go through a full 2824 factory reset during an exceptional firmware update situation, after 2825 which enrollment would have be repeated. 2827 The BRSKI call-home mechanism is mediated via the owner's Registrar, 2828 and the information that is transmitted is directly auditable by the 2829 device owner. This is in stark constrast to many "call-home" 2830 protocols where the device autonomously calls home and uses an 2831 undocumented protocol. 2833 While the contents of the signed part of the pledge voucher request 2834 can not be changed, they are not encrypted at the registrar. The 2835 ability to audit the messages by the owner of the network prevents 2836 exfiltration of data by a nefarious pledge. The contents of an 2837 unsigned voucher request are, however, completely changeable by the 2838 Registrar. Both are, to re-iterate, encrypted by TLS while in 2839 transit. 2841 The BRSKI-MASA exchange reveals the following information to the 2842 manufacturer: 2844 o the identity of the device being enrolled (down to the serial- 2845 number!). 2847 o an identity of the domain owner in the form of the domain trust 2848 anchor. However, this is not a global PKI anchored name within 2849 the WebPKI, so this identity could be pseudonymous. If there is 2850 sales channel integration, then the MASA will have authenticated 2851 the domain owner, either via pinned certificate, or perhaps 2852 another HTTP authentication method, as per Section 5.5.3. 2854 o the time the device is activated, 2856 o the IP address of the domain Owner's Registrar. For ISPs and 2857 Enterprises, the IP address provides very clear geolocation of the 2858 owner. No amount of IP address privacy extensions ([RFC4941]) can 2859 do anything about this, as a simple whois lookup likely identifies 2860 the ISP or Enterprise from the upper bits anyway. A passive 2861 attacker who observes the connection definitely may conclude that 2862 the given enterprise/ISP is a customer of the particular equipment 2863 vendor. The precise model that is being enrolled will remain 2864 private. 2866 The above situation is to be distinguished from a residential/ 2867 individual person who registers a device from a manufacturer: that an 2868 enterprise/ISP purchases routing products is hardly worth mentioning. 2869 Deviations would, however, be notable. 2871 The situation is not improved by the enterprise/ISP using 2872 anonymization services such as ToR [Dingledine2004], as a TLS 1.2 2873 connection will reveal the ClientCertificate used, clearly 2874 identifying the enterprise/ISP involved. TLS 1.3 is better in this 2875 regard, but an active attacker can still discover the parties 2876 involved by performing a Man-In-The-Middle-Attack on the first 2877 attempt (breaking/killing it with a TCP RST), and then letting 2878 subsequent connection pass through. 2880 A manufacturer could attempt to mix the BRSKI-MASA traffic in with 2881 general traffic their site by hosting the MASA behind the same (set) 2882 of load balancers that the companies normal marketing site is hosted 2883 behind. This makes lots of sense from a straight capacity planning 2884 point of view as the same set of services (and the same set of 2885 Distributed Denial of Service mitigations) may be used. 2886 Unfortunately, as the BRSKI-MASA connections include TLS 2887 ClientCertificate exchanges, this may easily be observed in TLS 1.2, 2888 and a traffic analysis may reveal it even in TLS 1.3. This does not 2889 make such a plan irrelevant. There may be other organizational 2890 reasons to keep the marketing site (which is often subject to 2891 frequent redesigs, outsourcing, etc.) seperate from the MASA, which 2892 may need to operate reliably for decades. 2894 10.3. Manufacturers and Used or Stolen Equipment 2896 As explained above, the manufacturer receives information each time 2897 that a device which is in factory-default mode does a zero-touch 2898 bootstrap, and attempts to enroll into a domain owner's registrar. 2900 The manufacturer is therefore in a position to decline to issue a 2901 voucher if it detects that the new owner is not the same as the 2902 previous owner. 2904 1. This can be seen as a feature if the equipment is believed to 2905 have been stolen. If the legitimate owner notifies the 2906 manufacturer of the theft, then when the new owner brings the 2907 device up, if they use the zero-touch mechanism, the new 2908 (illegitimate) owner reveals their location and identity. 2910 2. In the case of Used equipment, the initial owner could inform the 2911 manufacturer of the sale, or the manufacturer may just permit 2912 resales unless told otherwise. In which case, the transfer of 2913 ownership simply occurs. 2915 3. A manufacturer could however decide not to issue a new voucher in 2916 response to a transfer of ownership. This is essentially the 2917 same as the stolen case, with the manufacturer having decided 2918 that the sale was not legitimate. 2920 4. There is a fourth case, if the manufacturer is providing 2921 protection against stolen devices. The manufacturer then has a 2922 responsability to protect the legitimate owner against fraudulent 2923 claims that the the equipment was stolen. Such a claim would 2924 cause the manufacturer to refuse to issue a new voucher. Should 2925 the device go through a deep factory reset (for instance, 2926 replacement of a damaged main board component, the device would 2927 not bootstrap. 2929 5. Finally, there is a fifth case: the manufacturer has decided to 2930 end-of-line the device, or the owner has not paid a yearly 2931 support amount, and the manufacturer refuses to issue new 2932 vouchers at that point. This last case is not new to the 2933 industry: many license systems are already deployed that have 2934 significantly worse effect. 2936 This section has outlined five situations in which a manufacturer 2937 could use the voucher system to enforce what are clearly license 2938 terms. A manufacturer that attempted to enforce license terms via 2939 vouchers would find it rather ineffective as the terms would only be 2940 enforced when the device is enrolled, and this is not (to repeat), a 2941 daily or even monthly occurrance. 2943 10.4. Manufacturers and Grey market equipment 2945 Manufacturers of devices often sell different products into different 2946 regional markets. Which product is available in which market can be 2947 driven by price differentials, support issues (some markets may 2948 require manuals and tech-support to be done in the local language), 2949 government export regulation (such as whether strong crypto is 2950 permitted to be exported, or permitted to be used in a particular 2951 market). When an domain owner obtains a device from a different 2952 market (they can be new) and transfers it to a different location, 2953 this is called a Grey Market. 2955 A manufacturer could decide not to issue a voucher to an enterprise/ 2956 ISP based upon their location. There are a number of ways which this 2957 could be determined: from the geolocation of the registrar, from 2958 sales channel knowledge about the customer, and what products are 2959 (un-)available in that market. If the device has a GPS the 2960 coordinates of the device could even be placed into an extension of 2961 the voucher. 2963 The above actions are not illegal, and not new. Many manufacturers 2964 have shipped crypto-weak (exportable) versions of firmware as the 2965 default on equipment for decades. The first task of an enterprise/ 2966 ISP has always been to login to a manufacturer system, show one's 2967 "entitlement" (country informatin, proof that support payments have 2968 been made), and receive either a new updated firmware, or a license 2969 key that will activate the correct firmware. 2971 BRSKI permits the above process to automated (in an autonomic 2972 fashion), and therefore perhaps encourages this kind of 2973 differentiation by reducing the cost of doing it. 2975 An issue that manufacturers will need to deal with in the above 2976 automated process is when a device is shipped to one country with one 2977 set of rules (or laws or entitlements), but the domain registry is in 2978 another one. Which rules apply is something will have to be worked 2979 out: the manufacturer could come to believe they are dealing with 2980 Grey market equipment, when it is simply dealing with a global 2981 enterprise. 2983 10.5. Some mitigations for meddling by manufacturers 2985 The most obvious mitigation is not to buy the product. Pick 2986 manufacturers that are up-front about their policies, who do not 2987 change them gratutiously. 2989 A manufacturer could provide a mechanism to manage the trust anchors 2990 and built-in certificates (IDevID) as an extension. This is a 2991 substantial amount of work, and may be an area for future 2992 standardization work. 2994 Replacement of the voucher validation anchors (usually pointing to 2995 the original manufacturer's MASA) with those of the new owner permits 2996 the new owner to issue vouchers to subsequent owners. This would be 2997 done by having the selling (old) owner to run a MASA. 2999 In order to automatically find the new MASA, the mechanism describe 3000 in this document is to look for the MASA URL extension in the IDevID. 3001 A new owner could override this in their Registrar, or the 3002 manufacturer could provide a mechanism to update or replace the 3003 IDevID prior to sale. 3005 Once the voucher trust anchor and the IDevID is replaced, then the 3006 device will no longer trust the manufacturer in any way. When a new 3007 owner performs a bootstrap, the device will point to a MASA that has 3008 been chosen, and will validate vouchers from this new entity. 3010 The BRSKI protocol depends upon a trust anchor on the device and an 3011 identity on the device. Management of these these entities 3012 facilitiates a few new operatonal modes without making any changes to 3013 the BRSKI protocol. Those modes include: offline modes where the 3014 domain owner operates an internal MASA for all devices, resell modes 3015 where the first domain owner becomes the MASA for the next (resold- 3016 to) domain owner, and services where an aggregator acquires a large 3017 variety of devices, and then acts as a pseudonymized MASA for a 3018 variety of devices from a variety of manufacturers. 3020 Some manufacturers may wish to consider replacement of the IDevID as 3021 an indication that the device's warantee is terminated. For others, 3022 the privacy requiments of some deployments might consider this a 3023 standard operating practice. 3025 As discussed at the end of Section 5.8.1, new work could be done to 3026 use a distributed consensus technology for the audit log. This would 3027 permit the audit log to continue to be useful, even when there is a 3028 chain of MASA due to changes of ownership. 3030 11. Security Considerations 3032 This document details a protocol for bootstrapping that balances 3033 operational concerns against security concerns. As detailed in the 3034 introduction, and touched on again in Section 7, the protocol allows 3035 for reduced security modes. These attempt to deliver additional 3036 control to the local administrator and owner in cases where less 3037 security provides operational benefits. This section goes into more 3038 detail about a variety of specific considerations. 3040 To facilitate logging and administrative oversight, in addition to 3041 triggering Registration verification of MASA logs, the pledge reports 3042 on voucher parsing status to the registrar. In the case of a 3043 failure, this information is informative to a potentially malicious 3044 registrar. This is mandated anyway because of the operational 3045 benefits of an informed administrator in cases where the failure is 3046 indicative of a problem. The registrar is RECOMMENDED to verify MASA 3047 logs if voucher status telemetry is not received. 3049 To facilitate truely limited clients EST RFC7030 section 3.3.2 3050 requirements that the client MUST support a client authentication 3051 model have been reduced in Section 7 to a statement that the 3052 registrar "MAY" choose to accept devices that fail cryptographic 3053 authentication. This reflects current (poor) practices in shipping 3054 devices without a cryptographic identity that are NOT RECOMMENDED. 3056 During the provisional period of the connection the pledge MUST treat 3057 all HTTP header and content data as untrusted data. HTTP libraries 3058 are regularly exposed to non-secured HTTP traffic: mature libraries 3059 should not have any problems. 3061 Pledges might chose to engage in protocol operations with multiple 3062 discovered registrars in parallel. As noted above they will only do 3063 so with distinct nonce values, but the end result could be multiple 3064 vouchers issued from the MASA if all registrars attempt to claim the 3065 device. This is not a failure and the pledge choses whichever 3066 voucher to accept based on internal logic. The registrars verifying 3067 log information will see multiple entries and take this into account 3068 for their analytics purposes. 3070 11.1. DoS against MASA 3072 There are uses cases where the MASA could be unavailable or 3073 uncooperative to the Registrar. They include active DoS attacks, 3074 planned and unplanned network partitions, changes to MASA policy, or 3075 other instances where MASA policy rejects a claim. These introduce 3076 an operational risk to the Registrar owner in that MASA behavior 3077 might limit the ability to bootstrap a pledge device. For example 3078 this might be an issue during disaster recovery. This risk can be 3079 mitigated by Registrars that request and maintain long term copies of 3080 "nonceless" vouchers. In that way they are guaranteed to be able to 3081 bootstrap their devices. 3083 The issuance of nonceless vouchers themselves creates a security 3084 concern. If the Registrar of a previous domain can intercept 3085 protocol communications then it can use a previously issued nonceless 3086 voucher to establish management control of a pledge device even after 3087 having sold it. This risk is mitigated by recording the issuance of 3088 such vouchers in the MASA audit log that is verified by the 3089 subsequent Registrar and by Pledges only bootstrapping when in a 3090 factory default state. This reflects a balance between enabling MASA 3091 independence during future bootstrapping and the security of 3092 bootstrapping itself. Registrar control over requesting and auditing 3093 nonceless vouchers allows device owners to choose an appropriate 3094 balance. 3096 The MASA is exposed to DoS attacks wherein attackers claim an 3097 unbounded number of devices. Ensuring a registrar is representative 3098 of a valid manufacturer customer, even without validating ownership 3099 of specific pledge devices, helps to mitigate this. Pledge 3100 signatures on the pledge voucher-request, as forwarded by the 3101 registrar in the prior-signed-voucher-request field of the registrar 3102 voucher-request, significantly reduce this risk by ensuring the MASA 3103 can confirm proximity between the pledge and the registrar making the 3104 request. This mechanism is optional to allow for constrained 3105 devices. Supply chain integration ("know your customer") is an 3106 additional step that MASA providers and device vendors can explore. 3108 11.2. Freshness in Voucher-Requests 3110 A concern has been raised that the pledge voucher-request should 3111 contain some content (a nonce) provided by the registrar and/or MASA 3112 in order for those actors to verify that the pledge voucher-request 3113 is fresh. 3115 There are a number of operational problems with getting a nonce from 3116 the MASA to the pledge. It is somewhat easier to collect a random 3117 value from the registrar, but as the registrar is not yet vouched 3118 for, such a registrar nonce has little value. There are privacy and 3119 logistical challenges to addressing these operational issues, so if 3120 such a thing were to be considered, it would have to provide some 3121 clear value. This section examines the impacts of not having a fresh 3122 pledge voucher-request. 3124 Because the registrar authenticates the pledge, a full Man-in-the- 3125 Middle attack is not possible, despite the provisional TLS 3126 authentication by the pledge (see Section 5.) Instead we examine the 3127 case of a fake registrar (Rm) that communicates with the pledge in 3128 parallel or in close time proximity with the intended registrar. 3129 (This scenario is intentionally supported as described in 3130 Section 4.1.) 3132 The fake registrar (Rm) can obtain a voucher signed by the MASA 3133 either directly or through arbitrary intermediaries. Assuming that 3134 the MASA accepts the registrar voucher-request (either because Rm is 3135 collaborating with a legitimate registrar according to supply chain 3136 information, or because the MASA is in audit-log only mode), then a 3137 voucher linking the pledge to the registrar Rm is issued. 3139 Such a voucher, when passed back to the pledge, would link the pledge 3140 to registrar Rm, and would permit the pledge to end the provisional 3141 state. It now trusts Rm and, if it has any security vulnerabilities 3142 leveragable by an Rm with full administrative control, can be assumed 3143 to be a threat against the intended registrar. 3145 This flow is mitigated by the intended registrar verifying the audit 3146 logs available from the MASA as described in Section 5.8. Rm might 3147 chose to collect a voucher-request but wait until after the intended 3148 registrar completes the authorization process before submitting it. 3149 This pledge voucher-request would be 'stale' in that it has a nonce 3150 that no longer matches the internal state of the pledge. In order to 3151 successfully use any resulting voucher the Rm would need to remove 3152 the stale nonce or anticipate the pledge's future nonce state. 3153 Reducing the possibility of this is why the pledge is mandated to 3154 generate a strong random or pseudo-random number nonce. 3156 Additionally, in order to successfully use the resulting voucher the 3157 Rm would have to attack the pledge and return it to a bootstrapping 3158 enabled state. This would require wiping the pledge of current 3159 configuration and triggering a re-bootstrapping of the pledge. This 3160 is no more likely than simply taking control of the pledge directly 3161 but if this is a consideration the target network is RECOMMENDED to 3162 take the following steps: 3164 o Ongoing network monitoring for unexpected bootstrapping attempts 3165 by pledges. 3167 o Retreival and examination of MASA log information upon the 3168 occurance of any such unexpected events. Rm will be listed in the 3169 logs along with nonce information for analysis. 3171 11.3. Trusting manufacturers 3173 The BRSKI extensions to EST permit a new pledge to be completely 3174 configured with domain specific trust anchors. The link from built- 3175 in manufacturer-provided trust anchors to domain-specific trust 3176 anchors is mediated by the signed voucher artifact. 3178 If the manufacturer's IDevID signing key is not properly validated, 3179 then there is a risk that the network will accept a pledge that 3180 should not be a member of the network. As the address of the 3181 manufacturer's MASA is provided in the IDevID using the extension 3182 from Section 2.3, the malicious pledge will have no problem 3183 collaborating with it's MASA to produce a completely valid voucher. 3185 BRSKI does not, however, fundamentally change the trust model from 3186 domain owner to manufacturer. Assuming that the pledge used its 3187 IDevID with RFC7030 EST and BRSKI, the domain (registrar) still needs 3188 to trust the manufacturer. 3190 Establishing this trust between domain and manufacturer is outside 3191 the scope of BRSKI. There are a number of mechanisms that can 3192 adopted including: 3194 o Manually configuring each manufacturer's trust anchor. 3196 o A Trust-On-First-Use (TOFU) mechanism. A human would be queried 3197 upon seeing a manufacturer's trust anchor for the first time, and 3198 then the trust anchor would be installed to the trusted store. 3199 There are risks with this; even if the key to name is validated 3200 using something like the WebPKI, there remains the possibility 3201 that the name is a look alike: e.g, dem0.example. vs demO.example. 3203 o scanning the trust anchor from a QR code that came with the 3204 packaging (this is really a manual TOFU mechanism) 3206 o some sales integration process where trust anchors are provided as 3207 part of the sales process, probably included in a digital packing 3208 "slip", or a sales invoice. 3210 o consortium membership, where all manufacturers of a particular 3211 device category (e.g, a light bulb, or a cable-modem) are signed 3212 by an certificate authority specifically for this. This is done 3213 by CableLabs today. It is used for authentication and 3214 authorization as part of TR-79: [docsisroot] and [TR069]. 3216 The existing WebPKI provides a reasonable anchor between manufacturer 3217 name and public key. It authenticates the key. It does not provide 3218 a reasonable authorization for the manufacturer, so it is not 3219 directly useable on it's own. 3221 11.4. Manufacturer Maintainance of trust anchors 3223 BRSKI depends upon the manufacturer building in trust anchors to the 3224 pledge device. The voucher artifact which is signed by the MASA will 3225 be validated by the pledge using that anchor. This implies that the 3226 manufacturer needs to maintain access to a signing key that the 3227 pledge can validate. 3229 The manufacturer will need to maintain the ability to make signatures 3230 that can be validated for the lifetime that the device could be 3231 onboarded. Whether this onboarding lifetime is less than the device 3232 lifetime depends upon how the device is used. An inventory of 3233 devices kept in a warehouse as spares might not be onboarded for many 3234 decades. 3236 There are good cryptographic hygiene reasons why a manufacturer would 3237 not want to maintain access to a private key for many decades. A 3238 manufacturer in that situation can leverage a long-term certificate 3239 authority anchor, built-in to the pledge, and then a certificate 3240 chain may be incorporated using the normal CMS certificate set. This 3241 may increase the size of the voucher artifacts, but that is not a 3242 significant issues in non-constrained environements. 3244 There are a few other operational variations that manufacturers could 3245 consider. For instance, there is no reason that every device need 3246 have the same set of trust anchors pre-installed. Devices built in 3247 different factories, or on different days, or any other consideration 3248 could have different trust anchors built in, and the record of which 3249 batch the device is in would be recorded in the asset database. The 3250 manufacturer would then know which anchor to sign an artifact 3251 against. 3253 Aside from the concern about long-term access to private keys, a 3254 major limiting factor for the shelf-life of many devices will be the 3255 age of the cryptographic algorithms included. A device produced in 3256 2019 will have hardware and software capable of validating algorithms 3257 common in 2019, and will have no defense against attacks (both 3258 quantum and von-neuman brute force attacks) which have not yet been 3259 invented. This concern is orthogonal to the concern about access to 3260 private keys, but this concern likely dominates and limits the 3261 lifespan of a device in a warehouse. If any update to firmware to 3262 support new cryptographic mechanism were possible (while the device 3263 was in a warehouse), updates to trust anchors would also be done at 3264 the same time. 3266 12. Acknowledgements 3268 We would like to thank the various reviewers for their input, in 3269 particular William Atwood, Brian Carpenter, Toerless Eckert, Fuyu 3270 Eleven, Eliot Lear, Sergey Kasatkin, Anoop Kumar, Markus Stenberg, 3271 Peter van der Stok, and Thomas Werner 3273 Significant reviews were done by Jari Arko, Christian Huitema and 3274 Russ Housley. 3276 13. References 3278 13.1. Normative References 3280 [I-D.ietf-anima-autonomic-control-plane] 3281 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 3282 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 3283 plane-19 (work in progress), March 2019. 3285 [I-D.ietf-anima-grasp] 3286 Bormann, C., Carpenter, B., and B. Liu, "A Generic 3287 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 3288 grasp-15 (work in progress), July 2017. 3290 [IDevID] "IEEE 802.1AR Secure Device Identifier", December 2009, 3291 . 3294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3295 Requirement Levels", BCP 14, RFC 2119, 3296 DOI 10.17487/RFC2119, March 1997, 3297 . 3299 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 3300 Levkowetz, Ed., "Extensible Authentication Protocol 3301 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 3302 . 3304 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 3305 Configuration of IPv4 Link-Local Addresses", RFC 3927, 3306 DOI 10.17487/RFC3927, May 2005, 3307 . 3309 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 3310 "Randomness Requirements for Security", BCP 106, RFC 4086, 3311 DOI 10.17487/RFC4086, June 2005, 3312 . 3314 [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol 3315 (LDAP): Schema for User Applications", RFC 4519, 3316 DOI 10.17487/RFC4519, June 2006, 3317 . 3319 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 3320 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 3321 . 3323 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 3324 Address Autoconfiguration", RFC 4862, 3325 DOI 10.17487/RFC4862, September 2007, 3326 . 3328 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 3329 Extensions for Stateless Address Autoconfiguration in 3330 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 3331 . 3333 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3334 (TLS) Protocol Version 1.2", RFC 5246, 3335 DOI 10.17487/RFC5246, August 2008, 3336 . 3338 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 3339 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 3340 . 3342 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 3343 Housley, R., and W. Polk, "Internet X.509 Public Key 3344 Infrastructure Certificate and Certificate Revocation List 3345 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 3346 . 3348 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 3349 Security: An Unauthenticated Mode of IPsec", RFC 5386, 3350 DOI 10.17487/RFC5386, November 2008, 3351 . 3353 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 3354 RFC 5652, DOI 10.17487/RFC5652, September 2009, 3355 . 3357 [RFC5660] Williams, N., "IPsec Channels: Connection Latching", 3358 RFC 5660, DOI 10.17487/RFC5660, October 2009, 3359 . 3361 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 3362 Verification of Domain-Based Application Service Identity 3363 within Internet Public Key Infrastructure Using X.509 3364 (PKIX) Certificates in the Context of Transport Layer 3365 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 3366 2011, . 3368 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 3369 DOI 10.17487/RFC6762, February 2013, 3370 . 3372 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 3373 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 3374 . 3376 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 3377 "Enrollment over Secure Transport", RFC 7030, 3378 DOI 10.17487/RFC7030, October 2013, 3379 . 3381 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 3382 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 3383 2014, . 3385 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 3386 RFC 7950, DOI 10.17487/RFC7950, August 2016, 3387 . 3389 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 3390 RFC 7951, DOI 10.17487/RFC7951, August 2016, 3391 . 3393 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 3394 "A Voucher Artifact for Bootstrapping Protocols", 3395 RFC 8366, DOI 10.17487/RFC8366, May 2018, 3396 . 3398 [RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic 3399 Control Plane for Stable Connectivity of Network 3400 Operations, Administration, and Maintenance (OAM)", 3401 RFC 8368, DOI 10.17487/RFC8368, May 2018, 3402 . 3404 13.2. Informative References 3406 [Dingledine2004] 3407 Dingledine, R., Mathewson, N., and P. Syverson, "Tor: the 3408 second-generation onion router", 2004, 3409 . 3411 [docsisroot] 3412 "CableLabs Digital Certificate Issuance Service", February 3413 2018, . 3416 [I-D.ietf-ace-coap-est] 3417 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 3418 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 3419 est-12 (work in progress), June 2019. 3421 [I-D.ietf-anima-constrained-voucher] 3422 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 3423 Voucher Artifacts for Bootstrapping Protocols", draft- 3424 ietf-anima-constrained-voucher-03 (work in progress), 3425 March 2019. 3427 [I-D.ietf-anima-reference-model] 3428 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 3429 and J. Nobre, "A Reference Model for Autonomic 3430 Networking", draft-ietf-anima-reference-model-10 (work in 3431 progress), November 2018. 3433 [I-D.ietf-anima-stable-connectivity] 3434 Eckert, T. and M. Behringer, "Using Autonomic Control 3435 Plane for Stable Connectivity of Network OAM", draft-ietf- 3436 anima-stable-connectivity-10 (work in progress), February 3437 2018. 3439 [I-D.ietf-cbor-cddl] 3440 Birkholz, H., Vigano, C., and C. Bormann, "Concise data 3441 definition language (CDDL): a notational convention to 3442 express CBOR and JSON data structures", draft-ietf-cbor- 3443 cddl-08 (work in progress), March 2019. 3445 [I-D.ietf-netconf-zerotouch] 3446 Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero 3447 Touch Provisioning (SZTP)", draft-ietf-netconf- 3448 zerotouch-29 (work in progress), January 2019. 3450 [I-D.ietf-opsawg-mud] 3451 Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 3452 Description Specification", draft-ietf-opsawg-mud-25 (work 3453 in progress), June 2018. 3455 [I-D.richardson-anima-state-for-joinrouter] 3456 Richardson, M., "Considerations for stateful vs stateless 3457 join router in ANIMA bootstrap", draft-richardson-anima- 3458 state-for-joinrouter-02 (work in progress), January 2018. 3460 [imprinting] 3461 "Wikipedia article: Imprinting", July 2015, 3462 . 3464 [IoTstrangeThings] 3465 "IoT of toys stranger than fiction: Cybersecurity and data 3466 privacy update (accessed 2018-12-02)", March 2017, 3467 . 3470 [livingwithIoT] 3471 "What is it actually like to live in a house filled with 3472 IoT devices? (accessed 2018-12-02)", February 2018, 3473 . 3476 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3477 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 3478 December 1998, . 3480 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 3481 Translator (NAT) Terminology and Considerations", 3482 RFC 2663, DOI 10.17487/RFC2663, August 1999, 3483 . 3485 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 3486 Uniform Resource Identifiers (URIs)", RFC 5785, 3487 DOI 10.17487/RFC5785, April 2010, 3488 . 3490 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 3491 Galperin, S., and C. Adams, "X.509 Internet Public Key 3492 Infrastructure Online Certificate Status Protocol - OCSP", 3493 RFC 6960, DOI 10.17487/RFC6960, June 2013, 3494 . 3496 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 3497 Multiple Certificate Status Request Extension", RFC 6961, 3498 DOI 10.17487/RFC6961, June 2013, 3499 . 3501 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 3502 Interface Identifiers with IPv6 Stateless Address 3503 Autoconfiguration (SLAAC)", RFC 7217, 3504 DOI 10.17487/RFC7217, April 2014, 3505 . 3507 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 3508 Constrained-Node Networks", RFC 7228, 3509 DOI 10.17487/RFC7228, May 2014, 3510 . 3512 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 3513 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 3514 DOI 10.17487/RFC7231, June 2014, 3515 . 3517 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 3518 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 3519 2014, . 3521 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 3522 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 3523 December 2014, . 3525 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 3526 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 3527 Networking: Definitions and Design Goals", RFC 7575, 3528 DOI 10.17487/RFC7575, June 2015, 3529 . 3531 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 3532 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 3533 . 3535 [slowloris] 3536 "Slowloris (computer security)", February 2019, 3537 . 3540 [Stajano99theresurrecting] 3541 Stajano, F. and R. Anderson, "The resurrecting duckling: 3542 security issues for ad-hoc wireless networks", 1999, 3543 . 3546 [TR069] "TR-69: CPE WAN Management Protocol", February 2018, 3547 . 3550 Appendix A. IPv4 and non-ANI operations 3552 The secification of BRSKI in Section 4 intentionally only covers the 3553 mechanisms for an IPv6 pledge using Link-Local addresses. This 3554 section describes non-normative extensions that can be used in other 3555 environments. 3557 A.1. IPv4 Link Local addresses 3559 Instead of an IPv6 link-local address, an IPv4 address may be 3560 generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local 3561 Addresses. 3563 In the case that an IPv4 Link-Local address is formed, then the 3564 bootstrap process would continue as in the IPv6 case by looking for a 3565 (circuit) proxy. 3567 A.2. Use of DHCPv4 3569 The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP 3570 provided parameters for the Domain Name System can be used to perform 3571 DNS operations if all local discovery attempts fail. 3573 Appendix B. mDNS / DNSSD proxy discovery options 3575 Pledge discovery of the proxy (Section 4.1) MAY be performed with 3576 DNS-based Service Discovery [RFC6763] over Multicast DNS [RFC6762] to 3577 discover the proxy at "_brski-proxy._tcp.local.". 3579 Proxy discovery of the registrar (Section 4.3) MAY be performed with 3580 DNS-based Service Discovery over Multicast DNS to discover registrars 3581 by searching for the service "_brski-registrar._tcp.local.". 3583 To prevent unaccceptable levels of network traffic, when using mDNS, 3584 the congestion avoidance mechanisms specified in [RFC6762] section 7 3585 MUST be followed. The pledge SHOULD listen for an unsolicited 3586 broadcast response as described in [RFC6762]. This allows devices to 3587 avoid announcing their presence via mDNS broadcasts and instead 3588 silently join a network by watching for periodic unsolicited 3589 broadcast responses. 3591 Discovery of registrar MAY also be performed with DNS-based service 3592 discovery by searching for the service "_brski- 3593 registrar._tcp.example.com". In this case the domain "example.com" 3594 is discovered as described in [RFC6763] section 11 (Appendix A.2 3595 suggests the use of DHCP parameters). 3597 If no local proxy or registrar service is located using the GRASP 3598 mechanisms or the above mentioned DNS-based Service Discovery methods 3599 the pledge MAY contact a well known manufacturer provided 3600 bootstrapping server by performing a DNS lookup using a well known 3601 URI such as "brski-registrar.manufacturer.example.com". The details 3602 of the URI are manufacturer specific. Manufacturers that leverage 3603 this method on the pledge are responsible for providing the registrar 3604 service. Also see Section 2.7. 3606 The current DNS services returned during each query are maintained 3607 until bootstrapping is completed. If bootstrapping fails and the 3608 pledge returns to the Discovery state, it picks up where it left off 3609 and continues attempting bootstrapping. For example, if the first 3610 Multicast DNS _bootstrapks._tcp.local response doesn't work then the 3611 second and third responses are tried. If these fail the pledge moves 3612 on to normal DNS-based Service Discovery. 3614 Appendix C. MUD Extension 3616 The following extension augments the MUD model to include a single 3617 node, as described in [I-D.ietf-opsawg-mud] section 3.6, using the 3618 following sample module that has the following tree structure: 3620 module: ietf-mud-brski-masa 3621 augment /ietf-mud:mud: 3622 +--rw masa-server? inet:uri 3624 The model is defined as follows: 3626 file "ietf-mud-extension@2018-02-14.yang" 3627 module ietf-mud-brski-masa { 3628 yang-version 1.1; 3629 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa"; 3630 prefix ietf-mud-brski-masa; 3631 import ietf-mud { 3632 prefix ietf-mud; 3633 } 3634 import ietf-inet-types { 3635 prefix inet; 3636 } 3638 organization 3639 "IETF ANIMA (Autonomic Networking Integrated Model and 3640 Approach) Working Group"; 3641 contact 3642 "WG Web: http://tools.ietf.org/wg/anima/ 3643 WG List: anima@ietf.org 3644 "; 3645 description 3646 "BRSKI extension to a MUD file to indicate the 3647 MASA URL."; 3649 revision 2018-02-14 { 3650 description 3651 "Initial revision."; 3652 reference 3653 "RFC XXXX: Manufacturer Usage Description 3654 Specification"; 3655 } 3657 augment "/ietf-mud:mud" { 3658 description 3659 "BRSKI extension to a MUD file to indicate the 3660 MASA URL."; 3661 leaf masa-server { 3662 type inet:uri; 3663 description 3664 "This value is the URI of the MASA server"; 3665 } 3666 } 3667 } 3668 3670 The MUD extensions string "masa" is defined, and MUST be included in 3671 the extensions array of the mud container of a MUD file when this 3672 extension is used. 3674 Appendix D. Example Vouchers 3676 Three entities are involved in a voucher: the MASA issues (signs) it, 3677 the registrar's public key is mentioned in the voucher, and the 3678 pledge validates it. In order to provide reproduceable examples the 3679 public and private keys for an example MASA and registrar are first 3680 listed. 3682 D.1. Keys involved 3684 The Manufacturer has a Certificate Authority that signs the pledge's 3685 IDevID. In addition the Manufacturer's signing authority (the MASA) 3686 signs the vouchers, and that certificate must distributed to the 3687 devices at manufacturing time so that vouchers can be validated. 3689 D.1.1. MASA key pair for voucher signatures 3691 This private key signs vouchers: 3693 -----BEGIN EC PRIVATE KEY----- 3694 MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho 3695 r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA 3696 zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz 3697 Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= 3698 -----END EC PRIVATE KEY----- 3700 This public key validates vouchers: 3702 -----BEGIN CERTIFICATE----- 3703 MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 3704 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 3705 IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw 3706 EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU 3707 BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R 3708 b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf 3709 w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO 3710 MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O 3711 DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd 3712 MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= 3713 -----END CERTIFICATE----- 3715 D.1.2. Manufacturer key pair for IDevID signatures 3717 This private key signs IDevID certificates: 3719 -----BEGIN EC PRIVATE KEY----- 3720 MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho 3721 r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA 3722 zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz 3723 Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= 3724 -----END EC PRIVATE KEY----- 3726 This public key validates IDevID certificates: 3728 -----BEGIN CERTIFICATE----- 3729 MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 3730 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 3731 IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw 3732 EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU 3733 BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R 3734 b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf 3735 w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO 3736 MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O 3737 DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd 3738 MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= 3739 -----END CERTIFICATE----- 3741 D.1.3. Registrar key pair 3743 The registrar key (or chain) is the representative of the domain 3744 owner. This key signs registrar voucher-requests: 3746 -----BEGIN EC PRIVATE KEY----- 3747 MHcCAQEEIF+obiToYYYeMifPsZvrjWJ0yFsCJwIFhpokmT/TULmXoAoGCCqGSM49 3748 AwEHoUQDQgAENWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g 3749 6W/P6boTmyTGdFOh/8HwKUerL5bpneK8sg== 3750 -----END EC PRIVATE KEY----- 3752 The public key is indicated in a pledge voucher-request to show 3753 proximity. 3755 -----BEGIN CERTIFICATE----- 3756 MIIBrjCCATOgAwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQBGRYC 3757 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5n 3758 IEZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQzES 3759 MBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRIw 3760 EAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ1ZA7N 3761 w0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8/puhObJMZ0U6H/ 3762 wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM49BAMDA2kAMGYCMQC3 3763 /iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nuNifVKtyaara3F30AIkKSEC 3764 MQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdDCR54TrSFNLgxvt1lyFM+0fYpYR 3765 c3o= 3766 -----END CERTIFICATE----- 3767 The registrar public certificate as decoded by openssl's x509 3768 utility. Note that the registrar certificate is marked with the 3769 cmcRA extension. 3771 Certificate: 3772 Data: 3773 Version: 3 (0x2) 3774 Serial Number: 3 (0x3) 3775 Signature Algorithm: ecdsa-with-SHA384 3776 Issuer: DC = ca, DC = sandelman, CN = Unstrung Fount 3777 ain CA 3778 Validity 3779 Not Before: Sep 5 01:12:45 2017 GMT 3780 Not After : Sep 5 01:12:45 2019 GMT 3781 Subject: DC = ca, DC = sandelman, CN = localhost 3782 Subject Public Key Info: 3783 Public Key Algorithm: id-ecPublicKey 3784 Public-Key: (256 bit) 3785 pub: 3786 04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7 3787 8:17: 3788 34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5 3789 3:3e: 3790 03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e 3791 9:ba: 3792 13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2 3793 f:96: 3794 e9:9d:e2:bc:b2 3795 ASN1 OID: prime256v1 3796 NIST CURVE: P-256 3797 X509v3 extensions: 3798 X509v3 Basic Constraints: 3799 CA:FALSE 3800 Signature Algorithm: ecdsa-with-SHA384 3801 30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78: 3802 5b: 3803 9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e: 3804 b6: 3805 9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21: 3806 02: 3807 31:00:e2:db:d7:9f:6d:32:db:76:d0:e4:de:d7:9c:63:fa: 3808 c3: 3809 ed:5e:fb:5d:a2:7a:9d:80:a6:74:30:91:e7:84:eb:48:53: 3810 4b: 3811 83:1b:ed:d6:5c:85:33:ed:1f:62:96:11:73:7a 3813 D.1.4. Pledge key pair 3815 The pledge has an IDevID key pair built in at manufacturing time: 3817 -----BEGIN EC PRIVATE KEY----- 3818 MHcCAQEEIBgR6SV+uEvWfl5zCQWZxWjYbMhXPyNqdHJ3KPh11mm4oAoGCCqGSM49 3819 AwEHoUQDQgAEWi/jqPpRJ0JgWghZRgeZlLKutbXVjmnHb+1AYaEF/YQjE2g5FZV8 3820 KjiR/bkEl+l8M4onIC7KHaXKKkuag9S6Tw== 3821 -----END EC PRIVATE KEY----- 3823 The public key is used by the registrar to find the MASA. The MASA 3824 URL is in an extension described in Section 2.3. 3826 -----BEGIN CERTIFICATE----- 3827 MIICBDCCAYugAwIBAgIECe20qTAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQB 3828 GRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3Ry 3829 dW5nIEhpZ2h3YXkgQ0EwIBcNMTkwNDI0MDIxNjU4WhgPMjk5OTEyMzEwMDAwMDBa 3830 MBwxGjAYBgNVBAUMETAwLWQwLWU1LTAyLTAwLTJkMFkwEwYHKoZIzj0CAQYIKoZI 3831 zj0DAQcDQgAEWi/jqPpRJ0JgWghZRgeZlLKutbXVjmnHb+1AYaEF/YQjE2g5FZV8 3832 KjiR/bkEl+l8M4onIC7KHaXKKkuag9S6T6OBhzCBhDAdBgNVHQ4EFgQUj8KYdUoE 3833 OvJ0kcOIbjEWwgWdDYkwCQYDVR0TBAIwADArBgNVHREEJDAioCAGCSsGAQQBgu5S 3834 AaATDBEwMC1EMC1FNS0wMi0wMC0yRDArBgkrBgEEAYLuUgIEHgwcbWFzYS5ob25l 3835 eWR1a2VzLnNhbmRlbG1hbi5jYTAKBggqhkjOPQQDAgNnADBkAjAmvMjmNgjypDhc 3836 fynMV3kMuIpSKrYzRWr4g3PtTwXDsAe0oitTTj4QtU1bajhOfTkCMGMNbsW2Q41F 3837 z9t6PDVdtOKabBbAP1RVoFTlDQuO9nmLzb5kU+cUqCtPRFZBUXP3kg== 3838 -----END CERTIFICATE----- 3840 The pledge public certificate as decoded by openssl's x509 utility so 3841 that the extensions can be seen. There is a second Custom Extension 3842 is included to provided to contain the EUI48/EUI64 that the pledge 3843 will configure as it's layer-2 address (this is non-normative). 3845 Certificate: 3846 Data: 3847 Version: 3 (0x2) 3848 Serial Number: 166573225 (0x9edb4a9) 3849 Signature Algorithm: ecdsa-with-SHA256 3850 Issuer: DC = ca, DC = sandelman, CN = Unstrung Highway CA 3851 Validity 3852 Not Before: Apr 24 02:16:58 2019 GMT 3853 Not After : Dec 31 00:00:00 2999 GMT 3854 Subject: serialNumber = 00-d0-e5-02-00-2d 3855 Subject Public Key Info: 3856 Public Key Algorithm: id-ecPublicKey 3857 Public-Key: (256 bit) 3858 pub: 3859 04:5a:2f:e3:a8:fa:51:27:42:60:5a:08:59:46:07: 3860 99:94:b2:ae:b5:b5:d5:8e:69:c7:6f:ed:40:61:a1: 3861 05:fd:84:23:13:68:39:15:95:7c:2a:38:91:fd:b9: 3862 04:97:e9:7c:33:8a:27:20:2e:ca:1d:a5:ca:2a:4b: 3863 9a:83:d4:ba:4f 3864 ASN1 OID: prime256v1 3865 NIST CURVE: P-256 3866 X509v3 extensions: 3867 X509v3 Subject Key Identifier: 3868 8F:C2:98:75:4A:04:3A:F2:74:91:C3:88:6E:31:16:C2:05:9D:0D:89 3869 X509v3 Basic Constraints: 3870 CA:FALSE 3871 X509v3 Subject Alternative Name: 3872 othername: 3873 1.3.6.1.4.1.46930.2: 3874 ..masa.honeydukes.sandelman.ca 3875 Signature Algorithm: ecdsa-with-SHA256 3876 30:64:02:30:26:bc:c8:e6:36:08:f2:a4:38:5c:7f:29:cc:57: 3877 79:0c:b8:8a:52:2a:b6:33:45:6a:f8:83:73:ed:4f:05:c3:b0: 3878 07:b4:a2:2b:53:4e:3e:10:b5:4d:5b:6a:38:4e:7d:39:02:30: 3879 63:0d:6e:c5:b6:43:8d:45:cf:db:7a:3c:35:5d:b4:e2:9a:6c: 3880 16:c0:3f:54:55:a0:54:e5:0d:0b:8e:f6:79:8b:cd:be:64:53: 3881 e7:14:a8:2b:4f:44:56:41:51:73:f7:92 3883 D.2. Example process 3885 RFC-EDITOR: these examples will need to be replaced with CMS versions 3886 once IANA has assigned the eContentType in [RFC8366]. 3888 D.2.1. Pledge to Registrar 3890 As described in Section 5.2, the pledge will sign a pledge voucher- 3891 request containing the registrar's public key in the proximity- 3892 registrar-cert field. The base64 has been wrapped at 60 characters 3893 for presentation reasons. 3895 -----BEGIN CMS----- 3896 MIIGtQYJKoZIhvcNAQcCoIIGpjCCBqICAQExDTALBglghkgBZQMEAgEwggNRBgkq 3897 hkiG9w0BBwGgggNCBIIDPnsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6 3898 eyJhc3NlcnRpb24iOiJwcm94aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAxOS0wNS0x 3899 NVQxNzoyNTo1NS42NDQtMDQ6MDAiLCJzZXJpYWwtbnVtYmVyIjoiMDAtZDAtZTUt 3900 MDItMDAtMmQiLCJub25jZSI6IlZPVUZULVd3ckV2ME51QVFFSG9WN1EiLCJwcm94 3901 aW1pdHktcmVnaXN0cmFyLWNlcnQiOiJNSUlCMFRDQ0FWYWdBd0lCQWdJQkFqQUtC 3902 Z2dxaGtqT1BRUURBekJ4TVJJd0VBWUtDWkltaVpQeUxHUUJHUllDWTJFeEdUQVhC 3903 Z29Ka2lhSmsvSXNaQUVaRmdsellXNWtaV3h0WVc0eFFEQStCZ05WQkFNTU55TThV 3904 M2x6ZEdWdFZtRnlhV0ZpYkdVNk1IZ3dNREF3TURBd05HWTVNVEZoTUQ0Z1ZXNXpk 3905 SEoxYm1jZ1JtOTFiblJoYVc0Z1EwRXdIaGNOTVRjeE1UQTNNak0wTlRJNFdoY05N 3906 VGt4TVRBM01qTTBOVEk0V2pCRE1SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhH 3907 VEFYQmdvSmtpYUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhFakFRQmdOVkJBTU1D 3908 V3h2WTJGc2FHOXpkREJaTUJNR0J5cUdTTTQ5QWdFR0NDcUdTTTQ5QXdFSEEwSUFC 3909 SlpsVUhJMHVwL2wzZVpmOXZDQmIrbElub0VNRWdjN1JvK1haQ3RqQUkwQ0QxZkpm 3910 SlIvaEl5eURtSFd5WWlORmJSQ0g5ZnlhcmZremdYNHAwelRpenFqRFRBTE1Ba0dB 3911 MVVkRXdRQ01BQXdDZ1lJS29aSXpqMEVBd01EYVFBd1pnSXhBTFFNTnVyZjh0djUw 3912 bFJPRDVEUVhIRU9KSk5XM1FWMmc5UUVkRFNrMk1ZK0FvU3JCU21HU05qaDRvbEVP 3913 aEV1TGdJeEFKNG5XZk53K0JqYlptS2lJaVVFY1R3SE1oR1ZYYU1IWS9GN24zOXd3 3914 S2NCQlNPbmROUHFDcE9FTGw2YnEzQ1pxUT09In19oIICCDCCAgQwggGLoAMCAQIC 3915 BAnttKkwCgYIKoZIzj0EAwIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZIm 3916 iZPyLGQBGRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdod2F5IENB 3917 MCAXDTE5MDQyNDAyMTY1OFoYDzI5OTkxMjMxMDAwMDAwWjAcMRowGAYDVQQFDBEw 3918 MC1kMC1lNS0wMi0wMC0yZDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABFov46j6 3919 USdCYFoIWUYHmZSyrrW11Y5px2/tQGGhBf2EIxNoORWVfCo4kf25BJfpfDOKJyAu 3920 yh2lyipLmoPUuk+jgYcwgYQwHQYDVR0OBBYEFI/CmHVKBDrydJHDiG4xFsIFnQ2J 3921 MAkGA1UdEwQCMAAwKwYDVR0RBCQwIqAgBgkrBgEEAYLuUgGgEwwRMDAtRDAtRTUt 3922 MDItMDAtMkQwKwYJKwYBBAGC7lICBB4MHG1hc2EuaG9uZXlkdWtlcy5zYW5kZWxt 3923 YW4uY2EwCgYIKoZIzj0EAwIDZwAwZAIwJrzI5jYI8qQ4XH8pzFd5DLiKUiq2M0Vq 3924 +INz7U8Fw7AHtKIrU04+ELVNW2o4Tn05AjBjDW7FtkONRc/bejw1XbTimmwWwD9U 3925 VaBU5Q0LjvZ5i82+ZFPnFKgrT0RWQVFz95IxggErMIIBJwIBATBVME0xEjAQBgoJ 3926 kiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEcMBoGA1UE 3927 AwwTVW5zdHJ1bmcgSGlnaHdheSBDQQIECe20qTALBglghkgBZQMEAgGgaTAYBgkq 3928 hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA1MTUyMTI1 3929 NTVaMC8GCSqGSIb3DQEJBDEiBCAQN2lP7aqwyhmj9qUHt6Qk/SbOTOPXFOwn1wv2 3930 5YGYgDAKBggqhkjOPQQDAgRHMEUCIEYQhHToU0rrhPyQv2fR0TwWePTx2Z1DEhR4 3931 tTl/Dr/ZAiEA47u9+bIz/p6nFJ+wctKHER+ycUzYQF56h9odMo+Ilkc= 3932 -----END CMS----- 3934 file: examples/vr_00-D0-E5-02-00-2D.pkcs 3936 The ASN1 decoding of the artifact: 3938 0:d=0 hl=4 l=1717 cons: SEQUENCE 3939 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData 3941 15:d=1 hl=4 l=1702 cons: cont [ 0 ] 3942 19:d=2 hl=4 l=1698 cons: SEQUENCE 3943 23:d=3 hl=2 l= 1 prim: INTEGER :01 3944 26:d=3 hl=2 l= 13 cons: SET 3945 28:d=4 hl=2 l= 11 cons: SEQUENCE 3946 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 3947 41:d=3 hl=4 l= 849 cons: SEQUENCE 3948 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 3949 56:d=4 hl=4 l= 834 cons: cont [ 0 ] 3950 60:d=5 hl=4 l= 830 prim: OCTET STRING :{"ietf-voucher-request:v 3951 894:d=3 hl=4 l= 520 cons: cont [ 0 ] 3952 898:d=4 hl=4 l= 516 cons: SEQUENCE 3953 902:d=5 hl=4 l= 395 cons: SEQUENCE 3954 906:d=6 hl=2 l= 3 cons: cont [ 0 ] 3955 908:d=7 hl=2 l= 1 prim: INTEGER :02 3956 911:d=6 hl=2 l= 4 prim: INTEGER :09EDB4A9 3957 917:d=6 hl=2 l= 10 cons: SEQUENCE 3958 919:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 3959 929:d=6 hl=2 l= 77 cons: SEQUENCE 3960 931:d=7 hl=2 l= 18 cons: SET 3961 933:d=8 hl=2 l= 16 cons: SEQUENCE 3962 935:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3963 947:d=9 hl=2 l= 2 prim: IA5STRING :ca 3964 951:d=7 hl=2 l= 25 cons: SET 3965 953:d=8 hl=2 l= 23 cons: SEQUENCE 3966 955:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 3967 967:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 3968 978:d=7 hl=2 l= 28 cons: SET 3969 980:d=8 hl=2 l= 26 cons: SEQUENCE 3970 982:d=9 hl=2 l= 3 prim: OBJECT :commonName 3971 987:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Highway CA 3972 1008:d=6 hl=2 l= 32 cons: SEQUENCE 3973 1010:d=7 hl=2 l= 13 prim: UTCTIME :190424021658Z 3974 1025:d=7 hl=2 l= 15 prim: GENERALIZEDTIME :29991231000000Z 3975 1042:d=6 hl=2 l= 28 cons: SEQUENCE 3976 1044:d=7 hl=2 l= 26 cons: SET 3977 1046:d=8 hl=2 l= 24 cons: SEQUENCE 3978 1048:d=9 hl=2 l= 3 prim: OBJECT :serialNumber 3979 1053:d=9 hl=2 l= 17 prim: UTF8STRING :00-d0-e5-02-00-2d 3980 1072:d=6 hl=2 l= 89 cons: SEQUENCE 3981 1074:d=7 hl=2 l= 19 cons: SEQUENCE 3982 1076:d=8 hl=2 l= 7 prim: OBJECT :id-ecPublicKey 3983 1085:d=8 hl=2 l= 8 prim: OBJECT :prime256v1 3984 1095:d=7 hl=2 l= 66 prim: BIT STRING 3985 1163:d=6 hl=3 l= 135 cons: cont [ 3 ] 3986 1166:d=7 hl=3 l= 132 cons: SEQUENCE 3987 1169:d=8 hl=2 l= 29 cons: SEQUENCE 3988 1171:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Key Ident 3989 1176:d=9 hl=2 l= 22 prim: OCTET STRING [HEX DUMP]:04148FC298754A 3990 1200:d=8 hl=2 l= 9 cons: SEQUENCE 3991 1202:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints 3992 1207:d=9 hl=2 l= 2 prim: OCTET STRING [HEX DUMP]:3000 3993 1211:d=8 hl=2 l= 43 cons: SEQUENCE 3994 1213:d=9 hl=2 l= 3 prim: OBJECT :X509v3 Subject Alternati 3995 1218:d=9 hl=2 l= 36 prim: OCTET STRING [HEX DUMP]:3022A02006092B 3996 1256:d=8 hl=2 l= 43 cons: SEQUENCE 3997 1258:d=9 hl=2 l= 9 prim: OBJECT :1.3.6.1.4.1.46930.2 3998 1269:d=9 hl=2 l= 30 prim: OCTET STRING [HEX DUMP]:0C1C6D6173612E 3999 1301:d=5 hl=2 l= 10 cons: SEQUENCE 4000 1303:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 4001 1313:d=5 hl=2 l= 103 prim: BIT STRING 4002 1418:d=3 hl=4 l= 299 cons: SET 4003 1422:d=4 hl=4 l= 295 cons: SEQUENCE 4004 1426:d=5 hl=2 l= 1 prim: INTEGER :01 4005 1429:d=5 hl=2 l= 85 cons: SEQUENCE 4006 1431:d=6 hl=2 l= 77 cons: SEQUENCE 4007 1433:d=7 hl=2 l= 18 cons: SET 4008 1435:d=8 hl=2 l= 16 cons: SEQUENCE 4009 1437:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 4010 1449:d=9 hl=2 l= 2 prim: IA5STRING :ca 4011 1453:d=7 hl=2 l= 25 cons: SET 4012 1455:d=8 hl=2 l= 23 cons: SEQUENCE 4013 1457:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 4014 1469:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4015 1480:d=7 hl=2 l= 28 cons: SET 4016 1482:d=8 hl=2 l= 26 cons: SEQUENCE 4017 1484:d=9 hl=2 l= 3 prim: OBJECT :commonName 4018 1489:d=9 hl=2 l= 19 prim: UTF8STRING :Unstrung Highway CA 4019 1510:d=6 hl=2 l= 4 prim: INTEGER :09EDB4A9 4020 1516:d=5 hl=2 l= 11 cons: SEQUENCE 4021 1518:d=6 hl=2 l= 9 prim: OBJECT :sha256 4022 1529:d=5 hl=2 l= 105 cons: cont [ 0 ] 4023 1531:d=6 hl=2 l= 24 cons: SEQUENCE 4024 1533:d=7 hl=2 l= 9 prim: OBJECT :contentType 4025 1544:d=7 hl=2 l= 11 cons: SET 4026 1546:d=8 hl=2 l= 9 prim: OBJECT :pkcs7-data 4027 1557:d=6 hl=2 l= 28 cons: SEQUENCE 4028 1559:d=7 hl=2 l= 9 prim: OBJECT :signingTime 4029 1570:d=7 hl=2 l= 15 cons: SET 4030 1572:d=8 hl=2 l= 13 prim: UTCTIME :190515212555Z 4031 1587:d=6 hl=2 l= 47 cons: SEQUENCE 4032 1589:d=7 hl=2 l= 9 prim: OBJECT :messageDigest 4033 1600:d=7 hl=2 l= 34 cons: SET 4034 1602:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:1037694FEDAAB0 4035 1636:d=5 hl=2 l= 10 cons: SEQUENCE 4036 1638:d=6 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA256 4037 1648:d=5 hl=2 l= 71 prim: OCTET STRING [HEX DUMP]:30450220461084 4039 The JSON contained in the voucher request: 4041 {"ietf-voucher-request:voucher":{"assertion":"proximity","created-on":"2019-05-15T17:25:55.644-04:00","serial-number":"00-d0-e5-02-00-2d","nonce":"VOUFT-WwrEv0NuAQEHoV7Q","proximity-registrar-cert":"MIIB0TCCAVagAwIBAgIBAjAKBggqhkjOPQQDAzBxMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xQDA+BgNVBAMMNyM8U3lzdGVtVmFyaWFibGU6MHgwMDAwMDAwNGY5MTFhMD4gVW5zdHJ1bmcgRm91bnRhaW4gQ0EwHhcNMTcxMTA3MjM0NTI4WhcNMTkxMTA3MjM0NTI4WjBDMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xEjAQBgNVBAMMCWxvY2FsaG9zdDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJZlUHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHWyYiNFbRCH9fyarfkzgX4p0zTizqjDTALMAkGA1UdEwQCMAAwCgYIKoZIzj0EAwMDaQAwZgIxALQMNurf8tv50lROD5DQXHEOJJNW3QV2g9QEdDSk2MY+AoSrBSmGSNjh4olEOhEuLgIxAJ4nWfNw+BjbZmKiIiUEcTwHMhGVXaMHY/F7n39wwKcBBSOndNPqCpOELl6bq3CZqQ=="}} 4043 D.2.2. Registrar to MASA 4045 As described in Section 5.5 the registrar will sign a registrar 4046 voucher-request, and will include pledge's voucher request in the 4047 prior-signed-voucher-request. 4049 -----BEGIN CMS----- 4050 MIIPkwYJKoZIhvcNAQcCoIIPhDCCD4ACAQExDTALBglghkgBZQMEAgEwggnUBgkq 4051 hkiG9w0BBwGgggnFBIIJwXsiaWV0Zi12b3VjaGVyLXJlcXVlc3Q6dm91Y2hlciI6 4052 eyJhc3NlcnRpb24iOiJwcm94aW1pdHkiLCJjcmVhdGVkLW9uIjoiMjAxOS0wNS0x 4053 NVQyMToyNTo1NS43NThaIiwic2VyaWFsLW51bWJlciI6IjAwLWQwLWU1LTAyLTAw 4054 LTJkIiwibm9uY2UiOiJWT1VGVC1Xd3JFdjBOdUFRRUhvVjdRIiwicHJpb3Itc2ln 4055 bmVkLXZvdWNoZXItcmVxdWVzdCI6Ik1JSUd0UVlKS29aSWh2Y05BUWNDb0lJR3Bq 4056 Q0NCcUlDQVFFeERUQUxCZ2xnaGtnQlpRTUVBZ0V3Z2dOUkJna3Foa2lHOXcwQkJ3 4057 R2dnZ05DQklJRFBuc2lhV1YwWmkxMmIzVmphR1Z5TFhKbGNYVmxjM1E2ZG05MVky 4058 aGxjaUk2ZXlKaGMzTmxjblJwYjI0aU9pSndjbTk0YVcxcGRIa2lMQ0pqY21WaGRH 4059 VmtMVzl1SWpvaU1qQXhPUzB3TlMweE5WUXhOem95TlRvMU5TNDJORFF0TURRNk1E 4060 QWlMQ0p6WlhKcFlXd3RiblZ0WW1WeUlqb2lNREF0WkRBdFpUVXRNREl0TURBdE1t 4061 UWlMQ0p1YjI1alpTSTZJbFpQVlVaVUxWZDNja1YyTUU1MVFWRkZTRzlXTjFFaUxD 4062 SndjbTk0YVcxcGRIa3RjbVZuYVhOMGNtRnlMV05sY25RaU9pSk5TVWxDTUZSRFEw 4063 RldZV2RCZDBsQ1FXZEpRa0ZxUVV0Q1oyZHhhR3RxVDFCUlVVUkJla0o0VFZKSmQw 4064 VkJXVXREV2tsdGFWcFFlVXhIVVVKSFVsbERXVEpGZUVkVVFWaENaMjlLYTJsaFNt 4065 c3ZTWE5hUVVWYVJtZHNlbGxYTld0YVYzaDBXVmMwZUZGRVFTdENaMDVXUWtGTlRV 4066 NTVUVGhWTTJ4NlpFZFdkRlp0Um5saFYwWnBZa2RWTmsxSVozZE5SRUYzVFVSQmQw 4067 NUhXVFZOVkVab1RVUTBaMVpYTlhwa1NFb3hZbTFqWjFKdE9URmlibEpvWVZjMFox 4068 RXdSWGRJYUdOT1RWUmplRTFVUVROTmFrMHdUbFJKTkZkb1kwNU5WR3Q0VFZSQk0w 4069 MXFUVEJPVkVrMFYycENSRTFTU1hkRlFWbExRMXBKYldsYVVIbE1SMUZDUjFKWlEx 4070 a3lSWGhIVkVGWVFtZHZTbXRwWVVwckwwbHpXa0ZGV2tabmJIcFpWelZyV2xkNGRG 4071 bFhOSGhGYWtGUlFtZE9Wa0pCVFUxRFYzaDJXVEpHYzJGSE9YcGtSRUphVFVKTlIw 4072 SjVjVWRUVFRRNVFXZEZSME5EY1VkVFRUUTVRWGRGU0VFd1NVRkNTbHBzVlVoSk1I 4073 VndMMnd6WlZwbU9YWkRRbUlyYkVsdWIwVk5SV2RqTjFKdksxaGFRM1JxUVVrd1Ew 4074 UXhaa3BtU2xJdmFFbDVlVVJ0U0ZkNVdXbE9SbUpTUTBnNVpubGhjbVpyZW1kWU5I 4075 QXdlbFJwZW5GcVJGUkJURTFCYTBkQk1WVmtSWGRSUTAxQlFYZERaMWxKUzI5YVNY 4076 cHFNRVZCZDAxRVlWRkJkMXBuU1hoQlRGRk5UblZ5WmpoMGRqVXdiRkpQUkRWRVVW 4077 aElSVTlLU2s1WE0xRldNbWM1VVVWa1JGTnJNazFaSzBGdlUzSkNVMjFIVTA1cWFE 4078 UnZiRVZQYUVWMVRHZEplRUZLTkc1WFprNTNLMEpxWWxwdFMybEphVlZGWTFSM1NF 4079 MW9SMVpZWVUxSVdTOUdOMjR6T1hkM1MyTkNRbE5QYm1ST1VIRkRjRTlGVEd3Mllu 4080 RXpRMXB4VVQwOUluMTlvSUlDQ0RDQ0FnUXdnZ0dMb0FNQ0FRSUNCQW50dEtrd0Nn 4081 WUlLb1pJemowRUF3SXdUVEVTTUJBR0NnbVNKb21UOGl4a0FSa1dBbU5oTVJrd0Z3 4082 WUtDWkltaVpQeUxHUUJHUllKYzJGdVpHVnNiV0Z1TVJ3d0dnWURWUVFEREJOVmJu 4083 TjBjblZ1WnlCSWFXZG9kMkY1SUVOQk1DQVhEVEU1TURReU5EQXlNVFkxT0ZvWUR6 4084 STVPVGt4TWpNeE1EQXdNREF3V2pBY01Sb3dHQVlEVlFRRkRCRXdNQzFrTUMxbE5T 4085 MHdNaTB3TUMweVpEQlpNQk1HQnlxR1NNNDlBZ0VHQ0NxR1NNNDlBd0VIQTBJQUJG 4086 b3Y0Nmo2VVNkQ1lGb0lXVVlIbVpTeXJyVzExWTVweDIvdFFHR2hCZjJFSXhOb09S 4087 V1ZmQ280a2YyNUJKZnBmRE9LSnlBdXloMmx5aXBMbW9QVXVrK2pnWWN3Z1lRd0hR 4088 WURWUjBPQkJZRUZJL0NtSFZLQkRyeWRKSERpRzR4RnNJRm5RMkpNQWtHQTFVZEV3 4089 UUNNQUF3S3dZRFZSMFJCQ1F3SXFBZ0Jna3JCZ0VFQVlMdVVnR2dFd3dSTURBdFJE 4090 QXRSVFV0TURJdE1EQXRNa1F3S3dZSkt3WUJCQUdDN2xJQ0JCNE1IRzFoYzJFdWFH 4091 OXVaWGxrZFd0bGN5NXpZVzVrWld4dFlXNHVZMkV3Q2dZSUtvWkl6ajBFQXdJRFp3 4092 QXdaQUl3SnJ6STVqWUk4cVE0WEg4cHpGZDVETGlLVWlxMk0wVnErSU56N1U4Rnc3 4093 QUh0S0lyVTA0K0VMVk5XMm80VG4wNUFqQmpEVzdGdGtPTlJjL2JlancxWGJUaW1t 4094 d1d3RDlVVmFCVTVRMExqdlo1aTgyK1pGUG5GS2dyVDBSV1FWRno5NUl4Z2dFck1J 4095 SUJKd0lCQVRCVk1FMHhFakFRQmdvSmtpYUprL0lzWkFFWkZnSmpZVEVaTUJjR0Nn 4096 bVNKb21UOGl4a0FSa1dDWE5oYm1SbGJHMWhiakVjTUJvR0ExVUVBd3dUVlc1emRI 4097 SjFibWNnU0dsbmFIZGhlU0JEUVFJRUNlMjBxVEFMQmdsZ2hrZ0JaUU1FQWdHZ2FU 4098 QVlCZ2txaGtpRzl3MEJDUU14Q3dZSktvWklodmNOQVFjQk1Cd0dDU3FHU0liM0RR 4099 RUpCVEVQRncweE9UQTFNVFV5TVRJMU5UVmFNQzhHQ1NxR1NJYjNEUUVKQkRFaUJD 4100 QVFOMmxQN2Fxd3lobWo5cVVIdDZRay9TYk9UT1BYRk93bjF3djI1WUdZZ0RBS0Jn 4101 Z3Foa2pPUFFRREFnUkhNRVVDSUVZUWhIVG9VMHJyaFB5UXYyZlIwVHdXZVBUeDJa 4102 MURFaFI0dFRsL0RyL1pBaUVBNDd1OStiSXovcDZuRkord2N0S0hFUit5Y1V6WVFG 4103 NTZoOW9kTW8rSWxrYz0ifX2gggRCMIIB0TCCAVagAwIBAgIBAjAKBggqhkjOPQQD 4104 AzBxMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxt 4105 YW4xQDA+BgNVBAMMNyM8U3lzdGVtVmFyaWFibGU6MHgwMDAwMDAwNGY5MTFhMD4g 4106 VW5zdHJ1bmcgRm91bnRhaW4gQ0EwHhcNMTcxMTA3MjM0NTI4WhcNMTkxMTA3MjM0 4107 NTI4WjBDMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5k 4108 ZWxtYW4xEjAQBgNVBAMMCWxvY2FsaG9zdDBZMBMGByqGSM49AgEGCCqGSM49AwEH 4109 A0IABJZlUHI0up/l3eZf9vCBb+lInoEMEgc7Ro+XZCtjAI0CD1fJfJR/hIyyDmHW 4110 yYiNFbRCH9fyarfkzgX4p0zTizqjDTALMAkGA1UdEwQCMAAwCgYIKoZIzj0EAwMD 4111 aQAwZgIxALQMNurf8tv50lROD5DQXHEOJJNW3QV2g9QEdDSk2MY+AoSrBSmGSNjh 4112 4olEOhEuLgIxAJ4nWfNw+BjbZmKiIiUEcTwHMhGVXaMHY/F7n39wwKcBBSOndNPq 4113 CpOELl6bq3CZqTCCAmkwggHvoAMCAQICAQMwCgYIKoZIzj0EAwIwbTESMBAGCgmS 4114 JomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMTwwOgYDVQQD 4115 DDNmb3VudGFpbi10ZXN0LmV4YW1wbGUuY29tIFVuc3RydW5nIEZvdW50YWluIFJv 4116 b3QgQ0EwHhcNMTkwMTEzMjI1NDQ0WhcNMjEwMTEyMjI1NDQ0WjBtMRIwEAYKCZIm 4117 iZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xPDA6BgNVBAMM 4118 M2ZvdW50YWluLXRlc3QuZXhhbXBsZS5jb20gVW5zdHJ1bmcgRm91bnRhaW4gUm9v 4119 dCBDQTB2MBAGByqGSM49AgEGBSuBBAAiA2IABBt/WboXwxq8Zo2MbODD+jFxD2X2 4120 IpG9t1aAB9vfuHqlRU15ikaXGVmWMbGPaX0yvjzIPltjtUb2qNVvm/nA89O5FD9y 4121 R1Gkdt3S8L/1yo8wAX/4wl/T9SADRIuL8gdstKNjMGEwDwYDVR0TAQH/BAUwAwEB 4122 /zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLml9ssR4QekSSynCMZ8ELyHs3Qm 4123 MB8GA1UdIwQYMBaAFLml9ssR4QekSSynCMZ8ELyHs3QmMAoGCCqGSM49BAMCA2gA 4124 MGUCMAviLdbfd6AZdsOxNgf7D15WFmGC1JkHeEbT/0w4UXz6q/48S71/IMbSXRWH 4125 aNxiJwIxAOCRjtlN+VSmCLTvWwMTxnSpIuqMr/O1y2Z8rl459VRFphWPdbf4i0qE 4126 cwu0u4JzpDGCAUwwggFIAgEBMHYwcTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK 4127 CZImiZPyLGQBGRYJc2FuZGVsbWFuMUAwPgYDVQQDDDcjPFN5c3RlbVZhcmlhYmxl 4128 OjB4MDAwMDAwMDRmOTExYTA+IFVuc3RydW5nIEZvdW50YWluIENBAgECMAsGCWCG 4129 SAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF 4130 MQ8XDTE5MDUxNTIxMjU1NVowLwYJKoZIhvcNAQkEMSIEIFBQjMmWzZOEkRHXrVAS 4131 snJwgQ26goyvOAtUFYs3MstMMAoGCCqGSM49BAMCBEcwRQIgBthbhEmgbqZbYDkD 4132 zxHXLzJ5eusWplzHKqZyxNpzaR8CIQC3UtMu0QsXoUpYL016iTsbd7Eedi8IfnwQ 4133 akExfhh0ew== 4134 -----END CMS----- 4136 file: examples/parboiled_vr_00_D0-E5-02-00-2D.pkcs 4138 The ASN1 decoding of the artifact: 4140 0:d=0 hl=4 l=3987 cons: SEQUENCE 4141 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData 4142 15:d=1 hl=4 l=3972 cons: cont [ 0 ] 4143 19:d=2 hl=4 l=3968 cons: SEQUENCE 4144 23:d=3 hl=2 l= 1 prim: INTEGER :01 4145 26:d=3 hl=2 l= 13 cons: SET 4146 28:d=4 hl=2 l= 11 cons: SEQUENCE 4147 30:d=5 hl=2 l= 9 prim: OBJECT :sha256 4148 41:d=3 hl=4 l=2516 cons: SEQUENCE 4149 45:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data 4150 56:d=4 hl=4 l=2501 cons: cont [ 0 ] 4151 60:d=5 hl=4 l=2497 prim: OCTET STRING :{"ietf-voucher-request:v 4152 2561:d=3 hl=4 l=1090 cons: cont [ 0 ] 4153 2565:d=4 hl=4 l= 465 cons: SEQUENCE 4154 2569:d=5 hl=4 l= 342 cons: SEQUENCE 4155 2573:d=6 hl=2 l= 3 cons: cont [ 0 ] 4156 2575:d=7 hl=2 l= 1 prim: INTEGER :02 4157 2578:d=6 hl=2 l= 1 prim: INTEGER :02 4158 2581:d=6 hl=2 l= 10 cons: SEQUENCE 4159 2583:d=7 hl=2 l= 8 prim: OBJECT :ecdsa-with-SHA384 4160 2593:d=6 hl=2 l= 113 cons: SEQUENCE 4161 2595:d=7 hl=2 l= 18 cons: SET 4162 2597:d=8 hl=2 l= 16 cons: SEQUENCE 4163 2599:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 4164 2611:d=9 hl=2 l= 2 prim: IA5STRING :ca 4165 2615:d=7 hl=2 l= 25 cons: SET 4166 2617:d=8 hl=2 l= 23 cons: SEQUENCE 4167 2619:d=9 hl=2 l= 10 prim: OBJECT :domainComponent 4168 2631:d=9 hl=2 l= 9 prim: IA5STRING :sandelman 4169 2642:d=7 hl=2 l= 64 cons: SET 4170 2644:d=8 hl=2 l= 62 cons: SEQUENCE 4171 2646:d=9 hl=2 l= 3 prim: OBJECT :commonName 4172 2651:d=9 hl=2 l= 55 prim: UTF8STRING :#