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