idnits 2.17.1 draft-ietf-anima-bootstrapping-keyinfra-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2015) is 3112 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC6763' is mentioned on line 478, but not defined == Missing Reference: 'RFC6762' is mentioned on line 475, but not defined == Missing Reference: 'RFC5209' is mentioned on line 1296, but not defined Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG M. Pritikin 3 Internet-Draft Cisco 4 Intended status: Informational M. Richardson 5 Expires: April 20, 2016 SSW 6 M. Behringer 7 S. Bjarnason 8 Cisco 9 October 18, 2015 11 Bootstrapping Key Infrastructures 12 draft-ietf-anima-bootstrapping-keyinfra-01 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 April 20, 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 . . . . . . . . . . . . . . . . . . . . . 7 64 3.1. Behavior of a new entity . . . . . . . . . . . . . . . . 9 65 3.1.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 11 66 3.1.2. Identity . . . . . . . . . . . . . . . . . . . . . . 12 67 3.1.3. Request Join . . . . . . . . . . . . . . . . . . . . 12 68 3.1.4. Imprint . . . . . . . . . . . . . . . . . . . . . . . 13 69 3.1.5. Enrollment . . . . . . . . . . . . . . . . . . . . . 14 70 3.1.6. Being Managed . . . . . . . . . . . . . . . . . . . . 14 71 3.2. Behavior of a proxy . . . . . . . . . . . . . . . . . . . 15 72 3.3. Behavior of the Registrar (Bootstrap Server) . . . . . . 15 73 3.3.1. Entity Authentication . . . . . . . . . . . . . . . . 16 74 3.3.2. Entity Authorization . . . . . . . . . . . . . . . . 16 75 3.3.3. Claiming the New Entity . . . . . . . . . . . . . . . 17 76 3.3.4. Log Verification . . . . . . . . . . . . . . . . . . 18 77 3.3.5. Forwarding Audit Token plus Configuration . . . . . . 18 78 3.4. Behavior of the MASA Service . . . . . . . . . . . . . . 19 79 3.4.1. Issue Authorization Token and Log the event . . . . . 19 80 3.4.2. Retrieve Audit Entries from Log . . . . . . . . . . . 19 81 3.5. Leveraging the new key infrastructure / next steps . . . 20 82 3.5.1. Network boundaries . . . . . . . . . . . . . . . . . 20 83 3.6. Interactions with Network Access Control . . . . . . . . 20 84 4. Domain Operator Activities . . . . . . . . . . . . . . . . . 20 85 4.1. Instantiating the Domain Certification Authority . . . . 21 86 4.2. Instantiating the Registrar . . . . . . . . . . . . . . . 21 87 4.3. Accepting New Entities . . . . . . . . . . . . . . . . . 21 88 4.4. Automatic Enrollment of Devices . . . . . . . . . . . . . 22 89 4.5. Secure Network Operations . . . . . . . . . . . . . . . . 22 90 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 23 91 5.1. Request Audit Token . . . . . . . . . . . . . . . . . . . 25 92 5.2. Request Audit Token from MASA . . . . . . . . . . . . . . 26 93 5.3. Basic Configuration Information Package . . . . . . . . . 28 94 5.4. Request MASA authorization log . . . . . . . . . . . . . 28 95 6. Reduced security operational modes . . . . . . . . . . . . . 29 96 6.1. New Entity security reductions . . . . . . . . . . . . . 29 97 6.2. Registrar security reductions . . . . . . . . . . . . . . 29 98 6.3. MASA security reductions . . . . . . . . . . . . . . . . 30 99 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 100 7.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 32 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 103 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 104 9.2. Informative References . . . . . . . . . . . . . . . . . 32 105 Appendix A. Editor notes . . . . . . . . . . . . . . . . . . . . 33 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 108 1. Introduction 110 To literally "pull yourself up by the bootstraps" is an impossible 111 action. Similarly the secure establishment of a key infrastructure 112 without external help is also an impossibility. Today it is accepted 113 that the initial connections between nodes are insecure, until key 114 distribution is complete, or that domain-specific keying material is 115 pre-provisioned on each new device in a costly and non-scalable 116 manner. This document describes a zero-touch approach to 117 bootstrapping an entity by securing the initial distribution of key 118 material using third-party generic keying material, such as a 119 manufacturer installed IEEE 802.1AR certificate [IDevID], and a 120 corresponding third-party service on the Internet. 122 The two sides of an association being bootstrapped authenticate each 123 other and then determine appropriate authorization. This process is 124 described as four distinct steps between the existing domain and the 125 new entity being added: 127 o New entity authentication: "Who is this? What is its identity?" 129 o New entity authorization: "Is it mine? Do I want it? What are 130 the chances it has been compromised?" 132 o Domain authentication: "What is this domain's claimed identity?" 134 o Domain authorization: "Should I join it?" 136 A precise answer to these questions can not be obtained without 137 leveraging an established key infrastructure(s). The domain's 138 decisions are based on the new entity's authenticated identity, as 139 established by verification of previously installed credentials such 140 as a manufacturer installed IEEE 802.1AR certificate, and verified 141 back-end information such as a configured list of purchased devices 142 or communication with a trusted third-party. The new entity's 143 decisions are made according to verified communication with a trusted 144 third-party or in a strictly auditable fasion. 146 Optimal security is achieved with IEEE 802.1AR certificates on each 147 new entity, accompanied by a third-party Internet based service for 148 verification. Bootstrapping concepts run to completion with less 149 requirements, but are then less secure. A domain can choose to 150 accept lower levels of security when a trusted third-party is not 151 available so that bootstrapping proceeds even at the risk of reduced 152 security. Only the domain can make these decisions based on 153 administrative input and known behavior of the new entity. 155 The result of bootstrapping is that a domain specific key 156 infrastructure is deployed. Since IEEE 802.1AR PKI certificates are 157 used for identifying the new entity, and the public key of the domain 158 identity is leveraged during communiciations with an Internet based 159 service, which is itself authenticated using HTTPS, bootstrapping of 160 a domain specific Public Key Infrastructure (PKI) is described. 161 Sufficient agility to support bootstrapping alternative key 162 infrastructures (such as symmetric key solutions) is considered 163 although no such alternate key infrastructure is described. 165 1.1. Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described in 170 [RFC2119]. 172 The following terms are defined for clarity: 174 DomainID: The domain identity is the 160-bit SHA-1 hash of the BIT 175 STRING of the subjectPublicKey of the domain trust anchor that is 176 stored by the Domain CA. This is consistent with the RFC5280 177 Certification Authority subject key identifier of the Domain CA's 178 self signed root certificate. (A string value bound to the Domain 179 CA's self signed root certificate subject and issuer fields is 180 often colloquially used as a humanized identity value but during 181 protocol discussions the more exact term as defined here is used). 183 drop ship: The physical distribution of equipment containing the 184 "factory default" configuration to a final destination. In zero- 185 touch scenarios there is no staging or pre-configuration during 186 drop-ship. 188 imprint: the process where a device that wishes to join a network 189 acquires it's domain specific identity. This term is taken from 190 Konrad Lorenz's work in biology with new ducklings: during a 191 critical period, the duckling would assume that anything that 192 looks like a mother duck is in fact their mother. [imprinting] 194 pledge: the prospective device, which has the identity provided to 195 at the factory. Neither the device nor the network knows if the 196 device yet knows if this device belongs with this network. This 197 is definition 6, according to [pledge] 199 Audit Token: A signed token from the manufacturer authorized signing 200 authority indicating that the bootstrapping event has been 201 successfully logged. This has been referred to as an 202 "authorization token" indicating that it authorizes bootstrapping 203 to proceed. 205 Ownership Voucher: A signed voucher from the vendor vouching that a 206 specific domain "owns" the new entity. 208 2. Architectural Overview 210 The logical elements of the bootstrapping framework are described in 211 this section. Figure 1 provides a simplified overview of the 212 components. Each component is logical and may be combined with other 213 components as necessary. 215 . 216 .+------------------------+ 217 +--------------Drop Ship-------------->.| Vendor Service | 218 | .+------------------------+ 219 | .| M anufacturer| | 220 | .| A uthorized |Ownership| 221 | .| S igning |Tracker | 222 | .| A uthority | | 223 | .+--------------+---------+ 224 | .............. ^ 225 V | 226 +-------+ ............................................|... 227 | | . | . 228 | | . +------------+ +-----------+ | . 229 | | . | | | | | . 230 | <---L2---> | | <-------+ . 231 | | or | Proxy | | Registrar | . 232 | <---L3---> <---L3--> | . 233 | New | . | | | | . 234 | Entity| . +------------+ +-----+-----+ . 235 | | . | . 236 | | . +-----------------+----------+ . 237 | | . | Domain Certification | . 238 | | . | Authority | . 239 +-------+ . | Management and etc | . 240 . +----------------------------+ . 241 . . 242 ................................................ 243 "Domain" components 245 Figure 1 247 Domain: The set of entities that trust a common key infrastructure 248 trust anchor. This includes the Proxy, Registrar, Domain 249 Certificate Authority, Management components and any existing 250 entity that is already a member of the domain. 252 Domain CA: The domain Certification Authority (CA) provides 253 certification functionalities to the domain. At a minimum it 254 provides certification functionalities to the Registrar and stores 255 the trust anchor that defines the domain. Optionally, it 256 certifies all elements. 258 Registrar: A representative of the domain that is configured, 259 perhaps autonomically, to decide whether a new device is allowed 260 to join the domain. The administrator of the domain interfaces 261 with a Registrar to control this process. Typically a Registrar 262 is "inside" its domain. 264 New Entity: A new device or virtual machine or software component 265 that is not yet part of the domain. 267 Proxy: A domain entity that helps the New Entity join the domain. A 268 Proxy facilitates communication for devices that find themselves 269 in an environment where they are not provided connectivity until 270 after they are validated as members of the domain. The New Entity 271 is unaware that they are communicating with a proxy rather than 272 directly with the Registrar. 274 MASA Service: A Manufacturer Authorized Signing Authority (MASA) 275 service on the global Internet. The MASA provides a trusted 276 repository for audit log information concerning privacy protected 277 bootstrapping events. 279 Ownership Tracker An Ownership Tracker service on the global 280 internet. The Ownership Tracker uses business processes to 281 accurately track ownership of all devices shipped against domains 282 that have purchased them. Although optional this component allows 283 vendors to provide additional value in cases where their sales and 284 distribution channels allow for accurately tracking of such 285 ownership. 287 We assume a multi-vendor network. In such an environment there could 288 be a MASA or Ownership Tracker for each vendor that supports devices 289 following this document's specification, or an integrator could 290 provide a MASA service for all devices. It is unlikely that an 291 integrator could provide Ownership Tracking services for multiple 292 vendors. 294 This document describes a secure zero-touch approach to bootstrapping 295 a key infrastructure; if certain devices in a network do not support 296 this approach, they can still be bootstrapped manually. Although 297 manual deployment is not scalable and is not a focus of this document 298 the necessary mechanisms are called out in this document to ensure 299 such edge conditions are covered by the architectural and protocol 300 models. 302 3. Functional Overview 304 Entities behave in an autonomic fashion. They discover each other 305 and autonomically bootstrap into a key infrastructure deliminating 306 the autonomic domain. See 307 [I-D.irtf-nmrg-autonomic-network-definitions] for more information. 309 This section details the state machine and operational flow for each 310 of the main three entities. The New Entity, the Domain (primarily 311 the Registrar) and the MASA service. 313 The overall flow is shown in Figure 2: 315 +---------+ +----------+ +-----------+ 316 | New | Proxy | | | Vendor | 317 | Entity | not | Domain | | Service | 318 | | shown | | | (Internet)| 319 +---------+ +----------+ +-----------+ 320 | | | 321 |<-------discovery--------->| | 322 |---IEEE 802.1AR identity-->| | 323 | | | 324 | [accept device?] | 325 | | | 326 | |---IEEE 802.1AR identity--->| 327 | |---Domain ID--------------->| 328 | | | 329 | | [optional: does 330 | | the device belong 331 | | to the domain?] 332 | | | 333 | | [update audit log] 334 | | | 335 | |<---device audit log--------| 336 | |<---audit token-------------| 337 | |<-- ownership voucher-------| 338 | | (optional) | 339 | | | 340 | [ still accept device?] | 341 | | | 342 |<----audit token-----------| | 343 |<----ownership voucher-----| (optional) | 344 |<----config information----| | 345 | | | 346 [audit token valid?] | | 347 [or ownership voucher valid?] | | 348 [apply config information] | | 349 | | | 350 |----domain enrollment----->| | 351 |<----domain certificate----| | 352 | | | 354 Figure 2 356 3.1. Behavior of a new entity 358 A New Entity that has not yet been bootstrapped attempts to find a 359 local domain and join it. 361 States of a New Entity are as follows: 363 +--------------+ 364 | Start | 365 | | 366 +------+-------+ 367 | 368 +------v-------+ 369 | Discover | 370 +------------> | 371 | +------+-------+ 372 | | 373 | +------v-------+ 374 | | Identity | 375 ^------------+ | 376 | rejected +------+-------+ 377 | | 378 | +------v-------+ 379 | | Request | 380 | | Join | 381 | +------+-------+ 382 | | 383 | +------v-------+ 384 | | Imprint | Optional 385 ^------------+ <--+Manual input 386 | Bad Vendor +------+-------+ 387 | response | 388 | +------v-------+ 389 | | Enroll | 390 ^------------+ | 391 | Enroll +------+-------+ 392 | Failure | 393 | +------v-------+ 394 | | Being | 395 ^------------+ Managed | 396 Factory +--------------+ 397 reset 399 Figure 3 401 State descriptions are as follows: 403 1. Discover a communication channel to the "closest" Registrar by 404 trying the following steps in this order: 406 A. Search for a Proxy on the local link using a link local 407 discovery protocol (no routable addresses are required for 408 this approach). If multiple local proxies are discovered 409 attempt communications with each before widening the search 410 to other options. The proxy relays information to the 411 registrar. If this fails: 413 B. Obtain an IP address using existing methods, such as SLAAC or 414 DHCPv6, and search for a local registrar using DNS service 415 discovery. [[EDNOTE: ]]If this fails: 417 C. Obtain an IP address (as above), and search for the domain 418 registrar using a pre-defined Factory provided Internet based 419 re-direct service. Various methods could be used, such as 420 DNS or RESTful APIs. 422 2. Identify itself. This is done by presenting an IEEE 802.1AR 423 credentials to the discovered Registrar (via a Proxy if 424 necessary). Included is a generated nonce that is specific to 425 this attempt. 427 3. Requests to Join the Discovered domain. The device indicates the 428 Imprint methods it will accept and provides a nonce ensuring that 429 any responses can be associated with this particular 430 bootstrapping attempt. 432 4. Imprint on the Registrar. This requires verification of the MASA 433 service generated Audit Token as provided by the contacted 434 Registrar or the validation of the vendor provided ownership 435 voucher. The Audit Token contains the DomainID information for 436 this device and is signed by the MASA service. The device uses a 437 pre-installed root certificate of the MASA service to validate 438 the signature of the Audit Token or the Ownership Voucher. 440 5. Enroll by accepting the domain specific information from the 441 Registrar, and by obtaining a domain certificate from the 442 Registrar using a standard enrollment protocol, e.g. Enrolment 443 over Secure Transport (EST) [RFC7030]. 445 6. The New Entity is now a member of, and can be managed by, the 446 domain and will only repeat the discovery aspects of 447 bootstrapping if it is returned to factory default settings. 449 The following sections describe each of these steps in more detail. 451 3.1.1. Discovery 453 Existing protocols provide the functionality for discovery of the 454 Domain Bootstrap Server. The result of discovery might be 455 communication with a proxy instead of a Domain Bootstrap Server. In 456 such a case the proxy facilitates communication with the actual 457 Domain Bootstrap Server in a manner that is transparent to the New 458 Entity. 460 To discover the Domain Bootstrap Server the New Entity performs the 461 following actions in this order: 463 1. MUST: Obtains a local address using either IPv4 or IPv6 methods 464 as described in [[EDNOTE: do we need a reference?]]. 466 2. MUST: Attempt to establish a TLS connection to the next hop 467 neighbor at a well known AN port building on the [[EDNOTE: AN 468 node discovery discussion, need a reference??]]. [Toerless to 469 provide updated text] 471 3. MUST: unsecured-GRASP as a link local discovery method? 472 [Toerless to provide updated text] 474 4. MAY: Performs DNS-based Service Discovery [RFC6763] over 475 Multicast DNS [RFC6762] searching for the service 476 "_bootstrapks._tcp.local." 478 5. MAY: Performs DNS-based Service Discovery [RFC6763] over normal 479 DNS operations. In this case the domain is known so the service 480 searched for is "_bootstrapks._tcp.example.com". 482 6. MAY: If no local bootstrapks service is located using the DNS- 483 based Sevice Discovery methods the New Entity contacts a well 484 known vendor provided bootstrapping server by perfoming a DNS 485 lookup using a well known URI such as "bootstrapks.vendor- 486 example.com". 488 Once a domain bootstrapping server is discovered the New Entity 489 communicates with the discovered server using the bootstrapping 490 protocol defined in Section 5. The current DNS services returned 491 during each query is maintained until bootstrapping is completed. If 492 bootstrapping fails and the New Entity returns to the Discovery state 493 it picks up where it left off and continues attempting bootstrapping. 494 For example if the first Multicast DNS _bootstrapks._tcp.local 495 response doens't work then the second and third responses are tried. 496 If these fail the New Entity moves on to normal DNS-based Service 497 Discovery. 499 Once all discovered services are attempted the device SHOULD return 500 to Multicast DNS and keep trying. The New Entity may prioritize 501 selection order as appropriate for the anticipated environment. 503 [[EDNOTE: An appropriate backoff or rate limiting strategy should be 504 defined here such that the device doesn't flood the local network 505 with queries. If the device were to eventually give up -- or at 506 least have too long between attempts -- a power cycle would restart 507 the backoff mechanism.]] 509 [[EDNOTE: it is unclear yet if discovery happens on a per interface 510 basis or once per device. What is the requirement around joining 511 multiple domains; is this a bootstrapping requirement or is this a 512 broader autonomic requirement]] [[EDNOTE: b. carpenter: I seem to 513 think we settled on joining one domain (which might be a sub-domain) 514 and then doing some sort of cross-certification to get authenticated 515 and authorized in another domain. If so, it isn't a bootstrap 516 requirement.]] 518 3.1.2. Identity 520 The New Entity identifies itself during the communication protocol 521 handshake. If the client identity is rejected the New Entity repeats 522 the Discovery process using the next proxy or discovery method 523 available. 525 The boostrapping protocol server is as of yet not validated. Thus 526 this connection is provisional and all data recieved is untrusted 527 until sufficiently validated even though it is over a (D)TLS 528 connection. This is aligned with the existing provisional mode of 529 EST [RFC7030] during s4.1.1 "Bootstrap Distribution of CA 530 Certificates". 532 All security associations established are between the new device and 533 the Bootstrapping server regardless of proxy operations. 535 3.1.3. Request Join 537 The New Entity POSTs a request to join the domain to the 538 Bootstrapping server. This request contains a New Entity generated 539 nonce and informs the Bootstrapping server which imprint methods the 540 New Entity will accept. 542 As indicated in EST [RFC7030] the bootstrapping server MAY redirect 543 the client to an alternate server. This is most useful in the case 544 where the New Entity has resorted to a well known vendor URI and is 545 communicating with the vendor's Registrar directly. In this case the 546 New Entity has authenticated the Registrar using the local Implicit 547 Trust Anchor database and can therefore treat the redirect URI as a 548 trusted URI which can also be validated using the Implicit Trust 549 Anchor database. Since client authentication occurs during the TLS 550 handshake the bootstrapping server has sufficient information to 551 apply appropriate policy concerning which server to redirect to. 553 The nonce ensures the New Entity can verify that responses are 554 specific to this bootstrapping attempt. This minimizes the use of 555 global time and provides a substantial benefit for devices without a 556 valid clock. 558 3.1.4. Imprint 560 The domain trust anchor is received by the New Entity during the 561 boostrapping protocol methods in the form of either an Audit Token 562 containing the domainID or an explicit ownership voucher. The goal 563 of the imprint state is to securely obtain a copy of this trust 564 anchor without involving human interaction. 566 The enrollment protocol EST [RFC7030] details a set of non-autonomic 567 bootstrapping methods such as: 569 o using the Implicit Trust Anchor database (not an autonomic 570 solution because the URL must be securely distributed), 572 o engaging a human user to authorize the CA certificate using out- 573 of-band data (not an autonomic solution because the human user is 574 involved), 576 o using a configured Explicit TA database (not an autonomic solution 577 because the distribution of an explicit TA database is not 578 autonomic), 580 o and using a Certificate-Less TLS mutual authentication method (not 581 an autonomic solution because the distribution of symmetric key 582 material is not autonomic). 584 This document describes additional autonomic methods: 586 MASA audit token Audit tokens are obtained by the Registrar from the 587 MASA service and presented to the New Entity for validation. 588 These indicate to the New Entity that joining the domain has been 589 logged by a trusted logging server. 591 Ownership Voucher Ownership Vouchers are obtained by the Registrar 592 from the MASA service and explicitly indicate the fully qualified 593 domain name of the domain the new entity currently belongs to. 595 Since client authentication occurs during the TLS handshake the 596 bootstrapping server has sufficient information to apply appropriate 597 policy concerning which method to use. 599 An arbitrary basic configuration information package that is signed 600 by the domain can be delivered alongside the Audit Token or ownership 601 validation. This information is signed by the domain private keys 602 and is a one time delivery containing information such as which 603 enrollment server to communicate with and which management system to 604 communicate with. It is intended as a limited basic configuration 605 for these purposes and is not intended to deliver entire final 606 configuration to the device. 608 If the autonomic methods fail the New Entity returns to discovery 609 state and attempts bootstrapping with the next available discovered 610 Registrar. 612 3.1.5. Enrollment 614 As the final step of bootstrapping a Registrar helps to issue a 615 domain specific credential to the New Entity. For simplicity in this 616 document, a Registrar primarily facilitates issuing a credential by 617 acting as an RFC5280 Registration Authority for the Domain 618 Certification Authority. 620 Enrollment proceeds as described in Enrollment over Secure Transport 621 (EST) [RFC7030]. The New Entity contacts the Registrar using EST as 622 indicated: 624 o The New Entity is authenticated using the IEEE 802.1AR 625 credentials. 627 o The EST section 4.1.3 CA Certificates Response is verified using 628 either the Audit Token which provided the domain identity -or- 630 o The EST server is authenticated by using the Owership Voucher 631 indicated fully qualified domain name to build the EST URI such 632 that EST section 4.1.1 bootstrapping using the New Entity implicit 633 Trust Anchor database can be used. 635 3.1.6. Being Managed 637 Functionality to provide generic "configuration" information is 638 supported. The parsing of this data and any subsequent use of the 639 data, for example communications with a Network Management System is 640 out of scope but is expected to occur after bootstrapping enrollment 641 is complete. This ensures that all communications with management 642 systems which can divulge local security information (e.g. network 643 topology or raw key material) is secured using the local credentials 644 issued during enrollment. 646 See Section 3.5. 648 3.2. Behavior of a proxy 650 The role of the Proxy is to facilitate communications. The Proxy 651 forwards EST transport (TLS or DTLS) packets between the New Entity 652 and the Registrar that has been configured on the Proxy. 654 [[EDNOTE: To what extent do we need to explain how this occurs? It 655 is sufficient to indicate the basic behavior or do we need to 656 indicate here all the details? A rough implementation of an ipv4 657 proxy would be as follows: 659 socat -v tcp4-listen:443,reuseaddr,fork tcp4:registrar.example.com:443 661 There have been suggestions that a stateless proxy implementation 662 using a DTLS extension would be preferred. Is this a future 663 optimization opportunity or a short term requirement?]] 665 3.3. Behavior of the Registrar (Bootstrap Server) 667 Once a Registrar is established it listens for new entities and 668 determines if they can join the domain. The registrar delivers any 669 necessary authorization information to the new device and facilitates 670 enrollment with the domain PKI. 672 Registrar behavior is as follows: 674 Contacted by New Entity 675 + 676 | 677 +-------v----------+ 678 | Entity | fail? 679 | Authentication +---------+ 680 +-------+----------+ | 681 | | 682 +-------v----------+ | 683 | Entity | fail? | 684 | Authorization +---------> 685 +-------+----------+ | 686 | | 687 +-------v----------+ | 688 | Claiming the | fail? | 689 | Entity +---------> 690 +-------+----------+ | 691 | | 692 +-------v----------+ | 693 | Log Verification | fail? | 694 | +---------> 695 +-------+----------+ | 696 | | 697 +-------v----------+ +----v-------+ 698 | Forward | | | 699 | Audit | | Reject | 700 | token + config | | Device | 701 | to the Entity | | | 702 +------------------+ +------------+ 704 Figure 4 706 3.3.1. Entity Authentication 708 The applicable authentication methods detailed in EST [RFC7030] are: 710 o the use of an IEEE 802.1AR IDevID credential, 712 o or the use of a secret that is transmitted out of band between the 713 New Entity and the Registrar (this use case is not autonomic). 715 3.3.2. Entity Authorization 717 In a fully automated network all devices must be securely identified 718 and authorized to join the domain. 720 A Registrar accepts or declines a request to join the domain, based 721 on the authenticated identity presented. Automated acceptance 722 criteria include: 724 o allow any device of a specific type (as determined by the IEEE 725 802.1AR device identity), 727 o allow any device from a specific vendor (as determined by the IEEE 728 802.1AR identity), 730 o allow a specific device from a vendor (as determined by the IEEE 731 802.1AR identity) 733 Since all New Entities accept Audit Tokens the Registrar MUST use the 734 vendor provided MASA service to verify that the device's history log 735 does not include unexpected Registrars. If a device had previously 736 registered with another domain, the Registrar of that domain would 737 show in the log. 739 In order to validate the IEEE 802.1AR device identity the Registrar 740 maintains a database of vendor trust anchors (e.g. vendor root 741 certificates or keyIdentifiers for vendor root public keys). For 742 user interface purposes this database can be mapped to colloquial 743 vendor names. Registrars can be shipped with the trust anchors of a 744 significant number of third-party vendors within the target market. 746 If a device is accepted into the domain, it is expected request a 747 domain certificate through a certificate enrolment process. The 748 result is a common trust anchor and device certificates for all 749 autonomic devices in a domain (these certificates can subsequently be 750 used to determine the boundaries of the homenet, to authenticate 751 other domain nodes, and to autonomically enable services on the 752 homenet). The authorization performed during this phase MAY be 753 cached for the TLS session and applied to subsequent EST enrollment 754 requests so long as the session lasts. 756 3.3.3. Claiming the New Entity 758 Claiming an entity establishes an audit log at the MASA server and 759 provides the Registrar with proof, in the form of a MASA 760 authorization token, that the log entry has been inserted. As 761 indicated in Section 3.1.4 a New Entity will only proceed with 762 bootstrapping if a validated MASA authorization token has been 763 recieved. The New Entity therefore enforces that bootstrapping only 764 occurs if the claim has been logged. 766 Registrar's obtain the MASA URI via static configuration or by 767 extracting it from the IEEE 802.1AR credentail. [[EDNOTE: An 768 appropriate extension for indicating the MASA URI could be defined in 769 this document]]. 771 If ownership validation methods are being used the 'claiming' occured 772 during out-of-band integration within the sales process and is out- 773 of-scope. Instead the Registar simply requests an ownership 774 validation token. 776 During initial bootstrapping the New Entity provides a nonce specific 777 to the particular bootstrapping attempt. The Registrar SHOULD 778 include this nonce when claiming the New Entity from the MASA 779 service. Claims from an unauthenticated Registrar are only serviced 780 by the MASA resource if a nonce is provided. 782 The Registrar can claim a New Entity that is not online by forming 783 the request using the entities unique identifier and not including a 784 nonce in the claim request. Audit Tokens obtained in this way do not 785 have a lifetime and they provide a permanent method for the domain to 786 claim the device. Evidence of such a claim is provided in the audit 787 log entries available to any future Registrar. Such claims reduce 788 the ability for future domains to secure bootstrapping and therefore 789 the Registrar MUST be authenticated by the MASA service. [[EDNOTE: 790 some of this paragraph content belongs in the section on MASA 791 behavior]] 793 3.3.4. Log Verification 795 The Registrar requests the log information for the new entity from 796 the MASA service. The log is verified to confirm that the following 797 is true to the satisfaction of the Registrar's configured policy: 799 o Any nonceless entries in the log are associated with domainIDs 800 recognized by the registrar. 802 o Any nonce'd entries are older than when the domain is known to 803 have physical possession of the new entity or that the domainIDs 804 are recognized by the registrar. 806 If any of these criteria are unacceptable to the registrar the entity 807 is rejected. The registar MAY be configured to ignore the history of 808 the device but it is RECOMMENDED that this only be configured if 809 hardware assisted NEA [RFC5209] is supported. 811 3.3.5. Forwarding Audit Token plus Configuration 813 The Registrar forwards the received Audit Token to the New Entity. 814 To simplify the message flows an initial configuration package can be 815 delivered at this time which is signed by a representative of the 816 domain. 818 [[EDNOTE: format TBD. The configuration package signature data must 819 contain the full certificate path sufficient for the new entity to 820 use the domainID information (as a trust anchor) to accept and 821 validate the configuration)]] 823 3.4. Behavior of the MASA Service 825 The MASA service is provided by the Factory provider on the global 826 Internet. The URI of this service is well known. The URI SHOULD 827 also be provided as an IEEE 802.1AR IDevID X.509 extension (a "MASA 828 Audit Token Distribution Point" extension). 830 The MASA service provides the following functionalities to 831 Registrars: 833 3.4.1. Issue Authorization Token and Log the event 835 A Registrar POSTs a claim message optionally containing the bootstrap 836 nonce to the MASA server. 838 If a nonce is provided the MASA service responds to all requests. 839 The MASA service verifies the Registrar is representative of the 840 domain and generates a privacy protected log entry before responding 841 with the Audit Token. 843 If a nonce is not provided then the MASA service MUST authenticate 844 the Registrar as a valid customer. This prevents denial of service 845 attacks. The specific level of authentication provided by the 846 customer is not defined here. An MASA Practice Statement (MPS) 847 similar to the Certification Authority CPS, as defined in RFC5280, is 848 provided by the Factory such that Registrar's can determine the level 849 of trust they have in the Factory. 851 3.4.2. Retrieve Audit Entries from Log 853 When determining if a New Entity should be accepted into a domain the 854 Registrar retrieves a copy of the audit log from the MASA service. 855 This contains a list of privacy protected domain identities that have 856 previously claimed the device. Included in the list is an indication 857 of the time the entry was made and if the nonce was included. 859 3.5. Leveraging the new key infrastructure / next steps 861 As the devices have a common trust anchor, device identity can be 862 securely established, making it possible to automatically deploy 863 services across the domain in a secure manner. 865 Examples of services: 867 o Device management. 869 o Routing authentication. 871 o Service discovery. 873 3.5.1. Network boundaries 875 When a device has joined the domain, it can validate the domain 876 membership of other devices. This makes it possible to create trust 877 boundaries where domain members have higher level of trusted than 878 external devices. Using the autonomic User Interface, specific 879 devices can be grouped into to sub domains and specific trust levels 880 can be implemented between those. 882 3.6. Interactions with Network Access Control 884 The assumption is that Network Access Control (NAC) completes using 885 the New Entity 802.1AR credentials and results in the device having 886 sufficient connetivity to discovery and communicate with the proxy. 887 Any additional connectivity or quarantine behavior by the NAC 888 infrastructure is out-of-scope. After the devices has completed 889 bootstrapping the mechanism to trigger NAC to re-authenticate the 890 device and provide updated network privileges is also out-of-scope. 892 This achieves the goal of a bootstrap architecture that can integrate 893 with NAC but does not require NAC within the network where it wasn't 894 previously required. Future optimizations can be achieved by 895 integrating the bootstrapping protocol directly into an initial EAP 896 exchange. 898 4. Domain Operator Activities 900 This section describes how an operator interacts with a domain that 901 supports the bootstrapping as described in this document. 903 4.1. Instantiating the Domain Certification Authority 905 This is a one time step by the domain administrator. This is an "off 906 the shelf" CA with the exception that it is designed to work as an 907 integrated part of the security solution. This precludes the use of 908 3rd party certification authority services that do not provide 909 support for delegation of certificate issuance decisions to a domain 910 managed Registration Authority. 912 4.2. Instantiating the Registrar 914 This is a one time step by the domain administrator. One or more 915 devices in the domain are configured take on a Registrar function. 917 A device can be configured to act as a Registrar or a device can 918 auto-select itself to take on this function, using a detection 919 mechanism to resolve potential conflicts and setup communication with 920 the Domain Certification Authority. Automated Registrar selection is 921 outside scope for this document. 923 4.3. Accepting New Entities 925 For each New Entity the Registrar is informed of the unique 926 identifier (e.g. serial number) along with the manufacturer's 927 identifying information (e.g. manufacturer root certificate). This 928 can happen in different ways: 930 1. Default acceptance: In the simplest case, the new device asserts 931 its unique identity to the registrar. The registrar accepts all 932 devices without authorization checks. This mode does not provide 933 security against intruders and is not recommended. 935 2. Per device acceptance: The new device asserts its unique identity 936 to the registrar. A non-technical human validates the identity, 937 for example by comparing the identity displayed by the registrar 938 (for example using a smartphone app) with the identity shown on 939 the packaging of the device. Acceptance may be triggered by a 940 click on a smartphone app "accept this device", or by other forms 941 of pairing. See also [I-D.behringer-homenet-trust-bootstrap] for 942 how the approach could work in a homenet. 944 3. Whitelist acceptance: In larger networks, neither of the previous 945 approaches is acceptable. Default acceptance is not secure, and 946 a manual per device methods do not scale. Here, the registrar is 947 provided a priori with a list of identifiers of devices that 948 belong to the network. This list can be extracted from an 949 inventory database, or sales records. If a device is detected 950 that is not on the list of known devices, it can still be 951 manually accepted using the per device acceptance methods. 953 4. Automated Whitelist: an automated process that builds the 954 necessary whitelists and inserts them into the larger network 955 domain infrastructure is plausible. Once set up, no human 956 intervention is required in this process. Defining the exact 957 mechanisms for this is out of scope although the registrar 958 authorization checks is identified as the logical integration 959 point of any future work in this area. 961 None of these approaches require the network to have permanent 962 Internet connectivity. Even when the Internet based MASA service is 963 used, it is possible to pre-fetch the required information from the 964 MASA a priori, for example at time of purchase such that devices can 965 enrol later. This supports use cases where the domain network may be 966 entirely isolated during device deployment. 968 Additional policy can be stored for future authorization decisions. 969 For example an expected deployment time window or that a certain 970 Proxy must be used. 972 4.4. Automatic Enrollment of Devices 974 The approach outlined in this document provides a secure zero-touch 975 method to enrol new devices without any pre-staged configuration. 976 New devices communicate with already enrolled devices of the domain, 977 which proxy between the new device and a Registrar. As a result of 978 this completely automatic operation, all devices obtain a domain 979 based certificate. 981 4.5. Secure Network Operations 983 The certificate installed in the previous step can be used for all 984 subsequent operations. For example, to determine the boundaries of 985 the domain: If a neighbor has a certificate from the same trust 986 anchor it can be assumed "inside" the same organization; if not, as 987 outside. See also Section 3.5.1. The certificate can also be used 988 to securely establish a connection between devices and central 989 control functions. Also autonomic transactions can use the domain 990 certificates to authenticate and/or encrypt direct interactions 991 between devices. The usage of the domain certificates is outside 992 scope for this document. 994 5. Protocol Details 996 For simplicity the bootstrapping protocol is described as extensions 997 to EST [RFC7030]. 999 EST provides a bootstrapping mechanism for new entities that are 1000 configured with the URI of the EST server such that the Implicit TA 1001 database can be used to authenticate the EST server. Alternatively 1002 EST clients can "engage a human user to authorize the CA certificate 1003 using out-of-band data such as a CA certificate". EST does not 1004 provide a completely automated method of bootstrapping the PKI as 1005 both of these methods require some user input (either of the URI or 1006 authorizing the CA certificate). 1008 This section details additional EST functionality that support 1009 automated bootstrapping of the public key infrastructure. These 1010 additions provide for fully automated bootstrapping. These additions 1011 are to be optionally supported by the EST server within the same 1012 .well-known URI tree as the existing EST URIs. 1014 The "New Entity" is the EST client and the "Registrar" is the EST 1015 server. 1017 The extensions for the client are as follows: 1019 o The New Entity provisionally accept the EST server certificate 1020 during the TLS handshake as detailed in EST section 4.1.1 1021 ("Bootstrap Distribution of CA Certificates"). 1023 o The Registrar requests and validates the Audit Token from the 1024 vendor authorized MASA service. 1026 o The New Entity requests and validates the Audit Token as described 1027 below. At this point the New Entity has sufficient information to 1028 validate domain credentials. 1030 o The New Entity calls the EST defined /cacerts method to obtain the 1031 current CA certificate. These are validated using the Audit 1032 Token. 1034 o The New Entity completes bootstrapping as detailed in EST section 1035 4.1.1. 1037 These extensions could be implemented as an independent protocol from 1038 EST but since the overlap with basic enrollment is extensive, 1039 particularly with respect to client authorization, they are presented 1040 here as additions to EST. 1042 In order to obtain a validated Audit Token and Audit Log the 1043 Registrar contacts the MASA service Service using REST calls: 1045 +-----------+ +----------+ +-----------+ +----------+ 1046 | New | | | | | | | 1047 | Entity | | Proxy | | Registrar | | Vendor | 1048 | | | | | | | | 1049 ++----------+ +--+-------+ +-----+-----+ +--------+-+ 1050 | | | | 1051 | | | | 1052 | (D)TLS hello | | | 1053 Establish +---------------> (D)TLS hello | | 1054 (D)TLS | |---------------> | 1055 connection | (forwarding) | | 1056 | Server Cert <---------------+ | 1057 <---------------+ | | 1058 | Client Cert | | | 1059 +-------------------------------> | 1060 | | | | 1061 HTTP REST | POST /requestaudittoken | | 1062 Data +--------------------nonce------> | 1063 | . | /requestaudittoken 1064 | . +----------------> 1065 | <----------------+ 1066 | | /requestauditlog 1067 | +----------------> 1068 | audit token or owner voucher <----------------+ 1069 <-------------------------------+ | 1070 | (optional config information) | | 1071 | . | | 1072 | . | | 1074 Figure 5 1076 In some use cases the Registrar may need to contact the Vendor in 1077 advanced, for example when the target network is airgapped. The 1078 nonceless request format is provided for this and the resulting flow 1079 is slightly different. The security differences associated with not 1080 knowning the nonce are discussed below: 1082 +-----------+ +----------+ +-----------+ +----------+ 1083 | New | | | | | | | 1084 | Entity | | Proxy | | Registrar | | Vendor | 1085 | | | | | | | | 1086 ++----------+ +--+-------+ +-----+-----+ +--------+-+ 1087 | | | | 1088 | | | | 1089 | | | /requestaudittoken 1090 | | (nonce +----------------> 1091 | | unknown) <----------------+ 1092 | | | /requestauditlog 1093 | | +----------------> 1094 | | <----------------+ 1095 | (D)TLS hello | | | 1096 Establish +---------------> (D)TLS hello | | 1097 (D)TLS | |---------------> | 1098 connection | (forwarding) | | 1099 | SerVer Cert <---------------+ | 1100 <---------------+ | | 1101 | Client Cert | | | 1102 +-------------------------------> | 1103 | | | | 1104 HTTP REST | POST /requestaudittoken | | 1105 Data +----------------------nonce----> (discard | 1106 | audit token or owner Voucher | nonce) | 1107 <-------------------------------+ | 1108 | (optional config information) | | 1109 | . | | 1110 | . | | 1112 Figure 6 1114 5.1. Request Audit Token 1116 When the New Entity reaches the EST section 4.1.1 "Bootstrap 1117 Distribution of CA Certificates" state but wishes to proceed in a 1118 fully automated fashion it makes a request for a MASA authorization 1119 token from the Registrar. 1121 This is done with an HTTPS POST using the operation path value of 1122 "/requestaudittoken". 1124 The request format is JSON object containing a nonce. 1126 Request media type: application/auditnonce 1128 Request format: a JSON file with the following: 1130 {"nonce":"<64bit nonce value>", "OwnershipValidation":boolean} 1132 [[EDNOTE: exact format TBD. There is an advantage to having the 1133 client sign the nonce (similar to a PKI Certification Signing 1134 Request) since this allows the MASA service to confirm the actual 1135 device identity. It is not clear that there is a security benefit 1136 from this since its the New Entity that verifies the nonce.]] 1138 The Registrar validates the client identity as described in EST 1139 [RFC7030] section 3.3.2. The registrar performs authorization as 1140 detailed in Section 3.3.2. If authorization is successful the 1141 Registrar obtains an Audit Token from the MASA service (see 1142 Section 5.2). 1144 The recieved MASA authorization token is returned to the New Entity. 1146 As indicated in EST [RFC7030] the bootstrapping server can redirect 1147 the client to an alternate server. If the New Entity authenticated 1148 the Registrar using the well known URI method then the New Entity 1149 MUST follow the redirect automatically and authenticate the new 1150 Registrar against the redirect URI provided. If the New Entity had 1151 not yet authenticated the Registrar because it was discovered and was 1152 not a known-to-be-valid URI then the new Registrar must be 1153 authenticated using one of the two autonomic methods described in 1154 this document. 1156 5.2. Request Audit Token from MASA 1158 The Registrar requests the Audit Token from the MASA service using a 1159 REST interface. For simplicity this is defined as an optional EST 1160 message between the Registar and an EST server running on the MASA 1161 service although the Registrar is not required to make use of any 1162 other EST functionality when communicating with the MASA service. 1163 (The MASA service MUST properly reject any EST functionality requests 1164 it does not wish to service; a requirement that holds for any REST 1165 interface). 1167 This is done with an HTTP POST using the operation path value of 1168 "/requestaudittoken". 1170 The request format is a JSON object optionally containing the nonce 1171 value (as obtained from the bootstrap request) and the IEEE 802.1AR 1172 identity of the device as a serial number (the full certificate is 1173 not needed and no proof-of-possession information for the device 1174 identity is included). The New Entity's serial number is extracted 1175 from the subject name : 1177 {"nonce":"<64bit nonce value>", "serialnumber", ""} 1180 Inclusion of the nonce is optional because the Registar might request 1181 an authorization token when the New Entity is not online, or when the 1182 target bootstrapping environment is not on the same network as the 1183 MASA server. 1185 The JSON message information is encapsulated in a PKCS7 signed data 1186 structure that is signed by the Registrar. The entire certificate 1187 chain, up to and including the Domain CA, MUST be included in the 1188 PKCS7. 1190 The MASA service checks the internal consistency of the PKCS7 but is 1191 unable to actually authenticate the domain identity information. The 1192 domain is not know to the MASA server in advance and a shared trust 1193 anchor is not implied. The MASA server verifies that the PKCS7 is 1194 signed by a Registrar (by checking for the cmc-idRA field in the 1195 Registrar certificate) certificate that was issued by a the root 1196 certificate included in the PKCS7. This is sufficient for the MASA 1197 service to ensure that the Registar is in fact an authorized Registar 1198 of the unknown domain. 1200 The domain ID (e.g. hash of the public key of the domain) is 1201 extracted from the root certificate and is used to generate the MASA 1202 authorization token and to update the audit log. 1204 [[EDNOTE: The authorization token response format needs to be defined 1205 here. It consists of the nonce, if supplied, the serialnumber and 1206 the trust anchor of the domain. For example: 1208 {"nonce":"<64bit nonce value>", "serialnumber", "","domainID":} 1211 ]] 1213 [[EDNOTE: This assumes the Registrar can extract the serial number 1214 successfullly from the cilent certificate. The RFC4108 1215 hardwareModuleName is the best known location.]] 1217 [[EDNOTE: There is a strong similarity between this and the previous 1218 section. Both involve requesting the Audit Token from the upstream 1219 element. Because there are differing requirements on the data 1220 submitted and the signing of that data they are specified in distinct 1221 sections. The design team should have a meeting to discuss how to 1222 unify these sections or make the distinctions more clear]] 1224 5.3. Basic Configuration Information Package 1226 When the MASA authorization token is returned to the New Entity an 1227 arbitrary information package can be signed and delivered along side 1228 it. This is signed by the Domain Registar. The New Entity first 1229 verifies the Audit Token and, if it is valid, then uses the domain's 1230 TA to validate the Information Package. 1232 [[EDNOTE: The package format to be specified here. Any signed format 1233 is viable and ideally one can simply be specified from netconf. The 1234 Registar knows the New Entity device type from the 802.1AR credential 1235 and so is able to determine the proper format for the configuration]] 1237 5.4. Request MASA authorization log 1239 A registrar requests the MASA authorization log from the MASA service 1240 using this EST extension. 1242 This is done with an HTTP GET using the operation path value of 1243 "/requestMASAlog". 1245 The log data returned is a file consisting of all previous log 1246 entries. For example: 1248 "log":[ 1249 {"date":""}, 1250 "domainID":"", 1253 "nonce":""}, 1255 {"date":""}, 1256 "domainID":"", 1259 "nonce":""}, 1260 ] 1262 Distribution of a large log is less than ideal. This structure can 1263 be optimized as follows: only the most recent nonce'd log entry is 1264 required in the response. All nonce-less entries for the same 1265 domainID can be condensed into the single most recent nonceless 1266 entry. 1268 The Registrar uses this log information to make an informed decision 1269 regarding the continued bootstrapping of the New Entity. 1271 [[EDNOTE: certificate transparency might offer an alternative log 1272 entry method]] 1274 6. Reduced security operational modes 1276 A common requirement of bootstrapping is to support less secure 1277 operational modes for support specific use cases. The following 1278 sections detail specific ways that the New Entity, Registrar and MASA 1279 can be configured to run in a less secure mode for the indicated 1280 reasons. 1282 6.1. New Entity security reductions 1284 Although New Entity can choose to run in less secure modes this is 1285 MUST NOT be the default state because it permanently degrades the 1286 security for all other uses cases. 1288 The device may have an operational mode where it skips Audit Token 1289 validation one time. For example if a physical button is depressed 1290 during the bootstrapping operation. This can be useful if the MASA 1291 service is unavailable. This behavior SHOULD be available via local 1292 configuration or physical presence methods to ensure new entities can 1293 always be deployed even when autonomic methods fail. 1295 It is RECOMMENDED that this only be available if hardware assisted 1296 NEA [RFC5209] is supported. 1298 6.2. Registrar security reductions 1300 The Registrar can choose to accept devices using less secure methods. 1301 These methods are RECOMMENDED when low security models are needed as 1302 the security decisions are being made by the local administrator: 1304 1. The registrar MAY choose to accept all devices, or all devices of 1305 a particular type, at the administrator's discretion. This could 1306 occur when informing the Registrar of unique identifiers of new 1307 entities might be operationally difficult. 1309 2. The registrar MAY choose to accept devices that claim a unique 1310 identity without the benefit of authenticating that claimed 1311 identity. This could occur when the New Entity does not include 1312 an IEEE 802.1AR factory installed credential. 1314 3. The registrar MAY request nonce-less Audit Tokens from the MASA 1315 service. These tokens can then be transmitted to the Registrar 1316 and stored until they are needed during bootstrapping operations. 1317 This is for use cases where target network is protected by an air 1318 gap and therefore can not contact the MASA service during New 1319 Entity deployment. 1321 4. The registrar MAY ignore unrecognized nonce-less Audit Log 1322 entries. This could occur when used equipment is purchased with 1323 a valid history being deployed in air gap networks that required 1324 permanent Audit Tokens. 1326 6.3. MASA security reductions 1328 Lower security modes chosen by the MASA service effect all device 1329 deployments unless paired with strict device ownership validation, in 1330 which case these modes can be provided as additional features for 1331 specific customers. The MASA service can choose to run in less 1332 secure modes by: 1334 1. Not enforcing that a Nonce is in the Audit Token. This results 1335 in distribution of Audit Tokens that never expire and effectly 1336 makes the Domain an always trusted entity to the New Entity 1337 during any subsequent bootstrapping attempts. That this occured 1338 is captured in the log information so that the Domain registrar 1339 can make appropriate security decisions when a new device joins 1340 the domain. This is useful to support use cases where Registrars 1341 might not be online during actual device deployment. Because 1342 this results in long lived Audit Tokens and do not require the 1343 proof that the device is online this is only accepted when the 1344 Registrar is authenticated by the MASA server and authorized to 1345 provide this functionality. The MASA server is RECOMMENDED to 1346 use this functionality only in concert with Ownership Validation 1347 tracking. 1349 2. Not verifying ownership before responding with an Audit Token. 1350 This is expected to be a common operational model because doing 1351 so relieves the vendor providing MASA services from having to 1352 tracking ownership during shipping and supply chain and allows 1353 for a very low overhead MASA service. The Registrar uses the 1354 audit log information as a defense in depth strategy to ensure 1355 that this does not occur unexpectedly (for example when 1356 purchasing new equipment the Registrar would throw an error if 1357 any audit log information is reported). 1359 7. Security Considerations 1361 In order to support a wide variety of use cases, devices can be 1362 claimed by a registrar without proving possession of the device in 1363 question. This would result in a nonceless, and thus always valid, 1364 claim. Or would result in an invalid nonce being associated with a 1365 claim. The MASA service is required to authenticate such Registrars 1366 but no programmatic method is provided to ensure good behavior by the 1367 MASA service. Nonceless entries into the audit log therefore 1368 permanently reduce the value of a device because future Registrars, 1369 during future bootstrap attempts, would now have to be configured 1370 with policy to ignore previously (and potentially unknown) domains. 1372 Future registrars are recommended to take the audit history of a 1373 device into account when deciding to join such devices into their 1374 network. If the MASA server were to have allowed a significantly 1375 large number of claims this might become onerous to the MASA server 1376 which must maintain all the extra log entries. Ensuring the registar 1377 is representative of a valid customer domain even without validating 1378 ownership helps to mitigate this. 1380 It is possible for an attacker to send an authorization request to 1381 the MASA service directly after the real Registrar obtains an 1382 authorization log. If the attacker could also force the 1383 bootstrapping protocol to reset there is a theoretical opportunity 1384 for the attacker to use the Audit Token to take control of the New 1385 Entity but then proceed to enroll with the target domain. Possible 1386 prevention mechanisms include: 1388 o Per device rate limits on the MASA service ensure such timing 1389 attacks are difficult. 1391 o In the advent of an unexpectadly lost bootstrapping connection the 1392 Registrar repeats the request for audit log information. 1394 As indicated in EST [RFC7030] the connection is provisional and 1395 untrusted until the server is successfully authorized. If the server 1396 provides a redirect response the client MUST follow the redirect but 1397 the connection remains provisional. If the client uses a well known 1398 URI for contacting a well known Registrar the EST Implicit Trust 1399 Anchor database is used as is described in RFC6125 to authenticate 1400 the well known URI. In this case the connection is not provisional 1401 and RFC6125 methods can be used for each subsequent redirection. 1403 The MASA service could lock a claim and refuse to issue a new token 1404 or the MASA service could go offline (for example if a vendor went 1405 out of business). This functionality provides benefits such as theft 1406 resistance, but it also implies an operational risk to the Domain 1407 that Vendor behavior could limit future bootstrapping of the device 1408 by the Domain. This can be mitigated by Registrars that request 1409 nonce-less authorization tokens. 1411 7.1. Trust Model 1413 [[EDNOTE: (need to describe that we need to trust the device h/w. To 1414 be completed.)]] 1416 8. Acknowledgements 1418 We would like to thank the various reviewers for their input, in 1419 particular Markus Stenberg, Brian Carpenter, Fuyu Eleven. 1421 9. References 1423 9.1. Normative References 1425 [IDevID] IEEE Standard, , "IEEE 802.1AR Secure Device Identifier", 1426 December 2009, . 1429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1430 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1431 RFC2119, March 1997, 1432 . 1434 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1435 "Enrollment over Secure Transport", RFC 7030, DOI 1436 10.17487/RFC7030, October 2013, 1437 . 1439 9.2. Informative References 1441 [I-D.behringer-homenet-trust-bootstrap] 1442 Behringer, M., Pritikin, M., and S. Bjarnason, 1443 "Bootstrapping Trust on a Homenet", draft-behringer- 1444 homenet-trust-bootstrap-02 (work in progress), February 1445 2014. 1447 [I-D.irtf-nmrg-autonomic-network-definitions] 1448 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 1449 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 1450 Networking - Definitions and Design Goals", draft-irtf- 1451 nmrg-autonomic-network-definitions-07 (work in progress), 1452 March 2015. 1454 [imprinting] 1455 Wikipedia, , "Wikipedia article: Imprinting", July 2015, 1456 . 1458 [pledge] Dictionary.com, , "Dictionary.com Unabridged", July 2015, 1459 . 1461 Appendix A. Editor notes 1463 [[EDNOTE: This section is to capturing rough notes between editors 1464 and Anima Bootstrapping design team members. This entire section to 1465 be removed en masse before finalization]] 1467 Change Discussion: 1469 03 updated figures added "ownership voucher" concepts added "request 1470 join" state to the new entity discussions broke discovery and 1471 identity into two sections added request join section expanded 1472 imprint autonomic methods as per design team discussions 1473 simplified proxy discussion as per design team discussions 1474 clarified 'entity authorization' clarified 'claiming the new 1475 entity' removed EAP-EST references expanded on protocol details as 1476 per ownership validation options slight additions to security 1477 considerations 1479 02 Moved sections for readability, Updated introduction, simplified 1480 functional overview to avoid distractions from optional elements, 1481 addressed updated security considerations, fleshed out state 1482 machines. 1484 The following is a non-prioritized list of work items currently 1485 identified: 1487 o Continue to address gaps/opportunities highlighted by community 1488 work on bootstrappping. Refs: IETF92 "Survey of Security 1489 Bootstrapping", Aana Danping He, behcet Sarikaya. "NETCONF Zero 1490 Touch Update for ANIMA" https://www.ietf.org/proceedings/92/ 1491 anima.html and "Bootstrapping Key Infrastructures", Pritikin, 1492 Behringer, Bjarnason 1494 o IN PROGRESS: Intergrate "Ownership Voucher" as a valid optional 1495 format for the MASA response. So long as the issuance of this is 1496 logged and captured in the log response then the basic flow and 1497 threat model is substantially the same. 1499 o COMPLETE (moved to simple proxy): Attempt to re-use existing work 1500 as per the charter: Toerless notes: a) are existing [eap] options? 1501 or too complex? or doens't work? b) our own method (e.g. EAP- 1502 ANIMA c) if b then investigate using signaling protocol). 1504 o 1506 Authors' Addresses 1508 Max Pritikin 1509 Cisco 1511 Email: pritikin@cisco.com 1513 Michael C. Richardson 1514 Sandelman Software Works 1515 470 Dawson Avenue 1516 Ottawa, ON K1Z 5V7 1517 CA 1519 Email: mcr+ietf@sandelman.ca 1520 URI: http://www.sandelman.ca/ 1522 Michael H. Behringer 1523 Cisco 1525 Email: mbehring@cisco.com 1527 Steinthor Bjarnason 1528 Cisco 1530 Email: sbjarnas@cisco.com