idnits 2.17.1 draft-pritikin-anima-bootstrapping-keyinfra-02.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 == Line 181 has weird spacing: '...imprint the p...' == Line 186 has weird spacing: '... pledge the p...' -- The document date (July 6, 2015) is 3215 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5191' is mentioned on line 413, but not defined == Missing Reference: 'RFC2461' is mentioned on line 414, but not defined ** Obsolete undefined reference: RFC 2461 (Obsoleted by RFC 4861) == Missing Reference: 'RFC4861' is mentioned on line 414, but not defined Summary: 2 errors (**), 0 flaws (~~), 6 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 Cisco 4 Intended status: Informational M. Richardson 5 Expires: January 7, 2016 SSW 6 M. Behringer 7 S. Bjarnason 8 Cisco 9 July 6, 2015 11 Bootstrapping Key Infrastructures 12 draft-pritikin-anima-bootstrapping-keyinfra-02 14 Abstract 16 This document specifies automated bootstrapping of an key 17 infrastructure using vendor installed IEEE 802.1AR manufacturing 18 installed certificates, in combination with a vendor based service on 19 the Internet. Before being authenticated, a new device has only 20 link-local connectivity, and does not require a routable address. 21 When a vendor provides an Internet based service, devices can be 22 forced to join only specific domains but for constrained environments 23 we describe a variety of options that allow bootstrapping to proceed. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 7, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 61 2. Architectural Overview . . . . . . . . . . . . . . . . . . . . 5 62 3. Functional Overview . . . . . . . . . . . . . . . . . . . . . 7 63 3.1. Behavior of a new entity . . . . . . . . . . . . . . . . . 8 64 3.1.1. Discovery and Identity . . . . . . . . . . . . . . . . 10 65 3.1.2. Imprint . . . . . . . . . . . . . . . . . . . . . . . 11 66 3.1.3. Enrollment . . . . . . . . . . . . . . . . . . . . . . 12 67 3.1.4. Being Managed . . . . . . . . . . . . . . . . . . . . 12 68 3.2. Behavior of a proxy . . . . . . . . . . . . . . . . . . . 13 69 3.3. Behavior of the Registrar . . . . . . . . . . . . . . . . 13 70 3.3.1. Entity Authentication . . . . . . . . . . . . . . . . 14 71 3.3.2. Entity Authorization . . . . . . . . . . . . . . . . . 14 72 3.3.3. Claiming the New Entity . . . . . . . . . . . . . . . 15 73 3.3.4. Log Verification . . . . . . . . . . . . . . . . . . . 16 74 3.3.5. Forwarding Authorization Token plus Configuration . . 16 75 3.4. Behavior of the MASA Service . . . . . . . . . . . . . . . 16 76 3.4.1. Issue Authorization Token and Log the event . . . . . 17 77 3.4.2. Retrieve Audit Entries from Log . . . . . . . . . . . 17 78 3.5. Leveraging the new key infrastructure / next steps . . . . 17 79 3.5.1. Network boundaries . . . . . . . . . . . . . . . . . . 17 80 4. Domain Operator Activities . . . . . . . . . . . . . . . . . . 18 81 4.1. Instantiating the Domain Certification Authority . . . . . 18 82 4.2. Instantiating the Registrar . . . . . . . . . . . . . . . 18 83 4.3. Accepting New Entities . . . . . . . . . . . . . . . . . . 18 84 4.4. Automatic Enrolment of Devices . . . . . . . . . . . . . . 19 85 4.5. Secure Network Operations . . . . . . . . . . . . . . . . 19 86 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 20 87 5.1. EAP-EST . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 5.2. Request bootstrap token . . . . . . . . . . . . . . . . . 21 89 5.3. Request MASA authorization token . . . . . . . . . . . . . 21 90 5.4. Basic Configuration Information Package . . . . . . . . . 22 91 5.5. Request MASA authorization log . . . . . . . . . . . . . . 23 92 6. Reduced security operational modes . . . . . . . . . . . . . . 23 93 6.1. New Entity security reductions . . . . . . . . . . . . . . 24 94 6.2. Registrar security reductions . . . . . . . . . . . . . . 24 95 6.3. MASA security reductions . . . . . . . . . . . . . . . . . 25 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 97 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 26 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 100 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 101 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 102 Appendix A. Editor notes . . . . . . . . . . . . . . . . . . . . 27 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 105 1. Introduction 107 To literally "pull yourself up by the bootstraps" is an impossible 108 action. Similarly the secure establishment of a key infrastructure 109 without external help is also an impossibility. Today it is accepted 110 that the initial connections between nodes are insecure, until key 111 distribution is complete, or that domain-specific keying material is 112 pre-provisioned on each new device in a costly and non-scalable 113 manner. This document describes a zero-touch approach to 114 bootstrapping an entity by securing the initial distribution of key 115 material using third-party generic keying material, such as a 116 manufacturer installed IEEE 802.1AR certificate [IDevID], and a 117 corresponding third-party service on the Internet. 119 The two sides of an association being bootstrapped authenticate each 120 other and then determine appropriate authorization. This process is 121 described as four distinct steps between the existing domain and the 122 new entity being added: 124 o New entity authentication: "Who is this? What is its identity?" 125 o New entity authorization: "Is it mine? Do I want it? What are 126 the chances it has been compromised?" 127 o Domain authentication: "What is this domain's claimed identity?" 128 o Domain authorization: "Should I join it?" 130 A precise answer to these questions can not be obtained without 131 leveraging an established key infrastructure(s). The domain's 132 decisions are based on the new entity's authenticated identity, as 133 established by verification of previously installed credentials such 134 as a manufacturer installed IEEE 802.1AR certificate, and verified 135 back-end information such as a configured list of purchased devices 136 or communication with a trusted third-party. The new entity's 137 decisions are made according to verified communication with a trusted 138 third-party or in a strictly auditable fasion. 140 Optimal security is achieved with IEEE 802.1AR certificates on each 141 new entity, accompanied by a third-party Internet based service for 142 verification. The concept also works with less requirements, but is 143 then less secure. A domain can choose to accept lower levels of 144 security when a trusted third-party is not available so that 145 bootstrapping proceeds even at the risk of reduced security. Only 146 the domain can make these decisions based on administrative input and 147 known behavior of the new entity. 149 The result of bootstrapping is that a domain specific key 150 infrastructure is deployed. Since IEEE 802.1AR PKI certificates are 151 used for identifying the new entity and the public key of the domain 152 identity is leveraged during communiciations with an Internet based 153 service, which is itself authenticated using HTTPS, bootstrapping of 154 a domain specific Public Key Infrastructure (PKI) is fully described. 155 Sufficient agility to support bootstrapping alternative key 156 infrastructures (such as symmetric key solutions) is considered 157 although no such key infrastructure is described. 159 1.1. Terminology 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 163 "OPTIONAL" in this document are to be interpreted as described in 164 [RFC2119]. 166 The following terms are defined for clarity: 168 Domain Identity: The domain identity is the 160-bit SHA-1 hash of 169 the BIT STRING of the subjectPublicKey of the domain trust anchor 170 that is stored by the Domain CA. This is consistent with the 171 RFC5280 Certification Authority subject key identifier of the 172 Domain CA's self signed root certificate. (A string value bound 173 to the Domain CA's self signed root certificate subject and issuer 174 fields is often colloquially used as a humanized identity value 175 but during protocol discussions the more exact term as defined 176 here is used). 177 drop ship The physical distribution of equipment containing the 178 "factory default" configuration to a final destination. In zero- 179 touch scenarios there is no staging or pre-configuration during 180 drop-ship. 181 imprint the process where a device that wishes to join a network 182 acquires it's domain specific identity. This term is taken from 183 Konrad Lorenz's work in biology with new ducklings: during a 184 critical period, the duckling would assume that anything that 185 looks like a mother duck is in fact their mother. [imprinting] 186 pledge the prospective device, which has the identity provided to at 187 the factory. Neither the device nor the network knows if the 188 device yet knows if this device belongs with this network. This 189 is definition 6, according to [pledge] 191 2. Architectural Overview 193 The logical elements of the bootstrapping framework are described in 194 this section. Figure 1 provides a simplified overview of the 195 components. Each component is logical and may be combined with other 196 components as necessary. 198 Vendor components 199 . 200 .+---------------+ 201 +--------------Drop Ship------------------------.| Manufacturer | 202 | .+---------------+ 203 | .| M anufacturer | 204 | .| A uthorized | 205 | .| S igning | 206 | .| A uthority | 207 | .+---------------+ 208 V ...... ^ 209 +-------+ | 210 | New | +------------+ +-----------+ | 211 | Entity|<--L2-->| Proxy |<----->| | | 212 | | +------------+ | | | 213 | | | Registrar | | 214 | | | | | 215 | |<-----L3---------------------( may proxy )---------+ 216 | | +-----------+ 217 | | | 218 | | +----------------------------+ 219 | |<-----Enroll---->| Domain Certification | ^ 220 | |<-----Config---->| Authority | . 221 +-------+ . | Management and etc | . 222 . +----------------------------+ . 223 . . 224 ......................................... 225 "domain" components 227 Figure 1 229 Domain: The set of entities that trust a common key infrastructure 230 trust anchor. 231 Domain CA: The domain Certification Authority (CA) provides 232 certification functionalities to the domain. At a minimum it 233 provides certification functionalities to the Registrar and stores 234 the trust anchor that defines the domain. Optionally, it 235 certifies all elements. 236 Registrar: A representative of the domain that is configured, 237 perhaps autonomically, to decide whether a new device is allowed 238 to join the domain. The administrator of the domain interfaces 239 with a Registrar to control this process. Typically a Registrar 240 is "inside" its domain. 242 New Entity: A new device or virtual machine or software component 243 that is not yet part of the domain. 244 Proxy: A domain entity that helps the New Entity join the domain. A 245 Proxy facilitates communication for devices that find themselves 246 in an environment where they are not provided L3 connectivity 247 until after they are validated as members of the domain. 248 MASA Service: A Manufacturer Authorized Signing Authority (MASA) 249 service on the global Internet. At a minimum the MASA provides a 250 trusted repository for audit information concerning privacy 251 protected bootstrapping events. The MASA is recommended to 252 provide ownership validation services which allows for fully 253 secure zero-touch bootstrap of domain certificates with mutual 254 authentication. 256 We assume a multi-vendor network. In such an environment, there 257 could a MASA for each vendor that supports devices following this 258 document's specification, or an integrator could provide a MASA 259 service for all devices. 261 This document describes a secure zero-touch approach to bootstrapping 262 a key infrastructure; if certain devices in a network do not support 263 this approach, they can still be bootstrapped manually. Although 264 manual deployment is not scalable and is not a focus of this document 265 the necessary mechanisms are called out in this document to ensure 266 all such edge conditions are covered by the architectural and 267 protocol models. 269 3. Functional Overview 271 Entities behave in an autonomic fashion. They discover each other 272 and autonomically bootstrap into a key infrastructure deliminating 273 the autonomic domain. See 274 [I-D.irtf-nmrg-autonomic-network-definitions] for more information. 276 This section details the state machine and operational flow for each 277 of the main three entities. The New Entity, the Domain (primarily 278 the Registrar) and the MASA service. 280 The overall flow is shown in Figure 2: 282 +---------+ +----------+ +-----------+ 283 | New | | | | MASA | 284 | Entity | | Domain | | Service | 285 | | | | | (Internet)| 286 +---------+ +----------+ +-----------+ 287 | | | 288 |<-------discovery--------->| | 289 |---802.1AR credential----->| | 290 | | | 291 | [ accept device? ] | 292 | | | 293 | |---802.1AR identity-------->| 294 | |---Domain ID--------------->| 295 | | | 296 | | [device belongs] 297 | | [to domain? ] 298 | | | 299 | | [update audit log] 300 | | | 301 | |<---device history log------| 302 | |<-- authorization token-----| 303 | | | 304 | [ still accept device?] | 305 | | | 306 |<----authorization token---| | 307 |<----config information----| | 308 | | | 309 [authorization token valid?] | | 310 [apply config information] | | 311 | | | 312 |----domain enrolment------>| | 313 |<----domain certificate----| | 314 | | | 315 Figure 2 317 3.1. Behavior of a new entity 319 A New Entity that has not yet been bootstrapped attempts to find a 320 local domain and join it. 322 States of a New Entity are as follows: 324 +--------------+ 325 | Start | 326 | | 327 +------+-------+ 328 | 329 +------v-------+ 330 | Discover | 331 +------------> | 332 | +------+-------+ 333 | | 334 | +------v-------+ 335 | | Identity | 336 ^------------+ | 337 | rejected +------+-------+ 338 | | 339 | +------v-------+ 340 | | Imprint | Optional 341 ^------------+ <--+Manual input 342 | Bad MASA +------+-------+ 343 | response | 344 | +------v-------+ 345 | | Enroll | 346 ^------------+ | 347 | Enroll +------+-------+ 348 | Failure | 349 | +------v-------+ 350 | | Being | 351 ^------------+ Managed | 352 Factory +--------------+ 353 reset 355 Figure 3 357 State descriptions are as follows: 359 1. Discover a communication channel to the "closest" Registrar by 360 trying the following steps in this order: 361 A. Search for a Proxy on the local link using a link local 362 discovery protocol (no routable addresses are required for 363 this approach). If multiple local proxies are discovered 364 attempt communications with each before widening the search 365 to other options. The proxy relays information to the 366 registrar. If this fails: 367 B. Obtain an IP address using existing methods, such as SLAAC or 368 DHCPv6, and search for a local registrar using DNS service 369 discovery. If this fails: 371 C. Obtain an IP address (as above), and search for the domain 372 registrar using a pre-defined Factory provided Internet based 373 re-direct service. Various methods could be used, such as 374 DNS or RESTful APIs. 375 2. Identify itself. This is done by presenting an IEEE 802.1AR 376 credentials to the discovered Registrar (via a Proxy if 377 necessary). Included is a generated nonce that is specific to 378 this attempt. 379 3. Imprint on the Registrar. This requires verification of the MASA 380 service generated authorization token as provided by the 381 contacted Registrar. The authorization token contains the valid 382 domain(s) for this device and is signed by the MASA service. The 383 device uses a pre-installed certificate of the MASA service to 384 validate the signature of the MASA. The nonce information 385 previously provided is also checked, if it was not removed by the 386 Registrar. 387 4. Enroll by accepting the domain specific information from the 388 registrar, and by enrolling a domain certificate from the 389 registrar using a standard enrollment protocol, e.g. Enrolment 390 over Secure Transport (EST) [RFC7030]. 391 5. The New Entity is now a member of and Being Managed by the domain 392 and will only repeat the discovery aspects of bootstrapping if it 393 is returned to factory default settings. 394 The following sections describe each of these steps in more detail. 396 3.1.1. Discovery and Identity 398 Existing architectures provide the functionality for discovery of the 399 Domain Registrar. Use of an existing architecture is preferred over 400 development of a new architecture. Discovering of a Domain Proxy 401 that facilitates communication through to the Domain Registrar is 402 simplified as "discovery of the domain". A proxy is included in 403 Figure 1 although the simplified flow in Figure 2 does not include a 404 proxy - under the assuption that the proxy forwarding is mostly 405 transparent to the New Entity. Existing architectures for 406 investigation include: 408 IEEE 802.1X Where the New Entity can be cast as the "supplicant" and 409 the Proxy is the "authenticator". The bootstrapping protocol 410 messages are encapsulated as EAP methods. The "authenticator" 411 reencapsulates the EAPOL frames and forwards them to the 412 "Authentication Server", which provides Registrar functionalities. 413 PANA [RFC5191] [[EDNOTE: TBD]] 414 ND [RFC2461] / [RFC4861] [[EDNOTE: TBD]] NOTE: Neighbor Discovery 415 protocols do not describe a mechanism for forwarding messages. 416 Each provides a method for the New Entity to discover and initiate 417 communication with a local neighbor which is assumed to be a member 418 of the domain infrastructure. In each protocol methods are available 419 to support encapsulation of the bootstrapping protocol messages 420 described elsewhere in this document. Other protocols for 421 transporting bootstrapping messages can be added in future 422 references. 424 All security assocaitions established are between the new device and 425 the Registrar regardless of proxy operations. [[EDNOTE: this is the 426 simplest and most direct threat model but should be evaluated against 427 the anima use cases. It may be preferable to engage in secure 428 communications with the proxy itself?]] 430 The New Entity is expected to identify itself during one of the 431 communication protocol exchanges. For example using EAP-TLS. If the 432 client identity is rejected the New Entity repeats the Discovery 433 process using the next proxy or discovery method available. If 434 multiple proxies are available the New Entity tries each until a 435 successful bootstrapping occurs. The New Entity may prioritize 436 proxies selection order as appropriate for the anticipated 437 environment. 439 If Proxy discovery fails the New Entity moves on to discovering a 440 Registrar directly using an appropriate L3 protocol mechanisms. 442 [[EDNOTE: it is unclear yet if discovery happens on a per interface 443 basis or once per device. What is the requirement around joining 444 multiple domains; is this a bootstrapping requirement or is this a 445 broader autonomic requirement]] 447 3.1.2. Imprint 449 The domain trust anchor is received by the New Entity during the 450 boostrapping protocol methods in the form of a MASA authorization 451 token containing the domainID. The goal of the imprint state is to 452 securely obtain a copy of this trust anchor without involving human 453 interaction. 455 An enrollment protocol such as EST [RFC7030] details a set of non- 456 autonomic bootstrapping methods such as: 458 o using the Implicit Trust Anchor database (not an autonomic 459 solution because the URL must be securely distributed), 460 o engaging a human user to authorize the CA certificate using out- 461 of-band data (not an autonomic solution because the human user is 462 involved), 463 o using a configured Explicit TA database (not an autonomic solution 464 because the distribution of an explicit TA database is not 465 autonomic), 467 o and using a Certificate-Less TLS mutual authentication method (not 468 an autonomic solution because the distribution of symmetric key 469 material is not autonomic). 470 This document describes an additional autonomic method: 472 MASA authorization token Authorization tokens are obtained by the 473 Registrar from the MASA service and presented to the New Entity 474 for validation. 476 An arbitrary basic configuration information package that is signed 477 by the domain can be delivered alongside the authorization token. 478 This information is signed by the domain private keys and is a one 479 time delivery containing information such as which enrollment server 480 to communicate with and which management system to communicate with. 481 It is intended as a limited basic configuration for these purposes 482 and is not intended to deliver entire final configuration to the 483 device. 485 If the autonomic methods fails the New Entity returns to discovery 486 state and attempts bootstrapping with the next available discovered 487 Registrar. 489 3.1.3. Enrollment 491 As the final step of bootstrapping a Registrar helps to issue a 492 domain specific credential to the New Entity. For simplicity in this 493 document, a Registrar primarily facilitates issuing a credential by 494 acting as an RFC5280 Registration Authority for the Domain 495 Certification Authority. 497 Enrollment proceeds as described in Enrollment over Secure Transport 498 (EST) [RFC7030]. The New Entity contacts the Registrar using EST as 499 indicated: 501 o The New Entity is authenticated using the IEEE 802.1AR 502 credentials. 503 o The EST section 4.1.3 CA Certificates Response is verified using 504 the MASA authorization token provided domain identity. 506 3.1.4. Being Managed 508 Functionality to provide generic "configuration" information is 509 supported. The parsing of this data and any subsequent use of the 510 data, for example communications with a Network Management System is 511 out of scope but is expected to occur after bootstrapping enrollment 512 is complete. This ensures that all communications with management 513 systems which can divulge local security information (e.g. network 514 topology or raw key material) is secured using the local credentials 515 issued during enrollment. 517 See Section 3.5. 519 3.2. Behavior of a proxy 521 The role of the Proxy is to facilitate communications. The Proxy 522 forwards messages between the New Entity and a Registrar. Where 523 existing protocols, as detailed in Section 3.1.1, already provide 524 this functionality nothing additional is defined. 526 3.3. Behavior of the Registrar 528 Once a registrar is established it listens for new entities and 529 determines if they can join the domain. The registrar delivers any 530 necessary authorization information to the new device and facilitates 531 enrollment with the domain PKI. 533 Registrar behavior is as follows: 535 Contacted by New Entity 536 + 537 | 538 +-------v----------+ 539 | Entity | fail? 540 | Authentication +---------+ 541 +-------+----------+ | 542 | | 543 +-------v----------+ | 544 | Entity | fail? | 545 | Authorization +---------> 546 +-------+----------+ | 547 | | 548 +-------v----------+ | 549 | Claiming the | fail? | 550 | Entity +---------> 551 +-------+----------+ | 552 | | 553 +-------v----------+ | 554 | Log Verification | fail? | 555 | +---------> 556 +-------+----------+ | 557 | | 558 +-------v----------+ +----v-------+ 559 | Forward | | | 560 | Authorization | | Reject | 561 | token + config | | Device | 562 | to the Entity | | | 563 +------------------+ +------------+ 564 Figure 4 566 3.3.1. Entity Authentication 568 The applicable authentication methods detailed in EST [RFC7030] are: 570 o the use of an IEEE 802.1AR IDevID credential, 571 o or the use of a secret that is transmitted out of band between the 572 New Entity and the Registrar (this use case is not autonomic). 574 3.3.2. Entity Authorization 576 In a fully automated network all devices must be securely identified. 578 A Registrar accepts or declines a request to join the domain, based 579 on the authenticated identity presented and other policy defined 580 criteria such as Proxy identity. Automated acceptance criteria 581 include: 583 o allow any device of a specific type (as determined by the IEEE 584 802.1AR device identity), 585 o allow any device from a specific Factory (as determined by the 586 IEEE 802.1AR identity), 587 o allow a specific device from a Factory (as determined by the IEEE 588 802.1AR identity) 589 In all cases a Registrar must use the globally available MASA service 590 to verify that the device's history log does not include unexpected 591 Registrars. Because if a device had previously registered with 592 another domain, the registrar of that domain would show in the log. 594 If a device is accepted into the domain, it is then invited to 595 request a domain certificate through a certificate enrolment process. 596 The result is a common trust anchor and device certificates for all 597 autonomic devices in a domain. These certificates can subsequently 598 be used to determine the boundaries of the homenet, to authenticate 599 other domain nodes, and to autonomically enable services on the 600 homenet. 602 For each entity that will be accepted a Registrar maintains the 603 Factory CA identity and the entity's unique identifier. The Factory 604 CA identity could be implemented as the Factory CA root certificate 605 keyIdentifier (the 160-bit SHA-1 hash of the value of the BIT STRING 606 subjectPublicKey). For user interface purposes the keyIdentifier 607 information can be mapped to a colloquial Factory name (Registrars 608 can be shipped with the keyIdentifier of a significant number of 609 third-party manufacturers). 611 3.3.3. Claiming the New Entity 613 During initial bootstrapping the New Entity provides a nonce specific 614 to the particular bootstrapping attempt. The registrar should 615 include this nonce when claiming the New Entity from the Internet 616 based MASA service. If a nonce is provided by the Registrar, then 617 claims from an unauthenticated Registrar are serviced by the MASA 618 resource. 620 The Registrar can claim a New Entity that is not online by forming 621 the request using the entities unique identifier but not including a 622 nonce in the claim request. MASA authorization tokens obtained in 623 this way do not have a lifetime and they provide a permanent method 624 for the domain to claim the device. Evidence of such a claim is 625 provided in the audit log entries available to any future Registrar. 626 Such claims reduce the ability for future domains to secure 627 bootstrapping and therefore the Registrar MUST be authenticated by 628 the MASA service. 630 Claiming an entity establishes an audit log at the MASA server and 631 provides the Registrar with proof, in the form of a MASA 632 authorization token, that the log entry has been inserted. As 633 indicated in Section 3.1.2 a New Entity will only proceed with 634 bootstrapping if a validated MASA authorization token has been 635 recieved. The New Entity therefore enforces that bootstrapping only 636 occurs if the claim has been logged. 638 3.3.4. Log Verification 640 The Registrar requests the log information for the new entity from 641 the MASA service. The log is verified to confirm that the following 642 is true to the satisfaction of the registrar's configured parameters: 644 o Any nonceless entries in the log are associated with domainIDs 645 recognized by the registrar. The registar MAY be configured to 646 ignore the history of the device but it is RECOMMENDED that this 647 only be configured if the MASA server is known to perform 648 ownership validation or if Trusted Computing Group secure boot and 649 remote attestation is available. 650 o Any nonce'd entries are older than when the domain is known to 651 have physical possession of the new entity or that the domainIDs 652 are recognized by the registrar. 653 If any of these criteria are unacceptable to the registrar the entity 654 is rejected. 656 3.3.5. Forwarding Authorization Token plus Configuration 658 The Registrar forwards the received authorization token to the new 659 entity. To simplify the message flows an initial configuration 660 package can be delivered at this time which is signed by a 661 representative of the domain. 663 [[EDNOTE: format TBD. The configuration package signature data must 664 contain the full certificate path sufficient for the new entity to 665 use the domainID information (as a trust anchor) to accept and 666 validate the configuration)]] 668 3.4. Behavior of the MASA Service 670 The MASA service is provided by the Factory provider on the global 671 Internet. The URI of this service is well known. The URI should be 672 provided as an IEEE 802.1AR IDevID X.509 extension (a "MASA 673 authorization token Distribution Point" extension). 675 The MASA service provides the following functionalities to 676 Registrars: 678 3.4.1. Issue Authorization Token and Log the event 680 A Registrar POSTs a claim message optionally containing the bootstrap 681 nonce to the MASA server. 683 If a nonce is provided the MASA service responds to all requests. 684 The MASA service verifies the Registrar is representative of the 685 domain and generates a privacy protected log entry before responding 686 with the authorization token. 688 If a nonce is not provided then the MASA service MUST authenticate 689 the Registrar as a valid customer. This prevents denial of service 690 attacks. The specific level of authentication provided by the 691 customer is not defined here. An MASA Practice Statement (MPS) 692 similar to the Certification Authority CPS, as defined in RFC5280, is 693 provided by the Factory such that Registrar's can determine the level 694 of trust they have in the Factory. 696 3.4.2. Retrieve Audit Entries from Log 698 When determining if a New Entity should be accepted into a domain the 699 Registrar retrieves a copy of the audit log from the MASA service. 700 This contains a list of privacy protected domain identities that have 701 previously claimed the device. Included in the list is an indication 702 of the time the entry was made and if the nonce was included. 704 3.5. Leveraging the new key infrastructure / next steps 706 As the devices have a common trust anchor, device identity can be 707 securely established, making it possible to automatically deploy 708 services across the domain in a secure manner. 710 Examples of services: 711 o Device management. 712 o Routing authentication. 713 o Service discovery. 715 3.5.1. Network boundaries 717 When a device has joined the domain, it can validate the domain 718 membership of other devices. This makes it possible to create trust 719 boundaries where domain members have higher level of trusted than 720 external devices. Using the autonomic User Interface, specific 721 devices can be grouped into to sub domains and specific trust levels 722 can be implemented between those. 724 4. Domain Operator Activities 726 This section describes how an operator interacts with a domain that 727 supports the bootstrapping as described in this document. 729 4.1. Instantiating the Domain Certification Authority 731 This is a one time step by the domain administrator. This is an "off 732 the shelf" CA with the exception that it is designed to work as an 733 integrated part of the security solution. This precludes the use of 734 3rd party certification authority services that do not provide 735 support for delegation of certificate issuance decisions to a domain 736 managed Registration Authority. 738 4.2. Instantiating the Registrar 740 This is a one time step by the domain administrator. One or more 741 devices in the domain are configured take on a Registrar function. 743 A device can be configured to act as a Registrar or a device can 744 auto-select itself to take on this function, using a detection 745 mechanism to resolve potential conflicts and setup communication with 746 the Domain Certification Authority. Automated Registrar selection is 747 outside scope for this document. 749 4.3. Accepting New Entities 751 For each New Entity the Registrar is informed of the unique 752 identifier (e.g. serial number) along with the manufacturer's 753 identifying information (e.g. manufacturer root certificate). This 754 can happen in different ways: 756 1. Default acceptance: In the simplest case, the new device asserts 757 its unique identity to the registrar. The registrar accepts all 758 devices without authorization checks. This mode does not provide 759 security against intruders and is not recommended. 760 2. Per device acceptance: The new device asserts its unique identity 761 to the registrar. A non-technical human validates the identity, 762 for example by comparing the identity displayed by the registrar 763 (for example using a smartphone app) with the identity shown on 764 the packaging of the device. Acceptance may be triggered by a 765 click on a smartphone app "accept this device", or by other forms 766 of pairing. See also [I-D.behringer-homenet-trust-bootstrap] for 767 how the approach could work in a homenet. 768 3. Whitelist acceptance: In larger networks, neither of the previous 769 approaches is acceptable. Default acceptance is not secure, and 770 a manual per device methods do not scale. Here, the registrar is 771 provided a priori with a list of identifiers of devices that 772 belong to the network. This list can be extracted from an 773 inventory database, or sales records. If a device is detected 774 that is not on the list of known devices, it can still be 775 manually accepted using the per device acceptance methods. 776 4. Automated Whitelist: an automated process that builds the 777 necessary whitelists and inserts them into the larger network 778 domain infrastructure is plausible. Once set up, no human 779 intervention is required in this process. Defining the exact 780 mechanisms for this is out of scope although the registrar 781 authorization checks is identified as the logical integration 782 point of any future work in this area. 784 None of these approaches require the network to have permanent 785 Internet connectivity. Even when the Internet based MASA service is 786 used, it is possible to pre-fetch the required information from the 787 MASA a priori, for example at time of purchase such that devices can 788 enrol later. This supports use cases where the domain network may be 789 entirely isolated during device deployment. 791 Additional policy can be stored for future authorization decisions. 792 For example an expected deployment time window or that a certain 793 Proxy must be used. 795 4.4. Automatic Enrolment of Devices 797 The approach outlined in this document provides a secure zero-touch 798 method to enrol new devices without any pre-staged configuration. 799 New devices communicate with already enrolled devices of the domain, 800 which proxy between the new device and a Registrar. As a result of 801 this completely automatic operation, all devices obtain a domain 802 based certificate. 804 4.5. Secure Network Operations 806 The certificate installed in the previous step can be used for all 807 subsequent operations. For example, to determine the boundaries of 808 the domain: If a neighbor has a certificate from the same trust 809 anchor it can be assumed "inside" the same organization; if not, as 810 outside. See also Section 3.5.1. The certificate can also be used 811 to securely establish a connection between devices and central 812 control functions. Also autonomic transactions can use the domain 813 certificates to authenticate and/or encrypt direct interactions 814 between devices. The usage of the domain certificates is outside 815 scope for this document. 817 5. Protocol Details 819 For simplicity the bootstrapping protocol is described as extensions 820 to EST [RFC7030]. 822 EST provides a bootstrapping mechanism for new entities that are 823 configured with the URI of the EST server such that the Implicit TA 824 database can be used to authenticate the EST server. Alternatively 825 EST clients can "engage a human user to authorize the CA certificate 826 using out-of-band data such as a CA certificate". EST does not 827 provide a completely automated method of bootstrapping the PKI as 828 both of these methods require some user input (either of the URI or 829 authorizing the CA certificate). 831 This section details additional EST functionality that support 832 automated bootstrapping of the public key infrastructure. These 833 additions provide for fully automated bootstrapping. These additions 834 are to be optionally supported by the EST server within the same 835 .well-known URI tree as the existing EST URIs. 837 The "New Entity" is the EST client and the "Registrar" is the EST 838 server. 840 The extensions for the client are as follows: 842 o The New Entity provisionally accept the EST server certificate 843 during the TLS handshake as detailed in EST section 4.1.1 844 ("Bootstrap Distribution of CA Certificates"). 845 o The New Entity request and validates a "bootstrap token" as 846 described below. At this point the New Entity has sufficient 847 information to validate domain credentials. 848 o The New Entity calls the EST defined /cacerts method to obtain the 849 current CA certificate. These are validated using the "bootstrap 850 token". 851 o The New Entity completes bootstrapping as detailed in EST section 852 4.1.1. 854 These extensions could be implemented as an independent protocol from 855 EST but since the overlap with basic enrollment is extensive, 856 particularly with respect to client authorization, they are presented 857 here as additions to EST. 859 In order to obtain a validated bootstrap token and history logs the 860 Registrar contacts the MASA service Service using REST calls. 862 5.1. EAP-EST 864 In order to support Proxy environments EAP-EST is defined. 866 [[EDNOTE: TBD. EST is TLS with some data. EAP-TLS and other similar 867 protocols provide an example framework for filling out this section]] 869 5.2. Request bootstrap token 871 When the New Entity reaches the EST section 4.1.1 "Bootstrap 872 Distribution of CA Certificates" [[EDNOTE: out of date xref]] state 873 but wishes to proceed in a fully automated fashion it makes a request 874 for a MASA authorization token from the Registrar. 876 This is done with an HTTPS POST using the operation path value of 877 "/requestbootstraptoken". 879 The request format is JSON object containing a nonce. 881 Request media type: application/masanonce 883 Request format: a json file with the following: 885 {"nonce":"<64bit nonce value>"} 887 [[EDNOTE: exact format TBD. There is an advantage to having the 888 client sign the nonce (similar to a PKI Certification Signing 889 Request) since this allows the MASA service to confirm the actual 890 device identity. It is not clear that there is a security benefit 891 from this.]] 893 The Registrar validates the client identity as described in EST 894 [RFC7030] section 3.3.2. The registrar performs authorization as 895 detailed in Section 3.3.2. If authorization is successful the 896 Registrar obtains a MASA authorization token from the MASA service 897 (see Section 5.3). 899 The recieved MASA authorization token is returned to the New Entity. 901 5.3. Request MASA authorization token 903 A registrar requests the MASA authorization token from the MASA 904 service using a REST interface. 906 This is done with an HTTP POST using the operation path value of 907 "/requestMASAauthorization". 909 The request format is a JSON object optionally containing the nonce 910 value (as obtained from the bootstrap request) and the IEEE 802.1AR 911 identity of the device as a serial number (the full certificate is 912 not needed and no proof-of-possession information for the device 913 identity is included). The New Entity's serial number is extracted 914 from the subject name : 916 {"nonce":"<64bit nonce value>", "serialnumber", ""} 919 Inclusion of the nonce is optional because the Registar might request 920 an authorization token when the New Entity is not online, or when the 921 target bootstrapping environment is not on the same network as the 922 MASA server. 924 This information is encapsulated in a PKCS7 signed data structure 925 that is signed by the Registrar. The entire certificate chain, up to 926 and including the Domain CA, is included in the PKCS7. 928 The MASA service checks the internal consistency of the PKCS7 but is 929 unable to actually authenticate the domain identity information. The 930 domain is not know to the MASA server in advance and a shared trust 931 anchor is not implied. The MASA server verifies that the PKCS7 is 932 signed by a Registrar (by checking for the cmc-idRA field in the 933 Registrar certificate) certificate that was issued by the root 934 certificate included in the PKCS7. 936 The domain ID is extracted from the root certificate and is used to 937 generate the MASA authorization token and to update the audit log. 939 [[EDNOTE: The authorization token response format needs to be defined 940 here. It consists of the nonce, if supplied, the serialnumber and 941 the trust anchor of the domain. For example: 943 {"nonce":"<64bit nonce value>", "serialnumber", "","domainID":} 946 ]] 948 [[EDNOTE: This assumes the Registrar can extract the serial number 949 successfullly from the cilent certificate. The RFC4108 950 hardwareModuleName is likely the best known location.]] 952 5.4. Basic Configuration Information Package 954 When the MASA authorization token is returned to the New Entity an 955 arbitrary information package can be signed and delivered along side 956 it. This is signed by the Domain Registar. The New Entity first 957 verifies the MASA authorization token and, if it is valid, then uses 958 the domain's TA to validate the Information Package. 960 [[EDNOTE: The package format to be specified here. Any signed format 961 is viable and ideally one can simply be specified from netconf. The 962 Registar knows the New Entity device type from the 802.1AR credential 963 and so is able to determine the proper format for the configuration]] 965 5.5. Request MASA authorization log 967 A registrar requests the MASA authorization log from the MASA service 968 using this EST extension. 970 This is done with an HTTP GET using the operation path value of 971 "/requestMASAlog". 973 The log data returned is a file consisting of all previous log 974 entries. For example: 976 "log":[ 977 {"date":""}, 978 "domainID":"", 981 "nonce":""}, 983 {"date":""}, 984 "domainID":"", 987 "nonce":""}, 988 ] 990 Distribution of a large log is less than ideal. This structure can 991 be optimized as follows: only the most recent nonce'd log entry is 992 required in the response. All nonce-less entries for the same 993 domainID can be condensed into the single most recent nonceless 994 entry. 996 The Registrar uses this log information to make an informed decision 997 regarding the continued bootstrapping of the New Entity. 999 [[EDNOTE: certificate transparency might offer an alternative log 1000 entry method]] 1002 6. Reduced security operational modes 1004 A common requirement of bootstrapping is to support less secure 1005 operational modes for support specific use cases. The following 1006 sections detail specific ways that the New Entity, Registrar and MASA 1007 can be configured to run in a less secure mode for the indicated 1008 reasons. 1010 6.1. New Entity security reductions 1012 Although New Entity can choose to run in less secure modes this is 1013 MUST NOT be the default state because it permanently degrades the 1014 security for all other uses cases. When configured into lower 1015 security modes by a trusted administrator: 1017 1. The device may have an operational mode where it skips 1018 authorization token validation. For example if a physical button 1019 is depressed during the bootstrapping operation. This may occur 1020 when: A device Factory goes out of business or otherwise fails to 1021 provide a reliable MASA service or when local staging has pre- 1022 configured the New Entity with a known good Trust Anchor. 1023 2. The device may be configured during staging or requested from the 1024 factory to not require the MASA service authorization token. An 1025 entity that does not validate the domain identity is inherently 1026 dangerous as it may have had malware installed on it by a man-in- 1027 the-middle. This risk should be mitigated using attestation and 1028 measurement technologies. In order to support an unsecured 1029 imprint the New Entity MUST support remote attestation 1030 technologies such as is defined by the Trusted Computing Group. 1031 [[EDNOTE: How to include remote attestation into the boostrapping 1032 protocol exchange is TBD]]. This may occur when: The device 1033 Factory does not provide a MASA service. 1035 6.2. Registrar security reductions 1037 The Registrar can choose to accept devices using less secure methods. 1038 These methods are RECOMMENDED when low security models are needed as 1039 the security decisions are being made by the local administrator: 1040 1. The registrar may choose to accept all devices, or all devices of 1041 a particular type, at the administrator's discretion. This may 1042 occur when: Informing the Registrar of unique identifiers of new 1043 entities might be operationally difficult. 1044 2. The registrar may choose to accept devices that claim a unique 1045 identity without the benefit of authenticating that claimed 1046 identity. This may occur when: The New Entity does not include 1047 an IEEE 802.1AR factory installed credential. 1048 3. The registrar may request nonce-less authorization tokens from 1049 the MASA service. These tokens can then be transmitted to the 1050 Registrar and stored until they are needed during bootstrapping 1051 operations. This is for use cases where target network is 1052 protected by an air gap and therefore can not contact the MASA 1053 service during New Entity deployment. 1055 6.3. MASA security reductions 1057 Lower security modes chosen by the MASA service effect all device 1058 deployments unless paired with strict device ownership validation, in 1059 which case these modes can be provided as additional features for 1060 specific customers. The MASA service can choose to run in less 1061 secure modes by: 1063 1. Not enforcing that a Nonce is in the authorization token. This 1064 results in distribution of authorization tokens that never expire 1065 and effectly makes the Domain an always trusted entity to the New 1066 Entity during any subsequent bootstrapping attempts. That this 1067 occured is captured in the log information so that the Domain 1068 registrar can make appropriate security decisions when a new 1069 device joins the domain. This is useful to support use cases 1070 where Registrars might not be online during actual device 1071 deployment. 1072 2. Not verifying ownership before responding with an authorization 1073 token. Doing so relieves the vendor providing MASA services from 1074 having to tracking ownership during shipping and supply chain. 1075 The registrar uses the log information as a defense in depth 1076 strategy to ensure that this does not occur unexpectedly. For 1077 example when purchasing used equipment a MASA response is 1078 necessary for autonomic provisioning but the greatest level of 1079 security is achieved when the MASA server is also performing 1080 ownership validation. 1082 7. Security Considerations 1084 In order to support a wide variety of use cases, devices can be 1085 claimed by a registrar without proving possession of the device in 1086 question. This would result in a nonceless, and thus always valid, 1087 claim. Or would result in an invalid nonce being associated with a 1088 claim. The MASA service is required to authenticate such Registrars 1089 but no programmatic method is provided to ensure good behavior by the 1090 MASA service. Nonceless entries into the audit log therefore 1091 permanently reduce the value of a device because future Registrars, 1092 during future bootstrap attempts, would now have to be configured 1093 with policy to ignore previously (and potentially unknown) domains. 1095 Future registrars are recommended to take the audit history of a 1096 device into account when deciding to join such devices into their 1097 network. If the MASA server were to have allowed a significantly 1098 large number of claims this might become onerous to the MASA server 1099 which must maintain all the extra log entries. Ensuring the registar 1100 is representative of a valid customer domain even without validating 1101 ownership helps to mitigate this. 1103 It is possible for an attacker to send an authorization request to 1104 the MASA service directly after the real Registrar obtains an 1105 authorization log. If the attacker could also force the 1106 bootstrapping protocol to reset there is a theoretical opportunity 1107 for the attacker to use the authorization token to take control of 1108 the New Entity but then proceed to enrol with the target domain. To 1109 prevent this the MASA service is rate limited to only generate 1110 authorization tokens at a rate of 1 per minute. The Registrar 1111 therefore has at least 1 minute to get the response back to the New 1112 Entity. [[EDNOTE: a better solution can likely be found. This text 1113 captures the issue for now. Binding the logs via a ]] Also the 1114 Registrar can double check the log information after enrolling the 1115 New Entity. 1117 The MASA service could lock a claim and refuse to issue a new token. 1118 Or the MASA service could go offline (for example if a vendor went 1119 out of business). This functionality provides benefits such as theft 1120 resistance, but it also implies an operational risk. This can be 1121 mitigated by Registrars that request nonce-less authorization tokens. 1123 7.1. Trust Model 1125 [[EDNOTE: (need to describe that we need to trust the device h/w. To 1126 be completed.)]] 1128 8. Acknowledgements 1130 We would like to thank the various reviewers for their input, in 1131 particular Markus Stenberg, Brian Carpenter, Fuyu Eleven. 1133 9. References 1135 9.1. Normative References 1137 [IDevID] IEEE Standard, "IEEE 802.1AR Secure Device Identifier", 1138 December 2009, . 1141 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1142 Requirement Levels", BCP 14, RFC 2119, March 1997. 1144 [RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over 1145 Secure Transport", RFC 7030, October 2013. 1147 9.2. Informative References 1149 [I-D.behringer-homenet-trust-bootstrap] 1150 Behringer, M., Pritikin, M., and S. Bjarnason, 1151 "Bootstrapping Trust on a Homenet", 1152 draft-behringer-homenet-trust-bootstrap-02 (work in 1153 progress), February 2014. 1155 [I-D.irtf-nmrg-autonomic-network-definitions] 1156 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1157 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1158 Networking - Definitions and Design Goals", 1159 draft-irtf-nmrg-autonomic-network-definitions-07 (work in 1160 progress), March 2015. 1162 [imprinting] 1163 Wikipedia, "Wikipedia article: Imprinting", July 2015, 1164 . 1166 [pledge] Dictionary.com, "Dictionary.com Unabridged", July 2015, 1167 . 1169 Appendix A. Editor notes 1171 [[EDNOTE: This section is to capturing rough notes between editors 1172 and Anima Bootstrapping design team members. This entire section to 1173 be removed en masse before finalization]] 1175 Change Discussion: 1177 02 Moved sections for readability, Updated introduction, simplified 1178 functional overview to avoid distractions from optional elements, 1179 addressed updated security considerations, fleshed out state 1180 machines. 1182 The following is a non-prioritized list of work items currently 1183 identified: 1184 o Continue to address gaps/opportunities highlighted by community 1185 work on bootstrappping. Refs: IETF92 "Survey of Security 1186 Bootstrapping", Aana Danping He, behcet Sarikaya. "NETCONF Zero 1187 Touch Update for ANIMA" 1188 https://www.ietf.org/proceedings/92/anima.html and "Bootstrapping 1189 Key Infrastructures", Pritikin, Behringer, Bjarnason 1190 o Intergrate "Ownership Voucher" as a valid optional format for the 1191 MASA response. So long as the issuance of this is logged and 1192 captured in the log response then the basic flow and threat model 1193 is substantially the same. 1195 o Attempt to re-use existing work as per the charter: Toerless 1196 notes: a) are existing [eap] options? or too complex? or doens't 1197 work? b) our own method (e.g. EAP-ANIMA c) if b then investigate 1198 using signaling protocol). 1199 o 1201 Authors' Addresses 1203 Max Pritikin 1204 Cisco 1206 Email: pritikin@cisco.com 1208 Michael C. Richardson 1209 Sandelman Software Works 1210 470 Dawson Avenue 1211 Ottawa, ON K1Z 5V7 1212 CA 1214 Email: mcr+ietf@sandelman.ca 1215 URI: http://www.sandelman.ca/ 1217 Michael H. Behringer 1218 Cisco 1220 Email: mbehring@cisco.com 1222 Steinthor Bjarnason 1223 Cisco 1225 Email: sbjarnas@cisco.com