idnits 2.17.1 draft-ietf-anima-bootstrapping-keyinfra-09.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 30, 2017) is 2370 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: 'RFC3987' is mentioned on line 612, but not defined == Missing Reference: 'RFC2616' is mentioned on line 1600, 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 2048, but not defined == Missing Reference: 'RFC2131' is mentioned on line 2499, but not defined == Missing Reference: 'FIND-good-REF' is mentioned on line 2544, but not defined == Unused Reference: 'RFC3542' is defined on line 2342, but no explicit reference was found in the text == Unused Reference: 'RFC5386' is defined on line 2378, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 2383, but no explicit reference was found in the text == Unused Reference: 'RFC5660' is defined on line 2387, but no explicit reference was found in the text == Unused Reference: 'I-D.behringer-homenet-trust-bootstrap' is defined on line 2423, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-zerotouch' is defined on line 2429, but no explicit reference was found in the text == Unused Reference: 'RFC7217' is defined on line 2458, but no explicit reference was found in the text == Unused Reference: 'RFC7575' is defined on line 2473, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-12 == Outdated reference: A later version (-07) exists of draft-ietf-anima-voucher-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'IDevID' ** Downref: Normative reference to an Informational RFC: RFC 3542 ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Downref: Normative reference to an Informational RFC: RFC 7228 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-19 == Outdated reference: A later version (-25) exists of draft-ietf-opsawg-mud-13 == Outdated reference: A later version (-03) exists of draft-richardson-anima-state-for-joinrouter-01 == Outdated reference: A later version (-04) exists of draft-vanderstok-ace-coap-est-02 -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 6 errors (**), 0 flaws (~~), 20 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG M. Pritikin 3 Internet-Draft Cisco 4 Intended status: Standards Track M. Richardson 5 Expires: May 3, 2018 SSW 6 M. Behringer 7 Cisco 8 S. Bjarnason 9 Arbor Networks 10 K. Watsen 11 Juniper Networks 12 October 30, 2017 14 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 15 draft-ietf-anima-bootstrapping-keyinfra-09 17 Abstract 19 This document specifies automated bootstrapping of a remote secure 20 key infrastructure (BRSKI) using vendor installed X.509 certificate, 21 in combination with a vendor's authorizing service, both online and 22 offline. Bootstrapping a new device can occur using a routable 23 address and a cloud service, or using only link-local connectivity, 24 or on limited/disconnected networks. Support for lower security 25 models, including devices with minimal identity, is described for 26 legacy reasons but not encouraged. Bootstrapping is complete when 27 the cryptographic identity of the new key infrastructure is 28 successfully deployed to the device but the established secure 29 connection can be used to deploy a locally issued certificate to the 30 device as well. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on May 3, 2018. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. Other Bootstrapping Approaches . . . . . . . . . . . . . 5 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 69 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 8 70 1.4. Leveraging the new key infrastructure / next steps . . . 9 71 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 9 72 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 11 73 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 12 74 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 13 75 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 14 76 2.4.1. Architectural component: Pledge . . . . . . . . . . . 16 77 2.4.2. Architectural component: Circuit Proxy . . . . . . . 16 78 2.4.3. Architectural component: Domain Registrar . . . . . . 16 79 2.4.4. Architectural component: Vendor Service . . . . . . . 16 80 2.5. Lack of realtime clock . . . . . . . . . . . . . . . . . 16 81 2.6. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 17 82 2.7. Determining the MASA to contact . . . . . . . . . . . . . 17 83 3. Voucher-Request artifact . . . . . . . . . . . . . . . . . . 18 84 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 18 85 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 19 86 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21 87 4. Proxy details . . . . . . . . . . . . . . . . . . . . . . . . 23 88 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 24 89 4.1.1. Proxy Grasp announcements . . . . . . . . . . . . . . 25 90 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 26 91 4.3. HTTPS proxy connection to Registrar . . . . . . . . . . . 26 92 4.4. Proxy discovery of Registrar . . . . . . . . . . . . . . 26 93 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 28 94 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 30 95 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 30 96 5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 31 97 5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 32 98 5.5. Voucher Response . . . . . . . . . . . . . . . . . . . . 35 99 5.5.1. Completing authentication of Provisional TLS 100 connection . . . . . . . . . . . . . . . . . . . . . 36 101 5.6. Voucher Status Telemetry . . . . . . . . . . . . . . . . 37 102 5.7. MASA authorization log Request . . . . . . . . . . . . . 38 103 5.7.1. MASA authorization log Response . . . . . . . . . . . 39 104 5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 40 105 5.8.1. EST Distribution of CA Certificates . . . . . . . . . 40 106 5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 40 107 5.8.3. EST Client Certificate Request . . . . . . . . . . . 41 108 5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 41 109 5.8.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 43 110 6. Reduced security operational modes . . . . . . . . . . . . . 43 111 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 43 112 6.2. Pledge security reductions . . . . . . . . . . . . . . . 44 113 6.3. Registrar security reductions . . . . . . . . . . . . . . 44 114 6.4. MASA security reductions . . . . . . . . . . . . . . . . 45 115 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 116 7.1. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 46 117 7.2. Voucher Status Telemetry . . . . . . . . . . . . . . . . 46 118 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 119 8.1. Freshness in Voucher-Requests . . . . . . . . . . . . . . 48 120 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 121 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 122 10.1. Normative References . . . . . . . . . . . . . . . . . . 50 123 10.2. Informative References . . . . . . . . . . . . . . . . . 52 124 Appendix A. IPv4 operations . . . . . . . . . . . . . . . . . . 54 125 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 54 126 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 54 127 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 54 128 Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 55 129 C.1. Multiple Join networks on the Join Proxy side . . . . . . 55 130 C.2. Automatic configuration of tunnels on Registrar . . . . . 56 131 C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 56 132 C.4. Use of connected sockets; or IP_PKTINFO for CoAP on 133 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 57 134 C.5. Use of socket extension rather than virtual interface . . 57 135 Appendix D. MUD Extension . . . . . . . . . . . . . . . . . . . 57 136 Appendix E. Example Vouchers . . . . . . . . . . . . . . . . . . 59 137 E.1. Keys involved . . . . . . . . . . . . . . . . . . . . . . 59 138 E.1.1. MASA key pair for voucher signatures . . . . . . . . 59 139 E.1.2. Manufacturer key pair for IDevID signatures . . . . . 59 140 E.1.3. Registrar key pair . . . . . . . . . . . . . . . . . 60 141 E.1.4. Pledge key pair . . . . . . . . . . . . . . . . . . . 62 142 E.2. Example process . . . . . . . . . . . . . . . . . . . . . 64 143 E.2.1. Pledge to Registrar . . . . . . . . . . . . . . . . . 64 144 E.2.2. Registrar to MASA . . . . . . . . . . . . . . . . . . 66 145 E.2.3. MASA to Registrar . . . . . . . . . . . . . . . . . . 67 146 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 148 1. Introduction 150 BRSKI provides a foundation to securely answer the following 151 questions between an element of the network domain called the 152 "Registrar" and an unconfigured and untouched device called a 153 "Pledge": 155 o Registrar authenticating the Pledge: "Who is this device? What is 156 its identity?" 158 o Registrar authorization the Pledge: "Is it mine? Do I want it? 159 What are the chances it has been compromised?" 161 o Pledge authenticating the Registrar/Domain: "What is this domain's 162 identity?" 164 o Pledge authorization the Registrar: "Should I join it?" 166 This document details protocols and messages to the endpoints to 167 answer the above questions. The Registrar actions derive from Pledge 168 identity, third party cloud service communications, and local access 169 control lists. The Pledge actions derive from a cryptographically 170 protected "voucher" message delivered through the Registrar but 171 originating at a Manufacturer Authorized Signing Authority. 173 The syntactic details of vouchers are described in detail in 174 [I-D.ietf-anima-voucher]. This document details automated protocol 175 mechanisms to obtain vouchers, including the definition of a 176 'voucher-request' message that is a minor extension to the voucher 177 format (see Section 3). 179 BRSKI results in the Pledge storing an X.509 root certificate 180 sufficient for verifying the Registrar identity. In the process a 181 TLS connection is established which can be directly used for 182 Enrollment over Secure Transport (EST). In effect BRSKI provides an 183 automated mechanism for the "Bootstrap Distribution of CA 184 Certificates" described in [RFC7030] Section 4.1.1 wherein the Pledge 185 "MUST [...]. engage a human user to authorize the CA certificate 186 using out-of-band" information". With BRSKI the Pledge now can 187 automate this process using the voucher. Integration with a complete 188 EST enrollment is optional but trivial. 190 BRSKI is agile enough to support bootstrapping alternative key 191 infrastructures, such as a symmetric key solutions, but no such 192 system is described in this document. 194 1.1. Other Bootstrapping Approaches 196 To literally "pull yourself up by the bootstraps" is an impossible 197 action. Similarly the secure establishment of a key infrastructure 198 without external help is also an impossibility. Today it is commonly 199 accepted that the initial connections between nodes are insecure, 200 until key distribution is complete, or that domain-specific keying 201 material is pre-provisioned on each new device in a costly and non- 202 scalable manner. Existing mechanisms are known as non-secured 'Trust 203 on First Use' (TOFU) [RFC7435], 'resurrecting duckling' 204 [Stajano99theresurrecting] or 'pre-staging'. 206 Another approach is to try and minimize user actions during 207 bootstrapping. The enrollment protocol EST [RFC7030] details a set 208 of non-autonomic bootstrapping methods in this vein: 210 o using the Implicit Trust Anchor database (not an autonomic 211 solution because the URL must be securely distributed), 213 o engaging a human user to authorize the CA certificate using out- 214 of-band data (not an autonomic solution because the human user is 215 involved), 217 o using a configured Explicit TA database (not an autonomic solution 218 because the distribution of an explicit TA database is not 219 autonomic), 221 o and using a Certificate-Less TLS mutual authentication method (not 222 an autonomic solution because the distribution of symmetric key 223 material is not autonomic). 225 These "touch" methods do not meet the requirements for zero-touch. 227 There are "call home" technologies where the Pledge first establishes 228 a connection to a well known vendor service using a common client- 229 server authentication model. After mutual authentication appropriate 230 credentials to authenticate the target domain are transfered to the 231 Pledge. This creates serveral problems and limitations: 233 o the pledge requires realtime connectivity to the vendor service, 235 o the domain identity is exposed to the vendor service (this is a 236 privacy concern), 238 o the vendor is responsible for making the authorization decisions 239 (this is a liability concern), 241 BRSKI addresses these issues by defining extensions to the EST 242 protocol for the automated distribution of vouchers. 244 1.2. Terminology 246 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 247 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 248 "OPTIONAL" in this document are to be interpreted as described in 249 [RFC2119]. 251 The following terms are defined for clarity: 253 domainID: The domain IDentity is the 160-bit SHA-1 hash of the BIT 254 STRING of the subjectPublicKey of the root certificate for the 255 registrars in the domain. This is consistent with the subject key 256 identifier (Section 4.2.1.2 [RFC5280]). 258 drop ship: The physical distribution of equipment containing the 259 "factory default" configuration to a final destination. In zero- 260 touch scenarios there is no staging or pre-configuration during 261 drop-ship. 263 imprint: The process where a device obtains the cryptographic key 264 material to identify and trust future interactions with a network. 265 This term is taken from Konrad Lorenz's work in biology with new 266 ducklings: during a critical period, the duckling would assume 267 that anything that looks like a mother duck is in fact their 268 mother. An equivalent for a device is to obtain the fingerprint 269 of the network's root certification authority certificate. A 270 device that imprints on an attacker suffers a similar fate to a 271 duckling that imprints on a hungry wolf. Securely imprinting is a 272 primary focus of this document.[imprinting]. The analogy to 273 Lorenz's work was first noted in [Stajano99theresurrecting]. 275 enrollment: The process where a device presents key material to a 276 network and acquires a network specific identity. For example 277 when a certificate signing request is presented to a certification 278 authority and a certificate is obtained in response. 280 Pledge: The prospective device, which has an identity installed by a 281 third-party (e.g., vendor, manufacturer or integrator). 283 Voucher A signed statement from the MASA service that indicates to a 284 Pledge the cryptographic identity of the Registrar it should 285 trust. There are different types of vouchers depending on how 286 that trust asserted. Multiple voucher types are defined in 287 [I-D.ietf-anima-voucher] 289 Domain: The set of entities that trust a common key infrastructure 290 trust anchor. This includes the Proxy, Registrar, Domain 291 Certificate Authority, Management components and any existing 292 entity that is already a member of the domain. 294 Domain CA: The domain Certification Authority (CA) provides 295 certification functionalities to the domain. At a minimum it 296 provides certification functionalities to a Registrar and stores 297 the trust anchor that defines the domain. Optionally, it 298 certifies all elements. 300 Join Registrar (and Coordinator): A representative of the domain 301 that is configured, perhaps autonomically, to decide whether a new 302 device is allowed to join the domain. The administrator of the 303 domain interfaces with a Join Registrar (and Coordinator) to 304 control this process. Typically a Join Registrar is "inside" its 305 domain. For simplicity this document often refers to this as just 306 "Registrar". The term JRC is used in common with other bootstrap 307 mechanisms. 309 Join Proxy: A domain entity that helps the pledge join the domain. 310 A Proxy facilitates communication for devices that find themselves 311 in an environment where they are not provided connectivity until 312 after they are validated as members of the domain. The pledge is 313 unaware that they are communicating with a proxy rather than 314 directly with a Registrar. 316 MASA Service: A third-party Manufacturer Authorized Signing 317 Authority (MASA) service on the global Internet. The MASA signs 318 vouchers. It also provides a repository for audit log information 319 of privacy protected bootstrapping events. It does not track 320 ownership. 322 Ownership Tracker: An Ownership Tracker service on the global 323 internet. The Ownership Tracker uses business processes to 324 accurately track ownership of all devices shipped against domains 325 that have purchased them. Although optional this component allows 326 vendors to provide additional value in cases where their sales and 327 distribution channels allow for accurately tracking of such 328 ownership. Ownership tracking information is indicated in 329 vouchers as described in [I-D.ietf-anima-voucher] 331 IDevID: An Initial Device Identity X.509 certificate installed by 332 the vendor on new equipment. 334 TOFU: Trust on First Use. Used similarly to [RFC7435]. This is 335 where a Pledge device makes no security decisions but rather 336 simply trusts the first Registrar it is contacted by. This is 337 also known as the "resurrecting duckling" model. 339 1.3. Scope of solution 341 Questions have been posed as to whether this solution is suitable in 342 general for Internet of Things (IoT) networks. This depends on the 343 capabilities of the devices in question. The terminology of 344 [RFC7228] is best used to describe the boundaries. 346 The solution described in this document is aimed in general at non- 347 constrained (i.e. class 2+) devices operating on a non-Challenged 348 network. The entire solution as described here is not intended to be 349 useable as-is by constrained devices operating on challenged networks 350 (such as 802.15.4 LLNs). 352 In many target applications, the systems involved are large router 353 platforms with multi-gigabit inter-connections, mounted in controlled 354 access data centers. But this solution is not exclusive to the 355 large, it is intended to scale to thousands of devices located in 356 hostile environments, such as ISP provided CPE devices which are 357 drop-shipped to the end user. The situation where an order is 358 fulfilled from distributed warehouse from a common stock and shipped 359 directly to the target location at the request of the domain owner is 360 explicitly supported. That stock ("SKU") could be provided to a 361 number of potential domain owners, and the eventual domain owner will 362 not know a-priori which device will go to which location. 364 The bootstrapping process can take minutes to complete depending on 365 the network infrastructure and device processing speed. The network 366 communication itself is not optimized for speed; for privacy reasons, 367 the discovery process allows for the Pledge to avoid announcing it's 368 presence through broadcasting. 370 This protocol is not intended for low latency handoffs. In networks 371 requiring such things, the pledge SHOULD already have been enrolled. 373 Specifically, there are protocol aspects described here which might 374 result in congestion collapse or energy-exhaustion of intermediate 375 battery powered routers in an LLN. Those types of networks SHOULD 376 NOT use this solution. These limitations are predominately related 377 to the large credential and key sizes required for device 378 authentication. Defining symmetric key techniques that meet the 379 operational requirements is out-of-scope but the underlying protocol 380 operations (TLS handshake and signing structures) have sufficient 381 algorithm agility to support such techniques when defined. 383 The imprint protocol described here could, however, be used by non- 384 energy constrained devices joining a non-constrained network (for 385 instance, smart light bulbs are usually mains powered, and speak 386 802.11). It could also be used by non-constrained devices across a 387 non-energy constrained, but challenged network (such as 802.15.4). 388 The certificate contents, and the process by which the four questions 389 above are resolved do apply to constrained devices. It is simply the 390 actual on-the-wire imprint protocol which could be inappropriate. 392 This document presumes that network access control has either already 393 occurred, is not required, or is integrated by the proxy and 394 registrar in such a way that the device itself does not need to be 395 aware of the details. Although the use of an X.509 Initial Device 396 Identity is consistant with IEEE 802.1AR [IDevID], and allows for 397 alignment with 802.1X network access control methods, its use here is 398 for Pledge authentication rather than network access control. 399 Integrating this protocol with network access control, perhaps as an 400 Extensible Authentication Protocol (EAP) method (see [RFC3748]), is 401 out-of-scope. 403 1.4. Leveraging the new key infrastructure / next steps 405 As a result of the protocol described herein the bootstrapped devices 406 have a common trust anchor and a certificate has optionally been 407 issued from a local PKI. This makes it possible to automatically 408 deploy services across the domain in a secure manner. 410 Services which benefit from this: 412 o Device management. 414 o Routing authentication. 416 o Service discovery. 418 The major beneficiary is that it possible to use the credentials 419 deployed by this protocol to secure the Autonomic Control Plane (ACP) 420 ([I-D.ietf-anima-autonomic-control-plane]). 422 2. Architectural Overview 424 The logical elements of the bootstrapping framework are described in 425 this section. Figure 1 provides a simplified overview of the 426 components. Each component is logical and may be combined with other 427 components as necessary. 429 +------------------------+ 430 +--------------Drop Ship--------------->| Vendor Service | 431 | +------------------------+ 432 | | M anufacturer| | 433 | | A uthorized |Ownership| 434 | | S igning |Tracker | 435 | | A uthority | | 436 | +--------------+---------+ 437 | ^ 438 | | BRSKI- 439 V | MASA 440 +-------+ ............................................|... 441 | | . | . 442 | | . +------------+ +-----------+ | . 443 | | . | | | | | . 444 |Pledge | . | Circuit | | Domain <-------+ . 445 | | . | Proxy | | Registrar | . 446 | <-------->............<-------> (PKI RA) | . 447 | | | BRSKI-EST | | . 448 | | . | | +-----+-----+ . 449 |IDevID | . +------------+ | EST RFC7030 . 450 | | . +-----------------+----------+ . 451 | | . | Key Infrastructure | . 452 | | . | (e.g. PKI Certificate | . 453 +-------+ . | Authority) | . 454 . +----------------------------+ . 455 . . 456 ................................................ 457 "Domain" components 459 Figure 1 461 We assume a multi-vendor network. In such an environment there could 462 be a Vendor Service for each vendor that supports devices following 463 this document's specification, or an integrator could provide a 464 generic service authorized by multiple vendors. It is unlikely that 465 an integrator could provide Ownership Tracking services for multiple 466 vendors due to the required sales channel integrations necessary to 467 track ownership. 469 The domain is the managed network infrastructure with a Key 470 Infrastructure the Pledge is joining. The a domain provides initial 471 device connectivity sufficient for bootstrapping with a Circuit 472 Proxy. The Domain Registrar authenticates the Pledge, makes 473 authorization decisions, and distributes vouchers obtained from the 474 Vendor Service. Optionally the Registrar also acts as a PKI 475 Registration Authority. 477 2.1. Behavior of a Pledge 479 The pledge goes through a series of steps which are outlined here at 480 a high level. 482 +--------------+ 483 | Factory | 484 | default | 485 +------+-------+ 486 | 487 +------v-------+ 488 | Discover | 489 +------------> | 490 | +------+-------+ 491 | | 492 | +------v-------+ 493 | | Identity | 494 ^------------+ | 495 | rejected +------+-------+ 496 | | 497 | +------v-------+ 498 | | Request | 499 | | Join | 500 | +------+-------+ 501 | | 502 | +------v-------+ 503 | | Imprint | Optional 504 ^------------+ <--+Manual input (Appendix C) 505 | Bad Vendor +------+-------+ 506 | response | send Voucher Status Telemetry 507 | +------v-------+ 508 | | Enroll | 509 ^------------+ | 510 | Enroll +------+-------+ 511 | Failure | 512 | +------v-------+ 513 | | Enrolled | 514 ^------------+ | 515 Factory +--------------+ 516 reset 518 Figure 2 520 State descriptions for the pledge are as follows: 522 1. Discover a communication channel to a Registrar. 524 2. Identify itself. This is done by presenting an X.509 IDevID 525 credential to the discovered Registrar (via the Proxy) in a TLS 526 handshake. (The Registrar credentials are only provisionally 527 accepted at this time). 529 3. Requests to Join the discovered Registrar. A unique nonce can be 530 included ensuring that any responses can be associated with this 531 particular bootstrapping attempt. 533 4. Imprint on the Registrar. This requires verification of the 534 vendor service provided voucher. A voucher contains sufficient 535 information for the Pledge to complete authentication of a 536 Registrar. (It enables the Pledge to finish authentication of 537 the Registrar TLS server certificate). 539 5. Enroll. By accepting the domain specific information from a 540 Registrar, and by obtaining a domain certificate from a Registrar 541 using a standard enrollment protocol, e.g. Enrollment over 542 Secure Transport (EST) [RFC7030]. 544 6. The Pledge is now a member of, and can be managed by, the domain 545 and will only repeat the discovery aspects of bootstrapping if it 546 is returned to factory default settings. 548 2.2. Secure Imprinting using Vouchers 550 A voucher is a cryptographically protected statement to the Pledge 551 device authorizing a zero-touch imprint on the Registrar domain. 553 The format and cryptographic mechanism of vouchers is described in 554 detail in [I-D.ietf-anima-voucher]. 556 Vouchers provide a flexible mechanism to secure imprinting: the 557 Pledge device only imprints when a voucher can be validated. At the 558 lowest security levels the MASA server can indiscriminately issue 559 vouchers. At the highest security levels issuance of vouchers can be 560 integrated with complex sales channel integrations that are beyond 561 the scope of this document. This provides the flexibility for a 562 number of use cases via a single common protocol mechanism on the 563 Pledge and Registrar devices that are to be widely deployed in the 564 field. The MASA vendor services have the flexibility to leverage 565 either the currently defined claim mechanisms or to experiment with 566 higher or lower security levels. 568 Vouchers provide a signed but non-encrypted communication channel 569 between the Pledge, the MASA, and the Registrar. The Registrar 570 maintains control over the transport and policy decisions allowing 571 the local security policy of the domain network to be enforced. 573 2.3. Initial Device Identifier 575 Pledge authentication and Pledge voucher-request signing is via an 576 X.509 certificate installed during the manufacturing process. This 577 Initial Device Identifier provides a basis for authenticating the 578 Pledge during subsequent protocol exchanges and informing the 579 Registrar of the MASA URI. There is no requirement for a common root 580 PKI hierarchy. Each device vendor can generate their own root 581 certificate. 583 The following previously defined fields are in the X.509 IDevID 584 certificate: 586 o The subject field's DN encoding MUST include the "serialNumber" 587 attribute with the device's unique serial number. 589 o The subject-alt field's encoding SHOULD include a non-critical 590 version of the RFC4108 defined HardwareModuleName. 592 In order to build the voucher "serial-number" field these IDevID 593 fields need to be converted into a serial-number of "type string". 594 The following methods is used depending on the first available IDevID 595 certificate field (attempted in this order): 597 o An RFC4514 String Representation of the Distinguished Name 598 "serialNumber" attribute. 600 o The HardwareModuleName hwSerialNum OCTET STRING base64 encoded. 602 o The RFC4514 String Representation of the Distinguished Name 603 "common name" attribute. 605 The following newly defined field SHOULD be in the X.509 IDevID 606 certificate: An X.509 non-critical certificate extension that 607 contains a single Uniform Resource Identifier (URI) that points to an 608 on-line Manufacturer Authorized Signing Authority. The URI is 609 represented as described in Section 7.4 of [RFC5280]. 611 Any Internationalized Resource Identifiers (IRIs) MUST be mapped to 612 URIs as specified in Section 3.1 of [RFC3987] before they are placed 613 in the certificate extension. The URI provides the authority 614 information. The BRSKI .well-known tree is described in Section 5 616 The new extension is identified as follows: 618 620 MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) 621 internet(1) security(5) mechanisms(5) pkix(7) 622 id-mod(0) id-mod-MASAURLExtn2016(TBD) } 624 DEFINITIONS IMPLICIT TAGS ::= BEGIN 626 -- EXPORTS ALL -- 628 IMPORTS 629 EXTENSION 630 FROM PKIX-CommonTypes-2009 631 { iso(1) identified-organization(3) dod(6) internet(1) 632 security(5) mechanisms(5) pkix(7) id-mod(0) 633 id-mod-pkixCommon-02(57) } 635 id-pe 636 FROM PKIX1Explicit-2009 637 { iso(1) identified-organization(3) dod(6) internet(1) 638 security(5) mechanisms(5) pkix(7) id-mod(0) 639 id-mod-pkix1-explicit-02(51) } ; 640 MASACertExtensions EXTENSION ::= { ext-MASAURL, ... } 641 ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax 642 IDENTIFIED BY id-pe-masa-url } 644 id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe TBD } 646 MASAURLSyntax ::= IA5String 648 END 650 652 The choice of id-pe is based on guidance found in Section 4.2.2 of 653 [RFC5280], "These extensions may be used to direct applications to 654 on-line information about the issuer or the subject". The MASA URL 655 is precisely that: online information about the particular subject. 657 2.4. Protocol Flow 659 A representative flow is shown in Figure 3: 661 +--------+ +---------+ +------------+ +------------+ 662 | Pledge | | Circuit | | Domain | | Vendor | 663 | | | Proxy | | Registrar | | Service | 664 | | | | | (JRC) | | (MASA) | 665 +--------+ +---------+ +------------+ +------------+ 666 | | | Internet | 667 |<-RFC4862 IPv6 addr | | | 668 |<-RFC3927 IPv4 addr | Appendix A | | 669 | | | | 670 |-------------------->| | | 671 | optional: mDNS query| Appendix B | | 672 | RFC6763/RFC6762 | | | 673 | | | | 674 |<--------------------| | | 675 | GRASP M_FLOOD | | | 676 | periodic broadcast| | | 677 | | | | 678 |<------------------->C<----------------->| | 679 | TLS via the Circuit Proxy | | 680 |<--Registrar TLS server authentication---| | 681 [PROVISIONAL accept of server cert] | | 682 P---X.509 client authentication---------->| | 683 P | | | 684 P---Voucher Request (include nonce)------>| | 685 P | | | 686 P | /---> | | 687 P | | [accept device?] | 688 P | | [contact Vendor] | 689 P | | |--Pledge ID-------->| 690 P | | |--Domain ID-------->| 691 P | | |--optional:nonce--->| 692 P | | | [extract DomainID] 693 P | | | | 694 P | optional: | [update audit log] 695 P | |can | | 696 P | |occur | | 697 P | |in | | 698 P | |advance | | 699 P | |if | | 700 P | |nonceless | | 701 P | | |<- voucher ---------| 702 P | \----> | | 703 P | | | 704 P<------voucher---------------------------| | 705 [verify voucher ] | | | 706 [verify provisional cert| | | 707 | | | | 708 |---------------------------------------->| | 709 | [voucher status telemetry] |<-device audit log--| 710 | | [verify audit log and voucher] | 711 | | | | 712 |<--------------------------------------->| | 713 | Continue with RFC7030 enrollment | | 714 | using now bidirectionally authenticated | | 715 | TLS session. | | | 716 | | | | 718 Figure 3 720 2.4.1. Architectural component: Pledge 722 The Pledge is the device which is attempting to join. Until the 723 pledge completes the enrollment process, it does has network 724 connectivity only to the Proxy. 726 2.4.2. Architectural component: Circuit Proxy 728 The (Circuit) Proxy provides HTTPS connectivity between the pledge 729 and the registrar. The proxy mechanism is described in Section 4, 730 with an optional stateless mechanism described in Appendix C. 732 2.4.3. Architectural component: Domain Registrar 734 The Domain Registrar (having the formal name Join Registrar/ 735 Coordinator (JRC)), operates as a CMC Registrar, terminating the EST 736 and BRSKI connections. The Registrar is manually configured or 737 distributed with a list of trust anchors necessary to authenticate 738 any Pledge device expected on the network. The Registrar 739 communicates with the Vendor supplied MASA to establish ownership. 741 2.4.4. Architectural component: Vendor Service 743 The Vendor Service provides two logically seperate functions: the 744 Manufacturer Authorized Signing Authority (MASA), and an ownership 745 tracking/auditing function. 747 2.5. Lack of realtime clock 749 Many devices when bootstrapping do not have knowledge of the current 750 time. Mechanisms like Network Time Protocols can not be secured 751 until bootstrapping is complete. Therefore bootstrapping is defined 752 in a method that does not require knowledge of the current time. 754 Unfortunately there are moments during bootstrapping when 755 certificates are verified, such as during the TLS handshake, where 756 validity periods are confirmed. This paradoxical "catch-22" is 757 resolved by the Pledge maintaining a concept of the current "window" 758 of presumed time validity that is continually refined throughout the 759 bootstrapping process as follows: 761 o Initially the Pledge does not know the current time. 763 o During Pledge authentiation by the Registrar a realtime clock can 764 be used by the Registrar. This bullet expands on a closely 765 related issue regarding Pledge lifetimes. RFC5280 indicates that 766 long lived Pledge certifiates "SHOULD be assigned the 767 GeneralizedTime value of 99991231235959Z" [RFC7030] so the 768 Registrar MUST support such lifetimes and SHOULD support ignoring 769 Pledge lifetimes if they did not follow the RFC5280 770 recommendations. 772 o The Pledge authenticates the voucher presented to it. During this 773 authentication the Pledge ignores certificate lifetimes (by 774 necessity because it does not have a realtime clock). 776 o If the voucher contains a nonce then the Pledge MUST confirm the 777 nonce matches the original Pledge voucher-request. This ensures 778 the voucher is fresh. See / (Section 5.2). 780 o Once the voucher is accepted the validity period of the pinned- 781 domain-cert in the voucher now serves as a valid time window. Any 782 subsequent certificate validity periods checked during RFC5280 783 path validation MUST occur within this window. 785 o When accepting an enrollment certificate the validity period 786 within the new certificate is assumed to be valid by the Pledge. 787 The Pledge is now willing to use this credential for client 788 authentication. 790 2.6. Cloud Registrar 792 The Pledge MAY contact a well known URI of a cloud Registrar if a 793 local Registrar can not be discovered or if the Pledge's target use 794 cases do not include a local Registrar. 796 If the Pledge uses a well known URI for contacting a cloud Registrar 797 an Implicit Trust Anchor database (see [RFC7030]) MUST be used to 798 authenticate service as described in RFC6125. This is consistent 799 with the human user configuration of an EST server URI in [RFC7030] 800 which also depends on RFC6125. 802 2.7. Determining the MASA to contact 804 The registrar needs to be able to contact a MASA that is trusted by 805 the Pledge in order to obtain vouchers. There are three mechanisms 806 described: 808 The device's Initial Device Identifier will normally contain the MASA 809 URL as detailed in Section 2.3. This is the RECOMMENDED mechanism. 811 If the Registrar is integrated with [I-D.ietf-opsawg-mud] and the 812 Pledge IDevID contains the id-pe-mud-url then the Registrar MAY 813 attempt to obtain the MASA URL from the MUD file. The MUD file 814 extension for the MASA URL is defined in Appendix D. 816 It can be operationally difficult to ensure the necessary X.509 817 extensions are in the Pledge's' IDevID due to the difficulty of 818 aligning current Pledge manufacturing with software releases and 819 development. As a final fallback the Registrar MAY be manually 820 configured or distributed with a MASA URL for each vendor. Note that 821 the Registrar can only select the configured MASA URL based on the 822 trust anchor -- so vendors can only leverage this approach if they 823 ensure a single MASA URL works for all Pledge's associated with each 824 trust anchor. 826 3. Voucher-Request artifact 828 The Pledge voucher-request is how a Pledge requests a voucher. The 829 Pledge forms a voucher-request and submits it to the Registrar. The 830 Registrar in turn submits a voucher-request to the MASA server. To 831 help differentiate this document refers to "Pledge voucher-request" 832 and "Registrar voucher-request" when indicating the source is 833 beneficial. The "proximity-registrar-cert" leaf is used in Pledge 834 voucher-requests. The "prior-signed-voucher-request" is used in 835 Registrar voucher-requests that include a Pledge voucher-request. 837 Unless otherwise signaled (outside the voucher-request artifact), the 838 signing structure is as defined for vouchers, see 839 [I-D.ietf-anima-voucher]. 841 3.1. Tree Diagram 843 The following tree diagram illustrates a high-level view of a 844 voucher-request document. The notation used in this diagram is 845 described in [I-D.ietf-anima-voucher]. Each node in the diagram is 846 fully described by the YANG module in Section 3.3. Please review the 847 YANG module for a detailed description of the voucher-request format. 849 module: ietf-voucher-request 851 grouping voucher-request-grouping 852 +---- voucher 853 +---- created-on? yang:date-and-time 854 +---- expires-on? yang:date-and-time 855 +---- assertion enumeration 856 +---- serial-number string 857 +---- idevid-issuer? binary 858 +---- pinned-domain-cert? binary 859 +---- domain-cert-revocation-checks? boolean 860 +---- nonce? binary 861 +---- last-renewal-date? yang:date-and-time 862 +---- prior-signed-voucher-request? binary 863 +---- proximity-registrar-cert? binary 865 3.2. Examples 867 This section provides voucher examples for illustration purposes. 868 That these examples conform to the encoding rules defined in 869 [RFC7951]. 871 Example (1) The following example illustrates a Pledge voucher- 872 request. The assertion leaf is indicated as 'proximity' 873 and the Registrar's TLS server certificate is included 874 in the 'proximity-registrar-cert' leaf. See 875 Section 5.2. 877 { 878 "ietf-voucher-request:voucher": { 879 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 880 "created-on": "2017-01-01T00:00:00.000Z", 881 "assertion": "proximity", 882 "proximity-registrar-cert": "base64encodedvalue==" 883 } 884 } 886 Example (2) The following example illustrates a Registrar voucher- 887 request. The 'prior-signed-voucher-request' leaf is 888 populated with the Pledge's voucher-request (such as the 889 prior example). See Section 5.4. 891 { 892 "ietf-voucher-request:voucher": { 893 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 894 "created-on": "2017-01-01T00:00:02.000Z", 895 "assertion": "proximity", 896 "idevid-issuer": "base64encodedvalue==" 897 "serial-number": "JADA123456789" 898 "prior-signed-voucher": "base64encodedvalue==" 899 } 900 } 902 Example (3) The following example illustrates a Registrar voucher- 903 request. The 'prior-signed-voucher-request' leaf is not 904 populated with the Pledge's voucher-request nor is the 905 nonce leaf. This form might be used by a Registrar 906 requesting a voucher when the Pledge is offline or when 907 the Registrar expects to be offline during deployment. 908 See Section 5.4. 910 { 911 "ietf-voucher-request:voucher": { 912 "created-on": "2017-01-01T00:00:02.000Z", 913 "assertion": "TBD", 914 "idevid-issuer": "base64encodedvalue==" 915 "serial-number": "JADA123456789" 916 } 917 } 919 Example (4) The following example illustrates a Registrar voucher- 920 request. The 'prior-signed-voucher-request' leaf is not 921 populated with the Pledge voucher-request because the 922 Pledge did not sign it's own request. This form might 923 be used when more constrained Pledges are being 924 deployed. The nonce is populated from the Pledge's 925 request. See Section 5.4. 927 { 928 "ietf-voucher-request:voucher": { 929 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 930 "created-on": "2017-01-01T00:00:02.000Z", 931 "assertion": "proximity", 932 "idevid-issuer": "base64encodedvalue==" 933 "serial-number": "JADA123456789" 934 } 935 } 937 3.3. YANG Module 939 Following is a YANG [RFC7950] module formally extending the 940 [I-D.ietf-anima-voucher] voucher into a voucher-request. 942 file "ietf-voucher-request@2017-10-30.yang" 943 module ietf-voucher-request { 944 yang-version 1.1; 946 namespace 947 "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; 948 prefix "vch"; 950 import ietf-restconf { 951 prefix rc; 952 description 953 "This import statement is only present to access 954 the yang-data extension defined in RFC 8040."; 955 reference "RFC 8040: RESTCONF Protocol"; 956 } 958 import ietf-voucher { 959 prefix v; 960 description 961 "FIXME"; 962 reference "RFC ????: Voucher Profile for Bootstrapping Protocols"; 963 } 965 organization 966 "IETF ANIMA Working Group"; 968 contact 969 "WG Web: 970 WG List: 971 Author: Kent Watsen 972 973 Author: Max Pritikin 974 975 Author: Michael Richardson 976 977 Author: Toerless Eckert 978 "; 980 description 981 "This module... FIXME 983 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 984 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in 985 the module text are to be interpreted as described in RFC 2119. 987 Copyright (c) 2017 IETF Trust and the persons identified as 988 authors of the code. All rights reserved. 990 Redistribution and use in source and binary forms, with or without 991 modification, is permitted pursuant to, and subject to the license 992 terms contained in, the Simplified BSD License set forth in Section 993 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 994 (http://trustee.ietf.org/license-info). 996 This version of this YANG module is part of RFC XXXX; see the RFC 997 itself for full legal notices."; 999 revision "2017-10-30" { 1000 description 1001 "Initial version"; 1002 reference 1003 "RFC XXXX: Voucher Profile for Bootstrapping Protocols"; 1004 } 1006 // Top-level statement 1007 rc:yang-data voucher-request-artifact { 1008 uses voucher-request-grouping; 1009 } 1011 // Grouping defined for future usage 1012 grouping voucher-request-grouping { 1013 description 1014 "Grouping to allow reuse/extensions in future work."; 1016 uses v:voucher-artifact-grouping { 1017 refine "voucher/created-on" { 1018 mandatory false; 1019 } 1021 refine "voucher/pinned-domain-cert" { 1022 mandatory false; 1023 } 1025 augment "voucher" { 1026 description 1027 "Adds leaf nodes appropriate for requesting vouchers."; 1029 leaf prior-signed-voucher-request { 1030 type binary; 1031 description 1032 "If it is necessary to change a voucher, or re-sign and 1033 forward a voucher that was previously provided along a 1034 protocol path, then the previously signed voucher SHOULD be 1035 included in this field. 1037 For example, a pledge might sign a proximity voucher, which 1038 an intermediate registrar then re-signs to make its own 1039 proximity assertion. This is a simple mechanism for a 1040 chain of trusted parties to change a voucher, while 1041 maintaining the prior signature information. 1043 The pledge MUST ignore all prior voucher information when 1044 accepting a voucher for imprinting. Other parties MAY 1045 examine the prior signed voucher information for the 1046 purposes of policy decisions. For example this information 1047 could be useful to a MASA to determine that both pledge and 1048 registrar agree on proximity assertions. The MASA SHOULD 1049 remove all prior-signed-voucher information when signing 1050 a voucher for imprinting so as to minimize the final 1051 voucher size."; 1052 } 1054 leaf proximity-registrar-cert { 1055 type binary; 1056 description 1057 "An X.509 v3 certificate structure as specified by RFC 5280, 1058 Section 4 encoded using the ASN.1 distinguished encoding 1059 rules (DER), as specified in ITU-T X.690. 1061 The first certificate in the Registrar TLS server 1062 certificate_list sequence (see [RFC5246]) presented by 1063 the Registrar to the Pledge. This MUST be populated in a 1064 Pledge's voucher request if the proximity assertion is 1065 populated."; 1066 } 1067 } 1068 } 1069 } 1071 } 1073 1075 4. Proxy details 1077 The role of the Proxy is to facilitate communications. The Proxy 1078 forwards packets between the Pledge and a Registrar that has been 1079 configured on the Proxy. 1081 The Proxy does not terminate the TLS handshake: it passes streams of 1082 bytes onward without examination. 1084 A proxy MAY assume TLS framing for auditing purposes, but MUST NOT 1085 assume any TLS version. 1087 A Proxy is always assumed even if it is directly integrated into a 1088 Registrar. (In a completely autonomic network, the Registrar MUST 1089 provide proxy functionality so that it can be discovered, and the 1090 network can grow concentrically around the Registrar) 1092 As a result of the Proxy Discovery process in section Section 4.1.1, 1093 the port number exposed by the proxy does not need to be well known, 1094 or require an IANA allocation. 1096 If the Proxy joins an Autonomic Control Plane 1097 ([I-D.ietf-anima-autonomic-control-plane]) it SHOULD use Autonomic 1098 Control Plane secured GRASP ([I-D.ietf-anima-grasp]) to discovery the 1099 Registrar address and port. As part of the discovery process, the 1100 proxy mechanism (Circuit Proxy vs IPIP encapsulation) is agreed to 1101 between the Registrar and Join Proxy. 1103 For the IPIP encapsulation methods (described in Appendix C), the 1104 port announced by the Proxy SHOULD be the same as on the registrar in 1105 order for the proxy to remain stateless. 1107 In order to permit the proxy functionality to be implemented on the 1108 maximum variety of devices the chosen mechanism SHOULD use the 1109 minimum amount of state on the proxy device. While many devices in 1110 the ANIMA target space will be rather large routers, the proxy 1111 function is likely to be implemented in the control plane CPU of such 1112 a device, with available capabilities for the proxy function similar 1113 to many class 2 IoT devices. 1115 The document [I-D.richardson-anima-state-for-joinrouter] provides a 1116 more extensive analysis and background of the alternative proxy 1117 methods. 1119 4.1. Pledge discovery of Proxy 1121 The result of discovery is a logical communication with a Registrar, 1122 through a Proxy. The Proxy is transparent to the Pledge but is 1123 always assumed to exist. 1125 To discover the Proxy the Pledge performs the following actions: 1127 1. MUST: Obtains a local address using IPv6 methods as described in 1128 [RFC4862] IPv6 Stateless Address AutoConfiguration. Use of 1130 [RFC4941] temporary addresses is encouraged. A new temporary 1131 address SHOULD be allocated whenever the discovery process is 1132 forced to restart due to failures. Pledges will generally prefer 1133 use of IPv6 Link-Local addresses, and discovery of Proxy will be 1134 by Link-Local mechanisms. IPv4 methods are described in 1135 Appendix A 1137 2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) 1138 announcements of the objective: "AN_Proxy". See section 1139 Section 4.1.1 for the details of the objective. The Pledge may 1140 listen concurrently for other sources of information, see 1141 Appendix B. 1143 Once a proxy is discovered the Pledge communicates with a Registrar 1144 through the proxy using the bootstrapping protocol defined in 1145 Section 5. 1147 Each discovery method attempted SHOULD exponentially back-off 1148 attempts (to a maximum of one hour) to avoid overloading the network 1149 infrastructure with discovery. The back-off timer for each method 1150 MUST be independent of other methods. 1152 Methods SHOULD be run in parallel to avoid head of queue problems 1153 wherein an attacker running a fake proxy or registrar can operate 1154 protocol actions intentionally slowly. 1156 Once a connection to a Registrar is established (e.g. establishment 1157 of a TLS session key) there are expectations of more timely 1158 responses, see Section 5.2. 1160 Once all discovered services are attempted the device SHOULD return 1161 to listening for GRASP M_FLOOD. It should periodically retry the 1162 vendor specific mechanisms. The Pledge MAY prioritize selection 1163 order as appropriate for the anticipated environment. 1165 4.1.1. Proxy Grasp announcements 1167 A proxy uses the GRASP M_FLOOD mechanism to announce itself. The 1168 pledge SHOULD listen for messages of these form. This announcement 1169 can be within the same message as the ACP announcement detailed in 1170 [I-D.ietf-anima-autonomic-control-plane]. 1172 proxy-objective = ["AN_Proxy", [ O_IPv6_LOCATOR, ipv6-address, 1173 transport-proto, port-number ] ] 1175 ipv6-address - the v6 LL of the proxy 1176 transport-proto - 6, for TCP 17 for UDP 1177 port-number - the TCP or UDP port number to find the proxy 1179 Figure 5 1181 4.2. CoAP connection to Registrar 1183 The use of CoAP to connect from Pledge to Registrar is out of scope 1184 for this document, and may be described in future work. 1186 4.3. HTTPS proxy connection to Registrar 1188 The proxy SHOULD also provide one of: an IPIP encapsulation of HTTP 1189 traffic to the registrar, or a TCP circuit proxy that connects the 1190 Pledge to a Registrar. 1192 When the Proxy provides a circuit proxy to a Registrar the Registrar 1193 MUST accept HTTPS connections. 1195 4.4. Proxy discovery of Registrar 1197 The Registrar SHOULD announce itself so that proxies can find it and 1198 determine what kind of connections can be terminated. 1200 The registrar announces itself using GRASP M_FLOOD messages. The 1201 M_FLOOD is formatted as follows: 1203 [M_FLOOD, 12340815, h'fda379a6f6ee0000200000064000001', 180000, 1204 ["AN_join_registrar", 4, 255, "EST-TLS"], 1205 [O_IPv6_LOCATOR, 1206 h'fda379a6f6ee0000200000064000001', TCP, 80 1208 Figure 6: Registrar Discovery 1210 The formal CDDL definition is: 1212 flood-message = [M_FLOOD, session-id, initiator, ttl, 1213 +[objective, (locator-option / [])]] 1215 objective = ["AN_join_registrar", objective-flags, loop-count, 1216 objective-value] 1218 initiator = ACP address to contact Registrar 1219 objective-flags = sync-only ; as in GRASP spec 1220 sync-only = 4 ; M_FLOOD only requires synchronization 1221 loop-count = 255 ; mandatory maximum 1222 objective-value = text ; name of the (list of) of supported 1223 ; protocols: "EST-TLS" for RFC7030. 1225 Figure 7: AN_join_registrar CDDL 1227 The M_FLOOD message MUST be sent periodically. The period is subject 1228 to network administrator policy (EST server configuration). It must 1229 be so low that the aggregate amount of periodic M_FLOODs from all EST 1230 servers causes negligible traffic across the ACP. 1232 The locators are to be interpreted as follows: 1234 locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] 1235 locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] 1236 locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] 1238 Figure 7: Registrar Response 1240 The set of locators is to be interpreted as follows. A protocol of 6 1241 indicates that TCP proxying on the indicated port is desired. A 1242 protocol of 17 indicates that UDP proxying on the indicated port is 1243 desired. In each case, the traffic SHOULD be proxied to the same 1244 port at the ULA address provided. 1246 A protocol of 41 indicates that packets may be IPIP proxy'ed. In the 1247 case of that IPIP proxying is used, then the provided link-local 1248 address MUST be advertised on the local link using proxy neighbour 1249 discovery. The Join Proxy MAY limit forwarded traffic to the 1250 protocol (6 and 17) and port numbers indicated by locator1 and 1251 locator2. The address to which the IPIP traffic should be sent is 1252 the initiator address (an ACP address of the Registrar), not the 1253 address given in the locator. 1255 Registrars MUST accept TCP / UDP traffic on the ports given at the 1256 ACP address of the Registrar. If the Registrar supports IPIP 1257 ntunnelling, it MUST also accept traffic encapsulated with IPIP. 1259 Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated. 1260 Registrars MAY accept DTLS/CoAP/EST traffic on the UDP in addition to 1261 TCP traffic. 1263 5. Protocol Details 1265 The Pledge MUST initiate BRSKI after boot if it is unconfigured. The 1266 Pledge MUST NOT automatically initiate BRSKI if it has been 1267 configured or is in the process of being configured. 1269 BRSKI is described as extensions to EST [RFC7030] to reduce the 1270 number of TLS connections and crypto operations required on the 1271 Pledge. The Registrar implements the BRSKI REST interface within the 1272 same .well-known URI tree as the existing EST URIs as described in 1273 EST [RFC7030] section 3.2.2. The communication channel between the 1274 Pledge and the Registrar is referred to as "BRSKI-EST" (see 1275 Figure 1). 1277 The communication channel between the Registrar and MASA is similarly 1278 described as extensions to EST within the same ./well-known tree. 1279 For clarity this channel is referred to as "BRSKI-MASA". (See 1280 Figure 1). 1282 MASA URI is "https:// authority "./well-known/est". 1284 BRSKI uses EST message formats for existing operations, uses JSON 1285 [RFC7159] for all new operations defined here, and voucher formats. 1287 While EST section 3.2 does not insist upon use of HTTP 1.1 persistent 1288 connections, BRSKI-EST connections SHOULD use persistent connections. 1289 The intention of this guidance is to ensure the provisional TLS 1290 authentication occurs only once and is properly managed. 1292 Summarized automation extensions for the BRSKI-EST flow are: 1294 o The Pledge provisionally accepts the Registrar certificate during 1295 the TLS handshake as detailed in Section 5.1. 1297 o If the Registrar responds with a redirection to other web origins 1298 the Pledge MUST follow only a single redirection. (EST supports 1299 redirection but does not allow redirections to other web origins 1300 without user input). 1302 o The Registar MAY respond with an HTTP 202 ("the request has been 1303 accepted for processing, but the processing has not been 1304 completed") as described in EST [RFC7030] section 4.2.3 wherein 1305 the client "MUST wait at least the specified 'retry-after' time 1306 before repeating the same request". The Pledge is RECOMMENDED to 1307 provide local feed (blinked LED etc) during this wait cycle if 1308 mechanisms for this are available. To prevent an attacker 1309 Registrar from significantly delaying bootstrapping the Pledge 1310 MUST limit the 'retry-after' time to 60 seconds. To avoid 1311 blocking on a single erroneous Registrar the Pledge MUST drop the 1312 connection after 5 seconds in which there has been no progress on 1313 the TCP connection. It should proceed to other discovered 1314 Registrars if there are any. If there were no other Registrars 1315 discovered, the pledge MAY continue to wait, as long as it is 1316 concurrently listening for new proxy announcements. 1318 o Ideally the Pledge could keep track of the appropriate retry-after 1319 value for any number of outstanding Registrars but this would 1320 involve a large state table on the Pledge. Instead the pledge MAY 1321 ignore the exact retry-after value in favor of a single hard coded 1322 value that takes effect between discovery ([[ProxyDiscovery]]) 1323 attempts. A Registrar that is unable to complete the transaction 1324 the first time due to timing reasons will have future chances. 1326 o The Pledge requests and validates a voucher using the new REST 1327 calls described below. 1329 o If necessary the Pledge calls the EST defined /cacerts method to 1330 obtain the domain owners' CA certificate. The pinned-domain- 1331 certificate element from the voucher should validate this 1332 certificate, or be identical to it. 1334 o The Pledge completes authentication of the server certificate as 1335 detailed in Section 5.5.1. This moves the BRSKI-EST TLS 1336 connection out of the provisional state. Optionally, the BRSKI- 1337 EST TLS connection can now be used for EST enrollment. 1339 The extensions for a Registrar (equivalent to EST server) are: 1341 o Client authentication is automated using Initial Device Identity 1342 (IDevID) as per the EST certificate based client authentication. 1343 The subject field's DN encoding MUST include the "serialNumber" 1344 attribute with the device's unique serial number. In the language 1345 of RFC6125 this provides for a SERIALNUM-ID category of identifier 1346 that can be included in a certificate and therefore that can also 1347 be used for matching purposes. The SERIALNUM-ID whitelist is 1348 collated according to vendor trust anchor since serial numbers are 1349 not globally unique. 1351 o The Registrar requests and validates the Voucher from the vendor 1352 authorized MASA service. 1354 o The Registrar forwards the Voucher to the Pledge when requested. 1356 o The Registar performs log verifications in addition to local 1357 authorization checks before accepting optional Pledge device 1358 enrollment requests. 1360 5.1. BRSKI-EST TLS establishment details 1362 The Pledge establishes the TLS connection with the Registrar through 1363 the circuit proxy (see Section 4) but the TLS handshake is with the 1364 Registar. The BRSKI-EST Pledge is the TLS client and the BRSKI-EST 1365 Registrar is the TLS server. All security associations established 1366 are between the Pledge and the Registrar regardless of proxy 1367 operations. 1369 Establishment of the BRSKI-EST TLS connection is as specified in EST 1370 [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" 1371 [RFC7030] wherein the client is authenticated with the IDevID 1372 certificate, and the EST server (the Registrar) is provisionally 1373 authenticated with a unverified server certificate. 1375 The Pledge maintains a security paranoia concerning the provisional 1376 state, and all data received, until a voucher is received and 1377 verified as specified in Section 5.5.1 1379 5.2. Pledge Requests Voucher from the Registrar 1381 When the Pledge bootstraps it makes a request for a Voucher from a 1382 Registrar. 1384 This is done with an HTTPS POST using the operation path value of 1385 "/.well-known/est/requestvoucher". 1387 The request media types are: 1389 application/pkcs7-mime; smime-type=voucher-request The request is a 1390 "YANG-defined JSON document that has been signed using a PKCS#7 1391 structure" as described in Section 3 using the JSON encoding 1392 described in [RFC7951]. The Pledge SHOULD sign the request using 1393 the Section 2.3 credential. 1395 application/json The request is the "YANG-defined JSON document" as 1396 described in Section 3 with exception that it is not within a 1397 PKCS#7 structure. It is protected only by the TLS client 1398 authentication. This reduces the cryptographic requirements on 1399 the Pledge. 1401 For simplicity the term 'voucher-request' is used to refer to either 1402 of these media types. Registrar impementations SHOULD anticipate 1403 future media types but of course will simply fail the request if 1404 those types are not yet known. 1406 The Pledge populates the voucher-request fields as follows: 1408 created-on: Pledges that have a realtime clock are RECOMMENDED to 1409 populate this field. This provides additional information to the 1410 MASA. 1412 nonce: The Pledge voucher-request MUST contain a cryptographically 1413 strong random or pseudo-random number nonce. Doing so ensures 1414 Section 2.5 functionality. The nonce MUST NOT be reused for 1415 bootstrapping attempts. 1417 assertion: The Pledge voucher-request MAY contain an assertion of 1418 "proximity". 1420 proximity-registrar-cert: In a Pledge voucher-request this is the 1421 first certificate in the TLS server 'certificate_list' sequence 1422 (see [RFC5246]) presented by the Registrar to the Pledge. This 1423 MUST be populated in a Pledge voucher-request if the "proximity" 1424 assertion is populated. 1426 All other fields MAY be omitted in the Pledge voucher-request. 1428 An example JSON payload of a Pledge voucher-request is in Section 3.2 1429 Example 1. 1431 The Registrar validates the client identity as described in EST 1432 [RFC7030] section 3.3.2. If the request is signed the Registrar 1433 confirms the 'proximity' asserion and associated 'proximity- 1434 registrar-cert' are correct. The registrar performs authorization as 1435 detailed in [[EDNOTE: UNRESOLVED. See Appendix D "Pledge 1436 Authorization"]]. If these validations fail the Registrar SHOULD 1437 respond with an appropriate HTTP error code. 1439 If authorization is successful the Registrar obtains a voucher from 1440 the MASA service (see Section 5.4) and returns that MASA signed 1441 voucher to the pledge as described in Section 5.5. 1443 5.3. BRSKI-MASA TLS establishment details 1445 The BRSKI-MASA TLS connection is a 'normal' TLS connection 1446 appropriate for HTTPS REST interfaces. The Registrar initiates the 1447 connection and uses the MASA URL obtained as described in Section 2.7 1448 for RFC6125 authentication of the MASA server. 1450 The primary method of Registrar "authentication" by the MASA is 1451 detailed in Section 5.4. As detailed in Section 8 the MASA might 1452 find it necessary to request additional Registrar authentication. 1453 Registrars MUST be prepared to support TLS client certificate 1454 authentication and HTTP Basic or Digest authentication as described 1455 in RFC7030 for EST clients. Implementors are advised that contacting 1456 the MASA is to establish a secured REST connection with a web service 1457 and that there are a number of authentication models being explored 1458 within the industry. Registrars are RECOMMENDED to fail gracefully 1459 and generate useful administrative notifications or logs in the 1460 advent of unexpected HTTP 401 (Unauthorized) responses from the MASA. 1462 5.4. Registrar Requests Voucher from MASA 1464 When a Registrar receives a Pledge voucher-request it in turn submits 1465 a Registrar voucher-request to the MASA service. For simplicity this 1466 is defined as an optional EST message between a Registrar and an EST 1467 server running on the MASA service although the Registrar is not 1468 required to make use of any other EST functionality when 1469 communicating with the MASA service. (The MASA service MUST properly 1470 reject any EST functionality requests it does not wish to service; a 1471 requirement that holds for any REST interface). 1473 This is done with an HTTP POST using the operation path value of 1474 "/.well-known/est/requestvoucher". 1476 The request media type is: 1478 application/pkcs7-mime; smime-type=voucher-request The voucher- 1479 request is a "YANG-defined JSON document that has been signed 1480 using a PKCS#7 structure" as described in [I-D.ietf-anima-voucher] 1481 using the JSON encoding described in [RFC7951]. The Registrar 1482 MUST sign the Registrar voucher-request. The entire Registrar 1483 certificate chain, up to and including the Domain CA, MUST be 1484 included in the PKCS#7 structure. 1486 MASA impementations SHOULD anticipate future media types but of 1487 course will simply fail the request if those types are not yet known. 1489 The Registrar populates the voucher-request fields as follows: 1491 created-on: Registrars are RECOMMENDED to populate this field. This 1492 provides additional information to the MASA. 1494 nonce: The optional nonce value from the Pledge request if desired 1495 (see below). 1497 serial-number: The serial number of the Pledge the Registrar would 1498 like a voucher for. 1500 idevid-issuer: The idevid-issuer value from the pledge certificate 1501 is included to ensure a statistically unique identity. The 1502 Pledge's serial number is extracted from the X.509 IDevID. See 1503 Section 2.3. 1505 prior-signed-voucher: If a signed Pledge voucher-request was 1506 received then it SHOULD be included in the Registrar voucher- 1507 request. (NOTE: what is included is the complete Pledge voucher- 1508 request, inclusive of the 'assertion', 'proximity-registrar-cert', 1509 etc wrapped by the pledge's original signature). 1511 A nonceless Registrar voucher-request MAY be submitted to the MASA. 1512 Doing so allows the Registrar to request a Voucher when the Pledge is 1513 offline, or when the Registrar is expected to be offline when the 1514 Pledge is being deployed. These use cases require the Registrar to 1515 learn the appropriate IDevID SerialNumber field from the physical 1516 device labeling or from the sales channel (out-of-scope of this 1517 document). If a nonceless voucher-reqeust is submitted the MASA 1518 server MUST authenticate the Registrar as described in either EST 1519 [RFC7030] section 3.2, section 3.3, or by validating the Registrar's 1520 certificate used to sign the Registrar voucher-request. Any of these 1521 methods reduce the risk of DDoS attacks and provide an authenticated 1522 identity as an input to sales channel integration and authorizations 1523 (the actual sale-channel integration is also out-of-scope of this 1524 document). 1526 All other fields MAY be omitted in the Registrar voucher-request. 1528 Example JSON payloads of Registrar voucher-requests are in 1529 Section 3.2 Example 2 through 4. 1531 The MASA verifies that the Registrar voucher-request is internally 1532 consistent but does not necessarily authenticate the Registrar 1533 certificate since the registrar is not know to the MASA server in 1534 advance. The MASA validation checks before issuing a voucher are as 1535 follows: 1537 Renew for expired voucher: As described in [I-D.ietf-anima-voucher] 1538 vouchers are normally short lived to avoid revocation issues. If 1539 the request is for a previous (expired) voucher using the same 1540 Registrar (as determined by the Registrar pinned-domain-cert) and 1541 the MASA has not been informed that the claim is invalid then the 1542 request for a renewed voucher SHOULD be automatically authorized. 1544 Voucher signature consistency: The MASA MUST verify that the 1545 Registrar voucher-request is signed by a Registrar. This is 1546 confirmed by verifying that the id-kp-cmcRA extended key usage 1547 extension field (as detailed in EST RFC7030 section 3.6.1) exists 1548 in the certificate of the entity that signed the Registrar 1549 voucher-request. This verification is only a consistency check 1550 that the unauthenticated domain CA intended this to be a 1551 Registrar. Performing this check provides value to domain PKI by 1552 assuring the domain administrator that the MASA service will only 1553 respect claims from authorized Registration Authorities of the 1554 domain. (The requirement for the Registrar to include the Domain 1555 CA certificate in the signature structure was stated above). 1557 Registrar revocation consistency: The MASA SHOULD check for 1558 revocation of the Registrar certificate. The maximum lifetime of 1559 the voucher issued SHOULD NOT exceed the lifetime of the 1560 Registrar's revocation validation (for example if the Registrar 1561 revocation status is indicated in a CRL that is valid for two 1562 weeks then that is an appropriate lifetime for the voucher). 1563 Because the Registar certificate authority is unknown to the MASA 1564 in advance this is only an extended consistency check and is not 1565 required. The maximum lifetime of the voucher issued SHOULD NOT 1566 exceed the lifetime of the Registrar's revocation validation (for 1567 example if the Registrar revocation status is indicated in a CRL 1568 that is valid for two weeks then that is an appropriate lifetime 1569 for the voucher). 1571 Pledge proximity assertion: The MASA server MAY verify that the 1572 Registrar voucher-request includes the 'prior-signed-voucher' 1573 field populated with a Pledge voucher-request that includes a 1574 'proximity-registrar-cert' that is consistent with the certificate 1575 used to sign the Registrar voucher-request. The MASA server is 1576 aware of which Pledge's support signing of their voucher requests 1577 and can use this information to confirm proximity of the Pledge 1578 with the Registrar. 1580 Registar (certificate) authentication: This only occurs if the 1581 Registrar voucher-request is nonceless. As noted above the 1582 details concerning necessary sales-channel integration for the 1583 MASA to authenticate a Registrar certificate is out-of-scope. 1585 The Registrar's certificate chain is extracted from the signature 1586 method and the root certificate is used to populate the "pinned- 1587 domain-cert" of the Voucher being issued. The domainID (e.g. hash of 1588 the root public key) is determined from the pinned-domain-cert and is 1589 used to update the audit log. 1591 5.5. Voucher Response 1593 The voucher response to requests from the Pledge and requests from a 1594 Registrar are in the same format. A Registrar either caches prior 1595 MASA responses or dynamically requests a new Voucher based on local 1596 policy. 1598 If the join operation is successful, the server response MUST contain 1599 an HTTP 200 response code. The server MUST answer with a suitable 1600 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. The 1601 response data from the MASA server MUST be a plaintext human-readable 1602 (ASCII, english) error message containing explanatory information 1603 describing why the request was rejected. 1605 A 403 (Forbidden) response is appropriate if the voucher-request is 1606 not signed correctly, stale, or if the pledge has another outstanding 1607 voucher which can not be overridden. 1609 A 404 (Not Found) response is appropriate when the request is for a 1610 device which is not known to the MASA. 1612 A 406 (Not Acceptable) response is appropriate if a voucher of the 1613 desired type, or using the desired algorithms (as indicated by the 1614 Accept: headers, and algorithms used in the signature) can not be 1615 issued, such as because the MASA knows the pledge can not process 1616 that type. 1618 A 415 (Unsupported Media Type) response is approriate for a request 1619 that has a voucher encoding that is not understood. 1621 The response media type is: 1623 application/pkcs7-mime; smime-type=voucher The response is a "YANG- 1624 defined JSON document that has been signed using a PKCS#7 1625 structure" as described in [I-D.ietf-anima-voucher] using the JSON 1626 encoded described in [RFC7951]. The MASA MUST sign the request. 1628 The syntactic details of vouchers are described in detail in 1629 [I-D.ietf-anima-voucher]. For example, the voucher consists of: 1631 { 1632 "ietf-voucher:voucher": { 1633 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1634 "assertion": "logging" 1635 "pinned-domain-cert": "base64encodedvalue==" 1636 "serial-number": "JADA123456789" 1637 } 1638 } 1639 The Pledge verifies the signed voucher using the manufacturer 1640 installed trust anchor associated with the vendor's selected 1641 Manufacturer Authorized Signing Authority. 1643 The 'pinned-domain-cert' element of the voucher contains the domain 1644 CA's public key. The Pledge MUST use the 'pinned-domain-cert' trust 1645 anchor to immediately complete authentication of the provisional TLS 1646 connection. 1648 The Pledge MUST be prepared to parse and fail gracefully from a 1649 Voucher response that does not contain a 'pinned-domain-cert' field. 1650 The Pledge MUST be prepared to ignore additional fields it does not 1651 recognize. 1653 5.5.1. Completing authentication of Provisional TLS connection 1655 If a Registrar's credentials can not be verified using the pinned- 1656 domain-cert trust anchor from the voucher then the TLS connection is 1657 immediately discarded and the Pledge abandons attempts to bootstrap 1658 with this discovered registrar. The pledge SHOULD send voucher 1659 status telemetry (described below) before closing the TLS connection. 1660 The pledge MUST attempt to enroll using any other proxies it has 1661 found. It SHOULD return to the same proxy again after attempting 1662 with other proxies. Attempts should be attempted in the exponential 1663 backoff described earlier. Attempts SHOULD be repeated as failure 1664 may be the result of a temporary inconsistently (an inconsistently 1665 rolled Registrar key, or some other mis-configuration). The 1666 inconsistently could also be the result an active MITM attack on the 1667 EST connection. 1669 The Registrar MUST use a certificate that chains to the pinned- 1670 domain-cert as its TLS server certificate. 1672 The Pledge's PKIX path validation of a Registrar certificate's 1673 validity period information is as described in Section 2.5. Once the 1674 PKIX path validation is successful the TLS connection is no longer 1675 provisional. 1677 The pinned-domain-cert is installed as an Explicit Trust Anchor for 1678 future operations. It can therefore can be used to authenticate any 1679 dynamically discovered EST server that contain the id-kp-cmcRA 1680 extended key usage extension as detailed in EST RFC7030 section 1681 3.6.1; but to reduce system complexity the Pledge SHOULD avoid 1682 additional discovery operations. Instead the Pledge SHOULD 1683 communicate directly with the Registrar as the EST server. The ' 1684 pinned-domain-cert' is not a complete distribution of the EST section 1685 4.1.3 CA Certificate Response which is an additional justification 1686 for the recommendation to proceed with EST key management operations. 1688 Once a full CA Certificate Response is obtained it is more 1689 authoritative for the domain than the limited 'pinned-domain-cert' 1690 response.' 1692 5.6. Voucher Status Telemetry 1694 The domain is expected to provide indications to the system 1695 administrators concerning device lifecycle status. To facilitate 1696 this it needs telemetry information concerning the device's status. 1698 To indicate Pledge status regarding the Voucher, the pledge MUST post 1699 a status message. 1701 The posted data media type: application/json 1703 The client HTTP POSTs the following to the server at the EST well 1704 known URI /voucher_status. The Status field indicates if the Voucher 1705 was acceptable. If it was not acceptable the Reason string indicates 1706 why. In the failure case this message is being sent to an 1707 unauthenticated, potentially malicious Registrar and therefore the 1708 Reason string SHOULD NOT provide information beneficial to an 1709 attacker. The operational benefit of this telemetry information is 1710 balanced against the operational costs of not recording that an 1711 Voucher was ignored by a client the registar expected to continue 1712 joining the domain. 1714 { 1715 "version":"1", 1716 "Status":FALSE /* TRUE=Success, FALSE=Fail" 1717 "Reason":"Informative human readable message" 1718 "reason-context": { additional JSON } 1719 } 1721 The server SHOULD respond with an HTTP 200 but MAY simply fail with 1722 an HTTP 404 error. The client ignores any response. Within the 1723 server logs the server SHOULD capture this telemetry information. 1725 The reason-context attribute is an arbitrary JSON object (literal 1726 value or hash of values) which provides additional information 1727 specific to this pledge. The contents of this field are not subject 1728 to standardization." 1730 Additional standard responses MAY be added via Specification 1731 Required. 1733 5.7. MASA authorization log Request 1735 After receiving the voucher status telemetry Section 5.6, the 1736 Registrar SHOULD request the MASA authorization log from the MASA 1737 service using this EST extension. If a device had previously 1738 registered with another domain, a Registrar of that domain would show 1739 in the log. 1741 This is done with an HTTP GET using the operation path value of 1742 "/.well-known/est/requestauditlog". 1744 The Registrar MUST HTTP POSTs the same Registrar voucher-request as 1745 it did when requesting a Voucher. It is posted to the 1746 /requestauditlog URI instead. The "idevid-issuer" and "serial- 1747 number" informs the MASA server which log is requested so the 1748 appropriate log can be prepared for the response. Using the same 1749 media type and message minimizes cryptographic and message operations 1750 although it results in additional network traffic. The relying MASA 1751 server implementation MAY leverage internal state to associate this 1752 request with the original, and by now already validated, Registrar 1753 voucher-request so as to avoid an extra crypto validation. 1755 A MASA which receives a request for a device which does not exist, or 1756 for which the requesting owner was never an owner returns an HTTP 404 1757 ("Not found") code. 1759 Rather than returning the audit log as a response to the POST (with a 1760 return code 200), the MASA MAY instead return a 201 ("Created") 1761 RESTful response ([RFC7231] section 7.1) containing a URL to the 1762 prepared (and easily cachable) audit response. 1764 MASA servers that return URLs SHOULD take care to make the returned 1765 URL unguessable. URLs containing a database number such as 1766 https://example.com/auditlog/1234 or the EUI of the device such 1767 https://example.com/auditlog/10-00-00-11-22-33, would be easily 1768 enumerable by an attacker. It is recommended put to put some 1769 meaningless randomly generated slug that indexes a database instead. 1771 A MASA that returns a code 200 MAY also include a Location: header 1772 for future reference by the Registrar. 1774 The request media type is: 1776 application/pkcs7-mime; smime-type=voucher-request The request is a 1777 "YANG-defined JSON document that has been signed using a PKCS#7 1778 structure" as described in Section 3 using the JSON encoded 1779 described in [RFC7951]. The Registrar MUST sign the request. The 1780 entire Registrar certificate chain, up to and including the Domain 1781 CA, MUST be included in the PKCS#7 structure. 1783 5.7.1. MASA authorization log Response 1785 A log data file is returned consisting of all log entries. For 1786 example: 1788 { 1789 "version":"1", 1790 "events":[ 1791 { 1792 "date":"", 1793 "domainID":"", 1794 "nonce":"" 1795 }, 1796 { 1797 "date":"", 1798 "domainID":"", 1799 "nonce":"" 1800 } 1801 ] 1802 } 1804 Distribution of a large log is less than ideal. This structure can 1805 be optimized as follows: All nonceless entries for the same domainID 1806 MAY be condensed into the single most recent nonceless entry. 1808 A Registrar SHOULD use this log information to make an informed 1809 decision regarding the continued bootstrapping of the Pledge. For 1810 example if the log includes an unexpected domainID then the Pledge 1811 could have imprinted on an unexpected domain. If the log includes 1812 nonceless entries then any registrar in the same domain could 1813 theoretically trigger a reset of the device and take over management 1814 of the Pledge. Equipment that is purchased pre-owned can be expected 1815 to have an extensive history. A Registrar MAY request logs at future 1816 times. A Registrar MAY be configured to ignore the history of the 1817 device but it is RECOMMENDED that this only be configured if hardware 1818 assisted NEA [RFC5209] is supported. 1820 Log entries can be compared against local history logs in search of 1821 discrepancies. 1823 This document specifies a simple log format as provided by the MASA 1824 service to the registar. This format could be improved by 1825 distributed consensus technologies that integrate vouchers with a 1826 technologies such as block-chain or hash trees or the like. Doing so 1827 is out of the scope of this document but are anticipated improvements 1828 for future work. As such, the Registrar client SHOULD anticipate new 1829 kinds of responses, and SHOULD provide operator controls to indicate 1830 how to process unknown responses. 1832 5.8. EST Integration for PKI bootstrapping 1834 The Pledge SHOULD follow the BRSKI operations with EST enrollment 1835 operations including "CA Certificates Request", "CSR Attributes" and 1836 "Client Certificate Request" or "Server-Side Key Generation" etc. 1837 This is a relatively seamless integration since BRSKI REST calls 1838 provide an automated alternative to the manual bootstrapping method 1839 described in [RFC7030]. As noted above, use of HTTP 1.1 persistent 1840 connections simplifies the Pledge state machine. 1842 The Pledge is also RECOMMENDED to implement the following EST 1843 automation extensions. They supplement the RFC7030 EST to better 1844 support automated devices that do not have an end user. 1846 Although EST allows clients to obtain multiple certificates by 1847 sending multiple CSR requests BRSKI mandates use of the CSR 1848 Attributes request and mandates that the Registrar validate the CSR 1849 against the expected attributes. This implies that client requests 1850 will "look the same" and therefore result in a single logical 1851 certificate being issued even if the client were to make multiple 1852 requests. Registrars MAY contain more complex logic but doing so is 1853 out-of-scope of this specification. BRSKI does not signal any 1854 enhancement or restriction to this capability. Pledges that require 1855 multiple certificates could establish direct EST connections to the 1856 Registrar. 1858 5.8.1. EST Distribution of CA Certificates 1860 The Pledge MUST request the full EST Distribution of CA Certificates 1861 message. See RFC7030, section 4.1. 1863 This ensures that the Pledge has the complete set of current CA 1864 certificates beyond the pinned-domain-cert (see Section 5.5.1 for a 1865 discussion of the limitations inherent in having a single certificate 1866 instead of a full CA Certificates response). Although these 1867 limitations are acceptable during initial bootstrapping they are not 1868 appropriate for ongoing PKIX end entity certificate validation. 1870 5.8.2. EST CSR Attributes 1872 Automated bootstrapping occurs without local administrative 1873 configuration of the Pledge. In some deployments its plausible that 1874 the Pledge generates a certificate request containing only identity 1875 information known to the Pledge (essentially the X.509 IDevID 1876 information) and ultimately receives a certificate containing domain 1877 specific identity information. Conceptually the CA has complete 1878 control over all fields issued in the end entity certificate. 1879 Realistically this is operationally difficult with the current status 1880 of PKI certificate authority deployments where the CSR is submitted 1881 to the CA via a number of non-standard protocols. Even with all 1882 standardized protocols used, it could operationally be problematic to 1883 expect that service specific certificate fields can be created by a 1884 CA that is likely operated by a group that has no insight into 1885 different network services/protocols used. For example, the CA could 1886 even be outsourced. 1888 To alleviate these operational difficulties, the Pledge MUST request 1889 the EST "CSR Attributes" from the EST server and the EST server needs 1890 to be able to reply with the attributes necessary for use of the 1891 certificate in its intended protocols/services. This approach allows 1892 for minimal CA integrations and instead the local infrastructure (EST 1893 server) informs the Pledge of the proper fields to include in the 1894 generated CSR. This approach is beneficial to automated boostrapping 1895 in the widest number of environments. 1897 If the hardwareModuleName in the X.509 IDevID is populated then it 1898 SHOULD by default be propagated to the LDevID along with the 1899 hwSerialNum. The EST server SHOULD support local policy concerning 1900 this functionality. 1902 In networks using the BRSKI enrolled certificate to authenticate the 1903 ACP (Autonomic Control Plane), the EST attributes MUST include the 1904 "ACP information" field. See 1905 [I-D.ietf-anima-autonomic-control-plane] for more details. 1907 The Registar MUST also confirm the resulting CSR is formatted as 1908 indicated before forwarding the request to a CA. If the Registar is 1909 communicating with the CA using a protocol like full CMC which 1910 provides mechanisms to override the CSR attributes, then these 1911 mechanisms MAY be used even if the client ignores CSR Attribute 1912 guidance. 1914 5.8.3. EST Client Certificate Request 1916 The Pledge MUST request a new client certificate. See RFC7030, 1917 section 4.2. 1919 5.8.4. Enrollment Status Telemetry 1921 For automated bootstrapping of devices the adminstrative elements 1922 providing bootstrapping also provide indications to the system 1923 administrators concerning device lifecycle status. This might 1924 include information concerning attempted bootstrapping messages seen 1925 by the client, MASA provides logs and status of credential 1926 enrollment. The EST protocol assumes an end user and therefore does 1927 not include a final success indication back to the server. This is 1928 insufficient for automated use cases. 1930 To indicate successful enrollment the client SHOULD re-negotiate the 1931 EST TLS session using the newly obtained credentials. This occurs by 1932 the client initiating a new TLS ClientHello message on the existing 1933 TLS connection. The client MAY simply close the old TLS session and 1934 start a new one. The server MUST support either model. 1936 In the case of a FAIL the Reason string indicates why the most recent 1937 enrollment failed. The SubjectKeyIdentifier field MUST be included 1938 if the enrollment attempt was for a keypair that is locally known to 1939 the client. If EST /serverkeygen was used and failed then the field 1940 is omitted from the status telemetry. 1942 In the case of a SUCCESS the Reason string is omitted. The 1943 SubjectKeyIdentifier is included so that the server can record the 1944 successful certificate distribution. 1946 Status media type: application/json 1948 The client HTTP POSTs the following to the server at the new EST well 1949 known URI /enrollstatus. 1951 { 1952 "version":"1", 1953 "Status":TRUE /* TRUE=Success, FALSE=Fail" 1954 "Reason":"Informative human readable message" 1955 "reason-context": "Additional information" 1956 } 1958 The server SHOULD respond with an HTTP 200 but MAY simply fail with 1959 an HTTP 404 error. 1961 Within the server logs the server MUST capture if this message was 1962 received over an TLS session with a matching client certificate. 1963 This allows for clients that wish to minimize their crypto operations 1964 to simply POST this response without renegotiating the TLS session - 1965 at the cost of the server not being able to accurately verify that 1966 enrollment was truly successful. 1968 5.8.5. EST over CoAP 1970 This document describes extensions to EST for the purposes of 1971 bootstrapping of remote key infrastructures. Bootstrapping is 1972 relevant for CoAP enrollment discussions as well. The defintion of 1973 EST and BRSKI over CoAP is not discussed within this document beyond 1974 ensuring proxy support for CoAP operations. Instead it is 1975 anticipated that a definition of CoAP mappings will occur in 1976 subsequent documents such as [I-D.vanderstok-ace-coap-est] and that 1977 CoAP mappings for BRSKI will be discussed either there or in future 1978 work. 1980 6. Reduced security operational modes 1982 A common requirement of bootstrapping is to support less secure 1983 operational modes for support specific use cases. The following 1984 sections detail specific ways that the Pledge, Registrar and MASA can 1985 be configured to run in a less secure mode for the indicated reasons. 1987 6.1. Trust Model 1989 +--------+ +---------+ +------------+ +------------+ 1990 | Pledge | | Circuit | | Domain | | Vendor | 1991 | | | Proxy | | Registrar | | Service | 1992 | | | | | | | (Internet | 1993 +--------+ +---------+ +------------+ +------------+ 1995 Figure 10 1997 Pledge: The Pledge could be compromised and providing an attack 1998 vector for malware. The entity is trusted to only imprint using 1999 secure methods described in this document. Additional endpoint 2000 assessment techniques are RECOMMENDED but are out-of-scope of this 2001 document. 2003 Proxy: Provides proxy functionalities but is not involved in 2004 security considerations. 2006 Registrar: When interacting with a MASA server a Registrar makes all 2007 decisions. When Ownership Vouchers are involved a Registrar is 2008 only a conduit and all security decisions are made on the vendor 2009 service. 2011 Vendor Service, MASA: This form of vendor service is trusted to 2012 accurately log all claim attempts and to provide authoritative log 2013 information to Registrars. The MASA does not know which devices 2014 are associated with which domains. These claims could be 2015 strengthened by using cryptographic log techniques to provide 2016 append only, cryptographic assured, publicly auditable logs. 2017 Current text provides only for a trusted vendor. 2019 Vendor Service, Ownership Validation: This form of vendor service is 2020 trusted to accurately know which device is owned by which domain. 2022 6.2. Pledge security reductions 2024 The Pledge can choose to accept vouchers using less secure methods. 2025 These methods enable offline and emergency (touch based) deployment 2026 use cases: 2028 1. The Pledge MUST accept nonceless vouchers. This allows for 2029 offline use cases. Logging and validity periods address the 2030 inherent security considerations of supporting these use cases. 2032 2. The Pledge MAY support "trust on first use" for physical 2033 interfaces such as a local console port or physical user 2034 interface but MUST NOT support "trust on first use" on network 2035 interfaces. This is because "trust on first use" permanently 2036 degrades the security for all use cases. 2038 3. The Pledge MAY have an operational mode where it skips Voucher 2039 validation one time. For example if a physical button is 2040 depressed during the bootstrapping operation. This can be useful 2041 if the vendor service is unavailable. This behavior SHOULD be 2042 available via local configuration or physical presence methods to 2043 ensure new entities can always be deployed even when autonomic 2044 methods fail. This allows for unsecured imprint. 2046 It is RECOMMENDED that "trust on first use" or skipping voucher 2047 validation only be available if hardware assisted Network Endpoint 2048 Assessment [RFC5209] is supported. This recommendation ensures that 2049 domain network monitoring can detect innappropriate use of offline or 2050 emergency deployment procedures. 2052 6.3. Registrar security reductions 2054 A Registrar can choose to accept devices using less secure methods. 2055 These methods are acceptable when low security models are needed, as 2056 the security decisions are being made by the local administrator, but 2057 they MUST NOT be the default behavior: 2059 1. A registrar MAY choose to accept all devices, or all devices of a 2060 particular type, at the administrator's discretion. This could 2061 occur when informing all Registrars of unique identifiers of new 2062 entities might be operationally difficult. 2064 2. A registrar MAY choose to accept devices that claim a unique 2065 identity without the benefit of authenticating that claimed 2066 identity. This could occur when the Pledge does not include an 2067 X.509 IDevID factory installed credential. New Entities without 2068 an X.509 IDevID credential MAY form the Section 5.2 request using 2069 the Section 5.4 format to ensure the Pledge's serial number 2070 information is provided to the Registar (this includes the IDevID 2071 AuthorityKeyIdentifier value which would be statically configured 2072 on the Pledge). The Pledge MAY refuse to provide a TLS client 2073 certificate (as one is not available). The Pledge SHOULD support 2074 HTTP-based or certificate-less TLS authentication as described in 2075 EST RFC7030 section 3.3.2. A Registrar MUST NOT accept 2076 unauthenticated New Entities unless it has been configured to do 2077 so by an administrator that has verified that only expected new 2078 entities can communicate with a Registrar (presumably via a 2079 physically secured perimeter). 2081 3. A Registrar MAY submit a nonceless voucher-requests to MASA 2082 service (by not including a nonce in the voucher-request). The 2083 resulting Vouchers can then be stored by the Registrar until they 2084 are needed during bootstrapping operations. This is for use 2085 cases where target network is protected by an air gap and 2086 therefore can not contact the MASA service during Pledge 2087 deployment. 2089 4. A registrar MAY ignore unrecognized nonceless log entries. This 2090 could occur when used equipment is purchased with a valid history 2091 being deployed in air gap networks that required permanent 2092 Vouchers. 2094 6.4. MASA security reductions 2096 Lower security modes chosen by the MASA service effect all device 2097 deployments unless bound to the specific device identities. In which 2098 case these modes can be provided as additional features for specific 2099 customers. The MASA service can choose to run in less secure modes 2100 by: 2102 1. Not enforcing that a nonce is in the Voucher. This results in 2103 distribution of Voucher that never expires and in effect makes 2104 the Domain an always trusted entity to the Pledge during any 2105 subsequent bootstrapping attempts. That this occurred is 2106 captured in the log information so that the Registrar can make 2107 appropriate security decisions when a Pledge joins the Domain. 2108 This is useful to support use cases where Registrars might not be 2109 online during actual device deployment. Because this results in 2110 long lived Voucher and does not require the proof that the device 2111 is online this is only accepted when the Registrar is 2112 authenticated by the MASA server and authorized to provide this 2113 functionality. The MASA server is RECOMMENDED to use this 2114 functionality only in concert with an enhanced level of ownership 2115 tracking (out-of-scope). If the Pledge device is known to have a 2116 real-time-clock that is set from the factory use of a voucher 2117 validity period is RECOMMENDED. 2119 2. Not verifying ownership before responding with an Voucher. This 2120 is expected to be a common operational model because doing so 2121 relieves the vendor providing MASA services from having to track 2122 ownership during shipping and supply chain and allows for a very 2123 low overhead MASA service. A Registrar uses the audit log 2124 information as a defense in depth strategy to ensure that this 2125 does not occur unexpectedly (for example when purchasing new 2126 equipment the Registrar would throw an error if any audit log 2127 information is reported). The MASA should verify the 'prior- 2128 signed-voucher' information for Pledge's that support that 2129 functionality. This provides a proof-of-proximity check that 2130 reduces the need for ownership verification. 2132 7. IANA Considerations 2134 This document requests the following Parameter Values for the "smime- 2135 type" Parameters: 2137 o voucher-request 2139 o voucher 2141 7.1. PKIX Registry 2143 IANA is requested to register the following: 2145 This document requests a number for id-mod-MASAURLExtn2016(TBD) from 2146 the pkix(7) id-mod(0) Registry. [[EDNOTE: fix names]] 2148 This document requests a number from the id-pe registry for id-pe- 2149 masa-url. XXX 2151 7.2. Voucher Status Telemetry 2153 IANA is requested to create a registry entitled: _Voucher Status 2154 Telemetry Attributes_. New items can be added using the 2155 Specification Required. The following items are to be in the initial 2156 registration, with this document as the reference: 2158 o version 2159 o Status 2161 o Reason 2163 o reason-context 2165 8. Security Considerations 2167 There are uses cases where the MASA could be unavailable or 2168 uncooperative to the Registrar. They include planned and unplanned 2169 network partitions, changes to MASA policy, or other instances where 2170 MASA policy rejects a claim. These introduce an operational risk to 2171 the Registrar owner that MASA/vendor behavior might limit the ability 2172 to re-boostrap a Pledge device. For example this might be an issue 2173 during disaster recovery. This risk can be mitigated by Registrars 2174 that request and maintain long term copies of "nonceless" Vouchers. 2175 In that way they are guaranteed to be able to repeat bootstrapping 2176 for their devices. 2178 The issuance of nonceless vouchers themselves create a security 2179 concern. If the Registrar of a previous domain can intercept 2180 protocol communications then it can use a previously issued nonceless 2181 voucher to establish management control of a pledge device even after 2182 having sold it. This risk is mitigated by recording the issuance of 2183 such vouchers in the MASA audit log that is verified by the 2184 subsequent Registrar. This reduces the resale value of the equipment 2185 because future owners will detect the lowered security inherent in 2186 the existence of a nonceless voucher that would be trusted by their 2187 Pledge. This reflects a balance between partition resistant recovery 2188 and security of future bootstrapping. Registrars take the Pledge's 2189 audit history into account when applying policy to new devices. 2191 The MASA server is exposed to DoS attacks wherein attackers claim an 2192 unbounded number of devices. Ensuring a Registrar is representative 2193 of a valid vendor customer, even without validating ownership of 2194 specific Pledge devices, helps to mitigate this. Pledge signatures 2195 on the Pledge voucher-request, as forwarded by the Registrar in the 2196 prior-signed-voucher field of the Registrar voucher-request, 2197 significantly reduce this risk by ensuring the MASA can confirm 2198 proximity between the Pledge and the Registrar making the request. 2199 This mechanism is optional to allow for constrained devices. 2201 To facilitate logging and administrative oversight in addition to 2202 triggering Registration verification of MASA logs the Pledge reports 2203 on Voucher parsing status to the Registrar. In the case of a failure 2204 this information is informative to a potentially malicious Registar 2205 but this is mandated anyway because of the operational benefits of an 2206 informed administrator in cases where the failure is indicative of a 2207 problem. The Registrar is RECOMMENDED to verify MASA logs if voucher 2208 status telemetry is not received. 2210 The MASA authorization log includes a hash of the domainID for each 2211 registrar a voucher has been issued to. This information is closely 2212 related to the actual domain identity, especially when paired with 2213 the anti-DDoS authentication information the MASA might collect. 2214 This could provide sufficient information for the MASA service to 2215 build a detailed understanding the devices that have been provisioned 2216 within a domain. There are a number of design choices that mitigate 2217 this risk. The domain can maintain some privacy since it has not 2218 necessarily been authenticated and is not authoritatively bound to 2219 the supply chain. Additionally the domainID captures only the 2220 unauthenticated subject key identifier of the domain. A privacy 2221 sensitive domain could theoretically generate a new domainID for each 2222 device being deployed. Similarly a privacy sensitive domain would 2223 likely purchase devices that support proximity assertions from a 2224 vendor that does not require sales channel integrations. This would 2225 result in a significant level of privacy while maintaining the 2226 security characteristics provided by Registrar based audit log 2227 inspection. 2229 To facilitate truely limited clients EST RFC7030 section 3.3.2 2230 requirements that the client MUST support a client authentication 2231 model have been reduced in Section 6 to a statement that the 2232 Registrar "MAY" choose to accept devices that fail cryptographic 2233 authentication. This reflects current (poor) practices in shipping 2234 devices without a cryptographic identity that are NOT RECOMMENDED. 2236 During the provisional period of the connection the Pledge MUST treat 2237 all HTTP header and content data as untrusted data. HTTP libraries 2238 are regularly exposed to non-secured HTTP traffic: mature libraries 2239 should not have any problems. 2241 Pledge's might chose to engage in protocol operations with multiple 2242 discovered Registrars in parallel. As noted above they will only do 2243 so with distinct nonce values, but the end result could be multiple 2244 voucher's issued from the MASA if all registrars attempt to claim the 2245 device. This is not a failure and the Pledge choses whichever 2246 voucher to accept based on internal logic. The Registrar's verifying 2247 log information will see multiple entries and take this into account 2248 for their analytics purposes. 2250 8.1. Freshness in Voucher-Requests 2252 A concern has been raised that the Pledge voucher-request should 2253 contain some content (a nonce) provided by the Registrar and/or MASA 2254 in order for those actors to verify that the Pledge voucher-request 2255 is fresh. 2257 There are a number of operational problems with getting a nonce from 2258 the MASA to the pledge. It is somewhat easier to collect a random 2259 value from the Registrar, but as the Registrar is not yet vouched 2260 for, such a Registrar nonce has little value. There are privacy and 2261 logistical challenges to addressing these operational issues, so if 2262 such a thing were to be considered, it would have to provide some 2263 clear value. This section examines the impacts of not having a fresh 2264 Pledge voucher-request. 2266 Because the Registrar authenticates the Pledge a full Man-in-the- 2267 Middle attack is not possible, despite the provisional TLS 2268 authentication by the Pledge (see Section 5). Instead we examine the 2269 case of a fake Registrar (Rm) that communicates with the Pledge in 2270 parallel or in close time proximity with the intended Registrar. 2271 (This scenario is intentionally supported as described in 2272 Section 4.1). 2274 The fake Registrar (Rm) can obtain a voucher signed by the MASA 2275 either directly or through arbitrary intermediaries. Assuming that 2276 the MASA accepts the Registar voucher-request (either because Rm is 2277 collaborating with a legitimate Registrar according to supply chain 2278 information, or because the MASA is in audit-log only mode), then a 2279 voucher linking the pledge to the Registrar Rm is issued. 2281 Such a voucher, when passed back to the Pledge, would link the pledge 2282 to Registrar Rm, and would permit the Pledge to end the provisional 2283 state. It now trusts Rm and, if it has any security vulnerabilities 2284 leveragable by an Rm with full administrative control, can be assumed 2285 to be a threat against the intended Registrar. 2287 This flow is mitigated by the intended Registar verifying the audit 2288 logs available from the MASA as described in Section 5.7. Rm might 2289 chose to wait until after the intended Registrar completes the 2290 authorization process before submitting the now-stale Pledge voucher- 2291 request. The Rm would need to remove the Pledge's nonce. 2293 In order to successfully use the resulting "stale voucher" Rm would 2294 have to attack the Pledge and return it to a bootstrapping enabled 2295 state. This would require wiping the Pledge of current configuration 2296 and triggering a re-bootstrapping of the Pledge. This is no more 2297 likely than simply taking control of the Pledge directly but if this 2298 is a consideration the target network is RECOMMENDED to take the 2299 following steps: 2301 o Ongoing network monitoring for unexpected bootstrapping attempts 2302 by Pledges. 2304 o Retreival and examination of MASA log information upon the 2305 occurance of any such unexpected events. Rm will be listed in the 2306 logs. 2308 9. Acknowledgements 2310 We would like to thank the various reviewers for their input, in 2311 particular Brian Carpenter, Toerless Eckert, Fuyu Eleven, Eliot Lear, 2312 Sergey Kasatkin, Markus Stenberg, and Peter van der Stok 2314 10. References 2316 10.1. Normative References 2318 [I-D.ietf-anima-autonomic-control-plane] 2319 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 2320 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2321 plane-12 (work in progress), October 2017. 2323 [I-D.ietf-anima-grasp] 2324 Bormann, C., Carpenter, B., and B. Liu, "A Generic 2325 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 2326 grasp-15 (work in progress), July 2017. 2328 [I-D.ietf-anima-voucher] 2329 Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 2330 "Voucher Profile for Bootstrapping Protocols", draft-ietf- 2331 anima-voucher-06 (work in progress), October 2017. 2333 [IDevID] IEEE Standard, "IEEE 802.1AR Secure Device Identifier", 2334 December 2009, . 2337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2338 Requirement Levels", BCP 14, RFC 2119, 2339 DOI 10.17487/RFC2119, March 1997, 2340 . 2342 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 2343 "Advanced Sockets Application Program Interface (API) for 2344 IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003, 2345 . 2347 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2348 Levkowetz, Ed., "Extensible Authentication Protocol 2349 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 2350 . 2352 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 2353 Configuration of IPv4 Link-Local Addresses", RFC 3927, 2354 DOI 10.17487/RFC3927, May 2005, 2355 . 2357 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2358 Address Autoconfiguration", RFC 4862, 2359 DOI 10.17487/RFC4862, September 2007, 2360 . 2362 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 2363 Extensions for Stateless Address Autoconfiguration in 2364 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 2365 . 2367 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2368 (TLS) Protocol Version 1.2", RFC 5246, 2369 DOI 10.17487/RFC5246, August 2008, 2370 . 2372 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2373 Housley, R., and W. Polk, "Internet X.509 Public Key 2374 Infrastructure Certificate and Certificate Revocation List 2375 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2376 . 2378 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 2379 Security: An Unauthenticated Mode of IPsec", RFC 5386, 2380 DOI 10.17487/RFC5386, November 2008, 2381 . 2383 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2384 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2385 . 2387 [RFC5660] Williams, N., "IPsec Channels: Connection Latching", 2388 RFC 5660, DOI 10.17487/RFC5660, October 2009, 2389 . 2391 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2392 DOI 10.17487/RFC6762, February 2013, 2393 . 2395 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2396 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2397 . 2399 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 2400 "Enrollment over Secure Transport", RFC 7030, 2401 DOI 10.17487/RFC7030, October 2013, 2402 . 2404 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2405 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2406 2014, . 2408 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2409 Constrained-Node Networks", RFC 7228, 2410 DOI 10.17487/RFC7228, May 2014, 2411 . 2413 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2414 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2415 . 2417 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 2418 RFC 7951, DOI 10.17487/RFC7951, August 2016, 2419 . 2421 10.2. Informative References 2423 [I-D.behringer-homenet-trust-bootstrap] 2424 Behringer, M., Pritikin, M., and S. Bjarnason, 2425 "Bootstrapping Trust on a Homenet", draft-behringer- 2426 homenet-trust-bootstrap-02 (work in progress), February 2427 2014. 2429 [I-D.ietf-netconf-zerotouch] 2430 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 2431 Provisioning for NETCONF or RESTCONF based Management", 2432 draft-ietf-netconf-zerotouch-19 (work in progress), 2433 October 2017. 2435 [I-D.ietf-opsawg-mud] 2436 Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 2437 Description Specification", draft-ietf-opsawg-mud-13 (work 2438 in progress), October 2017. 2440 [I-D.richardson-anima-state-for-joinrouter] 2441 Richardson, M., "Considerations for stateful vs stateless 2442 join router in ANIMA bootstrap", draft-richardson-anima- 2443 state-for-joinrouter-01 (work in progress), July 2016. 2445 [I-D.vanderstok-ace-coap-est] 2446 Kumar, S., Stok, P., Kampanakis, P., Furuhed, M., and S. 2447 Raza, "EST over secure CoAP (EST-coaps)", draft- 2448 vanderstok-ace-coap-est-02 (work in progress), June 2017. 2450 [imprinting] 2451 Wikipedia, "Wikipedia article: Imprinting", July 2015, 2452 . 2454 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2455 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2456 December 1998, . 2458 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2459 Interface Identifiers with IPv6 Stateless Address 2460 Autoconfiguration (SLAAC)", RFC 7217, 2461 DOI 10.17487/RFC7217, April 2014, 2462 . 2464 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2465 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 2466 DOI 10.17487/RFC7231, June 2014, 2467 . 2469 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 2470 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 2471 December 2014, . 2473 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 2474 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 2475 Networking: Definitions and Design Goals", RFC 7575, 2476 DOI 10.17487/RFC7575, June 2015, 2477 . 2479 [Stajano99theresurrecting] 2480 Stajano, F. and R. Anderson, "The resurrecting duckling: 2481 security issues for ad-hoc wireless networks", 1999, 2482 . 2485 Appendix A. IPv4 operations 2487 A.1. IPv4 Link Local addresses 2489 Instead of an IPv6 link-local address, an IPv4 address may be 2490 generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local 2491 Addresses. 2493 In the case that an IPv4 Local-Local address is formed, then the 2494 bootstrap process would continue as in the IPv6 case by looking for a 2495 (circuit) proxy. 2497 A.2. Use of DHCPv4 2499 The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP 2500 provided parameters for the Domain Name System can be used to perform 2501 DNS operations if all local discovery attempts fail. 2503 Appendix B. mDNS / DNSSD proxy discovery options 2505 The Pledge MAY perform DNS-based Service Discovery [RFC6763] over 2506 Multicast DNS [RFC6762] searching for the service 2507 "_bootstrapks._tcp.local.". 2509 To prevent unaccceptable levels of network traffic the congestion 2510 avoidance mechanisms specified in [RFC6762] section 7 MUST be 2511 followed. The Pledge SHOULD listen for an unsolicited broadcast 2512 response as described in [RFC6762]. This allows devices to avoid 2513 announcing their presence via mDNS broadcasts and instead silently 2514 join a network by watching for periodic unsolicited broadcast 2515 responses. 2517 Performs DNS-based Service Discovery [RFC6763] over normal DNS 2518 operations. The service searched for is 2519 "_bootstrapks._tcp.example.com". In this case the domain 2520 "example.com" is discovered as described in [RFC6763] section 11. 2521 This method is only available if the host has received a useable IPv4 2522 address via DHCPv4 as suggested in Appendix A. 2524 If no local bootstrapks service is located using the GRASP 2525 mechanisms, or the above mentioned DNS-based Service Discovery 2526 methods the Pledge MAY contact a well known vendor provided 2527 bootstrapping server by performing a DNS lookup using a well known 2528 URI such as "bootstrapks.vendor-example.com". The details of the URI 2529 are vendor specific. Vendors that leverage this method on the Pledge 2530 are responsible for providing the bootstrapks service. 2532 The current DNS services returned during each query is maintained 2533 until bootstrapping is completed. If bootstrapping fails and the 2534 Pledge returns to the Discovery state it picks up where it left off 2535 and continues attempting bootstrapping. For example if the first 2536 Multicast DNS _bootstrapks._tcp.local response doesn't work then the 2537 second and third responses are tried. If these fail the Pledge moves 2538 on to normal DNS-based Service Discovery. 2540 Appendix C. IPIP Join Proxy mechanism 2542 The Circuit Proxy mechanism suffers from requiring a state on the 2543 Join Proxy for each connection that is relayed. The Circuit Proxy 2544 can be considered a kind of Algorithm Gateway [FIND-good-REF]. 2546 An alternative to proxying at the TCP layer is to selectively forward 2547 at the IP layer. This moves all per-connection to the Join 2548 Registrar. The IPIP tunnel statelessly forwards packets. This 2549 section provides some explanation of some of the details of the 2550 Registrar discovery procotol which are not important to Circuit 2551 Proxy, and some implementation advice. 2553 The IPIP tunnel is described in [RFC2473]. Each such tunnel is 2554 considered a unidirectional construct, but two tunnels may be 2555 associated to form a bidirectional mechanism. An IPIP tunnel is 2556 setup as follows. The outer addresses are an ACP address of the Join 2557 Proxy, and the ACP address of the Join Registrar. The inner 2558 addresses seen in the tunnel are the link-local addresses of the 2559 network on which the join activity is occuring. 2561 One way to look at this construct is to consider that the Registrar 2562 is extending attaching an interface to the network on which the Join 2563 Proxy is physically present. The Registrar then interacts as if it 2564 were present on that network using link-local (fe80::) addresses. 2565 The Join node is unaware that the traffic is being proxied through a 2566 tunnel, and does not need any special routing. 2568 There are a number of considerations with this mechanism which 2569 require cause some minor amounts of complexity. Note that due to the 2570 tunnels, the Registrar sees multiple connections to a fe80::/10 2571 network on not just physical interfaces, but on each of the virtual 2572 interfaces represending the tunnels. 2574 C.1. Multiple Join networks on the Join Proxy side 2576 The Join Proxy will in the general case be a routing device with 2577 multiple interfaces. Even a device as simple as a wifi access point 2578 may have wired, and multiple frequencies of wireless interfaces, 2579 potentially with multiple ESSIDs. 2581 Each of these interfaces on the Join Proxy may be seperate L3 routing 2582 domains, and therefore will have a unique set of link-local 2583 addresses. An IPIP packet being returned by the Registrar needs to 2584 be forwarded to the correct interface, so the Join Proxy needs an 2585 additional key to distinguish which network the packet should be 2586 returned to. 2588 The simplest way to get this additional key is to allocate an 2589 additional ACP address; one address for each network on which join 2590 traffic is occuring. The Join Proxy SHOULD do a GRASP M_NEG_SYN for 2591 each interface which they wish to relay traffic, as this allows the 2592 Registrar to do any static tunnel configuration that may be required. 2594 C.2. Automatic configuration of tunnels on Registrar 2596 The Join Proxy is expected to do a GRASP negotiation with the proxy 2597 for each Join Interface that it needs to relay traffic from. This is 2598 to permit Registrars to configure the appropriate virtual interfaces 2599 before join traffic arrives. 2601 A Registrar serving a large number of interfaces may not wish to 2602 allocate resources to every interface at all times, but can instead 2603 dynamically allocate interfaces. It can do this by monitoring IPIP 2604 traffic that arrives on it's ACP interface, and when packets arrive 2605 from new Join Proxys, it can dynamically configure virtual 2606 interfaces. 2608 A more sophisticated Registrar willing to modify the behaviour of 2609 it's TCP and UDP stack could note the IPIP traffic origination in the 2610 socket control block and make information available to the TCP layer 2611 (for HTTPS connections), or to the application (for CoAP connections) 2612 via a proprietary extension to the socket API. 2614 C.3. Proxy Neighbor Discovery by Join Proxy 2616 The Join Proxy MUST answer neighbor discovery messages for the 2617 address given by the Registrar as being it's link-local address. The 2618 Join Proxy must also advertise this address as the address to which 2619 to connect to when advertising it's existence. 2621 This proxy neighbor discovery means that the pledge will create TCP 2622 and UDP connections to the correct Registrar address. This matters 2623 as the TCP and UDP pseudo-header checksum includes the destination 2624 address, and for the proxy to remain completely stateless, it must 2625 not be necessary for the checksum to be updated. 2627 C.4. Use of connected sockets; or IP_PKTINFO for CoAP on Registrar 2629 TCP connections on the registrar SHOULD properly capture the ifindex 2630 of the incoming connection into the socket structure. This is normal 2631 IPv6 socket API processing. The outgoing responses will go out on 2632 the same (virtual) interface by ifindex. 2634 When using UDP sockets with CoAP, the application will have to pay 2635 attention to the incoming ifindex on the socket. Access to this 2636 information is available using the IP_PKTINFO auxiliary extension 2637 which is a standard part of the IPv6 sockets API. 2639 A registrar application could, after receipt of an initial CoAP 2640 message from the Pledge, create a connected UDP socket (including the 2641 ifindex information). The kernel would then take care of accurate 2642 demultiplexing upon receive, and subsequent transmission to the 2643 correct interface. 2645 C.5. Use of socket extension rather than virtual interface 2647 Some operating systems on which a Registrar need be implemented may 2648 find need for a virtual interface per Join Proxy to be problematic. 2649 There are other mechanism which can make be done. 2651 If the IPIP decapsulator can mark the (SYN) packet inside the kernel 2652 with the address of the Join Proxy sending the traffic, then an 2653 interface per Join Proxy may not be needed. The outgoing path need 2654 just pay attention to this extra information and add an appropriate 2655 IPIP header on outgoing. A CoAP over UDP mechanism may need to 2656 expose this extra information to the application as the UDP sockets 2657 are often not connected, and the application will need to specify the 2658 outgoing path on each packet send. 2660 Such an additional socket mechanism has not been standardized. 2661 Terminating L2TP connections over IPsec transport mode suffers from 2662 the same challenges. 2664 Appendix D. MUD Extension 2666 The following extension augments the MUD model to include a single 2667 node, as described in [I-D.ietf-opsawg-mud] section 3.6, using the 2668 following sample module that has the following tree structure: 2670 module: ietf-mud-brski-masa 2671 augment /ietf-mud:mud: 2672 +--rw masa-server? inet:uri 2674 The model is defined as follows: 2676 2677 module ietf-mud-brski-masa { 2678 yang-version 1.1; 2679 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa"; 2680 prefix ietf-mud-brski-masa; 2681 import ietf-mud { 2682 prefix ietf-mud; 2683 } 2684 import ietf-inet-types { 2685 prefix inet; 2686 } 2688 organization 2689 "IETF ANIMA (Autonomic Networking Integrated Model and 2690 Approach) Working Group"; 2691 contact 2692 "WG Web: http://tools.ietf.org/wg/anima/ 2693 WG List: anima@ietf.org 2694 "; 2695 description 2696 "BRSKI extension to a MUD file to indicate the 2697 MASA URL."; 2699 revision 2017-10-09 { 2700 description 2701 "Initial revision."; 2702 reference 2703 "RFC XXXX: Manufacturer Usage Description 2704 Specification"; 2705 } 2707 augment "/ietf-mud:mud" { 2708 description 2709 "BRSKI extension to a MUD file to indicate the 2710 MASA URL."; 2711 leaf masa-server { 2712 type inet:uri; 2713 description 2714 "This value is the URI of the MASA server"; 2715 } 2716 } 2717 } 2718 2720 Appendix E. Example Vouchers 2722 Three entities are involved in a voucher: the MASA issues (signs) it, 2723 the registrar's public key is mentioned in the voucher, and the 2724 pledge validates it. In order to provide reproduceable examples the 2725 public and private keys for an example MASA and Registrar are first 2726 listed. 2728 E.1. Keys involved 2730 The Manufacturer has a Certificate Authority that signs the Pledge's 2731 IDevID. In addition the Manufacturer's signing authority (the MASA) 2732 signs the vouchers, and that certificate must distributed to the 2733 devices at manufacturing time so that vouchers can be validated. 2735 E.1.1. MASA key pair for voucher signatures 2737 This private key signs vouchers: 2739 -----BEGIN EC PRIVATE KEY----- 2740 MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho 2741 r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA 2742 zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz 2743 Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= 2744 -----END EC PRIVATE KEY----- 2746 This public key validates vouchers: 2748 -----BEGIN CERTIFICATE----- 2749 MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 2750 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 2751 IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw 2752 EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU 2753 BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R 2754 b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf 2755 w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO 2756 MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O 2757 DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd 2758 MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= 2759 -----END CERTIFICATE----- 2761 E.1.2. Manufacturer key pair for IDevID signatures 2763 This private key signs IDevID certificates: 2765 -----BEGIN EC PRIVATE KEY----- 2766 MIGkAgEBBDAgiRoYqKoEcfOfvRvmZ5P5Azn58tuI7nSnIy7OgFnCeiNo+BmbgMho 2767 r6lcU60gwVagBwYFK4EEACKhZANiAATZAH3Rb2FvIJOnts+vXuWW35ofyNbCHzjA 2768 zOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCfw5ICgJ8CuM3vV5ty9bf7KUlOkejz 2769 Tvv+5PV++elkP9HQ83vqTAws2WwWTxI= 2770 -----END EC PRIVATE KEY----- 2772 This public key validates IDevID certificates: 2774 -----BEGIN CERTIFICATE----- 2775 MIIBzzCCAVagAwIBAgIBATAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 2776 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 2777 IEhpZ2h3YXkgQ0EwHhcNMTcwMzI2MTYxOTQwWhcNMTkwMzI2MTYxOTQwWjBHMRIw 2778 EAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xFjAU 2779 BgNVBAMMDVVuc3RydW5nIE1BU0EwdjAQBgcqhkjOPQIBBgUrgQQAIgNiAATZAH3R 2780 b2FvIJOnts+vXuWW35ofyNbCHzjAzOi2kWZFE1ByurKImNcNMFGirGnRXIXGqWCf 2781 w5ICgJ8CuM3vV5ty9bf7KUlOkejzTvv+5PV++elkP9HQ83vqTAws2WwWTxKjEDAO 2782 MAwGA1UdEwEB/wQCMAAwCgYIKoZIzj0EAwIDZwAwZAIwGb0oyM0doP6t3/LSPL5O 2783 DuatEwMYh7WGO+IYTHC8K7EyHBOmCYReKT2+GhV/CLWzAjBNy6UMJTt1tsxJsJqd 2784 MPUIFj+4wZg1AOIb/JoA6M7r33pwLQTrHRxEzVMGfWOkYUw= 2785 -----END CERTIFICATE----- 2787 E.1.3. Registrar key pair 2789 The registrar key (or chain) is the representative of the domain 2790 owner. This key signs Registrar voucher-requests: 2792 -----BEGIN EC PRIVATE KEY----- 2793 MHcCAQEEIF+obiToYYYeMifPsZvrjWJ0yFsCJwIFhpokmT/TULmXoAoGCCqGSM49 2794 AwEHoUQDQgAENWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g 2795 6W/P6boTmyTGdFOh/8HwKUerL5bpneK8sg== 2796 -----END EC PRIVATE KEY----- 2798 The public key is indicated in a pledge voucher-request to show 2799 proximity. 2801 -----BEGIN CERTIFICATE----- 2802 MIIBrjCCATOgAwIBAgIBAzAKBggqhkjOPQQDAzBOMRIwEAYKCZImiZPyLGQBGRYC 2803 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMMFFVuc3RydW5n 2804 IEZvdW50YWluIENBMB4XDTE3MDkwNTAxMTI0NVoXDTE5MDkwNTAxMTI0NVowQzES 2805 MBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRIw 2806 EAYDVQQDDAlsb2NhbGhvc3QwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAAQ1ZA7N 2807 w0xSM/Q2u194FzQMktZ94waAIV0i/oVTPgOJ8zW6MwF5z+Dpb8/puhObJMZ0U6H/ 2808 wfApR6svlumd4ryyow0wCzAJBgNVHRMEAjAAMAoGCCqGSM49BAMDA2kAMGYCMQC3 2809 /iTQJ3evYYcgbXhbmzrp64t3QC6qjIeY2jkDx062nuNifVKtyaara3F30AIkKSEC 2810 MQDi29efbTLbdtDk3tecY/rD7V77XaJ6nYCmdDCR54TrSFNLgxvt1lyFM+0fYpYR 2811 c3o= 2812 -----END CERTIFICATE----- 2813 The registrar public certificate as decoded by openssl's x509 2814 utility. Note that the registrar certificate is marked with the 2815 cmcRA extension. 2817 Certificate: 2818 Data: 2819 Version: 3 (0x2) 2820 Serial Number: 3 (0x3) 2821 Signature Algorithm: ecdsa-with-SHA384 2822 Issuer: DC=ca, DC=sandelman, CN=Unstrung Fountain CA 2823 Validity 2824 Not Before: Sep 5 01:12:45 2017 GMT 2825 Not After : Sep 5 01:12:45 2019 GMT 2826 Subject: DC=ca, DC=sandelman, CN=localhost 2827 Subject Public Key Info: 2828 Public Key Algorithm: id-ecPublicKey 2829 EC Public Key: 2830 pub: 2831 04:35:64:0e:cd:c3:4c:52:33:f4:36:bb:5f:7 2832 8:17: 2833 34:0c:92:d6:7d:e3:06:80:21:5d:22:fe:85:5 2834 3:3e: 2835 03:89:f3:35:ba:33:01:79:cf:e0:e9:6f:cf:e 2836 9:ba: 2837 13:9b:24:c6:74:53:a1:ff:c1:f0:29:47:ab:2 2838 f:96: 2839 e9:9d:e2:bc:b2 2840 ASN1 OID: prime256v1 2841 X509v3 extensions: 2842 X509v3 Basic Constraints: 2843 CA:FALSE 2844 Signature Algorithm: ecdsa-with-SHA384 2845 30:66:02:31:00:b7:fe:24:d0:27:77:af:61:87:20:6d:78:5 2846 b: 2847 9b:3a:e9:eb:8b:77:40:2e:aa:8c:87:98:da:39:03:c7:4e:b 2848 6: 2849 9e:e3:62:7d:52:ad:c9:a6:ab:6b:71:77:d0:02:24:29:21:0 2850 2: 2851 31:00:e2:db:d7:9f:6d:32:db:76:d0:e4:de:d7:9c:63:fa:c 2852 3: 2853 ed:5e:fb:5d:a2:7a:9d:80:a6:74:30:91:e7:84:eb:48:53:4 2854 b: 2855 83:1b:ed:d6:5c:85:33:ed:1f:62:96:11:73:7a 2857 E.1.4. Pledge key pair 2859 The pledge has an IDevID key pair built in at manufacturing time: 2861 -----BEGIN EC PRIVATE KEY----- 2862 MHcCAQEEIL+ue8PQcN+M7LFBGPsompYwobI/rsoHnTb2a+0hO+8joAoGCCqGSM49 2863 AwEHoUQDQgAEumBVaDlX87WyME8CJToyt9NWy6sYw0DTbjjJIn79pgr7ALa//Y8p 2864 r70WpK1SIaiUeeFw7e+lCzTp1Z+wJu14Bg== 2865 -----END EC PRIVATE KEY----- 2867 The public key is used by the registrar to find the MASA. The MASA 2868 URL is in an extension described in Section 2.3. RFC-EDITOR: Note 2869 that these certificates are using a Private Enterprise Number for the 2870 not-yet-assigned by IANA MASA URL, and need to be replaced before 2871 AUTH48. 2873 -----BEGIN CERTIFICATE----- 2874 MIICMjCCAbegAwIBAgIBDDAKBggqhkjOPQQDAjBNMRIwEAYKCZImiZPyLGQBGRYC 2875 Y2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5n 2876 IEhpZ2h3YXkgQ0EwIBcNMTcxMDEyMTM1MjUyWhgPMjk5OTEyMzEwMDAwMDBaMEsx 2877 EjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjEa 2878 MBgGA1UEAwwRMDAtRDAtRTUtRjItMDAtMDIwWTATBgcqhkjOPQIBBggqhkjOPQMB 2879 BwNCAARJp5i0dU1aUnR2u8wMRwgkNupNbNM7m1n0mj+0KJZjcPIqID+trPjTSobt 2880 uIdpRPfGZ8hU/nIUveqwyoYI8BPbo4GHMIGEMB0GA1UdDgQWBBQdMRZhthFQmzz6 2881 E7YVXzkL7XZDKjAJBgNVHRMEAjAAMCsGA1UdEQQkMCKgIAYJKwYBBAGC7lIBoBMM 2882 ETAwLUQwLUU1LUYyLTAwLTAyMCsGCSsGAQQBgu5SAgQeDBxodHRwczovL2hpZ2h3 2883 YXkuc2FuZGVsbWFuLmNhMAoGCCqGSM49BAMCA2kAMGYCMQDhJ1N+eanW1U/e5qoM 2884 SGvUvWHR7uic8cJbh7vXy580nBs8bpNn60k/+IzvEUetMzICMQCr1uxvdYeKq7mb 2885 RXCR4ZCJsw67fJ7jyXZbCUSir+3wBT2+lWggzPDRgYB5ABb7sAw= 2886 -----END CERTIFICATE----- 2888 The pledge public certificate as decoded by openssl's x509 utility so 2889 that the extensions can be seen. A second custom Extension is 2890 included to provided to contain the EUI48/EUI64 that the pledge will 2891 configure. 2893 Certificate: 2894 Data: 2895 Version: 3 (0x2) 2896 Serial Number: 12 (0xc) 2897 Signature Algorithm: ecdsa-with-SHA256 2898 Issuer: DC=ca, DC=sandelman, CN=Unstrung Highway CA 2899 Validity 2900 Not Before: Oct 12 13:52:52 2017 GMT 2901 Not After : Dec 31 00:00:00 2999 GMT 2902 Subject: DC=ca, DC=sandelman, CN=00-D0-E5-F2-00-02 2903 Subject Public Key Info: 2904 Public Key Algorithm: id-ecPublicKey 2905 EC Public Key: 2906 pub: 2907 04:49:a7:98:b4:75:4d:5a:52:74:76:bb:cc:0 2908 c:47: 2909 08:24:36:ea:4d:6c:d3:3b:9b:59:f4:9a:3f:b 2910 4:28: 2911 96:63:70:f2:2a:20:3f:ad:ac:f8:d3:4a:86:e 2912 d:b8: 2913 87:69:44:f7:c6:67:c8:54:fe:72:14:bd:ea:b 2914 0:ca: 2915 86:08:f0:13:db 2916 ASN1 OID: prime256v1 2917 X509v3 extensions: 2918 X509v3 Subject Key Identifier: 2919 1D:31:16:61:B6:11:50:9B:3C:FA:13:B6:15:5F:39 2920 :0B:ED:76:43:2A 2921 X509v3 Basic Constraints: 2922 CA:FALSE 2923 X509v3 Subject Alternative Name: 2924 othername: 2925 1.3.6.1.4.1.46930.2: 2926 ..https://highway.sandelman.ca 2927 Signature Algorithm: ecdsa-with-SHA256 2928 30:66:02:31:00:e1:27:53:7e:79:a9:d6:d5:4f:de:e6:aa:0 2929 c: 2930 48:6b:d4:bd:61:d1:ee:e8:9c:f1:c2:5b:87:bb:d7:cb:9f:3 2931 4: 2932 9c:1b:3c:6e:93:67:eb:49:3f:f8:8c:ef:11:47:ad:33:32:0 2933 2: 2934 31:00:ab:d6:ec:6f:75:87:8a:ab:b9:9b:45:70:91:e1:90:8 2935 9: 2936 b3:0e:bb:7c:9e:e3:c9:76:5b:09:44:a2:af:ed:f0:05:3d:b 2937 e: 2938 95:68:20:cc:f0:d1:81:80:79:00:16:fb:b0:0c 2940 E.2. Example process 2942 RFC-EDITOR: these examples will need to be replaced with CMS versions 2943 once IANA has assigned the eContentType in [I-D.ietf-anima-voucher]. 2945 E.2.1. Pledge to Registrar 2947 As described in Section 5.2, the pledge will sign a pledge voucher- 2948 request containing the Registrar's public key in the proximity- 2949 registrar-cert field. The base64 has been wrapped at 60 characters 2950 for presentation reasons. 2952 MIIHHAYJKoZIhvcNAQcCoIIHDTCCBwkCAQExDzANBglghkgBZQMEAgEFADCC 2953 Aw4GCSqGSIb3DQEHAaCCAv8EggL7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2 2954 b3VjaGVyIjp7ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24i 2955 OiIyMDE3LTA5LTAxIiwic2VyaWFsLW51bWJlciI6IjAwLUQwLUU1LUYyLTAw 2956 LTAyIiwibm9uY2UiOiJEc3M5OXNCcjNwTk1PQUNlLUxZWTd3IiwicHJveGlt 2957 aXR5LXJlZ2lzdHJhci1jZXJ0IjoiTUlJQnJqQ0NBVE9nQXdJQkFnSUJBekFL 2958 QmdncWhrak9QUVFEQXpCT01SSXdFQVlLQ1pJbWlaUHlMR1FCR1JZQ1kyRXhH 2959 VEFYQmdvSmtpYUprL0lzWkFFWkZnbHpZVzVrWld4dFlXNHhIVEFiQmdOVkJB 2960 TU1GRlZ1YzNSeWRXNW5JRVp2ZFc1MFlXbHVJRU5CTUI0WERURTNNRGt3TlRB 2961 eE1USTBOVm9YRFRFNU1Ea3dOVEF4TVRJME5Wb3dRekVTTUJBR0NnbVNKb21U 2962 OGl4a0FSa1dBbU5oTVJrd0Z3WUtDWkltaVpQeUxHUUJHUllKYzJGdVpHVnNi 2963 V0Z1TVJJd0VBWURWUVFEREFsc2IyTmhiR2h2YzNRd1dUQVRCZ2NxaGtqT1BR 2964 SUJCZ2dxaGtqT1BRTUJCd05DQUFRMVpBN053MHhTTS9RMnUxOTRGelFNa3Ra 2965 OTR3YUFJVjBpL29WVFBnT0o4elc2TXdGNXorRHBiOC9wdWhPYkpNWjBVNkgv 2966 d2ZBcFI2c3ZsdW1kNHJ5eW93MHdDekFKQmdOVkhSTUVBakFBTUFvR0NDcUdT 2967 TTQ5QkFNREEya0FNR1lDTVFDMy9pVFFKM2V2WVljZ2JYaGJtenJwNjR0M1FD 2968 NnFqSWVZMmprRHgwNjJudU5pZlZLdHlhYXJhM0YzMEFJa0tTRUNNUURpMjll 2969 ZmJUTGJkdERrM3RlY1kvckQ3Vjc3WGFKNm5ZQ21kRENSNTRUclNGTkxneHZ0 2970 MWx5Rk0rMGZZcFlSYzNvPSJ9faCCAjYwggIyMIIBt6ADAgECAgEMMAoGCCqG 2971 SM49BAMCME0xEjAQBgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkW 2972 CXNhbmRlbG1hbjEcMBoGA1UEAwwTVW5zdHJ1bmcgSGlnaHdheSBDQTAgFw0x 2973 NzEwMTIxMzUyNTJaGA8yOTk5MTIzMTAwMDAwMFowSzESMBAGCgmSJomT8ixk 2974 ARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRowGAYDVQQDDBEw 2975 MC1EMC1FNS1GMi0wMC0wMjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEmn 2976 mLR1TVpSdHa7zAxHCCQ26k1s0zubWfSaP7QolmNw8iogP62s+NNKhu24h2lE 2977 98ZnyFT+chS96rDKhgjwE9ujgYcwgYQwHQYDVR0OBBYEFB0xFmG2EVCbPPoT 2978 thVfOQvtdkMqMAkGA1UdEwQCMAAwKwYDVR0RBCQwIqAgBgkrBgEEAYLuUgGg 2979 EwwRMDAtRDAtRTUtRjItMDAtMDIwKwYJKwYBBAGC7lICBB4MHGh0dHBzOi8v 2980 aGlnaHdheS5zYW5kZWxtYW4uY2EwCgYIKoZIzj0EAwIDaQAwZgIxAOEnU355 2981 qdbVT97mqgxIa9S9YdHu6JzxwluHu9fLnzScGzxuk2frST/4jO8RR60zMgIx 2982 AKvW7G91h4qruZtFcJHhkImzDrt8nuPJdlsJRKKv7fAFPb6VaCDM8NGBgHkA 2983 FvuwDDGCAaUwggGhAgEBMFIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK 2984 CZImiZPyLGQBGRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdo 2985 d2F5IENBAgEMMA0GCWCGSAFlAwQCAQUAoIHkMBgGCSqGSIb3DQEJAzELBgkq 2986 hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MTAxMjE3NTQzMFowLwYJKoZI 2987 hvcNAQkEMSIEIP59cuKVAPkKOOlQIaIV/W1AsWKbmVmBd9wFSuD5yLafMHkG 2988 CSqGSIb3DQEJDzFsMGowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglg 2989 hkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 2990 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAoGCCqGSM49BAMCBEYw 2991 RAIgYUy0NTdP+xTkm/Et69eI++S/2z3dQwPKOwdL0cDCSvACIAh3jJbybMnK 2992 cf7DKKnsn2G/O06HeB/8imMI+hnA7CfN 2994 file: examples/vr_00-D0-E5-F2-00-02.pkcs 2996 The ASN1 decoding of the artifact: 2998 The JSON contained in the voucher request: 3000 E.2.2. Registrar to MASA 3002 As described in Section 5.4 the Registrar will sign a registrar 3003 voucher-request, and will include pledge's voucher request in the 3004 prior-signed-voucher-request. 3006 MIIN2gYJKoZIhvcNAQcCoIINyzCCDccCAQExDzANBglghkgBZQMEAgEFADCC 3007 Ck4GCSqGSIb3DQEHAaCCCj8Eggo7eyJpZXRmLXZvdWNoZXItcmVxdWVzdDp2 3008 b3VjaGVyIjp7ImFzc2VydGlvbiI6InByb3hpbWl0eSIsImNyZWF0ZWQtb24i 3009 OiIyMDE3LTA5LTE1VDAwOjAwOjAwLjAwMFoiLCJzZXJpYWwtbnVtYmVyIjoi 3010 SkFEQTEyMzQ1Njc4OSIsIm5vbmNlIjoiYWJjZDEyMzQiLCJwcmlvci1zaWdu 3011 ZWQtdm91Y2hlci1yZXF1ZXN0IjoiTUlJSEhRWUpLb1pJaHZjTkFRY0NvSUlI 3012 RGpDQ0J3b0NBUUV4RHpBTkJnbGdoa2dCWlFNRUFnRUZBRENDQXc0R0NTcUdT 3013 SWIzRFFFSEFhQ0NBdjhFZ2dMN2V5SnBaWFJtTFhadmRXTm9aWEl0Y21WeGRX 3014 VnpkRHAyYjNWamFHVnlJanA3SW1GemMyVnlkR2x2YmlJNkluQnliM2hwYlds 3015 MGVTSXNJbU55WldGMFpXUXRiMjRpT2lJeU1ERTNMVEE1TFRBeElpd2ljMlZ5 3016 YVdGc0xXNTFiV0psY2lJNklqQXdMVVF3TFVVMUxVWXlMVEF3TFRBeUlpd2li 3017 bTl1WTJVaU9pSkVjM001T1hOQ2NqTndUazFQUVVObExVeFpXVGQzSWl3aWNI 3018 SnZlR2x0YVhSNUxYSmxaMmx6ZEhKaGNpMWpaWEowSWpvaVRVbEpRbkpxUTBO 3019 QlZFOW5RWGRKUWtGblNVSkJla0ZMUW1kbmNXaHJhazlRVVZGRVFYcENUMDFT 3020 U1hkRlFWbExRMXBKYldsYVVIbE1SMUZDUjFKWlExa3lSWGhIVkVGWVFtZHZT 3021 bXRwWVVwckwwbHpXa0ZGV2tabmJIcFpWelZyV2xkNGRGbFhOSGhJVkVGaVFt 3022 ZE9Wa0pCVFUxR1JsWjFZek5TZVdSWE5XNUpSVnAyWkZjMU1GbFhiSFZKUlU1 3023 Q1RVSTBXRVJVUlROTlJHdDNUbFJCZUUxVVNUQk9WbTlZUkZSRk5VMUVhM2RP 3024 VkVGNFRWUkpNRTVXYjNkUmVrVlRUVUpCUjBObmJWTktiMjFVT0dsNGEwRlNh 3025 MWRCYlU1b1RWSnJkMFozV1V0RFdrbHRhVnBRZVV4SFVVSkhVbGxLWXpKR2RW 3026 cEhWbk5pVjBaMVRWSkpkMFZCV1VSV1VWRkVSRUZzYzJJeVRtaGlSMmgyWXpO 3027 UmQxZFVRVlJDWjJOeGFHdHFUMUJSU1VKQ1oyZHhhR3RxVDFCUlRVSkNkMDVE 3028 UVVGUk1WcEJOMDUzTUhoVFRTOVJNblV4T1RSR2VsRk5hM1JhT1RSM1lVRkpW 3029 akJwTDI5V1ZGQm5UMG80ZWxjMlRYZEdOWG9yUkhCaU9DOXdkV2hQWWtwTldq 3030 QlZOa2d2ZDJaQmNGSTJjM1pzZFcxa05ISjVlVzkzTUhkRGVrRktRbWRPVmto 3031 U1RVVkJha0ZCVFVGdlIwTkRjVWRUVFRRNVFrRk5SRUV5YTBGTlIxbERUVkZE 3032 TXk5cFZGRktNMlYyV1ZsaloySllhR0p0ZW5Kd05qUjBNMUZETm5GcVNXVlpN 3033 bXByUkhnd05qSnVkVTVwWmxaTGRIbGhZWEpoTTBZek1FRkphMHRUUlVOTlVV 3034 UnBNamxsWm1KVVRHSmtkRVJyTTNSbFkxa3Zja1EzVmpjM1dHRktObTVaUTIx 3035 a1JFTlNOVFJVY2xOR1RreG5lSFowTVd4NVJrMHJNR1paY0ZsU1l6TnZQU0o5 3036 ZmFDQ0FqWXdnZ0l5TUlJQnQ2QURBZ0VDQWdFTU1Bb0dDQ3FHU000OUJBTUNN 3037 RTB4RWpBUUJnb0praWFKay9Jc1pBRVpGZ0pqWVRFWk1CY0dDZ21TSm9tVDhp 3038 eGtBUmtXQ1hOaGJtUmxiRzFoYmpFY01Cb0dBMVVFQXd3VFZXNXpkSEoxYm1j 3039 Z1NHbG5hSGRoZVNCRFFUQWdGdzB4TnpFd01USXhNelV5TlRKYUdBOHlPVGs1 3040 TVRJek1UQXdNREF3TUZvd1N6RVNNQkFHQ2dtU0pvbVQ4aXhrQVJrV0FtTmhN 3041 Umt3RndZS0NaSW1pWlB5TEdRQkdSWUpjMkZ1WkdWc2JXRnVNUm93R0FZRFZR 3042 UUREQkV3TUMxRU1DMUZOUzFHTWkwd01DMHdNakJaTUJNR0J5cUdTTTQ5QWdF 3043 R0NDcUdTTTQ5QXdFSEEwSUFCRW1ubUxSMVRWcFNkSGE3ekF4SENDUTI2azFz 3044 MHp1YldmU2FQN1FvbG1Odzhpb2dQNjJzK05OS2h1MjRoMmxFOThabnlGVCtj 3045 aFM5NnJES2hnandFOXVqZ1ljd2dZUXdIUVlEVlIwT0JCWUVGQjB4Rm1HMkVW 3046 Q2JQUG9UdGhWZk9RdnRka01xTUFrR0ExVWRFd1FDTUFBd0t3WURWUjBSQkNR 3047 d0lxQWdCZ2tyQmdFRUFZTHVVZ0dnRXd3Uk1EQXRSREF0UlRVdFJqSXRNREF0 3048 TURJd0t3WUpLd1lCQkFHQzdsSUNCQjRNSEdoMGRIQnpPaTh2YUdsbmFIZGhl 3049 UzV6WVc1a1pXeHRZVzR1WTJFd0NnWUlLb1pJemowRUF3SURhUUF3WmdJeEFP 3050 RW5VMzU1cWRiVlQ5N21xZ3hJYTlTOVlkSHU2Snp4d2x1SHU5ZkxuelNjR3p4 3051 dWsyZnJTVC80ak84UlI2MHpNZ0l4QUt2VzdHOTFoNHFydVp0RmNKSGhrSW16 3052 RHJ0OG51UEpkbHNKUktLdjdmQUZQYjZWYUNETThOR0JnSGtBRnZ1d0RER0NB 3053 YVl3Z2dHaUFnRUJNRkl3VFRFU01CQUdDZ21TSm9tVDhpeGtBUmtXQW1OaE1S 3054 a3dGd1lLQ1pJbWlaUHlMR1FCR1JZSmMyRnVaR1ZzYldGdU1Sd3dHZ1lEVlFR 3055 RERCTlZibk4wY25WdVp5QklhV2RvZDJGNUlFTkJBZ0VNTUEwR0NXQ0dTQUZs 3056 QXdRQ0FRVUFvSUhrTUJnR0NTcUdTSWIzRFFFSkF6RUxCZ2txaGtpRzl3MEJC 3057 d0V3SEFZSktvWklodmNOQVFrRk1ROFhEVEUzTVRBeE1qRXpOVGd5TTFvd0x3 3058 WUpLb1pJaHZjTkFRa0VNU0lFSVA1OWN1S1ZBUGtLT09sUUlhSVYvVzFBc1dL 3059 Ym1WbUJkOXdGU3VENXlMYWZNSGtHQ1NxR1NJYjNEUUVKRHpGc01Hb3dDd1lK 3060 WUlaSUFXVURCQUVxTUFzR0NXQ0dTQUZsQXdRQkZqQUxCZ2xnaGtnQlpRTUVB 3061 UUl3Q2dZSUtvWklodmNOQXdjd0RnWUlLb1pJaHZjTkF3SUNBZ0NBTUEwR0ND 3062 cUdTSWIzRFFNQ0FnRkFNQWNHQlNzT0F3SUhNQTBHQ0NxR1NJYjNEUU1DQWdF 3063 b01Bb0dDQ3FHU000OUJBTUNCRWN3UlFJZ0VNZzFkSkw3RmNkdHJWRHg4cUNh 3064 em9lOSsyMk56NFp3UkI5Z0FUR0w3TU1DSVFEanNzVWxaekpxcDIva0NkNFdo 3065 eFVoc2FDcFRGd1Bybk5ldzV3Q2tZVUY4UT09In19oIIBsjCCAa4wggEzoAMC 3066 AQICAQMwCgYIKoZIzj0EAwMwTjESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYK 3067 CZImiZPyLGQBGRYJc2FuZGVsbWFuMR0wGwYDVQQDDBRVbnN0cnVuZyBGb3Vu 3068 dGFpbiBDQTAeFw0xNzA5MDUwMTEyNDVaFw0xOTA5MDUwMTEyNDVaMEMxEjAQ 3069 BgoJkiaJk/IsZAEZFgJjYTEZMBcGCgmSJomT8ixkARkWCXNhbmRlbG1hbjES 3070 MBAGA1UEAwwJbG9jYWxob3N0MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE 3071 NWQOzcNMUjP0NrtfeBc0DJLWfeMGgCFdIv6FUz4DifM1ujMBec/g6W/P6boT 3072 myTGdFOh/8HwKUerL5bpneK8sqMNMAswCQYDVR0TBAIwADAKBggqhkjOPQQD 3073 AwNpADBmAjEAt/4k0Cd3r2GHIG14W5s66euLd0AuqoyHmNo5A8dOtp7jYn1S 3074 rcmmq2txd9ACJCkhAjEA4tvXn20y23bQ5N7XnGP6w+1e+12iep2ApnQwkeeE 3075 60hTS4Mb7dZchTPtH2KWEXN6MYIBpzCCAaMCAQEwUzBOMRIwEAYKCZImiZPy 3076 LGQBGRYCY2ExGTAXBgoJkiaJk/IsZAEZFglzYW5kZWxtYW4xHTAbBgNVBAMM 3077 FFVuc3RydW5nIEZvdW50YWluIENBAgEDMA0GCWCGSAFlAwQCAQUAoIHkMBgG 3078 CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MTAy 3079 NjAxMzYxOFowLwYJKoZIhvcNAQkEMSIEIEQBM73PZzPo7tE9Mj8gQvaaYeMQ 3080 OsxlACaW/HenAqNwMHkGCSqGSIb3DQEJDzFsMGowCwYJYIZIAWUDBAEqMAsG 3081 CWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN 3082 AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo 3083 MAoGCCqGSM49BAMCBEcwRQIgDdp5uPUlMKp7GFQAD7ypAgqFv8q+KkJt6c3O 3084 7iVpVI8CIQCD1u8BkxipvigwvIDmWfjlYdJxcvozNjffq5j3UHg7Rg== 3086 file: examples/parboiled_vr_00-D0-E5-F2-00-02.pkcs 3088 The ASN1 decoding of the artifact: 3090 E.2.3. MASA to Registrar 3092 The MASA will return a voucher to the Registrar, to be relayed to the 3093 pledge. 3095 MIIG3AYJKoZIhvcNAQcCoIIGzTCCBskCAQExDzANBglghkgBZQMEAgEFADCC 3096 AxAGCSqGSIb3DQEHAaCCAwEEggL9eyJpZXRmLXZvdWNoZXI6dm91Y2hlciI6 3097 eyJhc3NlcnRpb24iOiJsb2dnZWQiLCJjcmVhdGVkLW9uIjoiMjAxNy0xMC0x 3098 MlQxMzo1NDozMS40MzktMDQ6MDAiLCJzZXJpYWwtbnVtYmVyIjoiMDAtRDAt 3099 RTUtRjItMDAtMDIiLCJub25jZSI6IkRzczk5c0JyM3BOTU9BQ2UtTFlZN3ci 3100 LCJwaW5uZWQtZG9tYWluLWNlcnQiOiJNSUlCcmpDQ0FUT2dBd0lCQWdJQkF6 3101 QUtCZ2dxaGtqT1BRUURBekJPTVJJd0VBWUtDWkltaVpQeUxHUUJHUllDWTJF 3102 eEdUQVhCZ29Ka2lhSmsvSXNaQUVaRmdsellXNWtaV3h0WVc0eEhUQWJCZ05W 3103 QkFNTUZGVnVjM1J5ZFc1bklFWnZkVzUwWVdsdUlFTkJNQjRYRFRFM01Ea3dO 3104 VEF4TVRJME5Wb1hEVEU1TURrd05UQXhNVEkwTlZvd1F6RVNNQkFHQ2dtU0pv 3105 bVQ4aXhrQVJrV0FtTmhNUmt3RndZS0NaSW1pWlB5TEdRQkdSWUpjMkZ1WkdW 3106 c2JXRnVNUkl3RUFZRFZRUUREQWxzYjJOaGJHaHZjM1F3V1RBVEJnY3Foa2pP 3107 UFFJQkJnZ3Foa2pPUFFNQkJ3TkNBQVExWkE3TncweFNNL1EydTE5NEZ6UU1r 3108 dFo5NHdhQUlWMGkvb1ZUUGdPSjh6VzZNd0Y1eitEcGI4L3B1aE9iSk1aMFU2 3109 SC93ZkFwUjZzdmx1bWQ0cnl5b3cwd0N6QUpCZ05WSFJNRUFqQUFNQW9HQ0Nx 3110 R1NNNDlCQU1EQTJrQU1HWUNNUUMzL2lUUUozZXZZWWNnYlhoYm16cnA2NHQz 3111 UUM2cWpJZVkyamtEeDA2Mm51TmlmVkt0eWFhcmEzRjMwQUlrS1NFQ01RRGky 3112 OWVmYlRMYmR0RGszdGVjWS9yRDdWNzdYYUo2bllDbWREQ1I1NFRyU0ZOTGd4 3113 dnQxbHlGTSswZllwWVJjM289In19oIIB0zCCAc8wggFWoAMCAQICAQEwCgYI 3114 KoZIzj0EAwIwTTESMBAGCgmSJomT8ixkARkWAmNhMRkwFwYKCZImiZPyLGQB 3115 GRYJc2FuZGVsbWFuMRwwGgYDVQQDDBNVbnN0cnVuZyBIaWdod2F5IENBMB4X 3116 DTE3MDMyNjE2MTk0MFoXDTE5MDMyNjE2MTk0MFowRzESMBAGCgmSJomT8ixk 3117 ARkWAmNhMRkwFwYKCZImiZPyLGQBGRYJc2FuZGVsbWFuMRYwFAYDVQQDDA1V 3118 bnN0cnVuZyBNQVNBMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAE2QB90W9hbyCT 3119 p7bPr17llt+aH8jWwh84wMzotpFmRRNQcrqyiJjXDTBRoqxp0VyFxqlgn8OS 3120 AoCfArjN71ebcvW3+ylJTpHo8077/uT1fvnpZD/R0PN76kwMLNlsFk8SoxAw 3121 DjAMBgNVHRMBAf8EAjAAMAoGCCqGSM49BAMCA2cAMGQCMBm9KMjNHaD+rd/y 3122 0jy+Tg7mrRMDGIe1hjviGExwvCuxMhwTpgmEXik9vhoVfwi1swIwTculDCU7 3123 dbbMSbCanTD1CBY/uMGYNQDiG/yaAOjO6996cC0E6x0cRM1TBn1jpGFMMYIB 3124 xjCCAcICAQEwUjBNMRIwEAYKCZImiZPyLGQBGRYCY2ExGTAXBgoJkiaJk/Is 3125 ZAEZFglzYW5kZWxtYW4xHDAaBgNVBAMME1Vuc3RydW5nIEhpZ2h3YXkgQ0EC 3126 AQEwDQYJYIZIAWUDBAIBBQCggeQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH 3127 ATAcBgkqhkiG9w0BCQUxDxcNMTcxMDEyMTc1NDMxWjAvBgkqhkiG9w0BCQQx 3128 IgQgQXnG628cIW8MoYfB1ljDDlLlJQlxED2tnjcvkLEfix0weQYJKoZIhvcN 3129 AQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQB 3130 AjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw 3131 BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwCgYIKoZIzj0EAwIEZzBlAjEAhzid 3132 /AkNjttpSP1rflNppdHsi324Z2+TXJxueewnJ8z/2NXb+Tf3DsThv7du00Oz 3133 AjBjyOnmkkSKHsPR2JluA5c6wovuPEnNKP32daGGeFKGEHMkTInbrqipC881 3134 /5K9Q+k= 3136 file: examples/voucher_00-D0-E5-F2-00-02.pkcs 3138 The ASN1 decoding of the artifact: 3140 Authors' Addresses 3142 Max Pritikin 3143 Cisco 3145 Email: pritikin@cisco.com 3147 Michael C. Richardson 3148 Sandelman Software Works 3150 Email: mcr+ietf@sandelman.ca 3151 URI: http://www.sandelman.ca/ 3153 Michael H. Behringer 3154 Cisco 3156 Email: mbehring@cisco.com 3158 Steinthor Bjarnason 3159 Arbor Networks 3161 Email: sbjarnason@arbor.net 3163 Kent Watsen 3164 Juniper Networks 3166 Email: kwatsen@juniper.net