idnits 2.17.1 draft-pritikin-anima-bootstrapping-keyinfra-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2015) is 3353 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5191' is mentioned on line 482, but not defined == Missing Reference: 'RFC2461' is mentioned on line 484, but not defined ** Obsolete undefined reference: RFC 2461 (Obsoleted by RFC 4861) == Missing Reference: 'RFC4861' is mentioned on line 484, but not defined == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-05 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG M. Pritikin 3 Internet-Draft M. Behringer 4 Intended status: Informational S. Bjarnason 5 Expires: August 17, 2015 Cisco 6 February 13, 2015 8 Bootstrapping Key Infrastructures 9 draft-pritikin-anima-bootstrapping-keyinfra-01 11 Abstract 13 This document specifies automated bootstrapping of an key 14 infrastructure using vendor installed IEEE 802.1AR manufacturing 15 installed certificates, in combination with a vendor based service on 16 the Internet. Before being authenticated, a new device has only 17 link-local connectivity, and does not require a routable address. 18 When a vendor provides an Internet based service, devices can be 19 forced to join only specific domains but for constrained environments 20 we describe a variety of options that allow bootstrapping to proceed. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 17, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 4 59 3. Operational Overview . . . . . . . . . . . . . . . . . . . . 7 60 3.1. Instantiating the Domain Certification Authority . . . . 7 61 3.2. Instantiating the Registrar . . . . . . . . . . . . . . . 7 62 3.3. Accepting New Entities . . . . . . . . . . . . . . . . . 8 63 3.4. Automatic Enrolment of Devices . . . . . . . . . . . . . 9 64 3.5. Operating the Network . . . . . . . . . . . . . . . . . . 9 65 4. Functional Overview . . . . . . . . . . . . . . . . . . . . . 9 66 4.1. Behavior of a new entity . . . . . . . . . . . . . . . . 10 67 4.1.1. Proxy Discovery . . . . . . . . . . . . . . . . . . . 11 68 4.1.2. Receiving and accepting the Domain Identity . . . . . 12 69 4.1.3. Enrollment . . . . . . . . . . . . . . . . . . . . . 13 70 4.1.4. After Enrollment . . . . . . . . . . . . . . . . . . 13 71 4.2. Behavior of a proxy . . . . . . . . . . . . . . . . . . . 13 72 4.3. Behavior of the Registrar . . . . . . . . . . . . . . . . 14 73 4.3.1. Authenticating the Device . . . . . . . . . . . . . . 14 74 4.3.2. Accepting the Entity . . . . . . . . . . . . . . . . 14 75 4.3.3. Claiming the new entity . . . . . . . . . . . . . . . 15 76 4.4. Behavior of the MASA Service . . . . . . . . . . . . . . 15 77 4.4.1. Issue Authorization Token and Log the event . . . . . 16 78 4.4.2. Retrieve Audit Entries from Log . . . . . . . . . . . 16 79 4.5. Leveraging the new key infrastructure / next steps . . . 16 80 4.5.1. Network boundaries . . . . . . . . . . . . . . . . . 16 81 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 17 82 5.1. EAP-EST . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 5.2. Request bootstrap token . . . . . . . . . . . . . . . . . 18 84 5.3. Request MASA authorization token . . . . . . . . . . . . 18 85 5.4. Request MASA authorization log . . . . . . . . . . . . . 19 86 6. Reduced security operational modes . . . . . . . . . . . . . 20 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 22 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 90 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 92 9.2. Informative References . . . . . . . . . . . . . . . . . 22 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 95 1. Introduction 97 To literally "pull yourself up by the bootstraps" is an impossible 98 action. Similarly the secure establishment of a key infrastructure 99 without external help is also an impossibility. Today it is accepted 100 that the initial connections between nodes are insecure, until key 101 distribution is complete, or that domain-specific keying material is 102 pre-provisioned on each new device in a costly and non-scalable 103 manner. This document describes a zero-touch approach to 104 bootstrapping an entity by securing the initial distribution of key 105 material using third-party generic keying material, such as a 106 manufacturer installed IEEE 802.1AR certificate [IDevID], and a 107 corresponding third-party service on the Internet. 109 The two sides of an association being bootstrapped authenticate each 110 other and then determine appropriate authorization. This process is 111 described as four distinct steps between the existing domain and the 112 new entity being added: 114 o New entity authentication: "Who is this? What is its identity?" 116 o New entity authorization: "Is it mine? Do I want it? What are 117 the chances it has been compromised?" 119 o Domain authentication: "What is this domain's claimed identity?" 121 o Domain authorization: "Should I join it?" 123 A precise answer to these questions can not be obtained without 124 leveraging an established key infrastructure(s). The domain's 125 decisions are based on the new entity's authenticated identity, as 126 established by verification of previously installed credentials such 127 as a manufacturer installed IEEE 802.1AR certificate, and verified 128 back-end information such as a configured list of purchased devices 129 or communication with a trusted third-party. The new entity's 130 decisions are made according to verified communication with a trusted 131 third-party or in a strictly auditable fasion. 133 Optimal security is achieved with IEEE 802.1AR certificates on each 134 new entity, accompanied by a third-party Internet based service for 135 verification. The concept also works with less requirements, but is 136 then less secure. A domain can choose to accept lower levels of 137 security when a trusted third-party is not available so that 138 bootstrapping proceeds even at the risk of reduced security. Only 139 the domain can make these decisions based on administrative input and 140 known behavior of the new entity. 142 The result of bootstrapping is that a domain specific key 143 infrastructure is deployed. Since IEEE 802.1AR PKI certificates are 144 used for identifying the new entity and the public key of the domain 145 identity is leveraged during communiciations with an Internet based 146 service, which is itself authenticated using HTTPS, bootstrapping of 147 a domain specific Public Key Infrastructure (PKI) is fully described. 148 Sufficient agility to support bootstrapping alternative key 149 infrastructures (such as symmetric key solutions) is considered 150 although no such key infrastructure is described. 152 1.1. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in 157 [RFC2119]. 159 The following terms are defined for clarity: 161 2. Architectural Overview 163 The logical elements of the bootstrapping framework are described in 164 this section. Figure 1 provides a simplified overview of the 165 components. Each component is logical and may be combined with other 166 components as necessary. 168 Factory components 169 . 170 . +------------+ 171 . | Factory CA | 172 . +------------+ 173 . | 174 . +------------+ 175 . | | 176 +--------------(provides)---------------------------| Factory | 177 | +---------->| | 178 | | . +------------+ 179 | V . 180 | +---------------+ . +------------+ 181 | | Orchestrator | . | MASA | 182 V +---------------+ . | Service | 183 +-------+ | . | | 184 | New | +------------+ +-----------+ . +------------+ 185 | Entity|<--L2-->| Proxy |<----->| | ....... ^ 186 | | +------------+ | | | 187 | | | Registrar | | 188 | | | | | 189 | |<--DHCP-->(L3 bootstrap) | | | 190 | | | | | 191 | |<-----L3---------------------( registrar )-----------+ 192 | | ( may proxy ) | 193 +-------+ +-----------+ 194 | 195 +----------------------------+ 196 ^ | Domain Certification | ^ 197 . | Authority | . 198 . +----------------------------+ . 199 . . 200 ......................................... 201 | 202 "domain" components 204 Figure 1 206 Domain: The set of entities that trust a common key infrastructure 207 trust anchor. 209 Domain CA: The domain Certification Authority (CA) provides 210 certification functionalities to the domain. At a minimum it 211 provides certification functionalities to the Registrar and stores 212 the trust anchor that defines the domain. Optionally, it 213 certifies all elements. 215 Domain Identity: The domain identity is the 160-bit SHA-1 hash of 216 the BIT STRING of the subjectPublicKey of the domain trust anchor 217 that is stored by the Domain CA. This is consistent with the 218 RFC5280 Certification Authority subject key identifier of the 219 Domain CA's self signed root certificate. (A string value bound 220 to the Domain CA's self signed root certificate subject and issuer 221 fields is often colloquially used as a humanized identity value 222 but during protocol discussions the more exact term as defined 223 here is used). 225 Orchestrator: Although bootstrapping of an individual device is 226 automated and requires zero administrative involvement 227 (particularly on the New Entity) the orchestrator drives general 228 operations of the domain. This can be an automated process or a 229 human administrator, see Section 3.3 for more details. 231 Factory: This instantiates the New Entity. For physical devices 232 this can be representative of third-party vendor manufacturing, 233 ordering and shipping process(es) that results in a physical 234 hardware device with an IEEE 802.1AR identity being drop shipped 235 to a destination domain for physical installation. In a virtual 236 machine environment this can be the virtual machine hypervisor 237 control software that initiates a virtual machine instance, in 238 which case the factory is a "virtual factory" and might be managed 239 by the domain itself. 241 Factory CA: This Certification Authority is leveraged by the Factory 242 to issue IEEE 802.1AR identities to each New Entity. For a 243 virtual factory it may be reasonable to assume the domain 244 certification authority is directly used but in a complex 245 environment it is assumed the Factory does not have direct access 246 to the Domain Certification Authority. 248 Registrar: A representative of the domain that is configured, 249 perhaps autonomically, to decide whether a new device is allowed 250 to join the domain. The administrator of the domain interfaces 251 with a Registrar to control this process. Typically a Registrar 252 is "inside" its domain. 254 New Entity: A new device or virtual machine or software component 255 that is not yet part of the domain. 257 Proxy: A domain entity that helps the New Entity join the domain. A 258 Proxy facilitates communication for devices that find themselves 259 in an environment where they are not provided L3 connectivity 260 until after they are validated as members of the domain. 262 MASA Service: A Manufacturer Authorized Signing Authority (MASA) 263 service on the global Internet. At a minimum the MASA provides a 264 trusted repository for audit information concerning privacy 265 protected bootstrapping events. As a service offering the MASA 266 can incorporate many of the bootstrapping elements (such as the 267 Registrar and the Domain CA) into the overall service. The MASA 268 is not a mandatory component, but it enables the new device to 269 validate which domain it is joining. This allows for a completely 270 secure zero-touch bootstrap of domain certificates with mutual 271 authentication (device <-> domain). 273 We assume a multi-vendor network. In such an environment, there 274 could a MASA for each vendor that supports devices following this 275 document's specification, or an integrator could provide a MASA 276 service for all devices which he supplies. Note again that the MASA 277 is not mandatory. Also, this approach describes a secure zero-touch 278 approach to bootstrapping a key infrastructure; if certain devices in 279 a network do not support this approach, they can still be 280 bootstrapped manually. 282 3. Operational Overview 284 This section describes how an operator interacts with a domain that 285 supports the bootstrapping as described in this document. 287 3.1. Instantiating the Domain Certification Authority 289 This is a one time step by the domain administrator. This is an "off 290 the shelf" CA with the exception that it is designed to work as an 291 integrated part of the security solution. This precludes the use of 292 3rd party certification authority services that do not provide 293 support for delegation of certificate issuance decisions to a domain 294 managed Registration Authority. 296 3.2. Instantiating the Registrar 298 This is a one time step by the domain administrator. One or more 299 devices in the domain are configured take on a Registrar function. 301 A device can be configured to act as a Registrar or a device can 302 auto-select itself to take on this function, using a detection 303 mechanism to resolve potential conflicts and setup communication with 304 the Domain Certification Authority. Automated Registrar selection is 305 outside scope for this document. 307 3.3. Accepting New Entities 309 For each New Entity the Registrar is informed the unique identifier 310 (e.g. serial number) along with the manufacturer's identifying 311 information (e.g. manufacturer root certificate). This can happen in 312 different ways: 314 1. Default acceptance: In the simplest case, the new device itself 315 provides its identity to the registrar, which then accepts any 316 device blindly, without validating its identity. This mode does 317 not provide any security against intruders and is not 318 recommended. 320 2. Per device acceptance: Also here the device provides its identity 321 directly to the registrar during enrollment. A non-technical 322 human validates the identity, for example by comparing the 323 identity displayed by the registrar (for example using a 324 smartphone app) with the identity shown on the packaging of the 325 device. Acceptance may be triggered by a click on a smartphone 326 app "accept this device", or by other forms of pairing. See also 327 [I-D.behringer-homenet-trust-bootstrap] for how the approach 328 could work in a homenet. 330 3. Whitelist approach: In larger networks, neither of the previous 331 approaches is acceptable. Default acceptance is not secure, and 332 a manual real-time acceptance per device does not scale. Here, 333 the registrar is provided a priori with a list of identifiers of 334 devices that belong to the network. This list can be for example 335 extracted from an inventory database, or sales records. If a 336 device is detected that is not on the list of known devices, it 337 can still be manually accepted or declined. 339 4. Automated Orchestrator: an automated process that queries the 340 MASA service or an inventory database either a priori for all 341 devices, or in real time for each new device. It feeds this 342 information into the Registrar. Once set up, no human 343 intervention is required in this process. 345 None of the approaches requires the network to have permanent 346 Internet connectivity. Even when the Internet based MASA service is 347 used, it is possible to pre-fetch the required information from the 348 MASA a priori, for example at time of purchase. In this case devices 349 can enrol later even in a completely isolated network. 351 Additional policy can be stored for future authorization decisions. 352 For example an expected deployment time window or that a certain 353 Proxy must be used. 355 3.4. Automatic Enrolment of Devices 357 The approach outlined in this document provides a secure zero-touch 358 method to enrol new devices without any pre-staged configuration. 359 New devices communicate with already enrolled devices of the domain, 360 which proxy between the new device and a Registrar. As a result of 361 this completely automatic operation, all devices obtain a domain 362 based certificate. 364 3.5. Operating the Network 366 The certificate installed in the previous step can be used for all 367 subsequent operations. For example, to determine the boundaries of 368 the domain: If a neighbor has a certificate from the same trust 369 anchor it can be assumed "inside" the same organization; if not, as 370 outside. See also Section 4.5.1. The certificate can also be used 371 to securely establish a connection between devices and central 372 control functions. Also autonomic transactions can use the domain 373 certificates to authenticate and/or encrypt direct interactions 374 between devices. The usage of the domain certificates is outside 375 scope for this document. 377 4. Functional Overview 379 Entities behave in an autonomic fashion. They discover each other 380 and autonomically establish a key infrastructure deliminating the 381 autonomic domain. See [I-D.irtf-nmrg-autonomic-network-definitions] 382 for more information. 384 The overall flow is shown in Figure 2: 386 +---------+ +----------+ +-----------+ 387 | New | | | | MASA | 388 | Entity | | Domain | | Service | 389 | | | | | (Internet)| 390 +---------+ +----------+ +-----------+ 391 | | | 392 |<-------discovery--------->| | 393 |---802.1AR credential----->| | 394 | | | 395 | [ accept device? ] | 396 | | | 397 | |---802.1AR identity-------->| 398 | |---Domain ID--------------->| 399 | | | 400 | | [device belongs] 401 | | [to domain? ] 402 | | | 403 | | [update audit log] 404 | | | 405 | |<---device history log------| 406 | |<-- authorization token-----| 407 | | | 408 | [ still accept device?] | 409 | | | 410 |<----authorization token---| | 411 |<----domain information----| | 412 | | | 413 [auth token valid?] | | 414 | | | 415 |----domain enrolment------>| | 416 |<----domain certificate----| | 417 | | 419 Figure 1 421 4.1. Behavior of a new entity 423 A New Entity that has not yet been bootstrapped attempts to find a 424 local domain and join it. A number of methods are attempted for 425 establishing communications with the domain in a specified order. 427 Client behavior is as follows: 429 1. Discover a communication channel to the "closest" Registrar by 430 trying the following steps in this order: 432 A. Search for a Proxy on the local link using a link local 433 discovery protocol (no routable addresses are required for 434 this approach). If multiple local proxies are discovered 435 attempt communications with each before widening the search 436 to other options. The proxy relays information to the 437 registrar. If this fails: 439 B. Obtain an IP address using existing methods, such as SLAAC or 440 DHCPv6, and search for a local registrar using DNS service 441 discovery. If this fails: 443 C. Obtain an IP address (as above), and search for the domain 444 registrar using a pre-defined Factory provided Internet based 445 re-direct service. Various methods could be used, such as 446 DNS or RESTful APIs. 448 2. Present IEEE 802.1AR credentials to the discovered Registrar (via 449 a Proxy if necessary). Included is a generated nonce that is 450 specific to this attempt. 452 3. Verify the MASA service generated authorization token as provided 453 by the contacted Registrar. The authorization token contains the 454 valid domain(s) for this device and is signed by the MASA 455 service. The device uses a pre-installed certificate of the MASA 456 service to validate the signature of the MASA. The nonce 457 information previously provided is also checked, if it was not 458 removed by the Registrar. 460 4. If and only if step three is successful: Join Domain, by 461 accepting the domain specific information from the registrar, and 462 by enrolling a domain certificate from the registrar. 464 5. The New Entity is now a member of the domain and will only repeat 465 the discovery aspects of bootstrapping if it is returned to 466 factory default settings. 468 The following sections describe each of these steps in more detail. 470 4.1.1. Proxy Discovery 472 Existing protocols provide the appropriate functionality for both 473 discovering the Proxy and facilitating communication through the 474 Proxy: 476 IEEE 802.1X Where the New Entity can be cast as the "supplicant" and 477 the Proxy is the "authenticator". The bootstrapping protocol 478 messages are encapsulated as EAP methods. The "authenticator" 479 reencapsulates the EAPOL frames and forwards them to the 480 "Authentication Server", which provides Registrar functionalities. 482 PANA [RFC5191] [[EDNOTE: TBD]] 484 ND [RFC2461] / [RFC4861] [[EDNOTE: TBD]] NOTE: Neighbor Discovery 485 protocols do not describe a mechanism for forwarding messages. 487 Each provides a method for the New Entity to discover and initiate 488 communication with a local neighbor. In each protocol methods are 489 available to support encapsulation of the bootstrapping protocol 490 messages described elsewhere in this document. Other protocols for 491 transporting bootstrapping messages can be added in future 492 references. 494 All security assocaitions established are between the new device and 495 the Registrar regardless of proxy operations. 497 If multiple proxies are available the New Entity tries each until a 498 successful bootstrapping occurs. The New Entity may prioritize 499 proxies selection order as appropriate for the anticipated 500 environment. 502 If Proxy discovery fails the New Entity moves on to discovering a 503 Registrar directly. 505 4.1.2. Receiving and accepting the Domain Identity 507 The domain trust anchor is received by the New Entity during the 508 boostrapping protocol exchange. 510 An enrollment protocol such as EST [RFC7030] details a set of non- 511 autonomic bootstrapping methods such as: 513 o using the Implicit Trust Anchor database (not an autonomic 514 solution because the URL must be securely distributed), 516 o engaging a human user to authorize the CA certificate using out- 517 of-band data (not an autonomic solution because the human user is 518 involved), 520 o using a configured Explicit TA database (not an autonomic solution 521 because the distribution of an explicit TA database is not 522 autonomic), 524 o and using a Certificate-Less TLS mutual authentication method (not 525 an autonomic solution because the distribution of symmetric key 526 material is not autonomic). 528 This document describes an additional autonomic method: 530 MASA authorization token Authorization tokens are obtained by the 531 Registrar from the MASA service and presented to the New Entity 532 for validation. 534 If the autonomic methods fails the New Entity returns to discovery 535 state and attempts bootstrapping with the next available discovered 536 Registrar. 538 4.1.3. Enrollment 540 As the final step of bootstrapping a Registrar helps to issue a 541 domain specific credential to the New Entity. For simplicity in this 542 document, a Registrar primarily facilitates issuing a credential by 543 acting as an RFC5280 Registration Authority for the Domain 544 Certification Authority. 546 Enrollment proceeds as described in Enrollment over Secure Transport 547 (EST) [RFC7030]. The New Entity contacts the Registrar using EST as 548 indicated: 550 o The New Entity is authenticated using the IEEE 802.1AR 551 credentials. (EST support for . 553 o The EST section 4.1.3 CA Certificates Response is verified using 554 the MASA authorization token provided domain identity. 556 4.1.4. After Enrollment 558 Functionality to provide generic "configuration" is supported. The 559 parsing of this data and any subsequent use of the data, for example 560 communications with a Network Management System is out of scope but 561 is expected to occur after bootstrapping enrollment is complete. 563 See Section 4.5. 565 4.2. Behavior of a proxy 567 The role of the Proxy is to facilitate communications. The Proxy 568 forwards messages between the New Entity and a Registrar. Where 569 existing protocols, as detailed in Section 4.1.1, already provide 570 this functionality nothing additional is defined. 572 4.3. Behavior of the Registrar 574 Once a registrar is established it listens for new entities and 575 determines if they can join the domain. The registrar delivers any 576 necessary authorization information to the new device and facilitates 577 enrollment with the domain PKI. 579 Registrar behavior is as follows: 581 4.3.1. Authenticating the Device 583 The applicable authentication methods detailed in EST [RFC7030] are: 585 o the use of an IEEE 802.1AR IDevID credential, 587 o or the use of a secret that is transmitted out of band between the 588 New Entity and the Registrar (this use case is not autonomic). 590 4.3.2. Accepting the Entity 592 In a fully automated network all devices must be securely identified. 594 A Registrar accepts or declines a request to join the domain, based 595 on the authenticated identity presented and other policy defined 596 criteria such as Proxy identity. Automated acceptance criteria 597 include: 599 o allow any device of a specific type (as determined by the IEEE 600 802.1AR device identity), 602 o allow any device from a specific Factory (as determined by the 603 IEEE 802.1AR identity), 605 o allow a specific device from a Factory (as determined by the IEEE 606 802.1AR identity) 608 In all cases a Registrar must use the globally available MASA service 609 to verify that the device's history log does not include unexpected 610 Registrars. Because if a device had previously registered with 611 another domain, the registrar of that domain would show in the log. 613 If a device is accepted into the domain, it is then invited to 614 request a domain certificate through a certificate enrolment process. 615 The result is a common trust anchor and device certificates for all 616 autonomic devices in a domain. These certificates can subsequently 617 be used to determine the boundaries of the homenet, to authenticate 618 other domain nodes, and to autonomically enable services on the 619 homenet. 621 For each entity that will be accepted a Registrar maintains the 622 Factory CA identity and the entity's unique identifier. The Factory 623 CA identity could be implemented as the Factory CA root certificate 624 keyIdentifier (the 160-bit SHA-1 hash of the value of the BIT STRING 625 subjectPublicKey). For user interface purposes the keyIdentifier 626 information can be mapped to a colloquial Factory name (Registrars 627 can be shipped with the keyIdentifier of a significant number of 628 third-party manufacturers). 630 4.3.3. Claiming the new entity 632 During initial bootstrapping the New Entity provides a nonce specific 633 to the particular bootstrapping attempt. The registrar should 634 include this nonce when claiming the New Entity from the Internet 635 based MASA service. If a nonce is provided by the Registrar, then 636 claims from an unauthenticated Registrar are serviced by the MASA 637 resource. 639 The Registrar can claim a New Entity that is not online by forming 640 the request using the entities unique identifier but not including a 641 nonce in the claim request. MASA authorization tokens obtained in 642 this way do not have a lifetime and they provide a permanent method 643 for the domain to claim the device. Evidence of such a claim is 644 provided in the audit log entries available to any future Registrar. 645 Such claims reduce the ability for future domains to secure 646 bootstrapping and therefore the Registrar MUST be authenticated by 647 the MASA service. 649 Claiming an entity establishes an audit log at the MASA server and 650 provides the Registrar with proof, in the form of a MASA 651 authorization token, that the log entry has been inserted. As 652 indicated in Section 4.1.2 a New Entity will only proceed with 653 bootstrapping if a validated MASA authorization token has been 654 recieved. The New Entity therefore enforces that bootstrapping only 655 occurs if the claim has been logged. 657 4.4. Behavior of the MASA Service 659 The MASA service is provided by the Factory provider on the global 660 Internet. The URI of this service is well known. The URI should be 661 provided as an IEEE 802.1AR IDevID X.509 extension (a "MASA 662 authorization token Distribution Point" extension). 664 The MASA service provides the following functionalities to 665 Registrars: 667 4.4.1. Issue Authorization Token and Log the event 669 A Registrar POSTs a claim message optionally containing the bootstrap 670 nonce to the MASA server. 672 If a nonce is provided the MASA service responds to all requests. 673 The MASA service verifies the Registrar is representative of the 674 domain and generates a privacy protected log entry before responding 675 with the authorization token. 677 If a nonce is not provided then the MASA service MUST authenticate 678 the Registrar as a valid customer. This prevents denial of service 679 attacks. The specific level of authentication provided by the 680 customer is not defined here. An MASA Practice Statement (MPS) 681 similar to the Certification Authority CPS, as defined in RFC5280, is 682 provided by the Factory such that Registrar's can determine the level 683 of trust they have in the Factory. 685 4.4.2. Retrieve Audit Entries from Log 687 When determining if a New Entity should be accepted into a domain the 688 Registrar retrieves a copy of the audit log from the MASA service. 689 This contains a list of privacy protected domain identities that have 690 previously claimed the device. Included in the list is an indication 691 of the time the entry was made and if the nonce was included. 693 4.5. Leveraging the new key infrastructure / next steps 695 As the devices have a common trust anchor, device identity can be 696 securely established, making it possible to automatically deploy 697 services across the domain in a secure manner. 699 Examples of services: 701 o Device management. 703 o Routing authentication. 705 o Service discovery. 707 4.5.1. Network boundaries 709 When a device has joined the domain, it can validate the domain 710 membership of other devices. This makes it possible to create trust 711 boundaries where domain members have higher level of trusted than 712 external devices. Using the autonomic User Interface, specific 713 devices can be grouped into to sub domains and specific trust levels 714 can be implemented between those. 716 5. Protocol Details 718 For simplicity the bootstrapping protocol is described as extensions 719 to EST [RFC7030]. 721 EST provides a bootstrapping mechanism for new entities that are 722 configured with the URI of the EST server such that the Implicit TA 723 database can be used to authenticate the EST server. Alternatively 724 EST clients can "engage a human user to authorize the CA certificate 725 using out-of-band data such as a CA certificate". EST does not 726 provide a completely automated method of bootstrapping the PKI as 727 both of these methods require some user input (either of the URI or 728 authorizing the CA certificate). 730 This section details additional EST functionality that support 731 automated bootstrapping of the public key infrastructure. These 732 additions provide for fully automated bootstrapping. These additions 733 are to be optionally supported by the EST server within the same 734 .well-known URI tree as the existing EST URIs. 736 The "New Entity" is the EST client and the "Registrar" is the EST 737 server. 739 The extensions for the client are as follows: 741 o The New Entity provisionally accept the EST server certificate 742 during the TLS handshake as detailed in EST section 4.1.1 743 ("Bootstrap Distribution of CA Certificates"). 745 o The New Entity request and validates a "bootstrap token" as 746 described below. At this point the New Entity has sufficient 747 information to validate domain credentials. 749 o The New Entity calls the EST defined /cacerts method to obtain the 750 current CA certificate. These are validated using the "bootstrap 751 token". 753 o The New Entity completes bootstrapping as detailed in EST section 754 4.1.1. 756 These extensions could be implemented as an independent protocol from 757 EST but since the overlap with basic enrollment is extensive, 758 particularly with respect to client authorization, they are presented 759 here as additions to EST. 761 In order to obtain a validated bootstrap token and history logs the 762 Registrar contacts the MASA service Service using REST calls. 764 5.1. EAP-EST 766 In order to support Proxy environments EAP-EST is defined. 768 [[EDNOTE: TBD. EST is TLS with some data. EAP-TLS and other similar 769 protocols provide an example framework for filling out this section]] 771 5.2. Request bootstrap token 773 When the New Entity reaches the EST section 4.1.1 "Bootstrap 774 Distribution of CA Certificates" state but wishes to proceed in a 775 fully automated fashion it makes a request for a MASA authorization 776 token from the Registrar. 778 This is done with an HTTPS POST using the operation path value of 779 "/requestbootstraptoken". 781 The request format is JSON object containing a nonce. 783 Request media type: application/masanonce 785 Request format: a json file with the following: 787 {"nonce":"<64bit nonce value>"} 789 [[EDNOTE: exact format TBD. There is an advantage to having the 790 client sign the nonce (similar to a PKI Certification Signing 791 Request) since this allows the MASA service to confirm the actual 792 device identity. It is not clear that there is a security benefit 793 from this.]] 795 The Registrar validates the client identity as described in EST 796 [RFC7030] section 3.3.2. The registrar performs authorization as 797 detailed in Section 4.3.2. If authorization is successful the 798 Registrar obtains a MASA authorization token from the MASA service 799 (see Section 5.3). 801 The recieved MASA authorization token is returned to the New Entity. 803 5.3. Request MASA authorization token 805 A registrar requests the MASA authorization token from the MASA 806 service using a REST interface. 808 This is done with an HTTP POST using the operation path value of 809 "/requestMASAauthorization". 811 The request format is a JSON object optionally containing the nonce 812 value (as obtained from the bootstrap request) and the IEEE 802.1AR 813 identity of the device as a serial number (the full certificate is 814 not needed and no proof-of-possession information for the device 815 identity is included). The New Entity's serial number is extracted 816 from the subject name : 818 {"nonce":"<64bit nonce value>", "serialnumber", ""} 821 Inclusion of the nonce is optional because the Registar might request 822 an authorization token when the New Entity is not online, or when the 823 target bootstrapping environment is not on the same network as the 824 MASA server. 826 This information is encapsulated in a PKCS7 signed data structure 827 that is signed by the Registrar. The entire certificate chain, up to 828 and including the Domain CA, is included in the PKCS7. 830 The MASA service checks the internal consistency of the PKCS7 but is 831 unable to actually authenticate the domain identity information. The 832 domain is not know to the MASA server in advance and a shared trust 833 anchor is not implied. The MASA server verifies that the PKCS7 is 834 signed by a Registrar (by checking for the cmc-idRA field in the 835 Registrar certificate) certificate that was issued by the root 836 certificate included in the PKCS7. 838 The domain ID is extracted from the root certificate and is used to 839 generate the MASA authorization token and to update the audit log. 841 [[EDNOTE: This assumes the Registrar can extract the serial number 842 successfullly from the cilent certificate. The RFC4108 843 hardwareModuleName is likely the best known location.]] 845 5.4. Request MASA authorization log 847 A registrar requests the MASA authorization log from the MASA service 848 using this EST extension. 850 This is done with an HTTP GET using the operation path value of 851 "/requestMASAlog". 853 The log data returned is a file consisting of all previous log 854 entries. For example: 856 "log":[ 857 {"date":""}, 858 "domainID":"", 861 "nonce":""}, 863 {"date":""}, 864 "domainID":"", 867 "nonce":""}, 868 ] 870 Distribution of a large log is less than ideal. This structure can 871 be optimized as follows: only the most recent nonce'd log entry is 872 required in the response. All nonce-less entries for the same 873 domainID can be condensed into the single most recent nonceless 874 entry. 876 The Registrar uses this log information to make an informed decision 877 regarding the continued bootstrapping of the New Entity. 879 [[EDNOTE: certificate transparency might offer an alternative log 880 entry method]] 882 6. Reduced security operational modes 884 A common requirement of bootstrapping infrastructures is often that 885 they support less secure operational modes. To support these 886 operational modes the Registrar can choose to accept devices using 887 less secure methods. For example: 889 1. The registrar may choose to accept all devices, or all devices of 890 a particular type, at the administrator's discretion. This may 891 occur when: Informing the Registrar of unique identifiers of new 892 entities might be operationally difficult. 894 2. The registrar may choose to accept devices that claim a unique 895 identity without the benefit of authenticating that claimed 896 identity. This may occur when: The New Entity does not include 897 an IEEE 802.1AR factory installed credential. 899 3. A representative of the Registrar (e.g. the Orchestrator) may 900 request nonce-less authorization tokens from the MASA service 901 when network connectivity is available. These tokens can then be 902 transmitted to the Registrar and stored until they are needed 903 during bootstrapping operations. This may occur when: The target 904 network is protected by an air gap and therefore can not contact 905 the MASA service during New Entity deployment. 907 4. The device may have an operational mode where it skips 908 authorization token validation. For example if a physical button 909 is depressed during the bootstrapping operation. This may occur 910 when: A device Factory goes out of business or otherwise fails to 911 provide a reliable MASA service. 913 5. The device may not require the MASA service authorization token. 914 An entity that does not validate the domain identity is 915 inherently dangerous as it may contain malware. This risk should 916 be mitigated using attestation and measurement technologies. In 917 order to support an unsecured imprint the New Entity MUST support 918 remote attestation technologies such as is defined by the Trusted 919 Computing Group. [[EDNOTE: How to include remote attestation 920 into the boostrapping protocol exchange is TBD]]. This may occur 921 when: The device Factory does not provide a MASA service. 923 7. Security Considerations 925 In order to support a variety of use cases, devices can be claimed by 926 a registrar without proving possession of the device in question. 927 This would result in a nonceless, and thus always valid, claim. The 928 MASA service is required to authenticate such Registrars but no 929 programmatic method is provided to ensure good behavior by the MASA 930 service. Nonceless entries into the audit log therefore permanently 931 reduce the value of a device because future Registrars, during future 932 bootstrap attempts, must now be configured with policy to ignore 933 previously (and potentially unknown) domains. 935 Future registrars are recommended to take the audit history of a 936 device into account when deciding to join such devices into their 937 network. 939 It is possible for an attacker to send an authorization request to 940 the MASA service directly after the real Registrar obtains an 941 authorization log. If the attacker could also force the 942 bootstrapping protocol to reset there is a theoretical opportunity 943 for the attacker to use the authorization token to take control of 944 the New Entity but then proceed to enrol with the target domain. To 945 prevent this the MASA service is rate limited to only generate 946 authorization tokens at a rate of 1 per minute. The Registrar 947 therefore has at least 1 minute to get the response back to the New 948 Entity. [[EDNOTE: a better solution can likely be found. This text 949 captures the issue for now.]] Also the Registrar can double check the 950 log information after enrolling the New Entity. 952 The MASA service could lock a claim and refuse to issue a new token. 953 Or the MASA service could go offline (for example if a vendor went 954 out of business). This functionality provides benefits such as theft 955 resistance, but it also implies an operational risk. This can be 956 mitigated by Registrars that request nonce-less authorization tokens. 958 7.1. Trust Model 960 [[EDNOTE: (need to describe that we need to trust the device h/w. To 961 be completed.)]] 963 8. Acknowledgements 965 We would like to thank the various reviewers for their input, in 966 particular Markus Stenberg, Michael Richardson, Brian Carpenter, Fuyu 967 Eleven. 969 9. References 971 9.1. Normative References 973 [IDevID] IEEE Standard, , "IEEE 802.1AR Secure Device Identifier", 974 December 2009, . 977 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 978 Requirement Levels", BCP 14, RFC 2119, March 1997. 980 [RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over 981 Secure Transport", RFC 7030, October 2013. 983 9.2. Informative References 985 [I-D.behringer-homenet-trust-bootstrap] 986 Behringer, M., Pritikin, M., and S. Bjarnason, 987 "Bootstrapping Trust on a Homenet", draft-behringer- 988 homenet-trust-bootstrap-02 (work in progress), February 989 2014. 991 [I-D.irtf-nmrg-autonomic-network-definitions] 992 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 993 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 994 Networking - Definitions and Design Goals", draft-irtf- 995 nmrg-autonomic-network-definitions-05 (work in progress), 996 December 2014. 998 Authors' Addresses 1000 Max Pritikin 1001 Cisco 1003 Email: pritikin@cisco.com 1005 Michael H. Behringer 1006 Cisco 1008 Email: mbehring@cisco.com 1010 Steinthor Bjarnason 1011 Cisco 1013 Email: sbjarnas@cisco.com