idnits 2.17.1 draft-ietf-anima-bootstrapping-keyinfra-07.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 (July 3, 2017) is 2489 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 502, but not defined == Missing Reference: 'RFC2616' is mentioned on line 1070, 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 2599, but not defined == Missing Reference: 'RFC2131' is mentioned on line 1808, but not defined == Missing Reference: 'FIND-good-REF' is mentioned on line 1854, but not defined == Unused Reference: 'RFC5652' is defined on line 1705, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-zerotouch' is defined on line 1748, but no explicit reference was found in the text == Unused Reference: 'I-D.lear-mud-framework' is defined on line 1754, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-06 == Outdated reference: A later version (-07) exists of draft-ietf-anima-voucher-04 == Outdated reference: A later version (-04) exists of draft-vanderstok-ace-coap-est-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'IDevID' ** Downref: Normative reference to an Informational RFC: RFC 3542 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 7228 == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-13 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-14 == Outdated reference: A later version (-03) exists of draft-richardson-anima-state-for-joinrouter-01 Summary: 4 errors (**), 0 flaws (~~), 15 warnings (==), 3 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: January 4, 2018 SSW 6 M. Behringer 7 S. Bjarnason 8 Cisco 9 K. Watsen 10 Juniper Networks 11 July 3, 2017 13 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 14 draft-ietf-anima-bootstrapping-keyinfra-07 16 Abstract 18 This document specifies automated bootstrapping of a remote secure 19 key infrastructure (BRSKI) using vendor installed X.509 certificate, 20 in combination with a vendor's authorizing service, both online and 21 offline. Bootstrapping a new device can occur using a routable 22 address and a cloud service, or using only link-local connectivity, 23 or on limited/disconnected networks. Support for lower security 24 models, including devices with minimal identity, is described for 25 legacy reasons but not encouraged. Bootstrapping is complete when 26 the cryptographic identity of the new key infrastructure is 27 successfully deployed to the device but the established secure 28 connection can be used to deploy a locally issued certificate to the 29 device as well. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 4, 2018. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Other Bootstrapping Approaches . . . . . . . . . . . . . 4 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 7 69 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 9 70 2.1. Secure Imprinting using Vouchers . . . . . . . . . . . . 10 71 2.2. Initial Device Identifier . . . . . . . . . . . . . . . . 10 72 2.3. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 12 73 2.4. Lack of realtime clock . . . . . . . . . . . . . . . . . 14 74 2.5. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 15 75 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 15 76 3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17 77 3.1.1. Proxy Discovery Protocol Details . . . . . . . . . . 18 78 3.1.2. Registrar Discovery Protocol Details . . . . . . . . 18 79 3.2. Request Voucher from the Registrar . . . . . . . . . . . 19 80 3.3. Request Voucher from MASA . . . . . . . . . . . . . . . . 20 81 3.4. Voucher Response . . . . . . . . . . . . . . . . . . . . 23 82 3.4.1. Completing authentication of Provisional TLS 83 connection . . . . . . . . . . . . . . . . . . . . . 24 84 3.5. Voucher Status Telemetry . . . . . . . . . . . . . . . . 25 85 3.6. MASA authorization log Request . . . . . . . . . . . . . 26 86 3.7. MASA authorization log Response . . . . . . . . . . . . . 26 87 3.8. EST Integration for PKI bootstrapping . . . . . . . . . . 27 88 3.8.1. EST Distribution of CA Certificates . . . . . . . . . 28 89 3.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 28 90 3.8.3. EST Client Certificate Request . . . . . . . . . . . 29 91 3.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 29 92 3.8.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 30 93 4. Reduced security operational modes . . . . . . . . . . . . . 30 94 4.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 30 95 4.2. Pledge security reductions . . . . . . . . . . . . . . . 31 96 4.3. Registrar security reductions . . . . . . . . . . . . . . 32 97 4.4. MASA security reductions . . . . . . . . . . . . . . . . 33 98 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 99 5.1. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 34 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 101 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 102 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 36 103 8.1. Normative References . . . . . . . . . . . . . . . . . . 36 104 8.2. Informative References . . . . . . . . . . . . . . . . . 38 105 Appendix A. IPv4 operations . . . . . . . . . . . . . . . . . . 39 106 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 39 107 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 39 108 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 39 109 Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 40 110 C.1. Multiple Join networks on the Join Proxy side . . . . . . 41 111 C.2. Automatic configuration of tunnels on Registrar . . . . . 41 112 C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 42 113 C.4. Use of connected sockets; or IP_PKTINFO for CoAP on 114 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 42 115 C.5. Use of socket extension rather than virtual interface . . 42 116 Appendix D. To be deprecated: Consolidation remnants . . . . . . 43 117 D.1. Functional Overview . . . . . . . . . . . . . . . . . . . 43 118 D.1.1. Behavior of a Pledge . . . . . . . . . . . . . . . . 46 119 D.1.2. Behavior of a Join Proxy . . . . . . . . . . . . . . 52 120 D.1.3. Behavior of the Registrar . . . . . . . . . . . . . . 53 121 D.1.4. Behavior of the MASA Service . . . . . . . . . . . . 57 122 D.1.5. Leveraging the new key infrastructure / next steps . 58 123 D.1.6. Interactions with Network Access Control . . . . . . 58 124 D.2. Domain Operator Activities . . . . . . . . . . . . . . . 58 125 D.2.1. Instantiating the Domain Certification Authority . . 59 126 D.2.2. Instantiating the Registrar . . . . . . . . . . . . . 59 127 D.2.3. Accepting New Entities . . . . . . . . . . . . . . . 59 128 D.2.4. Automatic Enrollment of Devices . . . . . . . . . . . 60 129 D.2.5. Secure Network Operations . . . . . . . . . . . . . . 60 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 132 1. Introduction 134 BRSKI provides a foundation to securely answer the following 135 questions between an element of the network domain called the 136 "Registrar" and an unconfigured and untouched device called a 137 "Pledge": 139 o Registrar authenticating the Pledge: "Who is this device? What is 140 its identity?" 142 o Registrar authorization the Pledge: "Is it mine? Do I want it? 143 What are the chances it has been compromised?" 145 o Pledge authenticating the Registrar/Domain: "What is this domain's 146 identity?" 148 o Pledge authorization the Registrar: "Should I join it?" 150 This document details protocols and messages to the endpoints to 151 answer the above questions. The Registrar actions derive from Pledge 152 identity, third party cloud service communications, and local access 153 control lists. The Pledge actions derive from a cryptographically 154 protected "voucher" message delivered through the Registrar. 156 The syntactic details of vouchers are described in detail in 157 [I-D.ietf-anima-voucher]. This document details automated protocol 158 mechanisms to obtain vouchers. 160 BRSKI results in the Pledge storing an X.509 root certificate 161 sufficient for verifying the Registrar identity. In the process a 162 TLS connection is established which can be directly used for 163 Enrollment over Secure Transport (EST). The Pledge can use these 164 credentials to secure additional protocol exchanges. 166 BRSKI is agile enough to support bootstrapping alternative key 167 infrastructures, such as a symmetric key solutions, but no such 168 system is described in this document. 170 1.1. Other Bootstrapping Approaches 172 To literally "pull yourself up by the bootstraps" is an impossible 173 action. Similarly the secure establishment of a key infrastructure 174 without external help is also an impossibility. Today it is commonly 175 accepted that the initial connections between nodes are insecure, 176 until key distribution is complete, or that domain-specific keying 177 material is pre-provisioned on each new device in a costly and non- 178 scalable manner. Existing mechanisms are known as non-secured 'Trust 179 on First Use' (TOFU) [RFC7435], 'resurrecting duckling' 180 [Stajano99theresurrecting] or 'pre-staging'. 182 Another approach is to try and minimize user actions during 183 bootstrapping. The enrollment protocol EST [RFC7030] details a set 184 of non-autonomic bootstrapping methods in this vein: 186 o using the Implicit Trust Anchor database (not an autonomic 187 solution because the URL must be securely distributed), 189 o engaging a human user to authorize the CA certificate using out- 190 of-band data (not an autonomic solution because the human user is 191 involved), 193 o using a configured Explicit TA database (not an autonomic solution 194 because the distribution of an explicit TA database is not 195 autonomic), 197 o and using a Certificate-Less TLS mutual authentication method (not 198 an autonomic solution because the distribution of symmetric key 199 material is not autonomic). 201 These "touch" methods do not meet the requirements for zero-touch. 203 There are "call home" technologies where the Pledge first establishes 204 a connection to a well known vendor service using a common client- 205 server authentication model. After mutual authentication appropriate 206 credentials to authenticate the target domain are transfered to the 207 Pledge. This creates serveral problems and limitations: 209 o the pledge requires realtime connectivity to the vendor service, 211 o the domain identity is exposed to the vendor service (this is a 212 privacy concern), 214 o the vendor is responsible for making the authorization decisions 215 (this is a liability concern), 217 BRSKI addresses these issues by defining extensions to the EST 218 protocol for the automated distribution of vouchers. 220 1.2. Terminology 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 224 "OPTIONAL" in this document are to be interpreted as described in 225 [RFC2119]. 227 The following terms are defined for clarity: 229 DomainID: The domain identity is the 160-bit SHA-1 hash of the BIT 230 STRING of the subjectPublicKey of the domain trust anchor that is 231 stored by the Domain CA. This is consistent with the 232 Certification Authority subject key identifier (Section 4.2.1.2 233 [RFC5280]) of the Domain CA's self signed root certificate. (A 234 string value bound to the Domain CA's self signed root certificate 235 subject and issuer fields is often colloquially used as a 236 humanized identity value but during protocol discussions the more 237 exact term as defined here is used). 239 drop ship: The physical distribution of equipment containing the 240 "factory default" configuration to a final destination. In zero- 241 touch scenarios there is no staging or pre-configuration during 242 drop-ship. 244 imprint: The process where a device obtains the cryptographic key 245 material to identify and trust future interactions with a network. 246 This term is taken from Konrad Lorenz's work in biology with new 247 ducklings: during a critical period, the duckling would assume 248 that anything that looks like a mother duck is in fact their 249 mother. An equivalent for a device is to obtain the fingerprint 250 of the network's root certification authority certificate. A 251 device that imprints on an attacker suffers a similar fate to a 252 duckling that imprints on a hungry wolf. Securely imprinting is a 253 primary focus of this document.[imprinting]. The analogy to 254 Lorenz's work was first noted in [Stajano99theresurrecting]. 256 enrollment: The process where a device presents key material to a 257 network and acquires a network specific identity. For example 258 when a certificate signing request is presented to a certification 259 authority and a certificate is obtained in response. 261 Pledge: The prospective device, which has an identity installed by a 262 third-party (e.g., vendor, manufacturer or integrator). 264 Voucher A signed statement from the MASA service that indicates to a 265 Pledge the cryptographic identity of the Registrar it should 266 trust. There are different types of vouchers depending on how 267 that trust asserted. Multiple voucher types are defined in 268 [I-D.ietf-anima-voucher] 270 Domain: The set of entities that trust a common key infrastructure 271 trust anchor. This includes the Proxy, Registrar, Domain 272 Certificate Authority, Management components and any existing 273 entity that is already a member of the domain. 275 Domain CA: The domain Certification Authority (CA) provides 276 certification functionalities to the domain. At a minimum it 277 provides certification functionalities to a Registrar and stores 278 the trust anchor that defines the domain. Optionally, it 279 certifies all elements. 281 Join Registrar (and Coordinator): A representative of the domain 282 that is configured, perhaps autonomically, to decide whether a new 283 device is allowed to join the domain. The administrator of the 284 domain interfaces with a Join Registrar (and Coordinator) to 285 control this process. Typically a Join Registrar is "inside" its 286 domain. For simplicity this document often refers to this as just 287 "Registrar". The term JRC is used in common with other bootstrap 288 mechanisms. 290 Join Proxy: A domain entity that helps the pledge join the domain. 291 A Proxy facilitates communication for devices that find themselves 292 in an environment where they are not provided connectivity until 293 after they are validated as members of the domain. The pledge is 294 unaware that they are communicating with a proxy rather than 295 directly with a Registrar. 297 MASA Service: A third-party Manufacturer Authorized Signing 298 Authority (MASA) service on the global Internet. The MASA signs 299 vouchers. It also provides a repository for audit log information 300 of privacy protected bootstrapping events. It does not track 301 ownership. 303 Ownership Tracker: An Ownership Tracker service on the global 304 internet. The Ownership Tracker uses business processes to 305 accurately track ownership of all devices shipped against domains 306 that have purchased them. Although optional this component allows 307 vendors to provide additional value in cases where their sales and 308 distribution channels allow for accurately tracking of such 309 ownership. Ownership tracking information is indicated in 310 vouchers as described in [I-D.ietf-anima-voucher] 312 IDevID: An Initial Device Identity X.509 certificate installed by 313 the vendor on new equipment. 315 TOFU: Trust on First Use. Used similarly to [RFC7435]. This is 316 where a Pledge device makes no security decisions but rather 317 simply trusts the first Registrar it is contacted by. This is 318 also known as the "resurrecting duckling" model. 320 1.3. Scope of solution 322 Questions have been posed as to whether this solution is suitable in 323 general for Internet of Things (IoT) networks. This depends on the 324 capabilities of the devices in question. The terminology of 325 [RFC7228] is best used to describe the boundaries. 327 The solution described in this document is aimed in general at non- 328 constrained (i.e. class 2+) devices operating on a non-Challenged 329 network. The entire solution as described here is not intended to be 330 useable as-is by constrained devices operating on challenged networks 331 (such as 802.15.4 LLNs). 333 In many target applications, the systems involved are large router 334 platforms with multi-gigabit inter-connections, mounted in controlled 335 access data centers. But this solution is not exclusive to the 336 large, it is intended to scale to thousands of devices located in 337 hostile environments, such as ISP provided CPE devices which are 338 drop-shipped to the end user. The situation where an order is 339 fulfilled from distributed warehouse from a common stock and shipped 340 directly to the target location at the request of the domain owner is 341 explicitly supported. That stock ("SKU") could be provided to a 342 number of potential domain owners, and the eventual domain owner will 343 not know a-priori which device will go to which location. 345 The bootstrapping process can take minutes to complete depending on 346 the network infrastructure and device processing speed. The network 347 communication itself is not optimized for speed; for privacy reasons, 348 the discovery process allows for the Pledge to avoid announcing it's 349 presence through broadcasting. 351 This protocol is not intended for low latency handoffs. In networks 352 requiring such things, the pledge SHOULD already have been enrolled. 354 Specifically, there are protocol aspects described here which might 355 result in congestion collapse or energy-exhaustion of intermediate 356 battery powered routers in an LLN. Those types of networks SHOULD 357 NOT use this solution. These limitations are predominately related 358 to the large credential and key sizes required for device 359 authentication. Defining symmetric key techniques that meet the 360 operational requirements is out-of-scope but the underlying protocol 361 operations (TLS handshake and signing structures) have sufficient 362 algorithm agility to support such techniques when defined. 364 The imprint protocol described here could, however, be used by non- 365 energy constrained devices joining a non-constrained network (for 366 instance, smart light bulbs are usually mains powered, and speak 367 802.11). It could also be used by non-constrained devices across a 368 non-energy constrained, but challenged network (such as 802.15.4). 369 The certificate contents, and the process by which the four questions 370 above are resolved do apply to constrained devices. It is simply the 371 actual on-the-wire imprint protocol which could be inappropriate. 373 This document presumes that network access control has either already 374 occurred, is not required, or is integrated by the proxy and 375 registrar in such a way that the device itself does not need to be 376 aware of the details. Although the use of an X.509 Initial Device 377 Identity is consistant with IEEE 802.1AR [IDevID], and allows for 378 alignment with 802.1X network access control methods, its use here is 379 for Pledge authentication rather than network access control. 380 Integrating this protocol with network access control, perhaps as an 381 Extensible Authentication Protocol (EAP) method (see [RFC3748]), is 382 out-of-scope. 384 2. Architectural Overview 386 The logical elements of the bootstrapping framework are described in 387 this section. Figure 1 provides a simplified overview of the 388 components. Each component is logical and may be combined with other 389 components as necessary. 391 . 392 .+------------------------+ 393 +--------------Drop Ship-------------->.| Vendor Service | 394 | .+------------------------+ 395 | .| M anufacturer| | 396 | .| A uthorized |Ownership| 397 | .| S igning |Tracker | 398 | .| A uthority | | 399 | .+--------------+---------+ 400 | .............. ^ 401 V | 402 +-------+ ............................................|... 403 | | . | . 404 | | . +------------+ +-----------+ | . 405 | | . | | | | | . 406 |Pledge | . | Circuit | | Domain <-------+ . 407 | | . | Proxy | | Registrar | . 408 | <--------> <-------> | . 409 | | . | | | | . 410 |X.509 | . +------------+ +-----+-----+ . 411 |IDevID | . | . 412 | | . +-----------------+----------+ . 413 | | . | Key Infrastructure | . 414 | | . | (e.g. PKI Certificate | . 415 +-------+ . | Authority) | . 416 . +----------------------------+ . 417 . . 418 ................................................ 419 "Domain" components 421 Figure 1 423 We assume a multi-vendor network. In such an environment there could 424 be a Vendor Service for each vendor that supports devices following 425 this document's specification, or an integrator could provide a 426 generic service authorized by multiple vendors. It is unlikely that 427 an integrator could provide Ownership Tracking services for multiple 428 vendors due to the required sales channel integrations necessary to 429 track ownership. 431 The domain is the managed network infrastructure with a Key 432 Infrastructure the Pledge is joining. The a domain provides initial 433 device connectivity sufficient for bootstrapping with a Circuit 434 Proxy. The Domain registrar authenticates the Pledge, makes 435 authorization decisions, and distributes vouchers obtained from the 436 Vendor Service. Optionally the Registrar also acts as a PKI 437 Registration Authority. 439 2.1. Secure Imprinting using Vouchers 441 A voucher is a cryptographically protected statement to the Pledge 442 device authorizing a zero-touch imprint on the Registrar domain. 444 The format and cryptographic mechanism of vouchers is described in 445 detail in [I-D.ietf-anima-voucher]. 447 Vouchers provide a flexible mechanism to secure imprinting: the 448 Pledge device only imprints when a voucher can be validated. At the 449 lowest security levels the MASA server can indiscriminately issue 450 vouchers. At the highest security levels issuance of vouchers can be 451 integrated with complex sales channel integrations that are beyond 452 the scope of this document. This provides the flexibility for a 453 number of use cases via a single common protocol mechanism on the 454 Pledge and Registrar devices that are to be widely deployed in the 455 field. The MASA vendor services have the flexibility to leverage 456 either the currently defined claim mechanisms or to experiment with 457 higher or lower security levels. 459 Vouchers provide a signed but non-encrypted communication channel 460 between the Pledge, the MASA, and the Registrar. The Registrar 461 maintains control over the transport and policy decisions allowing 462 the local security policy of the domain network to be enforced. 464 2.2. Initial Device Identifier 466 Pledge authentication is via an X.509 certificate installed during 467 the manufacturing process. This Initial Device Identifier provides a 468 basis for authenticating the Pledge during subsequent protocol 469 exchanges and informing the Registrar of the MASA URI. There is no 470 requirement for a common root PKI hierarchy. Each device vendor can 471 generate their own root certificate. 473 The following previously defined fields are in the X.509 IDevID 474 certificate: 476 o The subject field's DN encoding MUST include the "serialNumber" 477 attribute with the device's unique serial number. 479 o The subject-alt field's encoding SHOULD include a non-critical 480 version of the RFC4108 defined HardwareModuleName. 482 In order to build the voucher "serial-number" field these IDevID 483 fields need to be converted into a serial-number of "type string". 484 The following methods is used depending on the first available IDevID 485 certificate field (attempted in this order): 487 o An RFC4514 String Representation of the Distinguished Name 488 "serialNumber" attribute. 490 o The HardwareModuleName hwSerialNum OCTET STRING base64 encoded. 492 o The RFC4514 String Representation of the Distinguished Name 493 "common name" attribute. 495 The following newly defined field SHOULD be in the X.509 IDevID 496 certificate: An X.509 non-critical certificate extension that 497 contains a single Uniform Resource Identifier (URI) that points to an 498 on-line Manufacturer Authorized Signing Authority. The URI is 499 represented as described in Section 7.4 of [RFC5280]. 501 Any Internationalized Resource Identifiers (IRIs) MUST be mapped to 502 URIs as specified in Section 3.1 of [RFC3987] before they are placed 503 in the certificate extension. The URI provides the authority 504 information. The BRSKI .well-known tree is described in Section 3 506 The new extension is identified as follows: 508 510 MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) 511 internet(1) security(5) mechanisms(5) pkix(7) 512 id-mod(0) id-mod-MASAURLExtn2016(TBD) } 514 DEFINITIONS IMPLICIT TAGS ::= BEGIN 516 -- EXPORTS ALL -- 518 IMPORTS 519 EXTENSION 520 FROM PKIX-CommonTypes-2009 521 { iso(1) identified-organization(3) dod(6) internet(1) 522 security(5) mechanisms(5) pkix(7) id-mod(0) 523 id-mod-pkixCommon-02(57) } 525 id-pe 526 FROM PKIX1Explicit-2009 527 { iso(1) identified-organization(3) dod(6) internet(1) 528 security(5) mechanisms(5) pkix(7) id-mod(0) 529 id-mod-pkix1-explicit-02(51) } ; 530 MASACertExtensions EXTENSION ::= { ext-MASAURL, ... } 531 ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax 532 IDENTIFIED BY id-pe-masa-url } 534 id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe TBD } 536 MASAURLSyntax ::= IA5String 538 END 540 542 The choice of id-pe is based on guidance found in Section 4.2.2 of 543 [RFC5280], "These extensions may be used to direct applications to 544 on-line information about the issuer or the subject". The MASA URL 545 is precisely that: online information about the particular subject. 547 2.3. Protocol Flow 549 A representative flow is shown in Figure 2: 551 +--------+ +---------+ +------------+ +------------+ 552 | Pledge | | Circuit | | Domain | | Vendor | 553 | | | Proxy | | Registrar | | Service | 554 | | | | | | | (Internet | 555 +--------+ +---------+ +------------+ +------------+ 556 | | | | 557 |<-RFC3927 IPv4 adr | Appendix A | | 558 or|<-RFC4862 IPv6 adr | | | 559 | | | | 560 |-------------------->| | | 561 | optional: mDNS query| Appendix B | | 562 | RFC6763/RFC6762 | | | 563 | | | | 564 |<--------------------| | | 565 | GRASP M_FLOOD | | | 566 | periodic broadcast| | | 567 | | | | 568 |<------------------->C<----------------->| | 569 | TLS via the Circuit Proxy | | 570 |<--Registrar TLS server authentication---| | 571 [PROVISIONAL accept of server cert] | | 572 P---X.509 client authentication---------->| | 573 P | | | 574 P---Request Voucher (include nonce)------>| | 575 P | | | 576 P | /---> | | 577 P | | [accept device?] | 578 P | | [contact Vendor] | 579 P | | |--Pledge ID-------->| 580 P | | |--Domain ID-------->| 581 P | | |--optional:nonce--->| 582 P | | | [extract DomainID] 583 P | | | | 584 P | optional: | [update audit log] 585 P | |can | | 586 P | |occur | | 587 P | |in | | 588 P | |advance | | 589 P | | | | 590 P | | |<-device audit log--| 591 P | | |<- voucher ---------| 592 P | \----> | | 593 P | | | 594 P | [verify audit log and voucher] | 595 P | | | 596 P<------voucher---------------------------| | 597 [verify voucher ] | | | 598 [verify provisional cert| | | 599 | | | | 600 |<--------------------------------------->| | 601 | Continue with RFC7030 enrollment | | 602 | using now bidirectionally authenticated | | 603 | TLS session. | | | 604 | | | | 605 | | | | 606 | | | | 608 Figure 2 610 2.4. Lack of realtime clock 612 Many devices when bootstrapping do not have knowledge of the current 613 time. Mechanisms like Network Time Protocols can not be secured 614 until bootstrapping is complete. Therefore bootstrapping is defined 615 in a method that does not require knowledge of the current time. 617 Unfortunately there are moments during bootstrapping when 618 certificates are verified, such as during the TLS handshake, where 619 validity periods are confirmed. This paradoxical "catch-22" is 620 resolved by the Pledge maintaining a concept of the current "window" 621 of presumed time validity that is continually refined throughout the 622 bootstrapping process as follows: 624 o Initially the Pledge does not know the current time. 626 o During Pledge authentiation by the Registrar a realtime clock can 627 be used by the Registrar. This bullet expands on a closely 628 related issue regarding Pledge lifetimes. RFC5280 indicates that 629 long lived Pledge certifiates "SHOULD be assigned the 630 GeneralizedTime value of 99991231235959Z" [RFC7030] so the 631 Registrar MUST support such lifetimes and SHOULD support ignoring 632 Pledge lifetimes if they did not follow the RFC5280 633 recommendations. 635 o The Pledge authenticates the voucher presented to it. During this 636 authentication the Pledge ignores certificate lifetimes (by 637 necessity because it does not have a realtime clock). 639 o If the voucher contains a nonce then the Pledge MUST confirm the 640 nonce matches the original voucher request. This ensures the 641 voucher is fresh. See / (Section 3.2). 643 o Once the voucher is accepted the validity period of the 644 domainCAcert in the voucher (see Section 3.4) now serves as a 645 valid time window. Any subsequent certificate validity periods 646 checked during RFC5280 path validation MUST occur within this 647 window. 649 o When accepting an enrollment certificate the validity period 650 within the new certificate is assumed to be valid by the Pledge. 652 The Pledge is now willing to use this credential for client 653 authentication. 655 2.5. Cloud Registrar 657 The Pledge MAY contact a well known URI of a cloud Registrar if a 658 local Registrar can not be discovered or if the Pledge's target use 659 cases do not include a local Registrar. 661 If the Pledge uses a well known URI for contacting a cloud Registrar 662 an Implicit Trust Anchor database (see [RFC7030]) MUST be used to 663 authenticate service as described in RFC6125. This is consistent 664 with the human user configuration of an EST server URI in [RFC7030] 665 which also depends on RFC6125. 667 3. Protocol Details 669 The Pledge MUST initiate BRSKI after boot if it is unconfigured. The 670 Pledge MUST NOT automatically initiate BRSKI if it has been 671 configured or is in the process of being configured. 673 BRSKI is described as extensions to EST [RFC7030] to reduce the 674 number of TLS connections and crypto operations required on the 675 Pledge. The Registrar implements the BRSKI REST interface within the 676 same .well-known URI tree as the existing EST URIs as described in 677 EST [RFC7030] section 3.2.2. A MASA URI is therefore "https:// 678 authority "./well-known/est". 680 Establishment of the TLS connection for bootstrapping is as specified 681 in EST [RFC7030] section 4.1.1 "Bootstrap Distribution of CA 682 Certificates" [RFC7030] with the following extensions for automation: 684 Automation extensions for the Pledge (equivalent to EST client) are: 686 o The Pledge provisionally accepts the Registrar certificate during 687 the TLS handshake as detailed in EST. 689 o If the Registrar responds with a redirection to other web origins 690 the Pledge MUST follow only a single redirection. (EST supports 691 redirection but does not allow redirections to other web origins 692 without user input). 694 o The Registar MAY respond with an HTTP 202 ("the request has been 695 accepted for processing, but the processing has not been 696 completed") as described in EST [RFC7030] section 4.2.3 wherein 697 the client "MUST wait at least the specified 'retry-after' time 698 before repeating the same request". The Pledge is RECOMMENDED to 699 provide local feed (blinked LED etc) during this wait cycle if 700 mechanisms for this are available. To prevent an attacker 701 Registrar from significantly delaying bootstrapping the Pledge 702 MUST limit the 'retry-after' time to 60 seconds. To avoid waiting 703 on a single erroneous Registrar the Pledge MUST drop the 704 connection after 5 seconds and proceed to other discovered 705 Registrars. Ideally the Pledge could keep track of the 706 appropriate retry-after value for any number of outstanding 707 Registrars but this would involve a large state table on the 708 Pledge. Instead the Pledge MAY ignore the exact retry-after value 709 in favor of a single hard coded value that takes effect between 710 discovery (Appendix D.1.1.1) attempts. A Registrar that is unable 711 to complete the transaction the first time due to timing reasons 712 will have future chances. 714 o The Pledge requests and validates a voucher using the new REST 715 calls described below. 717 o If necessary the Pledge calls the EST defined /cacerts method to 718 obtain the current CA certificate. These are validated using the 719 Voucher. 721 o The Pledge completes authentication of the server certificate as 722 detailed in Section 3.4.1. This moves the TLS connection out of 723 the provisional state. Optionally the TLS connection can now be 724 used for EST enrollment. 726 The Pledge establishes the TLS connection with the Registrar through 727 the circuit proxy (see Appendix D.1.2) but the TLS connection is with 728 the Registar; so in the above section the "Pledge" is the TLS client 729 and the "Registrar" is the TLS server. All security associations 730 established are between the new device and the Registrar regardless 731 of proxy operations. 733 The extensions for a Registrar (equivalent to EST server) are: 735 o Client authentication is automated using Initial Device Identity. 736 The subject field's DN encoding MUST include the "serialNumber" 737 attribute with the device's unique serial number. In the language 738 of RFC6125 this provides for a SERIALNUM-ID category of identifier 739 that can be included in a certificate and therefore that can also 740 be used for matching purposes. The SERIALNUM-ID whitelist is 741 collated according to vendor trust anchor since serial numbers are 742 not globally unique. 744 o The Registrar requests and validates the Voucher from the vendor 745 authorized MASA service. 747 o The Registrar forwards the Voucher to the Pledge when requested. 749 o The Registar performs log verifications in addition to local 750 authorization checks before accepting optional Pledge device 751 enrollment requests. 753 3.1. Discovery 755 The result of discovery is a logical communication with a Registrar, 756 through a Proxy. The Proxy is transparent to the Pledge but is 757 always assumed to exist. 759 To discover the Registrar the Pledge performs the following actions: 761 a. MUST: Obtains a local address using IPv6 methods as described in 762 [RFC4862] IPv6 Stateless Address AutoConfiguration. [RFC7217] is 763 encouraged. Pledges will generally prefer use of IPv6 Link-Local 764 addresses, and discovery of Proxy will be by Link-Local 765 mechanisms. IPv4 methods are described in Appendix A 767 b. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) 768 announcements of the objective: "ACP+Proxy". See section 769 Section 3.1.1 for the details of the the objective. The Pledge 770 may listen concurrently for other sources of information, see 771 Appendix B. 773 Once a proxy is discovered the Pledge communicates with a Registrar 774 through the proxy using the bootstrapping protocol defined in 775 Section 3. 777 Each discovery method attempted SHOULD exponentially back-off 778 attempts (to a maximum of one hour) to avoid overloading the network 779 infrastructure with discovery. The back-off timer for each method 780 MUST be independent of other methods. 782 Methods SHOULD be run in parallel to avoid head of queue problems 783 wherein an attacker running a fake proxy or registrar can operate 784 protocol actions intentionally slowly. 786 Once a connection to a Registrar is established (e.g. establishment 787 of a TLS session key) there are expectations of more timely 788 responses, see Section 3.2. 790 Once all discovered services are attempted the device SHOULD return 791 to listening for GRASP M_FLOOD. It should periodically retry the 792 vendor specific mechanisms. The Pledge MAY prioritize selection 793 order as appropriate for the anticipated environment. 795 3.1.1. Proxy Discovery Protocol Details 797 The proxy uses the GRASP M_FLOOD mechanism to announce itself. This 798 announcement is done with the same message as the ACP announcement 799 detailed in [I-D.ietf-anima-autonomic-control-plane]. 801 proxy-objective = ["Proxy", [ O_IPv6_LOCATOR, ipv6-address, 802 transport-proto, port-number ] ] 804 ipv6-address - the v6 LL of the proxy 805 transport-proto - 6, for TCP 17 for UDP 806 port-number - the TCP or UDP port number to find the proxy 808 Figure 5 810 3.1.2. Registrar Discovery Protocol Details 812 A Registrar is typically configured manually. When the Registrar 813 joins an Autonomic Control Plane 814 ([I-D.ietf-anima-autonomic-control-plane]) it MUST respond to GRASP 815 ([I-D.ietf-anima-grasp]) M_NEG_SYN message. 817 The registrar responds to discovery messages from the proxy (or GRASP 818 caches between them) as follows: (XXX changed from M_DISCOVERY) 820 objective = ["AN_registrar", F_DISC, 255 ] 821 discovery-message = [M_NEG_SYN, session-id, initiator, objective] 823 Figure 6: Registrar Discovery 825 The response from the registrar (or cache) will be a M_RESPONSE with 826 the following parameters: 828 response-message = [M_RESPONSE, session-id, initiator, ttl, 829 (+locator-option // divert-option), ?objective)] 830 initiator = ACP address of Registrar 831 locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] 832 locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] 833 locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] 835 Figure 7: Registrar Response 837 The set of locators is to be interpreted as follows. A protocol of 6 838 indicates that TCP proxying on the indicated port is desired. A 839 protocol of 17 indicates that UDP proxying on the indicated port is 840 desired. In each case, the traffic SHOULD be proxied to the same 841 port at the ULA address provided. 843 A protocol of 41 indicates that packets may be IPIP proxy'ed. In the 844 case of that IPIP proxying is used, then the provided link-local 845 address MUST be advertised on the local link using proxy neighbour 846 discovery. The Join Proxy MAY limit forwarded traffic to the 847 protocol (6 and 17) and port numbers indicated by locator1 and 848 locator2. The address to which the IPIP traffic should be sent is 849 the initiator address (an ACP address of the Registrar), not the 850 address given in the locator. 852 Registrars MUST accept TCP / UDP traffic on the ports given at the 853 ACP address of the Registrar. If the Registrar supports IPIP 854 tunnelling, it MUST also accept traffic encapsulated with IPIP. 856 Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated. 857 Registrars MAY accept DTLS/CoAP/EST traffic on the UDP in addition to 858 TCP traffic. 860 3.2. Request Voucher from the Registrar 862 When the Pledge bootstraps it makes a request for a Voucher from a 863 Registrar. 865 This is done with an HTTPS POST using the operation path value of 866 "/requestvoucher". 868 The request media types are: 870 application/voucherrequest The request is a "YANG-defined JSON 871 document that has been signed using a PKCS#7 structure" as 872 described in [I-D.ietf-anima-voucher] using the JSON encoded 873 described in [RFC7951]. Signing the request is RECOMMENDED if the 874 Pledge has sufficient processing to perform the crypto operations. 875 Doing so allows the Registrar to forward the Pledge's signed 876 'proximity' assertion to the MASA as discussed in the security 877 considerations. 879 application/unsignedvoucherrequest The request is the "YANG-defined 880 JSON document" but has not been signed. It is the inner JSON 881 structure protected only by the TLS client authentication. This 882 reduces the cryptographic requirements on the Pledge. 884 For simplicity the term 'voucher request' is used to refer to either 885 of these media types. Registrar impementations SHOULD anticipate 886 future media types but of course will simply fail the request if 887 those types are not yet known. 889 The Pledge populates the voucher request fields as follows: 891 created-on: Pledges that have a realtime clock are RECOMMENDED to 892 populate this field. This provides additional information to the 893 MASA. 895 nonce: The voucher request MUST contain a cryptographically strong 896 random or pseudo-random number nonce. Doing so ensures 897 Section 2.4 functionality. The nonce MUST NOT be reused for 898 multiple bootstrapping attempts. 900 assertion: The voucher request MAY contain an assertion of 901 "proximity". 903 pinned-domain-cert: In a Pledge voucher request this is the 904 Registrar certificate as extracted from the TLS handshake (for 905 example the first certificate in the TLS 'certificate_list' 906 sequence (see [RFC5246]). This MUST be populated in a Pledge's 907 voucher request if the "proximity" assertion is populated. 909 All other fields MAY be ommitted in the voucher request. 911 An example JSON payload of a voucher request from a Pledge: 913 { 914 "ietf-voucher:voucher": { 915 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 916 "created-on": "2017-01-01T00:00:00.000Z", 917 "assertion": "proximity", 918 "pinned-domain-cert": "" 919 } 920 } 922 The Registrar validates the client identity as described in EST 923 [RFC7030] section 3.3.2. If the request is signed the Registrar 924 confirms the 'proximity' asserion and associated 'pinned-domain-cert' 925 are correct. The registrar performs authorization as detailed in 926 [[EDNOTE: UNRESOLVED. See Appendix D "Pledge Authorization"]]. If 927 these validations fail the Registrar SHOULD respond with an 928 appropriate HTTP error code. 930 If authorization is successful the Registrar obtains a voucher from 931 the MASA service (see Section 3.3) and returns that MASA signed 932 voucher to the pledge as described in Section 3.4. 934 3.3. Request Voucher from MASA 936 when a Registrar recieves a voucher request from a Pledge it in turn 937 requests a voucher from the MASA service. For simplicity this is 938 defined as an optional EST message between a Registrar and an EST 939 server running on the MASA service although the Registrar is not 940 required to make use of any other EST functionality when 941 communicating with the MASA service. (The MASA service MUST properly 942 reject any EST functionality requests it does not wish to service; a 943 requirement that holds for any REST interface). 945 This is done with an HTTP POST using the operation path value of 946 "/requestvoucher". 948 The request media type is: 950 application/voucherrequest The request is a "YANG-defined JSON 951 document that has been signed using a PKCS#7 structure" as 952 described in [I-D.ietf-anima-voucher] using the JSON encoded 953 described in [RFC7951]. The Registrar MUST sign the request. The 954 entire Registrar certificate chain, up to and including the Domain 955 CA, MUST be included in the PKCS#7 structure. 957 For simplicity the term 'voucher request' is used. MASA 958 impementations SHOULD anticipate future media types but of course 959 will simply fail the request if those types are not yet known. 961 The Registrar populates the voucher request fields as follows: 963 created-on: Registrars are RECOMMENDED to populate this field. This 964 provides additional information to the MASA. 966 nonce: The optional nonce value from the Pledge request if desired 967 (see below). 969 serial-number: The serial number of the Pledge the Registrar would 970 like a voucher for. 972 idevid-issuer: The idevid-issuer value from the pledge certificate 973 is included to ensure a statistically unique identity. The 974 Pledge's serial number is extracted from the X.509 IDevID. See 975 Section 2.2. 977 prior-signed-voucher: If the Pledge provided a signed voucher 978 request then it SHOULD be included in the voucher request built by 979 the Registrar. 981 All other fields MAY be ommitted in the voucher request. 983 An example JSON payload of a voucher request from a Registrar: 985 { 986 "ietf-voucher:voucher": { 987 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 988 "created-on": "2017-01-01T00:00:00.000Z", 989 "assertion": "proximity" 990 "idevid-issuer": "" 991 "serial-number": "JADA123456789" 992 "prior-signed-voucher": "" 993 } 994 } 996 A Registrar MAY exclude the nonce from the voucher request it submits 997 to the MASA. Doing so allows the Registrar to request a Voucher when 998 the Pledge is offline, or when the Registrar is expected to be 999 offline when the Pledge is being deployed. These use cases require 1000 the Registrar to learn the appropriate IDevID SerialNumber field from 1001 the physical device labeling or from the sales channel (out-of-scope 1002 of this document). If a nonce is not provided the MASA server MUST 1003 authenticate the Registrar as described in EST [RFC7030] section 1004 3.3.2 to reduce the risk of DDoS attacks and to provide an 1005 authenticated identity as an input to sales channel integration and 1006 authorizations (also out-of-scope of this document). 1008 The MASA verifies that the voucher request is internally consistent 1009 but does not authenticate the domain identity information since the 1010 domain is not know to the MASA server in advance. The MASA 1011 validation checks before issuing a voucher are as follows: 1013 Renew for expired voucher: As described in [I-D.ietf-anima-voucher] 1014 vouchers are normally short lived to avoid revocation issues. If 1015 the request is for a previous (expired) voucher using the same 1016 Registrar (as determined by the Registrar pinned-domain-cert) and 1017 the MASA has not been informed that the claim is invalid then the 1018 request for a renewed voucher SHOULD be automatically authorized. 1020 Voucher signature consistency: The MASA MUST verify that the voucher 1021 request is signed by a Registrar. This is confirmed by verifying 1022 that the id-kp-cmcRA extended key usage extension field (as 1023 detailed in EST RFC7030 section 3.6.1) exists in the certificate 1024 of the entity that signed the voucher request. This verification 1025 is only a consistency check that the unauthenticated domain CA 1026 intended this to be a Registrar. Performing this check provides 1027 value to domain PKI by assuring the domain administrator that the 1028 MASA service will only respect claims from authorized Registration 1029 Authorities of the domain. (The requirement for the Registrar to 1030 include the Domain CA certificate in the signature structure was 1031 stated above). 1033 Registrar revocation consistency: The MASA SHOULD check for 1034 revocation of the Registrar certificate. The maximum lifetime of 1035 the voucher issued SHOULD NOT exceed the lifetime of the 1036 Registrar's revocation validation (for example if the Registrar 1037 revocation status is indicated in a CRL that is valid for two 1038 weeks then that is an appropriate lifetime for the voucher). 1039 Because the Registar certificate authority is unknown to the MASA 1040 in advance this is only an extended consistency check and is not 1041 required. The maximum lifetime of the voucher issued SHOULD NOT 1042 exceed the lifetime of the Registrar's revocation validation (for 1043 example if the Registrar revocation status is indicated in a CRL 1044 that is valid for two weeks then that is an appropriate lifetime 1045 for the voucher). 1047 Pledge proximity assertion: The MASA server MAY verify that the 1048 Registrar signed voucher includes the 'prior-signed-voucher' field 1049 populated with a Pledge signed voucher that includes a pinned- 1050 domain-cert that is consistent with the Registrar certificate 1051 chain. The MASA server is aware of which Pledge's support signing 1052 of their voucher requests and can use this information to confirm 1053 proximity of the Pledge with the Registrar. 1055 The root certificate is extracted from the signature method and used 1056 to populate the "pinned-domain-cert" of the Voucher being issued. 1057 The domain ID (e.g. hash of the public key of the domain) is 1058 extracted from the root certificate and is used to update the audit 1059 log. 1061 3.4. Voucher Response 1063 The voucher response to requests from the Pledge and requests from a 1064 Registrar are in the same format. A Registrar either caches prior 1065 MASA responses or dynamically requests a new Voucher based on local 1066 policy. 1068 If the the join operation is successful, the server response MUST 1069 contain an HTTP 200 response code. The server MUST answer with a 1070 suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. 1071 The response data from the MASA server MUST be a plaintext human- 1072 readable (ASCII, english) error message containing explanatory 1073 information describing why the request was rejected. 1075 Response media type: application/voucher+cms 1077 The syntactic details of vouchers are described in detail in 1078 [I-D.ietf-anima-voucher]. For example, the voucher consists of: 1080 { 1081 "ietf-voucher:voucher": { 1082 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1083 "assertion": "logging" 1084 "pinned-domain-cert": "" 1085 "serial-number": "JADA123456789" 1086 } 1087 } 1089 The Pledge verifies the signed voucher using the manufacturer 1090 installed trust anchor associated with the vendor's selected 1091 Manufacturer Authorized Signing Authority. 1093 The 'pinned-domain-cert' element of the voucher contains the domain 1094 CA's public key. The Pledge MUST use the 'pinned-domain-cert' trust 1095 anchor to immediately complete authentication of the provisional TLS 1096 connection. 1098 The Pledge MUST be prepared to parse and fail gracefully from an 1099 Voucher response that does not contain a 'pinned-domain-cert' field. 1100 The Pledge MUST be prepared to ignore additional fields it does not 1101 recognize. 1103 3.4.1. Completing authentication of Provisional TLS connection 1105 If a Registrar's credentials can not be verified using the pinned- 1106 domain-cert trust anchor from the voucher then the TLS connection is 1107 immediately discarded and the Pledge abandons attempts to bootstrap 1108 with this discovered registrar. The pledge SHOULD send voucher 1109 status telemetry (described below) before closing the TLS connection. 1110 The pledge MUST attempt to enroll using any other proxies it has 1111 found. It SHOULD return to the same proxy again after attempting 1112 with other proxies. Attempts should be attempted in the exponential 1113 backoff described earlier. Attempts SHOULD be repeated as failure 1114 may be the result of a temporary inconsistently (an inconsistently 1115 rolled Registrar key, or some other mis-configuration). The 1116 inconsistently could also be the result an active MITM attack on the 1117 EST connection. 1119 The Registrar MUST use a certificate that chains to the pinned- 1120 domain-cert as its TLS server certificate. 1122 The Pledge's PKIX path validation of a Registrar certificate's 1123 validity period information is as described in Section 2.4. Once the 1124 PKIX path validation is successful the TLS connection is no longer 1125 provisional. 1127 The pinned-domain-cert is installed as an Explicit Trust Anchor for 1128 future operations. It can therefore can be used to authenticate any 1129 dynamically discovered EST server that contain the id-kp-cmcRA 1130 extended key usage extension as detailed in EST RFC7030 section 1131 3.6.1; but to reduce system complexity the Pledge SHOULD avoid 1132 additional discovery operations. Instead the Pledge SHOULD 1133 communicate directly with the Registrar as the EST server. The ' 1134 pinned-domain-cert' is not a complete distribution of the EST section 1135 4.1.3 CA Certificate Response which is an additional justification 1136 for the recommendation to proceed with EST key management operations. 1137 Once a full CA Certificate Response is obtained it is more 1138 authoritative for the domain than the limited 'pinned-domain-cert' 1139 response.' 1141 3.5. Voucher Status Telemetry 1143 The domain is expected to provide indications to the system 1144 administrators concerning device lifecycle status. To facilitate 1145 this it needs telemetry information concerning the device's status. 1147 To indicate Pledge status regarding the Voucher the client SHOULD 1148 post a status message. 1150 The posted data media type: application/json 1152 The client HTTP POSTs the following to the server at the EST well 1153 known URI /voucher_status. The Status field indicates if the Voucher 1154 was acceptable. If it was not acceptable the Reason string indicates 1155 why. In the failure case this message is being sent to an 1156 unauthenticated, potentially malicious Registrar and therefore the 1157 Reason string SHOULD NOT provide information beneficial to an 1158 attacker. The operational benefit of this telemetry information is 1159 balanced against the operational costs of not recording that an 1160 Voucher was ignored by a client the registar expected to continue 1161 joining the domain. 1163 { 1164 "version":"1", 1165 "Status":FALSE /* TRUE=Success, FALSE=Fail" 1166 "Reason":"Informative human readable message" 1167 } 1169 The server SHOULD respond with an HTTP 200 but MAY simply fail with 1170 an HTTP 404 error. The client ignores any response. Within the 1171 server logs the server SHOULD capture this telemetry information. 1173 3.6. MASA authorization log Request 1175 A registrar requests the MASA authorization log from the MASA service 1176 using this EST extension. If a device had previously registered with 1177 another domain, a Registrar of that domain would show in the log. 1179 This is done with an HTTP GET using the operation path value of 1180 "/requestauditlog". 1182 The registrar MUST HTTP POSTs the same Voucher Request as when 1183 requesting a Voucher. It is posted to the /requestauditlog URI 1184 instead. The "idevid-issuer" and "serial-number" informs the MASA 1185 server which log is requested so the appropriate log can be prepared 1186 for the response. Using the same media type and message minimizes 1187 cryptographic and message operations although it results in 1188 additional network traffic. The relying MASA server implementation 1189 MAY leverage internal state to associate this request with the 1190 original, and by now already validated, voucher request so as to 1191 avoid an extra crypto validation. 1193 Request media type: application/voucherrequest+cms 1195 3.7. MASA authorization log Response 1197 A log data file is returned consisting of all log entries. For 1198 example: 1200 { 1201 "version":"1", 1202 "events":[ 1203 { 1204 "date":"", 1205 "domainID":"", 1207 "nonce":"" 1208 }, 1209 { 1210 "date":"", 1211 "domainID":"", 1213 "nonce":"" 1214 } 1215 ] 1216 } 1218 Distribution of a large log is less than ideal. This structure can 1219 be optimized as follows: All nonce-less entries for the same domainID 1220 MAY be condensed into the single most recent nonceless entry. 1222 A Registrar SHOULD use this log information to make an informed 1223 decision regarding the continued bootstrapping of the Pledge. For 1224 example if the log includes unexpected domainIDs this is indicative 1225 of problematic imprints by the Pledge. If the log includes nonce- 1226 less entries this is indicative of the permanent ability for the 1227 indicated domain to trigger a reset of the device and take over 1228 management of it. Equipment that is purchased pre-owned can be 1229 expected to have an extensive history. A Registrar MAY request logs 1230 at future times. A Registrar MAY be configured to ignore the history 1231 of the device but it is RECOMMENDED that this only be configured if 1232 hardware assisted NEA [RFC5209] is supported. 1234 Log entries containing the Domain's ID can be compared against local 1235 history logs in search of discrepancies. 1237 This document specifies a simple log format as provided by the MASA 1238 service to the registar. This format could be improved by 1239 distributed consensus technologies that integrate vouchers with a 1240 technologies such as block-chain or hash trees or the like. Doing so 1241 is out of the scope of this document but are anticipated improvements 1242 for future work. As such, the Registrar client SHOULD anticipate new 1243 kinds of responses, and SHOULD provide operator controls to indicate 1244 how to process unknown responses. 1246 3.8. EST Integration for PKI bootstrapping 1248 This section describes EST extensions necessary to enable fully 1249 automated bootstrapping. Although the Voucher request/response 1250 structure members "idevid-issuer" and "pinned-domain-cert" are 1251 specific to PKI bootstrapping these are the only PKI specific aspects 1252 of the extensions and future voucher definitions might replace them 1253 with non-PKI fields. 1255 Once the Voucher is received, as specified in this document, the 1256 client has sufficient information to leverage the existing 1257 communication channel with a Registrar to continue an EST RFC7030 1258 enrollment. The voucher provides an automated mechanism for the 1259 "Bootstrap Distribution of CA Certificates" described in [RFC7030] 1260 section 4.1.1 wherein the Pledge "MUST [...]. engage a human user to 1261 authorize the CA certificate using out-of-band" information". 1262 Instead the Pledge now can automate this process using the voucher 1263 provided "pinned-domain-cert". 1265 The Pledge SHOULD use the existing current TLS connection to proceed 1266 with EST enrollment, thus reducing the total amount of cryptographic 1267 and round trip operations required during bootstrapping. After 1268 voucher verification the Pledge continues with EST enrollment 1269 operations including "CA Certificates Request", "CSR Attributes" and 1270 "Client Certificate Request" or "Server-Side Key Generation" etc. 1272 The Pledge is RECOMMENDED to implement the following EST automation 1273 extensions. They supplement the RFC7030 EST to better support 1274 automated devices that do not have an end user. 1276 3.8.1. EST Distribution of CA Certificates 1278 The Pledge MUST request the full EST Distribution of CA Certificates 1279 message. See RFC7030, section 4.1. 1281 This ensures that the Pledge has the complete set of current CA 1282 certificates beyond the domainCAcert (see Section 3.4 for a 1283 discussion of the limitations). Although these restrictions are 1284 acceptable for a Registrar integrated with initial bootstrapping they 1285 are not appropriate for ongoing PKIX end entity certificate 1286 validation. 1288 3.8.2. EST CSR Attributes 1290 Automated bootstrapping occurs without local administrative 1291 configuration of the Pledge. In some deployments its plausible that 1292 the Pledge generates a certificate request containing only identity 1293 information known to the Pledge (essentially the X.509 IDevID 1294 information) and ultimately receives a certificate containing domain 1295 specific identity information. Conceptually the CA has complete 1296 control over all fields issued in the end entity certificate. 1297 Realistically this is operationally difficult with the current status 1298 of PKI certificate authority deployments where the CSR is submitted 1299 to the CA via a number of non-standard protocols. Even with all 1300 standardized protocols used, it could operationally be problematic to 1301 expect that service specific certificate fields can be created by a 1302 CA that is likely operated by a group that has no insight into 1303 different network services/protocols used. For example, the CA could 1304 even be outsourced. 1306 To alleviate these operational difficulties, the Pledge MUST request 1307 the EST "CSR Attributes" from the EST server and the EST server needs 1308 to be able to reply with the attributes necessary for use of the 1309 certificate in its intended protocols/services. This approach allows 1310 for minimal CA integrations and instead the local infrastructure (EST 1311 server) informs the Pledge of the proper fields to include in the 1312 generated CSR. This approach is beneficial to automated boostrapping 1313 in the widest number of environments. 1315 If the hardwareModuleName in the X.509 IDevID is populated then it 1316 SHOULD by default be propagated to the LDevID along with the 1317 hwSerialNum. The EST server SHOULD support local policy concerning 1318 this functionality. 1320 In networks using the BRSKI enrolled certificate to authenticate the 1321 ACP (Autonomic Control Plane), the EST attributes MUST include the 1322 "ACP information" field. See 1323 [I-D.ietf-anima-autonomic-control-plane] for more details. 1325 The Registar MUST also confirm the resulting CSR is formatted as 1326 indicated before forwarding the request to a CA. If the Registar is 1327 communicating with the CA using a protocol like full CMC which 1328 provides mechanisms to override the CSR attributes, then these 1329 mechanisms MAY be used even if the client ignores CSR Attribute 1330 guidance. 1332 3.8.3. EST Client Certificate Request 1334 The Pledge MUST request a new client certificate. See RFC7030, 1335 section 4.2. 1337 3.8.4. Enrollment Status Telemetry 1339 For automated bootstrapping of devices the adminstrative elements 1340 providing bootstrapping also provide indications to the system 1341 administrators concerning device lifecycle status. This might 1342 include information concerning attempted bootstrapping messages seen 1343 by the client, MASA provides logs and status of credential 1344 enrollment. The EST protocol assumes an end user and therefore does 1345 not include a final success indication back to the server. This is 1346 insufficient for automated use cases. 1348 To indicate successful enrollment the client SHOULD re-negotiate the 1349 EST TLS session using the newly obtained credentials. This occurs by 1350 the client initiating a new TLS ClientHello message on the existing 1351 TLS connection. The client MAY simply close the old TLS session and 1352 start a new one. The server MUST support either model. 1354 In the case of a FAIL the Reason string indicates why the most recent 1355 enrollment failed. The SubjectKeyIdentifier field MUST be included 1356 if the enrollment attempt was for a keypair that is locally known to 1357 the client. If EST /serverkeygen was used and failed then the field 1358 is omitted from the status telemetry. 1360 In the case of a SUCCESS the Reason string is omitted. The 1361 SubjectKeyIdentifier is included so that the server can record the 1362 successful certificate distribution. 1364 Status media type: application/json 1365 The client HTTP POSTs the following to the server at the new EST well 1366 known URI /enrollstatus. 1368 { 1369 "version":"1", 1370 "Status":TRUE /* TRUE=Success, FALSE=Fail" 1371 "Reason":"Informative human readable message" 1372 "SubjectKeyIdentifier":"" 1374 } 1376 The server SHOULD respond with an HTTP 200 but MAY simply fail with 1377 an HTTP 404 error. 1379 Within the server logs the server MUST capture if this message was 1380 received over an TLS session with a matching client certificate. 1381 This allows for clients that wish to minimize their crypto operations 1382 to simply POST this response without renegotiating the TLS session - 1383 at the cost of the server not being able to accurately verify that 1384 enrollment was truly successful. 1386 3.8.5. EST over CoAP 1388 This document describes extensions to EST for the purposes of 1389 bootstrapping of remote key infrastructures. Bootstrapping is 1390 relevant for CoAP enrollment discussions as well. The defintion of 1391 EST and BRSKI over CoAP is not discussed within this document beyond 1392 ensuring proxy support for CoAP operations. Instead it is 1393 anticipated that a definition of CoAP mappings will occur in 1394 subsequent documents such as [I-D.vanderstok-ace-coap-est] and that 1395 CoAP mappings for BRSKI will be discussed either there or in future 1396 work. 1398 4. Reduced security operational modes 1400 A common requirement of bootstrapping is to support less secure 1401 operational modes for support specific use cases. The following 1402 sections detail specific ways that the Pledge, Registrar and MASA can 1403 be configured to run in a less secure mode for the indicated reasons. 1405 4.1. Trust Model 1406 +--------+ +---------+ +------------+ +------------+ 1407 | Pledge | | Circuit | | Domain | | Vendor | 1408 | | | Proxy | | Registrar | | Service | 1409 | | | | | | | (Internet | 1410 +--------+ +---------+ +------------+ +------------+ 1412 Figure 10 1414 Pledge: The Pledge could be compromised and providing an attack 1415 vector for malware. The entity is trusted to only imprint using 1416 secure methods described in this document. Additional endpoint 1417 assessment techniques are RECOMMENDED but are out-of-scope of this 1418 document. 1420 Proxy: Provides proxy functionalities but is not involved in 1421 security considerations. 1423 Registrar: When interacting with a MASA server a Registrar makes all 1424 decisions. When Ownership Vouchers are involved a Registrar is 1425 only a conduit and all security decisions are made on the vendor 1426 service. 1428 Vendor Service, MASA: This form of vendor service is trusted to 1429 accurately log all claim attempts and to provide authoritative log 1430 information to Registrars. The MASA does not know which devices 1431 are associated with which domains. These claims could be 1432 strengthened by using cryptographic log techniques to provide 1433 append only, cryptographic assured, publicly auditable logs. 1434 Current text provides only for a trusted vendor. 1436 Vendor Service, Ownership Validation: This form of vendor service is 1437 trusted to accurately know which device is owned by which domain. 1439 4.2. Pledge security reductions 1441 The Pledge can choose to accept vouchers using less secure methods. 1442 These methods enable offline and emergency (touch based) deployment 1443 use cases: 1445 1. The Pledge MUST accept nonceless vouchers. This allows for 1446 offline use cases. Logging and validity periods address the 1447 inherent security considerations of supporting these use cases. 1449 2. The Pledge MAY support "trust on first use" for physical 1450 interfaces such as a local console port or physical user 1451 interface but MUST NOT support "trust on first use" on network 1452 interfaces. This is because "trust on first use" permanently 1453 degrades the security for all use cases. 1455 3. The Pledge MAY have an operational mode where it skips Voucher 1456 validation one time. For example if a physical button is 1457 depressed during the bootstrapping operation. This can be useful 1458 if the vendor service is unavailable. This behavior SHOULD be 1459 available via local configuration or physical presence methods to 1460 ensure new entities can always be deployed even when autonomic 1461 methods fail. This allows for unsecured imprint. 1463 It is RECOMMENDED that "trust on first use" or skipping voucher 1464 validation only be available if hardware assisted Network Endpoint 1465 Assessment [RFC5209] is supported. This recommendation ensures that 1466 domain network monitoring can detect innappropriate use of offline or 1467 emergency deployment procedures. 1469 4.3. Registrar security reductions 1471 A Registrar can choose to accept devices using less secure methods. 1472 These methods are acceptable when low security models are needed, as 1473 the security decisions are being made by the local administrator, but 1474 they MUST NOT be the default behavior: 1476 1. A registrar MAY choose to accept all devices, or all devices of a 1477 particular type, at the administrator's discretion. This could 1478 occur when informing all Registrars of unique identifiers of new 1479 entities might be operationally difficult. 1481 2. A registrar MAY choose to accept devices that claim a unique 1482 identity without the benefit of authenticating that claimed 1483 identity. This could occur when the Pledge does not include an 1484 X.509 IDevID factory installed credential. New Entities without 1485 an X.509 IDevID credential MAY form the Section 3.2 request using 1486 the Section 3.3 format to ensure the Pledge's serial number 1487 information is provided to the Registar (this includes the IDevID 1488 AuthorityKeyIdentifier value which would be statically configured 1489 on the Pledge). The Pledge MAY refuse to provide a TLS client 1490 certificate (as one is not available). The Pledge SHOULD support 1491 HTTP-based or certificate-less TLS authentication as described in 1492 EST RFC7030 section 3.3.2. A Registrar MUST NOT accept 1493 unauthenticated New Entities unless it has been configured to do 1494 so by an administrator that has verified that only expected new 1495 entities can communicate with a Registrar (presumably via a 1496 physically secured perimeter). 1498 3. A Registrar MAY request nonce-less Vouchers from the MASA service 1499 (by not including a nonce in the request). These Vouchers can 1500 then be transmitted to the Registrar and stored until they are 1501 needed during bootstrapping operations. This is for use cases 1502 where target network is protected by an air gap and therefore can 1503 not contact the MASA service during Pledge deployment. 1505 4. A registrar MAY ignore unrecognized nonce-less log entries. This 1506 could occur when used equipment is purchased with a valid history 1507 being deployed in air gap networks that required permanent 1508 Vouchers. 1510 4.4. MASA security reductions 1512 Lower security modes chosen by the MASA service effect all device 1513 deployments unless bound to the specific device identities. In which 1514 case these modes can be provided as additional features for specific 1515 customers. The MASA service can choose to run in less secure modes 1516 by: 1518 1. Not enforcing that a nonce is in the Voucher. This results in 1519 distribution of Voucher that never expires and in effect makes 1520 the Domain an always trusted entity to the Pledge during any 1521 subsequent bootstrapping attempts. That this occurred is 1522 captured in the log information so that the Domain registrar can 1523 make appropriate security decisions when a Pledge joins the 1524 Domain. This is useful to support use cases where Registrars 1525 might not be online during actual device deployment. Because 1526 this results in long lived Voucher and does not require the proof 1527 that the device is online this is only accepted when the 1528 Registrar is authenticated by the MASA server and authorized to 1529 provide this functionality. The MASA server is RECOMMENDED to 1530 use this functionality only in concert with an enhanced level of 1531 ownership tracking (out-of-scope). If the Pledge device is known 1532 to have a real-time-clock that is set from the factory use of a 1533 voucher validity period is RECOMMENDED. 1535 2. Not verifying ownership before responding with an Voucher. This 1536 is expected to be a common operational model because doing so 1537 relieves the vendor providing MASA services from having to track 1538 ownership during shipping and supply chain and allows for a very 1539 low overhead MASA service. A Registrar uses the audit log 1540 information as a defense in depth strategy to ensure that this 1541 does not occur unexpectedly (for example when purchasing new 1542 equipment the Registrar would throw an error if any audit log 1543 information is reported). The MASA should verify the 'prior- 1544 signed-voucher' information for Pledge's that support that 1545 functionality. This provides a proof-of-proximity check that 1546 reduces the need for ownership verification. 1548 5. IANA Considerations 1550 5.1. PKIX Registry 1552 This document requests a number for id-mod-MASAURLExtn2016(TBD) from 1553 the pkix(7) id-mod(0) Registry. [[EDNOTE: fix names]] 1555 This document requests a number from the id-pe registry for id-pe- 1556 masa-url. XXX 1558 6. Security Considerations 1560 There are uses cases where the MASA could be unavailable or 1561 uncooperative to the Registrar. They include planned and unplanned 1562 network partitions, changes to MASA policy, or other instances where 1563 MASA policy rejects a claim. These introduce an operational risk to 1564 the Registrar owner that MASA/vendor behavior might limit the ability 1565 to re-boostrap a Pledge device. For example this might be an issue 1566 during disaster recovery. This risk can be mitigated by Registrars 1567 that request and maintain long term copies of "nonceless" Vouchers. 1568 In that way they are guaranteed to be able to repeat bootstrapping 1569 for their devices. 1571 The issuance of nonceless vouchers themselves create a security 1572 concern. If the Registrar of a previous domain can intercept 1573 protocol communications then it can use a previously issued nonceless 1574 voucher to establish management control of a pledge device even after 1575 having sold it. This risk is mitigated by recording the issuance of 1576 such vouchers in the MASA audit log that is verified by the 1577 subsequent Registrar. This reduces the resale value of the equipment 1578 because future owners will detect the lowered security inherent in 1579 the existence of a nonceless voucher that would be trusted by their 1580 Pledge. This reflects a balance between partition resistant recovery 1581 and security of future bootstrapping. Registrars take the Pledge's 1582 audit history into account when applying policy to new devices. 1584 The MASA server is exposed to DoS attacks wherein attackers claim an 1585 unbounded number of devices. Ensuring a Registrar is representative 1586 of a valid vendor customer, even without validating ownership of 1587 specific Pledge devices, helps to mitigate this. Pledge signatures 1588 on the initial voucher request, as forwarded by the Registrar in the 1589 prior-signed-voucher field, significantly reduce this risk by 1590 ensuring the MASA can confirm proximity between the Pledge and the 1591 Registrar making the request. This mechanism is optional to allow 1592 for constrained devices. 1594 It is possible for an attacker to request a voucher from the MASA 1595 service directly after the real Registrar obtains an audit log. If 1596 the attacker could also force the bootstrapping protocol to reset 1597 there is a theoretical opportunity for the attacker to use their 1598 voucher to take control of the Pledge but then proceed to enroll with 1599 the target domain. Possible prevention mechanisms include: 1601 o Per device rate limits on the MASA service ensure such timing 1602 attacks are difficult. 1604 o The Registrar can repeat the request for audit log information at 1605 some time after bootstrapping is complete. 1607 To facilitate logging and administrative oversight the Pledge reports 1608 on Voucher parsing status to the Registrar. In the case of a failure 1609 this information is informative to a potentially malicious Registar 1610 but this is RECOMMENDED anyway because of the operational benefits of 1611 an informed administrator in cases where the failure is indicative of 1612 a problem. 1614 To facilitate truely limited clients EST RFC7030 section 3.3.2 1615 requirements that the client MUST support a client authentication 1616 model have been reduced in Section 4 to a statement that the 1617 Registrar "MAY" choose to accept devices that fail cryptographic 1618 authentication. This reflects current (poor) practices in shipping 1619 devices without a cryptographic identity that are NOT RECOMMENDED. 1621 During the provisional period of the connection all HTTP header and 1622 content data MUST treated as untrusted data. HTTP libraries are 1623 regularly exposed to non-secured HTTP traffic: mature libraries 1624 should not have any problems. 1626 Pledge's might chose to engage in protocol operations with multiple 1627 discovered Registrars in parallel. As noted above they will only do 1628 so with distinct nonce values, but the end result could be multple 1629 voucher's issued from the MASA if all registrars attempt to claim the 1630 device. This is not a failure and the Pledge choses whichever 1631 voucher to accept based on internal logic. The Registrar's verifying 1632 log information will see multiple entries and take this into account 1633 for their analytics purposes. 1635 7. Acknowledgements 1637 We would like to thank the various reviewers for their input, in 1638 particular Brian Carpenter, Toerless Eckert, Fuyu Eleven, Eliot Lear, 1639 Sergey Kasatkin, Markus Stenberg, and Peter van der Stok 1641 8. References 1643 8.1. Normative References 1645 [I-D.ietf-anima-autonomic-control-plane] 1646 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 1647 Control Plane", draft-ietf-anima-autonomic-control- 1648 plane-06 (work in progress), March 2017. 1650 [I-D.ietf-anima-voucher] 1651 Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1652 "Voucher Profile for Bootstrapping Protocols", draft-ietf- 1653 anima-voucher-04 (work in progress), July 2017. 1655 [I-D.vanderstok-ace-coap-est] 1656 Kumar, S., Stok, P., Kampanakis, P., Furuhed, M., and S. 1657 Raza, "EST over secure CoAP (EST-coaps)", draft- 1658 vanderstok-ace-coap-est-02 (work in progress), June 2017. 1660 [IDevID] IEEE Standard, "IEEE 802.1AR Secure Device Identifier", 1661 December 2009, . 1664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1665 Requirement Levels", BCP 14, RFC 2119, 1666 DOI 10.17487/RFC2119, March 1997, 1667 . 1669 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 1670 "Advanced Sockets Application Program Interface (API) for 1671 IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003, 1672 . 1674 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1675 Levkowetz, Ed., "Extensible Authentication Protocol 1676 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1677 . 1679 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1680 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1681 DOI 10.17487/RFC3927, May 2005, 1682 . 1684 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1685 Address Autoconfiguration", RFC 4862, 1686 DOI 10.17487/RFC4862, September 2007, 1687 . 1689 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1690 (TLS) Protocol Version 1.2", RFC 5246, 1691 DOI 10.17487/RFC5246, August 2008, 1692 . 1694 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1695 Housley, R., and W. Polk, "Internet X.509 Public Key 1696 Infrastructure Certificate and Certificate Revocation List 1697 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1698 . 1700 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 1701 Security: An Unauthenticated Mode of IPsec", RFC 5386, 1702 DOI 10.17487/RFC5386, November 2008, 1703 . 1705 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1706 RFC 5652, DOI 10.17487/RFC5652, September 2009, 1707 . 1709 [RFC5660] Williams, N., "IPsec Channels: Connection Latching", 1710 RFC 5660, DOI 10.17487/RFC5660, October 2009, 1711 . 1713 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1714 DOI 10.17487/RFC6762, February 2013, 1715 . 1717 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 1718 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 1719 . 1721 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1722 "Enrollment over Secure Transport", RFC 7030, 1723 DOI 10.17487/RFC7030, October 2013, 1724 . 1726 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1727 Constrained-Node Networks", RFC 7228, 1728 DOI 10.17487/RFC7228, May 2014, 1729 . 1731 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1732 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1733 . 1735 8.2. Informative References 1737 [I-D.behringer-homenet-trust-bootstrap] 1738 Behringer, M., Pritikin, M., and S. Bjarnason, 1739 "Bootstrapping Trust on a Homenet", draft-behringer- 1740 homenet-trust-bootstrap-02 (work in progress), February 1741 2014. 1743 [I-D.ietf-anima-grasp] 1744 Bormann, C., Carpenter, B., and B. Liu, "A Generic 1745 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 1746 grasp-13 (work in progress), June 2017. 1748 [I-D.ietf-netconf-zerotouch] 1749 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 1750 Provisioning for NETCONF or RESTCONF based Management", 1751 draft-ietf-netconf-zerotouch-14 (work in progress), June 1752 2017. 1754 [I-D.lear-mud-framework] 1755 Lear, E., "Manufacturer Usage Description Framework", 1756 draft-lear-mud-framework-00 (work in progress), January 1757 2016. 1759 [I-D.richardson-anima-state-for-joinrouter] 1760 Richardson, M., "Considerations for stateful vs stateless 1761 join router in ANIMA bootstrap", draft-richardson-anima- 1762 state-for-joinrouter-01 (work in progress), July 2016. 1764 [imprinting] 1765 Wikipedia, "Wikipedia article: Imprinting", July 2015, 1766 . 1768 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1769 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 1770 December 1998, . 1772 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1773 Interface Identifiers with IPv6 Stateless Address 1774 Autoconfiguration (SLAAC)", RFC 7217, 1775 DOI 10.17487/RFC7217, April 2014, 1776 . 1778 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1779 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1780 December 2014, . 1782 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1783 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1784 Networking: Definitions and Design Goals", RFC 7575, 1785 DOI 10.17487/RFC7575, June 2015, 1786 . 1788 [Stajano99theresurrecting] 1789 Stajano, F. and R. Anderson, "The resurrecting duckling: 1790 security issues for ad-hoc wireless networks", 1999, 1791 . 1794 Appendix A. IPv4 operations 1796 A.1. IPv4 Link Local addresses 1798 Instead of an IPv6 link-local address, an IPv4 address may be 1799 generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local 1800 Addresses. 1802 In the case that an IPv4 Local-Local address is formed, then the 1803 bootstrap process would continue as in the IPv6 case by looking for a 1804 (circuit) proxy. 1806 A.2. Use of DHCPv4 1808 The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP 1809 provided parameters for the Domain Name System can be used to perform 1810 DNS operations if all local discovery attempts fail. 1812 Appendix B. mDNS / DNSSD proxy discovery options 1814 The Pledge MAY perform DNS-based Service Discovery [RFC6763] over 1815 Multicast DNS [RFC6762] searching for the service 1816 "_bootstrapks._tcp.local.". 1818 To prevent unaccceptable levels of network traffic the congestion 1819 avoidance mechanisms specified in [RFC6762] section 7 MUST be 1820 followed. The Pledge SHOULD listen for an unsolicited broadcast 1821 response as described in [RFC6762]. This allows devices to avoid 1822 announcing their presence via mDNS broadcasts and instead silently 1823 join a network by watching for periodic unsolicited broadcast 1824 responses. 1826 Performs DNS-based Service Discovery [RFC6763] over normal DNS 1827 operations. The service searched for is 1828 "_bootstrapks._tcp.example.com". In this case the domain 1829 "example.com" is discovered as described in [RFC6763] section 11. 1831 This method is only available if the host has received a useable IPv4 1832 address via DHCPv4 as suggested in Appendix A. 1834 If no local bootstrapks service is located using the GRASP 1835 mechanisms, or the above mentioned DNS-based Service Discovery 1836 methods the Pledge MAY contact a well known vendor provided 1837 bootstrapping server by performing a DNS lookup using a well known 1838 URI such as "bootstrapks.vendor-example.com". The details of the URI 1839 are vendor specific. Vendors that leverage this method on the Pledge 1840 are responsible for providing the bootstrapks service. 1842 The current DNS services returned during each query is maintained 1843 until bootstrapping is completed. If bootstrapping fails and the 1844 Pledge returns to the Discovery state it picks up where it left off 1845 and continues attempting bootstrapping. For example if the first 1846 Multicast DNS _bootstrapks._tcp.local response doesn't work then the 1847 second and third responses are tried. If these fail the Pledge moves 1848 on to normal DNS-based Service Discovery. 1850 Appendix C. IPIP Join Proxy mechanism 1852 The Circuit Proxy mechanism suffers from requiring a state on the 1853 Join Proxy for each connection that is relayed. The Circuit Proxy 1854 can be considered a kind of Algorithm Gateway [FIND-good-REF]. 1856 An alternative to proxying at the TCP layer is to selectively forward 1857 at the IP layer. This moves all per-connection to the Join 1858 Registrar. The IPIP tunnel statelessly forwards packets. This 1859 section provides some explanation of some of the details of the 1860 Registrar discovery procotol which are not important to Circuit 1861 Proxy, and some implementation advice. 1863 The IPIP tunnel is described in [RFC2473]. Each such tunnel is 1864 considered a unidirectional construct, but two tunnels may be 1865 associated to form a bidirectional mechanism. An IPIP tunnel is 1866 setup as follows. The outer addresses are an ACP address of the Join 1867 Proxy, and the ACP address of the Join Registrar. The inner 1868 addresses seen in the tunnel are the link-local addresses of the 1869 network on which the join activity is occuring. 1871 One way to look at this construct is to consider that the Registrar 1872 is extending attaching an interface to the network on which the Join 1873 Proxy is physically present. The Registrar then interacts as if it 1874 were present on that network using link-local (fe80::) addresses. 1875 The Join node is unaware that the traffic is being proxied through a 1876 tunnel, and does not need any special routing. 1878 There are a number of considerations with this mechanism which 1879 require cause some minor amounts of complexity. Note that due to the 1880 tunnels, the Registrar sees multiple connections to a fe80::/10 1881 network on not just physical interfaces, but on each of the virtual 1882 interfaces represending the tunnels. 1884 C.1. Multiple Join networks on the Join Proxy side 1886 The Join Proxy will in the general case be a routing device with 1887 multiple interfaces. Even a device as simple as a wifi access point 1888 may have wired, and multiple frequencies of wireless interfaces, 1889 potentially with multiple ESSIDs. 1891 Each of these interfaces on the Join Proxy may be seperate L3 routing 1892 domains, and therefore will have a unique set of link-local 1893 addresses. An IPIP packet being returned by the Registrar needs to 1894 be forwarded to the correct interface, so the Join Proxy needs an 1895 additional key to distinguish which network the packet should be 1896 returned to. 1898 The simplest way to get this additional key is to allocate an 1899 additional ACP address; one address for each network on which join 1900 traffic is occuring. The Join Proxy SHOULD do a GRASP M_NEG_SYN for 1901 each interface which they wish to relay traffic, as this allows the 1902 Registrar to do any static tunnel configuration that may be required. 1904 C.2. Automatic configuration of tunnels on Registrar 1906 The Join Proxy is expected to do a GRASP negotiation with the proxy 1907 for each Join Interface that it needs to relay traffic from. This is 1908 to permit Registrars to configure the appropriate virtual interfaces 1909 before join traffic arrives. 1911 A Registrar serving a large number of interfaces may not wish to 1912 allocate resources to every interface at all times, but can instead 1913 dynamically allocate interfaces. It can do this by monitoring IPIP 1914 traffic that arrives on it's ACP interface, and when packets arrive 1915 from new Join Proxys, it can dynamically configure virtual 1916 interfaces. 1918 A more sophisticated Registrar willing to modify the behaviour of 1919 it's TCP and UDP stack could note the IPIP traffic origination in the 1920 socket control block and make information available to the TCP layer 1921 (for HTTPS connections), or to the the application (for CoAP 1922 connections) via a proprietary extension to the socket API. 1924 C.3. Proxy Neighbor Discovery by Join Proxy 1926 The Join Proxy MUST answer neighbor discovery messages for the 1927 address given by the Registrar as being it's link-local address. The 1928 Join Proxy must also advertise this address as the address to which 1929 to connect to when advertising it's existence. 1931 This proxy neighbor discovery means that the pledge will create TCP 1932 and UDP connections to the correct Registrar address. This matters 1933 as the TCP and UDP pseudo-header checksum includes the destination 1934 address, and for the proxy to remain completely stateless, it must 1935 not be necessary for the checksum to be updated. 1937 C.4. Use of connected sockets; or IP_PKTINFO for CoAP on Registrar 1939 TCP connections on the registrar SHOULD properly capture the ifindex 1940 of the incoming connection into the socket structure. This is normal 1941 IPv6 socket API processing. The outgoing responses will go out on 1942 the same (virtual) interface by ifindex. 1944 When using UDP sockets with CoAP, the application will have to pay 1945 attention to the incoming ifindex on the socket. Access to this 1946 information is available using the IP_PKTINFO auxiliary extension 1947 which is a standard part of the IPv6 sockets API. 1949 A registrar application could, after receipt of an initial CoAP 1950 message from the Pledge, create a connected UDP socket (including the 1951 ifindex information). The kernel would then take care of accurate 1952 demultiplexing upon receive, and subsequent transmission to the 1953 correct interface. 1955 C.5. Use of socket extension rather than virtual interface 1957 Some operating systems on which a Registrar need be implemented may 1958 find need for a virtual interface per Join Proxy to be problematic. 1959 There are other mechanism which can make be done. 1961 If the IPIP decapsulator can mark the (SYN) packet inside the kernel 1962 with the address of the Join Proxy sending the traffic, then an 1963 interface per Join Proxy may not be needed. The outgoing path need 1964 just pay attention to this extra information and add an appropriate 1965 IPIP header on outgoing. A CoAP over UDP mechanism may need to 1966 expose this extra information to the application as the UDP sockets 1967 are often not connected, and the application will need to specify the 1968 outgoing path on each packet send. 1970 Such an additional socket mechanism has not been standardized. 1971 Terminating L2TP connections over IPsec transport mode suffers from 1972 the same challenges. 1974 Appendix D. To be deprecated: Consolidation remnants 1976 [[EDNOTE: As per working group feedback there were multiple instances 1977 where this document repeated itself. To address this we have moved 1978 all text to this appendix and restored only one copy of each 1979 normative discussion. The next pass will reduce and delete this 1980 appendix to '0'; although some may be maintained in a design 1981 considerations appendix.]] 1983 D.1. Functional Overview 1985 Entities behave in an autonomic fashion. They discover each other 1986 and autonomically bootstrap into a key infrastructure delineating the 1987 autonomic domain. See [RFC7575] for more information. 1989 This section details the state machine and operational flow for each 1990 of the main three entities. The pledge, the domain (primarily a 1991 Registrar) and the MASA service. 1993 A representative flow is shown in Figure 2: 1995 +--------+ +---------+ +------------+ +------------+ 1996 | Pledge | | Circuit | | Domain | | Vendor | 1997 | | | Proxy | | Registrar | | Service | 1998 | | | | | | | (Internet | 1999 +--------+ +---------+ +------------+ +------------+ 2000 | | | | 2001 |<-RFC3927 IPv4 adr | Appendix A | | 2002 or|<-RFC4862 IPv6 adr | | | 2003 | | | | 2004 |-------------------->| | | 2005 | optional: mDNS query| Appendix B | | 2006 | RFC6763/RFC6762 | | | 2007 | | | | 2008 |<--------------------| | | 2009 | GRASP M_FLOOD | | | 2010 | periodic broadcast| | | 2011 | | | | 2012 |<------------------->C<----------------->| | 2013 | TLS via the Circuit Proxy | | 2014 |<--Registrar TLS server authentication---| | 2015 [PROVISIONAL accept of server cert] | | 2016 P---X.509 client authentication---------->| | 2017 P | | | 2018 P---Request Voucher (include nonce)------>| | 2019 P | | | 2020 P | /---> | | 2021 P | | [accept device?] | 2022 P | | [contact Vendor] | 2023 P | | |--Pledge ID-------->| 2024 P | | |--Domain ID-------->| 2025 P | | |--optional:nonce--->| 2026 P | | | [extract DomainID] 2027 P | | | | 2028 P | optional: | [update audit log] 2029 P | |can | | 2030 P | |occur | | 2031 P | |in | | 2032 P | |advance | | 2033 P | | | | 2034 P | | |<-device audit log--| 2035 P | | |<- voucher ---------| 2036 P | \----> | | 2037 P | | | 2038 P | [verify audit log and voucher] | 2039 P | | | 2040 P<------voucher---------------------------| | 2041 [verify voucher ] | | | 2042 [verify provisional cert| | | 2043 | | | | 2044 |<--------------------------------------->| | 2045 | Continue with RFC7030 enrollment | | 2046 | using now bidirectionally authenticated | | 2047 | TLS session. | | | 2048 | | | | 2049 | | | | 2050 | | | | 2052 Figure 2 2054 [[UNRESOLVED:need to restore some functional overview section for all 2055 these diagrams]]In order to obtain a Voucher and associated logs a 2056 Registrar contacts the MASA service Service using REST calls: 2058 +-----------+ +----------+ +-----------+ +----------+ 2059 | New | | Circuit | | | | | 2060 | Entity | | Proxy | | Registrar | | Vendor | 2061 | | | | | | | | 2062 ++----------+ +--+-------+ +-----+-----+ +--------+-+ 2063 | | | | 2064 | | | | 2065 | TLS hello | TLS hello | | 2066 Establish +---------------C---------------> | 2067 TLS | | | | 2068 connection | | Server Cert | | 2069 <---------------C---------------+ | 2070 | Client Cert | | | 2071 +---------------C---------------> | 2072 | | | | 2073 HTTP REST | POST /requestvoucher | | 2074 Data +--------------------nonce------> | 2075 | . | /requestvoucher| 2076 | . +----------------> 2077 | <----------------+ 2078 | | /requestlog | 2079 | +----------------> 2080 | voucher <----------------+ 2081 <-------------------------------+ | 2082 | (optional config information) | | 2083 | . | | 2084 | . | | 2086 Figure 8 2088 In some use cases the Registrar may need to contact the Vendor in 2089 advanced, for example when the target network is air-gapped. The 2090 nonceless request format is provided for this and the resulting flow 2091 is slightly different. The security differences associated with not 2092 knowing the nonce are discussed below: 2094 +-----------+ +----------+ +-----------+ +----------+ 2095 | New | | Circuit | | | | | 2096 | Entity | | Proxy | | Registrar | | Vendor | 2097 | | | | | | | | 2098 ++----------+ +--+-------+ +-----+-----+ +--------+-+ 2099 | | | | 2100 | | | | 2101 | | | /requestvoucher| 2102 | | (nonce +----------------> 2103 | | unknown) <----------------+ 2104 | | | /requestlog | 2105 | | +----------------> 2106 | | <----------------+ 2107 | TLS hello | TLS hello | | 2108 Establish +---------------C---------------> | 2109 TLS | | | | 2110 connection | | Server Cert | | 2111 <---------------C---------------+ | 2112 | Client Cert | | | 2113 | | | | 2114 HTTP REST | POST /requestvoucher | | 2115 Data +----------------------nonce----> (discard | 2116 | voucher | nonce) | 2117 <-------------------------------+ | 2118 | (optional config information) | | 2119 | . | | 2120 | . | | 2122 Figure 9 2124 D.1.1. Behavior of a Pledge 2126 A pledge that has not yet been bootstrapped attempts to find a local 2127 domain and join it. A pledge [[RESOLVED:MUST NOT]] automatically 2128 initiate bootstrapping if it has already been configured or is in the 2129 process of being configured. 2131 States of a pledge are as follows: 2133 +--------------+ 2134 | Factory | 2135 | default | 2136 +------+-------+ 2137 | 2138 +------v-------+ 2139 | Discover | 2140 +------------> | 2141 | +------+-------+ 2142 | | 2143 | +------v-------+ 2144 | | Identity | 2145 ^------------+ | 2146 | rejected +------+-------+ 2147 | | 2148 | +------v-------+ 2149 | | Request | 2150 | | Join | 2151 | +------+-------+ 2152 | | 2153 | +------v-------+ 2154 | | Imprint | Optional 2155 ^------------+ <--+Manual input (Appendix C) 2156 | Bad Vendor +------+-------+ 2157 | response | 2158 | +------v-------+ 2159 | | Enroll | 2160 ^------------+ | 2161 | Enroll +------+-------+ 2162 | Failure | 2163 | +------v-------+ 2164 | | Enrolled | 2165 ^------------+ | 2166 Factory +--------------+ 2167 reset 2169 Figure 3 2171 State descriptions for the pledge are as follows: 2173 1. Discover a communication channel to a Registrar. 2175 2. Identify itself. This is done by presenting an X.509 IDevID 2176 credential to the discovered Registrar (via the Proxy) in a TLS 2177 handshake. (The Registrar credentials are only provisionally 2178 accepted at this time). 2180 3. Requests to Join the discovered Registrar. A unique nonce 2181 [[RESOLVED:can be]] included ensuring that any responses can be 2182 associated with this particular bootstrapping attempt. 2184 4. Imprint on the Registrar. This requires verification of the 2185 vendor service provided voucher. A voucher contains sufficient 2186 information for the Pledge to complete authentication of a 2187 Registrar. (It enables the Pledge to finish authentication of 2188 the Registrar TLS server certificate). 2190 5. Enroll. By accepting the domain specific information from a 2191 Registrar, and by obtaining a domain certificate from a Registrar 2192 using a standard enrollment protocol, e.g. Enrollment over 2193 Secure Transport (EST) [RFC7030]. 2195 6. The Pledge is now a member of, and can be managed by, the domain 2196 and will only repeat the discovery aspects of bootstrapping if it 2197 is returned to factory default settings. 2199 The following sections describe each of these steps in more detail. 2201 D.1.1.1. Discovery 2203 [[RESOLVED:TEXT moved up into above]] 2205 D.1.1.2. Identity 2207 The Pledge identifies itself during the communication protocol 2208 handshake. If the client identity is rejected (that is, the TLS 2209 handshake does not complete) the Pledge repeats the Identity process 2210 using the next proxy or discovery method available. 2212 [[RESOLVED: need normative statement in protocol section]] The 2213 bootstrapping protocol server is not initially authenticated. Thus 2214 the connection is provisional and all data received is untrusted 2215 until sufficiently validated even though it is over a TLS connection. 2216 This is aligned with the existing provisional mode of EST [RFC7030] 2217 during s4.1.1 "Bootstrap Distribution of CA Certificates". See 2218 Section 3.4 for more information about when the TLS connection 2219 authentication is completed. 2221 [[RESOLVED:]]All security associations established are between the 2222 new device and the Bootstrapping server regardless of proxy 2223 operations. 2225 D.1.1.2.1. Concurrent attempts to join 2227 [[RESOLVED: by dropping this text. the "priority mechanism" is 2228 unspecified thus any discussion is unclear. Not only that once an 2229 initial request is sent to the registrar the question of multiple 2230 MASA interactions has already occurred. Nothing breaks if 2231 implementations do this. I've added text to the security 2232 considerations indicating the end result (MASA entries that might be 2233 ignored by the device but which confuse the end administrator)]] The 2234 Pledge MAY attempt multiple mechanisms concurrently, but if it does 2235 so, it MUST wait in the provisional state until all mechanisms have 2236 either succeeded or failed, and then MUST proceed with the highest 2237 priority mechanism which has succeed. To proceed beyond this point, 2238 specifically, to provide a nonce, could result in the MASA 2239 gratuitously auditing a connection. 2241 D.1.1.3. Request Join 2243 The Pledge POSTs a request to join the domain to the Bootstrapping 2244 server. This request contains a Pledge generated nonce and informs 2245 the Bootstrapping server which imprint methods the Pledge will 2246 accept. 2248 The nonce ensures the Pledge can verify that responses are specific 2249 to this bootstrapping attempt. This minimizes the use of global time 2250 and provides a substantial benefit for devices without a valid clock. 2252 D.1.1.3.1. Redirects during the Join Process 2254 [[RESOVED via current root protocol discussion. reference to 2255 mdnsmethods is dropped]] EST [RFC7030] describes situations where the 2256 bootstrapping server MAY redirect the client to an alternate server 2257 via a 3xx status code. Such redirects MAY be accepted if the pledge 2258 has used the methods described in Appendix B, in combination with an 2259 implicit trust anchor. Redirects during the provisional period are 2260 otherwise unstrusted, and MUST cause a failure. 2262 D.1.1.4. Imprint 2264 The Pledge validates the voucher and accepts the Registrar ID. The 2265 provisional TLS connection is validated using the Registrar ID from 2266 the voucher. 2268 D.1.1.5. Lack of realtime clock APPENDIX 2270 [[RESOVED: entire section promoted back into the main text]] 2271 Many devices when bootstrapping do not have knowledge of the current 2272 time. Mechanisms like Network Time Protocols can not be secured 2273 until bootstrapping is complete. Therefore bootstrapping is defined 2274 in a method that does not require knowledge of the current time. 2276 Unfortunately there are moments during bootstrapping when 2277 certificates are verified, such as during the TLS handshake, where 2278 validity periods are confirmed. This paradoxical "catch-22" is 2279 resolved by the Pledge maintaining a concept of the current "window" 2280 of presumed time validity that is continually refined throughout the 2281 bootstrapping process as follows: 2283 o Initially the Pledge does not know the current time. 2285 o During Pledge authentiation by the Registrar a realtime clock can 2286 be used by the Registrar. This bullet expands on a closely 2287 related issue regarding Pledge lifetimes. RFC5280 indicates that 2288 long lived Pledge certifiates "SHOULD be assigned the 2289 GeneralizedTime value of 99991231235959Z" [RFC7030] so the 2290 Registrar MUST support such lifetimes and SHOULD support ignoring 2291 Pledge lifetimes if they did not follow the RFC5280 2292 recommendations. 2294 o The Pledge authenticates the voucher presented to it. During this 2295 authentication the Pledge ignores certificate lifetimes (by 2296 necessity because it does not have a clock). The voucher itself 2297 SHOULD contain the nonce included in the original request which 2298 proves the voucher is fresh. 2300 o Once the voucher is accepted the validity period of the 2301 domainCAcert in the voucher (see Section 3.4) now serves as a 2302 valid time window. Any subsequent certificate validity periods 2303 checked during RFC5280 path validation MUST occur within this 2304 window. 2306 o When accepting an enrollment certificate the validity period 2307 within the new certificate is assumed to be valid by the Pledge. 2308 The Pledge is now willing to use this credential for client 2309 authentication. 2311 D.1.1.6. Enrollment 2313 As the final step of bootstrapping a Registrar helps to issue a 2314 domain specific credential to the Pledge. For simplicity in this 2315 document, a Registrar primarily facilitates issuing a credential by 2316 acting as an RFC5280 Registration Authority for the Domain 2317 Certification Authority. 2319 Enrollment proceeds as described in [RFC7030]. Authentication of the 2320 EST server is done using the Voucher rather than the methods defined 2321 in EST. 2323 [[RESOLVED: moved to protocol discussion]]Once the Voucher is 2324 received, as specified in this document, the client has sufficient 2325 information to leverage the existing communication channel with a 2326 Registrar to continue an EST RFC7030 enrollment. Enrollment picks up 2327 at RFC7030 section 4.1.1. bootstrapping where the Voucher provides 2328 the "out-of-band" CA certificate fingerprint (in this case the full 2329 CA certificate) such that the client can now complete the TLS server 2330 authentication. At this point the client continues with EST 2331 enrollment operations including "CA Certificates Request", "CSR 2332 Attributes" and "Client Certificate Request" or "Server-Side Key 2333 Generation". 2335 [[RESOLVED: included into EST discussion]]For the purposes of 2336 creating the ANIMA Autonomic Control Plane, the contents of the new 2337 certificate MUST be carefully specified. 2338 [I-D.ietf-anima-autonomic-control-plane] section 5.1.1 contains 2339 details. The Registrar MUST provide the the correct ACP information 2340 to populate the subjectAltName / rfc822Name field in the "CSR 2341 Attributes" step. 2343 D.1.1.7. Being Managed 2345 [[RESOLVED: by slight change to introduction text.]] Functionality to 2346 provide generic "configuration" information is supported. The 2347 parsing of this data and any subsequent use of the data, for example 2348 communications with a Network Management System is out of scope but 2349 is expected to occur after bootstrapping enrollment is complete. 2350 This ensures that all communications with management systems which 2351 can divulge local security information (e.g. network topology or raw 2352 key material) is secured using the local credentials issued during 2353 enrollment. 2355 The Pledge uses bootstrapping to join only one domain. Management by 2356 multiple domains is out-of-scope of bootstrapping. After the device 2357 has successfully joined a domain and is being managed it is plausible 2358 that the domain can insert credentials for other domains depending on 2359 the device capabilities. 2361 See Appendix D.1.5. 2363 D.1.2. Behavior of a Join Proxy 2365 The role of the Proxy is to facilitate communications. The Proxy 2366 forwards packets between the Pledge and a Registrar that has been 2367 configured on the Proxy. 2369 [[UNRESOLVED: since proxy behavior is not visible we can limit 2370 ourselves to discussion of what the protocol does to enable/faciliate 2371 a theoretical proxy]]The Proxy does not terminate the TLS handshake. 2373 [[UNRESOLVED: this is an anima architecture requirement to use BRSKI? 2374 move to there?]] A Proxy is always assumed even if it is directly 2375 integrated into a Registrar. (In a completely autonomic network, the 2376 Registrar MUST provide proxy functionality so that it can be 2377 discovered, and the network can grow concentrically around the 2378 Registrar) 2380 As a result of the Proxy Discovery process in section 2381 Appendix D.1.1.1, the port number exposed by the proxy does not need 2382 to be well known, or require an IANA allocation. 2384 If the Proxy joins an Autonomic Control Plane 2385 ([I-D.ietf-anima-autonomic-control-plane]) it SHOULD use Autonomic 2386 Control Plane secured GRASP ([I-D.ietf-anima-grasp]) to discovery the 2387 Registrar address and port. As part of the discovery process, the 2388 proxy mechanism (Circuit Proxy vs IPIP encapsulation) is agreed to 2389 between the Registrar and Join Proxy. 2391 For the IPIP encapsulation methods, the port announced by the Proxy 2392 MUST be the same as on the registrar in order for the proxy to remain 2393 stateless. 2395 In order to permit the proxy functionality to be implemented on the 2396 maximum variety of devices the chosen mechanism SHOULD use the 2397 minimum amount of state on the proxy device. While many devices in 2398 the ANIMA target space will be rather large routers, the proxy 2399 function is likely to be implemented in the control plane CPU of such 2400 a device, with available capabilities for the proxy function similar 2401 to many class 2 IoT devices. 2403 The document [I-D.richardson-anima-state-for-joinrouter] provides a 2404 more extensive analysis of the alternative proxy methods. 2406 D.1.2.1. CoAP connection to Registrar 2408 [[RESOLVED:this section thus removed]]The CoAP mechanism was 2409 depreciated. 2411 D.1.2.2. HTTPS proxy connection to Registrar 2413 The proxy SHOULD also provide one of: an IPIP encapsulation of HTTP 2414 traffic on TCP port TBD to the registrar, or a TCP circuit proxy that 2415 connects the Pledge to a Registrar. 2417 When the Proxy provides a circuit proxy to a Registrar the Registrar 2418 MUST accept HTTPS connections. 2420 When the Proxy provides a stateless IPIP encapsulation to a 2421 Registrar, then the Registrar will have to perform IPIP 2422 decapsulation, remembering the originating outer IPIP source address 2423 in order to qualify the inner link-local address. This is a kind of 2424 encapsulation and processing which is similar in many ways to how 2425 mobile IP works. 2427 Being able to connect a TCP (HTTP) or UDP (CoAP) socket to a link- 2428 local address with an encapsulated IPIP header requires API 2429 extensions beyond [RFC3542] for UDP use, and requires a form of 2430 connection latching (see section 4.1 of [RFC5386] and all of 2431 [RFC5660], except that a simple IPIP tunnel is used rather than an 2432 IPsec tunnel). 2434 D.1.3. Behavior of the Registrar 2436 A Registrar listens for Pledges and determines if they can join the 2437 domain. A Registrar obtains a Voucher from the MASA service and 2438 delivers them to the Pledge as well as facilitating enrollment with 2439 the domain PKI. 2441 [[RESOLVED: moved to discovery discussion]] A Registrar is typically 2442 configured manually. When the Registrar joins an Autonomic Control 2443 Plane ([I-D.ietf-anima-autonomic-control-plane]) it MUST respond to 2444 GRASP ([I-D.ietf-anima-grasp]) M_DISCOVERY message. See 2445 Section 3.1.2 2447 Registrar behavior is as follows: 2449 Contacted by Pledge 2450 + 2451 | 2452 +-------v----------+ 2453 | Entity | fail? 2454 | Authentication +---------+ 2455 +-------+----------+ | 2456 | | 2457 +-------v----------+ | 2458 | Entity | fail? | 2459 | Authorization +---------> 2460 +-------+----------+ | 2461 | | 2462 +-------v----------+ | 2463 | Claiming the | fail? | 2464 | Entity +---------> 2465 +-------+----------+ | 2466 | | 2467 +-------v----------+ | 2468 | Log Verification | fail? | 2469 | +---------> 2470 +-------+----------+ | 2471 | | 2472 +-------v----------+ +----v-------+ 2473 | Forward | | | 2474 | Voucher | | Reject | 2475 | to the Pledge | | Device | 2476 | | | | 2477 +------------------+ +------------+ 2479 Figure 4 2481 D.1.3.1. Pledge Authentication 2483 The applicable authentication methods detailed in EST [RFC7030] are: 2485 o [[RESOLVED:pointed out in protocol details]]the use of an X.509 2486 IDevID credential during the TLS client authentication, 2488 o or the use of a secret that is transmitted out of band between the 2489 Pledge and a Registrar (this use case is not autonomic). 2491 In order to validate the X.509 IDevID credential a Registrar 2492 maintains a database of vendor trust anchors (e.g. vendor root 2493 certificates or keyIdentifiers for vendor root public keys). For 2494 user interface purposes this database can be mapped to colloquial 2495 vendor names. Registrars can be shipped with the trust anchors of a 2496 significant number of third-party vendors within the target market. 2498 D.1.3.2. Pledge Authorization 2500 [[UNRESOLVED: this is referenced above as how the MASA does 2501 authorization. That is incorrect]] 2503 In a fully automated network all devices must be securely identified 2504 and authorized to join the domain. 2506 A Registrar accepts or declines a request to join the domain, based 2507 on the authenticated identity presented. Automated acceptance 2508 criteria include: 2510 o allow any device of a specific type (as determined by the X.509 2511 IDevID), 2513 o allow any device from a specific vendor (as determined by the 2514 X.509 IDevID), 2516 o allow a specific device from a vendor (as determined by the X.509 2517 IDevID) against a domain white list. (The mechanism for checking 2518 a shared white list potentially used by multiple Registrars is out 2519 of scope). 2521 [[RESOLVED: this looks like good text to include in above]]To look 2522 the Pledge up in a domain white list a consistent method for 2523 extracting device identity from the X.509 certificate is required. 2524 RFC6125 describes Domain-Based Application Service identity but here 2525 we require Vendor Device-Based identity. The subject field's DN 2526 encoding MUST include the "serialNumber" attribute with the device's 2527 unique serial number. In the language of RFC6125 this provides for a 2528 SERIALNUM-ID category of identifier that can be included in a 2529 certificate and therefore that can also be used for matching 2530 purposes. The SERIALNUM-ID whitelist is collated according to vendor 2531 trust anchor since serial numbers are not globally unique. 2533 [[RESOLVED: into log request]]The Registrar MUST use the vendor 2534 provided MASA service to verify that the device's history log does 2535 not include unexpected Registrars. If a device had previously 2536 registered with another domain, a Registrar of that domain would show 2537 in the log. 2539 [[RESOLVED: est integration section used 'SHOULD']]The authorization 2540 performed during BRSKI MAY be used for EST enrollment requests by 2541 proceeding with EST enrollment using the authenticated and authorized 2542 TLS connection. This minimizes the number of cryptographic and 2543 protocol operations necessary to complete bootstrapping of the local 2544 key infrastructure. 2546 D.1.3.3. Claiming the Pledge 2548 Claiming an pledge establishes an audit log at the MASA server and 2549 provides a Registrar with proof, in the form of the Voucher, that the 2550 log entry has been inserted. As indicated in Appendix D.1.1.4 a 2551 Pledge will only proceed with bootstrapping if a Voucher has been 2552 received. The Pledge therefore enforces that bootstrapping only 2553 occurs if the claim has been logged. There is no requirement for the 2554 vendor to definitively know that the device is owned by the 2555 Registrar. 2557 The Registrar obtains the MASA URI via static configuration or by 2558 extracting it from the X.509 IDevID credential. See Section 2.2. 2560 During initial bootstrapping the Pledge provides a nonce specific to 2561 the particular bootstrapping attempt. [[RESOLVED: to resolve this I 2562 updated many points where vouchers are referenced]]The Registrar 2563 SHOULD include this nonce when claiming the Pledge from the MASA 2564 service. Claims from an unauthenticated Registrar are only serviced 2565 by the MASA resource if a nonce is provided. 2567 The Registrar can claim a Pledge that is offline by forming the 2568 request using the entities unique identifier and not including a 2569 nonce in the claim request. Vouchers obtained in this way do not 2570 have a lifetime and they provide a permanent method for the domain to 2571 claim the device. Evidence of such a claim is provided in the audit 2572 log entries available to any future Registrar. Such claims reduce 2573 the ability for future domains to secure bootstrapping and therefore 2574 the Registrar MUST be authenticated by the MASA service although no 2575 requirement is implied that the MASA associates this authentication 2576 with ownership. 2578 An Ownership Voucher requires the vendor to definitively know that a 2579 device is owned by a specific domain. The method used to "claim" 2580 this are out-of-scope. A MASA ignores or reports failures when an 2581 attempt is made to claim a device that has a an Ownership Voucher. 2583 D.1.3.4. Log Verification 2585 A Registrar requests the log information for the Pledge from the MASA 2586 service. The log is verified to confirm that the following is true 2587 to the satisfaction of a Registrar's configured policy: 2589 o Any nonceless entries in the log are associated with domainIDs 2590 recognized by the registrar. 2592 o Any nonce'd entries are older than when the domain is known to 2593 have physical possession of the Pledge or that the domainIDs are 2594 recognized by the registrar. 2596 If any of these criteria are unacceptable to a Registrar the entity 2597 is rejected. [[RESOLVED: moved to main body]] A Registrar MAY be 2598 configured to ignore the history of the device but it is RECOMMENDED 2599 that this only be configured if hardware assisted NEA [RFC5209] is 2600 supported. 2602 [[RESOLVED: added to main text]]This document specifies a simple log 2603 format as provided by the MASA service to the registar. This format 2604 could be improved by distributed consensus technologies that 2605 integrate vouchers with a technologies such as block-chain or hash 2606 trees or the like. Doing so is out of the scope of this document but 2607 are anticipated improvements for future work. 2609 D.1.4. Behavior of the MASA Service 2611 [[UNRESOLVED: primary value of keeping this discussion is to 2612 distinguish between registrar and masa particularly wrt to the 2613 protocol functions provided. perhaps add statements in each protocol 2614 entry "provided by masa" etc?]] 2616 The Manufacturer Authorized Signing Authority service is directly 2617 provided by the manufacturer, or can be provided by a third party the 2618 manufacturer authorizes. It is a cloud resource. The MASA service 2619 provides the following functionalities to Registrars: 2621 Issue Vouchers: In response to Registrar requests the MASA service 2622 issues vouchers. Depending on the MASA policy the Registrar claim 2623 of device ownership is either accepted or verified using out-of- 2624 scope methods (that are expected to improve over time). 2626 Log Vouchers Issued: When a voucher is issued the act of issuing it 2627 includes updating the certifiable logs. Future work to enhance 2628 and distribute these logs is out-of-scope but expected over time. 2630 Provide Logs: As a baseline implementation of the certified logging 2631 mechanism the MASA is repsonsible for reporting logged 2632 information. The current method involves trusting the MASA. 2633 Other logging methods where the MASA is less trusted are expected 2634 to be developed over time. 2636 D.1.5. Leveraging the new key infrastructure / next steps 2638 As the devices have a common trust anchor, device identity can be 2639 securely established, making it possible to automatically deploy 2640 services across the domain in a secure manner. 2642 Examples of services: 2644 o Device management. 2646 o Routing authentication. 2648 o Service discovery. 2650 D.1.5.1. Network boundaries 2652 When a device has joined the domain, it can validate the domain 2653 membership of other devices. This makes it possible to create trust 2654 boundaries where domain members have higher level of trusted than 2655 external devices. Using the autonomic User Interface, specific 2656 devices can be grouped into to sub domains and specific trust levels 2657 can be implemented between those. 2659 D.1.6. Interactions with Network Access Control 2661 [[RESOLVED: via paragraph in 'scope of solution' discussion.]] 2663 The assumption is that Network Access Control (NAC) completes using 2664 the Pledge 's X.509 IDevID credentials and results in the device 2665 having sufficient connectivity to discovery and communicate with the 2666 proxy. Any additional connectivity or quarantine behavior by the NAC 2667 infrastructure is out-of-scope. After the devices has completed 2668 bootstrapping the mechanism to trigger NAC to re-authenticate the 2669 device and provide updated network privileges is also out-of-scope. 2671 This achieves the goal of a bootstrap architecture that can integrate 2672 with NAC but does not require NAC within the network where it wasn't 2673 previously required. Future optimizations can be achieved by 2674 integrating the bootstrapping protocol directly into an initial EAP 2675 exchange. 2677 D.2. Domain Operator Activities 2679 This section describes how an operator interacts with a domain that 2680 supports the bootstrapping as described in this document. 2682 D.2.1. Instantiating the Domain Certification Authority 2684 This is a one time step by the domain administrator. This is an "off 2685 the shelf" CA with the exception that it is designed to work as an 2686 integrated part of the security solution. This precludes the use of 2687 3rd party certification authority services that do not provide 2688 support for delegation of certificate issuance decisions to a domain 2689 managed Registration Authority. 2691 D.2.2. Instantiating the Registrar 2693 This is a one time step by the domain administrator. One or more 2694 devices in the domain are configured take on a Registrar function. 2696 A device can be configured to act as a Registrar or a device can 2697 auto-select itself to take on this function, using a detection 2698 mechanism to resolve potential conflicts and setup communication with 2699 the Domain Certification Authority. Automated Registrar selection is 2700 outside scope for this document. 2702 D.2.3. Accepting New Entities 2704 For each Pledge the Registrar is informed of the unique identifier 2705 (e.g. serial number) along with the manufacturer's identifying 2706 information (e.g. manufacturer root certificate). This can happen in 2707 different ways: 2709 1. Default acceptance: In the simplest case, the new device asserts 2710 its unique identity to a Registrar. The registrar accepts all 2711 devices without authorization checks. This mode does not provide 2712 security against intruders and is not recommended. 2714 2. Per device acceptance: The new device asserts its unique identity 2715 to a Registrar. A non-technical human validates the identity, 2716 for example by comparing the identity displayed by the registrar 2717 (for example using a smartphone app) with the identity shown on 2718 the packaging of the device. Acceptance may be triggered by a 2719 click on a smartphone app "accept this device", or by other forms 2720 of pairing. See also [I-D.behringer-homenet-trust-bootstrap] for 2721 how the approach could work in a homenet. 2723 3. Whitelist acceptance: In larger networks, neither of the previous 2724 approaches is acceptable. Default acceptance is not secure, and 2725 a manual per device methods do not scale. Here, the registrar is 2726 provided a priori with a list of identifiers of devices that 2727 belong to the network. This list can be extracted from an 2728 inventory database, or sales records. If a device is detected 2729 that is not on the list of known devices, it can still be 2730 manually accepted using the per device acceptance methods. 2732 4. Automated Whitelist: an automated process that builds the 2733 necessary whitelists and inserts them into the larger network 2734 domain infrastructure is plausible. Once set up, no human 2735 intervention is required in this process. Defining the exact 2736 mechanisms for this is out of scope although the registrar 2737 authorization checks is identified as the logical integration 2738 point of any future work in this area. 2740 None of these approaches require the network to have permanent 2741 Internet connectivity. Even when the Internet based MASA service is 2742 used, it is possible to pre-fetch the required information from the 2743 MASA a priori, for example at time of purchase such that devices can 2744 enroll later. This supports use cases where the domain network may 2745 be entirely isolated during device deployment. 2747 Additional policy can be stored for future authorization decisions. 2748 For example an expected deployment time window or that a certain 2749 Proxy must be used. 2751 D.2.4. Automatic Enrollment of Devices 2753 The approach outlined in this document provides a secure zero-touch 2754 method to enroll new devices without any pre-staged configuration. 2755 New devices communicate with already enrolled devices of the domain, 2756 which proxy between the new device and a Registrar. As a result of 2757 this completely automatic operation, all devices obtain a domain 2758 based certificate. 2760 D.2.5. Secure Network Operations 2762 The certificate installed in the previous step can be used for all 2763 subsequent operations. For example, to determine the boundaries of 2764 the domain: If a neighbor has a certificate from the same trust 2765 anchor it can be assumed "inside" the same organization; if not, as 2766 outside. See also Appendix D.1.5.1. The certificate can also be 2767 used to securely establish a connection between devices and central 2768 control functions. Also autonomic transactions can use the domain 2769 certificates to authenticate and/or encrypt direct interactions 2770 between devices. The usage of the domain certificates is outside 2771 scope for this document. 2773 Authors' Addresses 2775 Max Pritikin 2776 Cisco 2778 Email: pritikin@cisco.com 2780 Michael C. Richardson 2781 Sandelman Software Works 2783 Email: mcr+ietf@sandelman.ca 2784 URI: http://www.sandelman.ca/ 2786 Michael H. Behringer 2787 Cisco 2789 Email: mbehring@cisco.com 2791 Steinthor Bjarnason 2792 Cisco 2794 Email: sbjarnas@cisco.com 2796 Kent Watsen 2797 Juniper Networks 2799 Email: kwatsen@juniper.net