idnits 2.17.1 draft-pritikin-bootstrapping-keyinfrastructures-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 (September 26, 2014) is 3471 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5191' is mentioned on line 420, but not defined == Missing Reference: 'RFC2461' is mentioned on line 422, but not defined ** Obsolete undefined reference: RFC 2461 (Obsoleted by RFC 4861) == Missing Reference: 'RFC4861' is mentioned on line 422, but not defined == Missing Reference: 'RFC5246' is mentioned on line 481, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Pritikin 3 Internet-Draft M. Behringer 4 Intended status: Informational S. Bjarnason 5 Expires: March 30, 2015 Cisco 6 September 26, 2014 8 Bootstrapping Key Infrastructures 9 draft-pritikin-bootstrapping-keyinfrastructures-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 cloud 16 service. Before being authenticated, a new device has only link- 17 local connectivity, and does not require a routable address. When a 18 vendor cloud service is provided devices can be forced to join only 19 specific domains but for contrained environments we describe a 20 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 March 30, 2015. 39 Copyright Notice 41 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . 7 63 3.4. Operating the Network . . . . . . . . . . . . . . . . . . 8 64 4. Functional Overview . . . . . . . . . . . . . . . . . . . . . 8 65 4.1. Behavior of a new entity . . . . . . . . . . . . . . . . 9 66 4.1.1. Proxy Discovery . . . . . . . . . . . . . . . . . . . 10 67 4.1.2. Receiving and accepting the Domain Identity . . . . . 11 68 4.1.3. Enrollment . . . . . . . . . . . . . . . . . . . . . 12 69 4.1.4. After Enrollment . . . . . . . . . . . . . . . . . . 12 70 4.2. Behavior of a proxy . . . . . . . . . . . . . . . . . . . 12 71 4.3. Behavior of the Registrar . . . . . . . . . . . . . . . . 13 72 4.3.1. Authenticating the Device . . . . . . . . . . . . . . 13 73 4.3.2. Accepting the Entity . . . . . . . . . . . . . . . . 13 74 4.3.3. Claiming the new entity . . . . . . . . . . . . . . . 14 75 4.4. Behavior of the MASA Cloud Service . . . . . . . . . . . 14 76 4.4.1. Issue Authorization Token and Log the event . . . . . 14 77 4.4.2. Retrieve Audit Entries from Log . . . . . . . . . . . 15 78 4.5. Leveraging the new key infrastructure / next steps . . . 15 79 4.5.1. Network boundaries . . . . . . . . . . . . . . . . . 15 80 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 15 81 5.1. EAP-EST . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 5.2. Request bootstrap token . . . . . . . . . . . . . . . . . 16 83 5.3. Request MASA authorization token . . . . . . . . . . . . 17 84 5.4. Request MASA authorization log . . . . . . . . . . . . . 17 85 6. Reduced security operational modes . . . . . . . . . . . . . 18 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 89 8.2. Informative References . . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 92 1. Introduction 94 To literally "pull yourself up by the bootstraps" is an impossible 95 action. Similarly the secure establishment of a key infrastructure 96 without external help is also an impossibility. Today it is accepted 97 that the initial connections between nodes are insecure, until key 98 distribution is complete, or that domain-specific keying material is 99 pre-provisioned on each new device in a costly and non-scalable 100 manner. This document describes a zero-touch approach to 101 bootstrapping an entity by securing the initial distribution of key 102 material using third-party generic keying material, such as a 103 manufacturer installed IEEE 802.1AR certificate [IDevID], and a 104 corresponding third-party cloud service. 106 The two sides of an association being bootstrapped authenticate each 107 other and then determine appropriate authorization. This process is 108 described as four distinct steps between the existing domain and the 109 new entity being added: 111 o New entity authentication: "Who is this? What is its identity?" 113 o New entity authorization: "Is it mine? Do I want it? What are 114 the chances it has been compromised?" 116 o Domain authentication: "What is this domain's claimed identity?" 118 o Domain authorization: "Should I join it?" 120 A precise answer to these questions can not be obtained without 121 leveraging an established key infrastructure(s). The domain's 122 decisions are based on the new entity's authenticated identity, as 123 established by verification of previously installed credentials such 124 as a manufacturer installed IEEE 802.1AR certificate, and verified 125 back-end information such as a configured list of purchased devices 126 or communication with a trusted third-party. The new entity's 127 decisions are made according to verified communication with a trusted 128 third-party or in a strictly auditable fasion. 130 Optimal security is achieved with IEEE 802.1AR certificates on each 131 new entity, accompanied by a third-party cloud service for 132 verification. The concept also works with less requirements, but is 133 then less secure. A domain can choose to accept lower levels of 134 security when a trusted third-party is not available so that 135 bootstrapping proceeds even at the risk of reduced security. Only 136 the domain can make these decisions based on administrative input and 137 known behavior of the new entity. 139 The result of bootstrapping is that a domain specific key 140 infrastructure is deployed. Since IEEE 802.1AR PKI certificates are 141 used for identifying the new entity and the public key of the domain 142 identity is leveraged during communiciations with a cloud service, 143 which is itself authenticated using HTTPS, bootstrapping of a domain 144 specific Public Key Infrastructure (PKI) is fully described. 146 Sufficient agility to support bootstrapping alternative key 147 infrastructures (such as symmetric key solutions) is considered 148 although no such key infrastructure is described. 150 1.1. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in 155 [RFC2119]. 157 The following terms are defined for clarity: 159 2. Architectural Overview 161 The logical elements of the bootstrapping framework are described in 162 this section. Figure 1 provides a simplified overview of the 163 components. Each component is logical and may be combined with other 164 components as necessary. 166 Factory components 167 . 168 . +------------+ 169 . | Factory CA | 170 . +------------+ 171 . | 172 . +------------+ 173 . | | 174 +--------------(provides)---------------------------| Factory | 175 | +---------->| | 176 | | . +------------+ 177 | V . 178 | +---------------+ . +------------+ 179 | | Orchestrator | . | MASA | 180 V +---------------+ . | Cloud | 181 +-------+ | . | Service | 182 | New | +------------+ +-----------+ . +------------+ 183 | Entity|<--L2-->| Proxy |<----->| | ....... ^ 184 | | +------------+ | | | 185 | | | Registrar | | 186 | | | | | 187 | |<--DHCP-->(L3 bootstrap) | | | 188 | | | | | 189 | |<-----L3---------------------( registrar )-----------+ 190 | | ( may proxy ) | 191 +-------+ +-----------+ 192 | 193 +----------------------------+ 194 ^ | Domain Certification | ^ 195 . | Authority | . 196 . +----------------------------+ . 197 . . 198 ......................................... 199 | 200 "domain" components 202 Figure 1 204 Domain: The set of entities that trust a common key infrastructure 205 trust anchor. 207 Domain CA: The domain Certification Authority (CA) optionally 208 provides certification functionalities to the domain entities. At 209 a minimum it provides certification funtionalities to the 210 Registrar and stores the trust anchor that defines the domain. 212 Domain Identity: The domain identity is the 160-bit SHA-1 hash of 213 the BIT STRING of the subjectPublicKey of the domain trust anchor 214 that is stored by the Domain CA. This is consistent with the 215 RFC5280 Certification Authority subject key identifier of the 216 Domain CA's self signed root certificate. (A string value bound 217 to the Domain CA's self signed root certificate subject and issuer 218 fields is often colloqually used as a humanized identity value but 219 during protocol discussions the more exact term as defined here is 220 used). 222 Orchestrator: Although bootstrapping of an individual device is 223 automated and requires zero administrative involvement 224 (particularly on the New Entity) the orchestrator drives general 225 operations of the domain. In simple deployments this might be a 226 single administrator ordering a new device from the Factory and 227 manually inputing a serial number from the bill-of-sale into a 228 Registrar. In a more complex environment this might be an 229 automated process that directs a hypervisor "Factory" to 230 instantiate a new virtual machine. 232 Factory: This instantiates the New Entity. For physical devices 233 this can be representative of third-party vendor manufacturing, 234 ordering and shipping process(es) that results in a physical 235 hardware device with an IEEE 802.1AR identity being drop shipped 236 to a destination domain for physical installation. In a virtual 237 machine environment this can be the virtual machine hypervisor 238 control software that initiates a virtual machine instance, in 239 which case the factory is a "virtual factory" and might be managed 240 by the domain itself. 242 Factory CA: This Certification Authority is leveraged by the Factory 243 to issue IEEE 802.1AR identities to each New Entity. For a 244 virtual factory it may be reasonable to assume the domain 245 certification authority is directly used but in a complex 246 environment it is assumed the Factory does not have direct access 247 to the Domain Certification Authority. 249 Registrar: A representative of the domain that is configured, 250 perhaps autonomically, to decide whether a new device is allowed 251 to join the domain. The administrator of the domain interfaces 252 with a Registrar to control this process. 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 Cloud Service: A Manufacturer Authorized Signing Authority 263 (MASA) cloud service on the global Internet. At a minimum the 264 MASA provides a trusted repository for audit information 265 concerning privacy protected bootstrapping events. As a service 266 offering the MASA can encorporate many of the bootstrapping 267 elements (such as the Registrar and the Domain CA) into the cloud 268 service. 270 3. Operational Overview 272 This section describes how an operator interacts with a domain that 273 supports the bootstrapping as described in this document. 275 3.1. Instantiating the Domain Certification Authority 277 This is a one time step by the domain administrator. This is an "off 278 the shelf" CA with the exception that it is designed to work as an 279 integrated part of the security solution. This precludes the use of 280 3rd party certification authority services that do not provide 281 support for delegation of certificate issuance decisions to a domain 282 managed Registration Authority. 284 3.2. Instantiating the Registrar 286 This is a one time step by the domain administrator. One or more 287 devices in the domain are configured take on a Registrar function. 289 A device can be configured to act as a Registrar or a device can 290 auto-select itself to take on this function, using a detection 291 mechanism to resolve potential conflicts and setup communication with 292 the Domain Certification Authority. An automated Registrar selection 293 processes is not detailed here. [[EDNOTE: yet]] 295 3.3. Accepting New Entities 297 For each New Entity the Registrar is informed a priori the unique 298 identifier (e.g. serial number). This can be supplied automatically 299 from the Orchestrator [[EDNOTE: TBD]] or inputed manually by the 300 administrator. 302 For each entity that will be accepted a Registrar maintains the 303 Factory CA identity and the entity's unique identifier. The Factory 304 CA identity could be implemented as the Factory CA root certificate 305 keyIdentifier (the 160-bit SHA-1 hash of the value of the BIT STRING 306 subjectPublicKey). For user interface purposes the keyIdentifier 307 information can be mapped to a colloquial Factory name (Registrars 308 can be shipped with the keyIdentifier of a significant number of 309 third-party manufacturers). 311 Additional policy can be stored for future authorization decisions. 312 For example an expected deployment time window or that a certain 313 Proxy must be used. 315 3.4. Operating the Network 317 Once devices are enrolled to the domain, the network operator can 318 specify a policy, or otherwise configure the devices if required. 319 This is outside scope for this document. 321 4. Functional Overview 323 Entities behave in an autonomic fashion. They discover each other 324 and autonomically establish a key infrastructure deliminating the 325 autonomic domain. See [I-D.behringer-autonomic-network-framework] 326 for more information. 328 The overall flow is shown in Figure 2: 330 +---------+ +----------+ +-----------+ 331 | New | | | | Factory | 332 | Entity | | Domain | | Cloud | 333 | | | | | Service | 334 +---------+ +----------+ +-----------+ 335 | | | 336 |<-------discovery--------->| | 337 |---802.1AR credential----->| | 338 | | | 339 | [ accept device? ] | 340 | | | 341 | |---802.1AR identity-------->| 342 | |---Domain ID--------------->| 343 | | | 344 | | [device belongs] 345 | | [to domain? ] 346 | | | 347 | | [update audit log] 348 | | | 349 | |<---device history log------| 350 | |<-- authorization token-----| 351 | | | 352 | [ still accept device?] | 353 | | | 354 |<----authorization token---| | 355 |<----domain information----| | 356 | | | 357 [auth token valid?] | | 358 | | | 359 |----domain enrolment------>| | 360 |<----domain certificate----| | 361 | | 363 4.1. Behavior of a new entity 365 A New Entity that has not yet been bootstrapped attempts to find a 366 local domain and join it. A number of methods are attempted for 367 establishing communications with the domain in a specified order. 369 Client behavior is as follows: 371 1. Discover a communication channel to the "closest" Registrar by 372 trying the following steps in this order: 374 A. Search for a Proxy on the local link using Neighbor 375 Discovery. If multiple local proxies are discovered attempt 376 communications with each before widening the search to other 377 options. If this fails: 379 B. Obtain an IP address using DHCP, and search for a local 380 registrar using DNS service discovery. If this fails: 382 C. Obtain an IP address using DHCP, and search for a pre-defined 383 Factory provided global registrar using DNS. 385 2. Present IEEE 802.1AR credentials to the discovered Registrar (via 386 a Proxy if necessary). Included is a generated nonce that is 387 specific to this attempt. 389 3. Verify the MASA cloud service generated authorization token as 390 provided by the contacted Registrar. The nonce information 391 previously provided is also checked, if it was not removed by the 392 Registrar. 394 4. If and only if step three is successful: Join Domain, by 395 accepting the domain specific information from the registrar, and 396 by enrolling a domain certificate from the registrar. 398 5. The New Entity is now a member of the domain and will only repeat 399 the discovery aspects of bootstrapping if it is returned to 400 factory default settings. 402 [[EDNOTE: Step (1b and 1c) is similar to the vendor DNS mechanisms 403 described in draft-kwatsen-netconf-zerotouch although the goal here 404 is to contact a Registrar rather than a vendor supplied NMS] 406 The following sections describe each of these steps in more detail. 408 4.1.1. Proxy Discovery 410 Existing protocols provide the appropriate functionality for both 411 discovering the Proxy and facilitating communication through the 412 Proxy: 414 IEEE 802.1X Where the New Entity can be cast as the "supplicant" and 415 the Proxy is the "authenticator". The bootstrapping protocol 416 messages are encapsulated as EAP methods. The "authenticator" 417 reencapsulates the EAPOL frames and forwards them to the 418 "Authentication Server", which provides Registrar functionalities. 420 PANA [RFC5191] [[EDNOTE: TBD]] 422 ND [RFC2461] / [RFC4861] [[EDNOTE: TBD]] NOTE: Neighbor Discovery 423 protocols do not describe a mechanism for forwarding messages. 425 Each provides a method for the New Entity to discover and initiate 426 communication with a local neighbor. In each protocol methods are 427 available to support encapsulation of the bootstrapping protocol 428 messages described elsewhere in this document. Other protocols for 429 transporting bootstrapping messages can be added in future 430 references. 432 All security assocaitions established are between the new device and 433 the Registrar regardless of proxy operations. 435 If multiple proxies are available the New Entity tries each until a 436 successful bootstrapping occurs. The New Entity may prioritize 437 proxies selection order as appropriate for the anticipated 438 environment. 440 If Proxy discovery fails the New Entity moves on to discovering a 441 Registrar directly. 443 4.1.2. Receiving and accepting the Domain Identity 445 The domain trust anchor is received by the New Entity during the 446 boostrapping protocol exchange. 448 EST [RFC7030] details a set of non-autonomic bootstrapping methods 449 such as: 451 o using the Implicit Trust Anchor database (not an autonomic 452 solution because the URL must be securely distributed), 454 o engaging a human user to authorize the CA certificate using out- 455 of-band data (not an autonomic solution because the human user is 456 involved), 458 o and using a configured Explicit TA database (not an autonomic 459 solution because the distribution of symmetric key material is not 460 autonomic). 462 This document describes two additional autonomic methods: 464 MASA authorization token Authorization tokens are obtained by the 465 Registrar from the MASA cloud service and presented to the New 466 Entity for validation. 468 URL redirect If the New Entity discovers a well known global 469 registrar using DNS then the EST protocol exchange is protected 470 using an Implicit TA database, but also the MASA authorization is 471 required. The global registrar MUST claim the device with the 472 MASA server to ensure the logging information is consistent. The 473 global registrar forwards the New Entity to an alternate URI as 474 described in EST [RFC7030]. 476 If these methods fail the New Entity returns to discovery state and 477 attempts bootstrapping with the next available discovered Registrar. 479 [[EDNOTE: move protocol discussion down into protocol section]] The 480 domain trust anchor MUST be included in the TLS handshake Server 481 Certificate "certificate_list" [RFC5246] or the client MUST request 482 the EST Bootstrap Distribution of CA Certificates [RFC7030]. (This 483 document defines an additional method for accepting the CA 484 certificates). 486 4.1.3. Enrollment 488 As the final step of bootstrapping a Registrar helps to issue a 489 domain specific credential to the New Entity. For simplicity in this 490 document, a Registrar primarly facilitates issuing a credential by 491 acting as an RFC5280 Registration Authority for the Domain 492 Certification Authority. 494 Enrollment proceeds as described in Enrollment over Secure Transport 495 (EST) [RFC7030]. The New Entity contacts the Registrar using EST as 496 indicated: 498 o The New Entity is authenticated using the IEEE 802.1AR credentials 499 [[EDNOTE: or in the non-autonomic case using the the out of band 500 secret]. 502 o The EST section 4.1.3 CA Certificates Response is verified using 503 the MASA authorization token provided domain identity. 505 4.1.4. After Enrollment 507 Functionality to provide generic "configuration" is supported. The 508 parsing of this data and any subsequent use of the data, for example 509 communications with a Network Management System is out of scope but 510 is expected to occur after bootstrapping enrollment is complete. 512 See Section 4.5. 514 4.2. Behavior of a proxy 516 The role of the Proxy is to facilitate communications. The Proxy 517 forwards messages between the New Entity and a Registrar. Where 518 existing protocols as detailed in Section 4.1.1 already provide this 519 functionality nothing additional is defined. 521 [[EDNOTE: If neighbor discovery protocols are used for Proxy 522 discovery then a proxy forwarding protocol is to be defined here]] 524 4.3. Behavior of the Registrar 526 One a registrar is established it listens for new entities and 527 determines if they can join the domain. The registrar delivers any 528 necessary authorization information to the new device and facilitates 529 enrollment with the domain PKI. 531 Registrar behavior is as follows: 533 4.3.1. Authenticating the Device 535 The authentication methods detailed in EST [RFC7030] are: 537 o the use of an IEEE 802.1AR IDevID credential, 539 o or the use of a secret that is transmitted out of band between the 540 New Entity and the Registrar (this use case is not autonomic). 542 4.3.2. Accepting the Entity 544 In a fully automated nework all devices must be securely identified. 546 A Registrar accepts or declines a request to join the domain, based 547 on the authenticated identity presented and other policy defined 548 criteria such as Proxy identity. Automated acceptance criteria 549 include: 551 o allow any device of a specific type (as determined by the IEEE 552 802.1AR device identity), 554 o allow any device from a specific Factory (as determined by the 555 IEEE 802.1AR identity), 557 o allow a specific device from a Factory (as determined by the IEEE 558 802.1AR identity) 560 In all cases a Registrar must use the globally available MASA cloud 561 service to verify the device's history log does not include 562 unexpected Registrars. 564 If a device is accepted into the domain, it is then invited to 565 request a domain certificate through a certificate enrolment process. 566 The result is a common trust anchor and device certificates for all 567 autonomic devices in a domain. These certificates can subsequently 568 be used to determine the boundaries of the homenet, to authenticate 569 other domain nodes, and to autonomically enable services on the 570 homenet. 572 4.3.3. Claiming the new entity 574 During initial bootstrapping the New Entity provides a nonce specific 575 to the particular bootstrapping attempt. The registrar should 576 include this nonce when claiming the New Entity from the MASA cloud 577 service. If a nonce is provided by the Registrar then claims from an 578 unauthenticated Registrar are serviced by the MASA cloud resource. 580 The Registrar can claim a New Entity that is not online by forming 581 the request using the entities unique identifier but not including a 582 nonce in the claim request. MASA authorization tokens obtained in 583 this way do not have a lifetime and they provide a permanent method 584 for the domain to claim the device. Evidence of such a claim is 585 provided in the audit log entries available to any future Registrar. 586 Such claims reduce the ability for future domains to secure 587 bootstrapping and therefore the Registrar MUST be authenticated by 588 the MASA cloud service. 590 Claiming an entity establishes an audit log at the MASA server and 591 provides the Registrar with proof, in the form of a MASA 592 authorization token, that the log entry has been inserted. As 593 indicated in Section 4.1.2 a New Entity will only proceed with 594 bootstrapping if a validated MASA authorization token has been 595 recieved. The New Entity therefore enforces that bootstrapping only 596 occurs if the claim has been logged. 598 4.4. Behavior of the MASA Cloud Service 600 The cloud service is provided by the Factory provider. The URI of 601 the cloud service is well known. The URI should be provided as an 602 IEEE 802.1AR IDevID X.509 extension (a "MASA authorization token 603 Distribution Point" extension). 605 The cloud service provides the following functionalities to 606 Registrars: 608 4.4.1. Issue Authorization Token and Log the event 610 A Registrar POSTs a claim message optionally containing the bootstrap 611 nonce to the MASA server. 613 If a nonce is provided the MASA cloud service responds to all 614 requests. The MASA cloud service verifies the Registrar is 615 representative of the domain and generates a privacy protected log 616 entry before responding with the authorization token. 618 If a nonce is not provided the MASA cloud service MUST authenticate 619 the Registrar as a valid customer. This prevents denial of service 620 attacks. The specific level of authentication provided by the 621 customer is not defined here. An MASA Practice Statement (MPS) 622 similar to the Certification Authority CPS, as defined in RFC5280, is 623 provided by the Factory such that Registrar's can determine the level 624 of trust they have in the Factory. 626 4.4.2. Retrieve Audit Entries from Log 628 When determining if a New Entity should be accepted into a domain the 629 Registrar retrieves a copy of the audit log from the MASA cloud 630 service. This contains a list of privacy protected domain identities 631 that have previously claimed the device. Included in the list is an 632 indication of the time the entry was made and if the nonce was 633 included. 635 4.5. Leveraging the new key infrastructure / next steps 637 As the devices have a common trust anchor, device identity can be 638 securely established, making it possible to automatically deploy 639 services across the domain in a secure manner. 641 Examples of services: 643 o Device management. 645 o Routing authentication. 647 o Service discovery. 649 4.5.1. Network boundaries 651 When a device has joined the domain, it can validate the domain 652 membership of other devices. This makes it possible to create trust 653 boundaries where domain members have higher level of trusted than 654 external devices. Using the autonomic User Interface, specific 655 devices can be grouped into to sub domains and specific trust levels 656 can be implemented between those. 658 5. Protocol Details 660 The bootstrapping protocol is an extension of EST [RFC7030]. 662 [[EDNOTE: Insert figure here]] 664 EST provides a bootstrapping mechanism for new entities that are 665 configured with the URI of the EST server or new entities that can 666 "engage a human user to authorize the CA certificate using out-of- 667 band data such as a CA certificate". EST does not provide a 668 completely automated method of bootstrapping the PKI. [[EDNOTE: This 669 paragraph should be expanded to provide a detailed discussion of 670 current EST functionalitites, or do we assume the reader follows the 671 normative reference?]]. 673 The following additions provide for fully automated functionality. 674 EST is extended by defining additional HTTP URIs and messages 675 specific to bootstrapping. These are optionally supported by the EST 676 server within the same .well-known URI tree as the existing EST URIs. 678 The "New Entity" is the EST client and the "Registrar" is the EST 679 server. 681 5.1. EAP-EST 683 In order to support Proxy environments EAP-EST is defined. 685 [[EDNOTE: TBD. EST is TLS with some data. EAP-TLS and other similar 686 protocols provide an example framework for filling out this section]] 688 5.2. Request bootstrap token 690 When the New Entity reaches the EST section 4.1.1 "Bootstrap 691 Distribution of CA Certificates" state but wishes to proceed in a 692 fully automated fashion it makes a request for a MASA authorization 693 token from the Registrar. 695 This is done with an HTTPS POST using the operation path value of 696 "/requestbootstraptoken". 698 The request format is a raw nonce value. [[EDNOTE: exact format TBD. 699 There is an advantage to having the client sign the nonce (similar to 700 a PKI Certification Signing Request) since this allows the MASA cloud 701 service to confirm the actual device identity. It is not clear that 702 there is a security benefit from this.]] 704 The Registrar validates the client identity as described in EST 705 [RFC7030] section 3.3.2. The registrar performs authorization as 706 detailed in Section 4.3.2. If authorization is successful the 707 Registrar obtains a MASA authorization token from the MASA cloud 708 service (see Section 5.3). 710 The recieved MASA authorization token is returned to the New Entity. 712 [[EDNOTE: update to CMS language]] 714 5.3. Request MASA authorization token 716 A registrar requests the MASA authorization token from the cloud 717 service using this EST extension. 719 This is done with an HTTP POST using the operation path value of 720 "/requestMASAauthorization". 722 The request format is an optional raw nonce value (as obtained from 723 the bootstrap request) and the IEEE 802.1AR identity of the device as 724 a serial number (the full certificate is not needed and no proof-of- 725 possession information for the device identity is included). This 726 information is encapsulated in a PKCS7 signed data structure that is 727 signed by the Registrar. The entire certificate chain, up to and 728 including the Domain CA, is included in the PKCS7. 730 The MASA cloud service checks the internal consistency of the PKCS7 731 but is unable to actually authenticate the domain identity 732 information. The domain is not know to the MASA server in advance 733 and a shared trust anchor is not implied. The MASA server verifies 734 that the PKCS7 is signed by a Registrar (by checking for the cmc-idRA 735 field in the Registrar certificate) certificate that was issued by 736 the root certificate included in the PKCS7. 738 The domain ID is extracted from the root certificate and is used to 739 generate the MASA authorization token and to update the audit log. 741 [[EDNOTE: update to CMS language]] 743 5.4. Request MASA authorization log 745 A registrar requests the MASA authorization log from the cloud 746 service using this EST extension. 748 This is done with an HTTP GET using the operation path value of 749 "/requestMASAlog". 751 The log data returned is a file consisting of each log entry. The 752 data in each entry includes: 754 o date/time of the entry 756 o domain ID (this is just a hash of the public key information and 757 is thus privacy protected) 759 o nonce value 761 [[EDNOTE: exact format TBD]] 763 6. Reduced security operational modes 765 A common requirement of bootstrapping infrastructures is often that 766 they support less secure operational modes. To support these 767 operational modes the Registrar can choose to accept devices using 768 less secure methods. For example: 770 1. The registrar may chose to accept all devices, or all devices of 771 a particular type, at the administrator's discretion. This may 772 occur when: Informing the Registrar of unique identifiers of new 773 entities might be operationally difficult. 775 2. The registrar may chose to accept devices that claim a unique 776 identity without the benefit of authenticating that claimed 777 identity. This may occur when: The New Entity does not include 778 an IEEE 802.1AR factory installed credential. 780 3. A representative of the Registar (e.g. the Orchestrator) may 781 request nonce-less authorization tokens from the MASA cloud 782 service when network connectivity is available. These tokens can 783 then be transmitted to the Registrar and stored until they are 784 needed during bootstrapping operations. Ths may occur when: The 785 target network is protected by an air gap and therefore can not 786 contact the MASA cloud service during New Entity deployment. 788 4. The device may have an operational mode where it skips 789 authorization token validation. For example if a physical button 790 is depressed during the bootstrapping operation. This may occur 791 when: A device Factory goes out of business or otherwise fails to 792 provide a reliable MASA cloud service. 794 5. The device may not require the MASA cloud service authorization 795 token. An entity that does not validate the domain identity is 796 inherently dangerous as it may contain malware. This risk should 797 be mitigated using attestation and measurement technologies. In 798 order to support an unsecured imprint the New Entity MUST support 799 remote attestation technologies such as is defined by the Trusted 800 Computing Group. [[EDNOTE: How to include remote attestation 801 into the boostrapping protocol exchange is TBD]]. This may occur 802 when: The device Factory does not provide a MASA cloud service. 804 7. Security Considerations 806 In order to support a variety of use cases, devices can be claimed by 807 a registrar without proving possession of the device in question. 808 This would result in a nonceless, and thus always valid, claim. The 809 MASA cloud service is required to authenticate such Registrars but no 810 programatic method is provided to ensure good behavior by the MASA 811 cloud service. Nonceless entries into the audit log therefore 812 permanently reduce the value of a device because future Registrars, 813 during future bootstrap attempts, must now be configured with policy 814 to ignore previously (and potentially unknown) domains. 816 Future registrars are recommended to take the audit history of a 817 device into account when deciding to join such devices into their 818 network. 820 It is possible for an attacker to send an authorization request to 821 the MASA cloud service directly after the real Registrar obtains an 822 authorization log. If the attacker could also force the 823 bootstrapping protocol to reset there is a theoretical opportunity 824 for the attacker to use the authorization token to take control of 825 the New Entity but then proceed to enrol with the target domain. To 826 prevent this the MASA cloud service is rate limited to only generate 827 authorization tokens at a rate of 1 per minute. The Registrar 828 therefore has at least 1 minute to get the response back to the New 829 Entity. [[EDNOTE: a better solution can likely be found. This text 830 captures the issue for now.]] Also the Registar can double check the 831 log information after enrolling the New Entity. 833 The MASA cloud service could lock a claim and refuse to issue a new 834 token. Or the MASA cloud service could go offline (for example if a 835 vendor went out of business). This functionality provides benefits 836 such as theft resistance, but it also implies an operational risk. 837 This can be mitigated by Registrars that request nonce-less 838 authorization tokens. 840 8. References 842 8.1. Normative References 844 [IDevID] IEEE Standard, , "IEEE 802.1AR Secure Device Identifier", 845 December 2009, . 848 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 849 Requirement Levels", BCP 14, RFC 2119, March 1997. 851 [RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over 852 Secure Transport", RFC 7030, October 2013. 854 8.2. Informative References 856 [I-D.behringer-autonomic-network-framework] 857 Behringer, M., Pritikin, M., Bjarnason, S., and A. Clemm, 858 "A Framework for Autonomic Networking", draft-behringer- 859 autonomic-network-framework-01 (work in progress), October 860 2013. 862 Authors' Addresses 864 Max Pritikin 865 Cisco 867 Email: pritikin@cisco.com 869 Michael H. Behringer 870 Cisco 872 Email: mbehring@cisco.com 874 Steinthor Bjarnason 875 Cisco 877 Email: sbjarnas@cisco.com