idnits 2.17.1 draft-ietf-anima-bootstrapping-keyinfra-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2591 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC3987' is mentioned on line 549, but not defined == Missing Reference: 'RFC5209' is mentioned on line 2006, but not defined == Missing Reference: 'RFC2616' is mentioned on line 1646, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Missing Reference: 'TBD' is mentioned on line 1867, but not defined == Missing Reference: 'RFC7252' is mentioned on line 1943, but not defined == Missing Reference: 'RFC2131' is mentioned on line 2307, but not defined == Missing Reference: 'FIND-good-REF' is mentioned on line 2352, but not defined == Unused Reference: 'I-D.ietf-netconf-zerotouch' is defined on line 2248, but no explicit reference was found in the text == Unused Reference: 'I-D.lear-mud-framework' is defined on line 2253, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-05 == Outdated reference: A later version (-07) exists of draft-ietf-anima-voucher-00 == Outdated reference: A later version (-15) exists of draft-ietf-anima-grasp-09 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-12 == Outdated reference: A later version (-03) exists of draft-richardson-anima-state-for-joinrouter-01 Summary: 2 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). 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: September 14, 2017 SSW 6 M. Behringer 7 S. Bjarnason 8 Cisco 9 K. Watsen 10 Juniper Networks 11 March 13, 2017 13 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 14 draft-ietf-anima-bootstrapping-keyinfra-05 16 Abstract 18 This document specifies automated bootstrapping of a remote secure 19 key infrastructure (BRSKI) using vendor installed X.509 certificate, 20 in combination with a vendor's authorizing service, both online the 21 Internet, and offline. Bootstrapping a new device can occur using a 22 routable address and a cloud service, or using only link-local 23 connectivity, or on limited/disconnected networks. Support for lower 24 security models, including devices with minimal identity, is 25 described for legacy reasons but not encouraged. Bootstrapping is 26 complete when the cryptographic identity of the new key 27 infrastructure is successfully deployed to the device but the 28 established secure connection can be used to deploy a locally issued 29 certificate to the device as well. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 14, 2017. 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. Secure Imprinting without Vouchers . . . . . . . . . . . 5 67 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 68 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 8 69 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 9 70 2.1. Secure Imprinting without Vouchers . . . . . . . . . . . 11 71 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 12 72 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 12 73 3. Functional Overview . . . . . . . . . . . . . . . . . . . . . 13 74 3.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 15 75 3.1.1. Discovery . . . . . . . . . . . . . . . . . . . . . . 17 76 3.1.2. Identity . . . . . . . . . . . . . . . . . . . . . . 18 77 3.1.3. Request Join . . . . . . . . . . . . . . . . . . . . 18 78 3.1.4. Imprint . . . . . . . . . . . . . . . . . . . . . . . 19 79 3.1.5. Lack of realtime clock . . . . . . . . . . . . . . . 19 80 3.1.6. Enrollment . . . . . . . . . . . . . . . . . . . . . 20 81 3.1.7. Being Managed . . . . . . . . . . . . . . . . . . . . 20 82 3.2. Behavior of a Join Proxy . . . . . . . . . . . . . . . . 21 83 3.2.1. CoAP connection to Registrar . . . . . . . . . . . . 22 84 3.2.2. HTTPS proxy connection to Registrar . . . . . . . . . 22 85 3.3. Behavior of the Registrar . . . . . . . . . . . . . . . . 22 86 3.3.1. Pledge Authentication . . . . . . . . . . . . . . . . 23 87 3.3.2. Pledge Authorization . . . . . . . . . . . . . . . . 24 88 3.3.3. Claiming the New Entity . . . . . . . . . . . . . . . 24 89 3.3.4. Log Verification . . . . . . . . . . . . . . . . . . 25 90 3.4. Behavior of the MASA Service . . . . . . . . . . . . . . 26 91 3.5. Leveraging the new key infrastructure / next steps . . . 26 92 3.5.1. Network boundaries . . . . . . . . . . . . . . . . . 26 93 3.6. Interactions with Network Access Control . . . . . . . . 27 94 4. Domain Operator Activities . . . . . . . . . . . . . . . . . 27 95 4.1. Instantiating the Domain Certification Authority . . . . 27 96 4.2. Instantiating the Registrar . . . . . . . . . . . . . . . 27 97 4.3. Accepting New Entities . . . . . . . . . . . . . . . . . 28 98 4.4. Automatic Enrollment of Devices . . . . . . . . . . . . . 29 99 4.5. Secure Network Operations . . . . . . . . . . . . . . . . 29 100 5. Proxy Discovery Protocol Details . . . . . . . . . . . . . . 29 101 6. Registrar Discovery Protocol Details . . . . . . . . . . . . 29 102 7. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 30 103 7.1. Request Voucher from the Registrar . . . . . . . . . . . 34 104 7.2. Request Voucher from MASA . . . . . . . . . . . . . . . . 35 105 7.3. Voucher Response . . . . . . . . . . . . . . . . . . . . 36 106 7.3.1. Completing authentication of Provisional TLS 107 connection . . . . . . . . . . . . . . . . . . . . . 37 108 7.4. Voucher Status Telemetry . . . . . . . . . . . . . . . . 38 109 7.5. MASA authorization log Request . . . . . . . . . . . . . 39 110 7.6. MASA authorization log Response . . . . . . . . . . . . . 39 111 7.7. EST Integration for PKI bootstrapping . . . . . . . . . . 40 112 7.7.1. EST Distribution of CA Certificates . . . . . . . . . 41 113 7.7.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 41 114 7.7.3. EST Client Certificate Request . . . . . . . . . . . 42 115 7.7.4. Enrollment Status Telemetry . . . . . . . . . . . . . 42 116 7.7.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 43 117 8. Reduced security operational modes . . . . . . . . . . . . . 43 118 8.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 43 119 8.2. New Entity security reductions . . . . . . . . . . . . . 44 120 8.3. Registrar security reductions . . . . . . . . . . . . . . 44 121 8.4. MASA security reductions . . . . . . . . . . . . . . . . 45 122 9. Security Considerations . . . . . . . . . . . . . . . . . . . 46 123 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 48 124 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 125 11.1. Normative References . . . . . . . . . . . . . . . . . . 48 126 11.2. Informative References . . . . . . . . . . . . . . . . . 49 127 Appendix A. IPv4 operations . . . . . . . . . . . . . . . . . . 51 128 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 51 129 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 51 130 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 51 131 Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 52 132 C.1. Multiple Join networks on the Join Proxy side . . . . . . 53 133 C.2. Automatic configuration of tunnels on Registrar . . . . . 53 134 C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 53 135 C.4. Use of connected sockets; or IP_PKTINFO for CoAP on 136 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 54 137 C.5. Use of socket extension rather than virtual interface . . 54 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 140 1. Introduction 142 To literally "pull yourself up by the bootstraps" is an impossible 143 action. Similarly the secure establishment of a key infrastructure 144 without external help is also an impossibility. Today it is commonly 145 accepted that the initial connections between nodes are insecure, 146 until key distribution is complete, or that domain-specific keying 147 material is pre-provisioned on each new device in a costly and non- 148 scalable manner. These existing mechanisms are known as non-secured 149 'Trust on First Use' (TOFU) [RFC7435], 'resurrecting duckling' 150 [Stajano99theresurrecting] or 'pre-staging'. 152 This document describes a zero-touch approach to bootstrapping that 153 secures the initial distribution of key material between an 154 unconfigured and untouched device called a "Pledge" and the 155 "Registrar" device that is a member of an established network domain. 156 The bootstrapping process provides a foundation to securely answer 157 the following questions: 159 o Registrar authenticating the Pledge: "Who is this device? What is 160 its identity?" 162 o Registrar authorization the Pledge: "Is it mine? Do I want it? 163 What are the chances it has been compromised?" 165 o Pledge authenticating the Registrar/Domain: "What is this domain's 166 identity?" 168 o Pledge authorization the Registrar: "Should I join it?" 170 This document details protocols and messages to the endpoints to 171 answer the above questions. The Registrar actions derive from Pledge 172 identity, third party cloud service communications, and local access 173 control lists. The Pledge actions derive from a cryptographically 174 protected "voucher" message delivered through the Registrar. 175 Multiple forms of "vouchers" are described to support a variety of 176 use cases. 178 The syntactic details of vouchers are described in detail in 179 [I-D.ietf-anima-voucher]. This document details automated protocol 180 mechanisms to obtain vouchers. 182 The result of bootstrapping is that a security association between 183 the Pledge and the Registrar is established. A method of leveraging 184 this association to optimize PKI enrollment is described. 186 The described system is agile enough to support bootstrapping 187 alternative key infrastructures, such as a symmetric key solutions, 188 but no such system is described. 190 1.1. Secure Imprinting without Vouchers 192 There are pre-existing methods available for establishing initial 193 trust. For example the enrollment protocol EST [RFC7030] details a 194 set of non-autonomic bootstrapping methods such as: 196 o using the Implicit Trust Anchor database (not an autonomic 197 solution because the URL must be securely distributed), 199 o engaging a human user to authorize the CA certificate using out- 200 of-band data (not an autonomic solution because the human user is 201 involved), 203 o using a configured Explicit TA database (not an autonomic solution 204 because the distribution of an explicit TA database is not 205 autonomic), 207 o and using a Certificate-Less TLS mutual authentication method (not 208 an autonomic solution because the distribution of symmetric key 209 material is not autonomic). 211 These "touch" methods do not meet the requirements for zero-touch. 213 There are "call home" technologies where the Pledge first establishes 214 a connection to a well known vendor service using a common client- 215 server authentication model. After mutual authentication appropriate 216 credentials to authenticate the target domain are transfered to the 217 Pledge. This creates serveral problems and limitations: 219 o the pledge requires realtime connectivity to the vendor service, 221 o the domain identity is exposed to the vendor service (this is a 222 privacy concern), 224 o the vendor is responsible for making the authorization decisions 225 (this is a liability concern), 227 BRSKI addresses these issues by introducting an authorization layer 228 via "vouchers". The additional complexity provides for significant 229 flexibility. 231 1.2. Terminology 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 235 "OPTIONAL" in this document are to be interpreted as described in 236 [RFC2119]. 238 The following terms are defined for clarity: 240 DomainID: The domain identity is the 160-bit SHA-1 hash of the BIT 241 STRING of the subjectPublicKey of the domain trust anchor that is 242 stored by the Domain CA. This is consistent with the 243 Certification Authority subject key identifier (Section 4.2.1.2 244 [RFC5280]) of the Domain CA's self signed root certificate. (A 245 string value bound to the Domain CA's self signed root certificate 246 subject and issuer fields is often colloquially used as a 247 humanized identity value but during protocol discussions the more 248 exact term as defined here is used). 250 drop ship: The physical distribution of equipment containing the 251 "factory default" configuration to a final destination. In zero- 252 touch scenarios there is no staging or pre-configuration during 253 drop-ship. 255 imprint: The process where a device obtains the cryptographic key 256 material to identify and trust future interactions with a network. 257 This term is taken from Konrad Lorenz's work in biology with new 258 ducklings: during a critical period, the duckling would assume 259 that anything that looks like a mother duck is in fact their 260 mother. An equivalent for a device is to obtain the fingerprint 261 of the network's root certification authority certificate. A 262 device that imprints on an attacker suffers a similar fate to a 263 duckling that imprints on a hungry wolf. Securely imprinting is a 264 primary focus of this document.[imprinting]. The analogy to 265 Lorenz's work was first noted in [Stajano99theresurrecting]. 267 enrollment: The process where a device presents key material to a 268 network and acquires a network specific identity. For example 269 when a certificate signing request is presented to a certification 270 authority and a certificate is obtained in response. 272 Pledge: The prospective device, which has an identity installed by a 273 third-party (e.g., vendor, manufacturer or integrator). 275 Voucher A signed statement from the MASA service that indicates to a 276 Pledge the cryptographic identity of the Registrar it should 277 trust. There are different types of vouchers depending on how 278 that trust asserted. Multiple voucher types are defined in 279 [I-D.ietf-anima-voucher] 281 Domain: The set of entities that trust a common key infrastructure 282 trust anchor. This includes the Proxy, Registrar, Domain 283 Certificate Authority, Management components and any existing 284 entity that is already a member of the domain. 286 Domain CA: The domain Certification Authority (CA) provides 287 certification functionalities to the domain. At a minimum it 288 provides certification functionalities to a Registrar and stores 289 the trust anchor that defines the domain. Optionally, it 290 certifies all elements. 292 Join Registrar (and Coordinator): A representative of the domain 293 that is configured, perhaps autonomically, to decide whether a new 294 device is allowed to join the domain. The administrator of the 295 domain interfaces with a Join Registrar (and Coordinator) to 296 control this process. Typically a Join Registrar is "inside" its 297 domain. For simplicity this document often refers to this as just 298 "Registrar". The term JRC is used in common with other bootstrap 299 mechanisms. 301 Join Proxy: A domain entity that helps the pledge join the domain. 302 A Proxy facilitates communication for devices that find themselves 303 in an environment where they are not provided connectivity until 304 after they are validated as members of the domain. The pledge is 305 unaware that they are communicating with a proxy rather than 306 directly with a Registrar. 308 MASA Service: A third-party Manufacturer Authorized Signing 309 Authority (MASA) service on the global Internet. The MASA signs 310 vouchers. It also provides a repository for audit log information 311 of privacy protected bootstrapping events. It does not track 312 ownership. 314 Ownership Tracker: An Ownership Tracker service on the global 315 internet. The Ownership Tracker uses business processes to 316 accurately track ownership of all devices shipped against domains 317 that have purchased them. Although optional this component allows 318 vendors to provide additional value in cases where their sales and 319 distribution channels allow for accurately tracking of such 320 ownership. Ownership tracking information is indicated in 321 vouchers as described in [I-D.ietf-anima-voucher] 323 IDevID: An Initial Device Identity X.509 certificate installed by 324 the vendor on new equipment. 326 TOFU: Trust on First Use. Used similarly to [RFC7435]. This is 327 where a Pledge device makes no security decisions but rather 328 simply trusts the first Registrar it is contacted by. This is 329 also known as the "resurrecting duckling" model. 331 1.3. Scope of solution 333 Questions have been posed as to whether this solution is suitable in 334 general for Internet of Things (IoT) networks. This depends on the 335 capabilities of the devices in question. The terminology of 336 [RFC7228] is best used to describe the boundaries. 338 The solution described in this document is aimed in general at non- 339 constrained (i.e. class 2+) devices operating on a non-Challenged 340 network. The entire solution as described here is not intended to be 341 useable as-is by constrained devices operating on challenged networks 342 (such as 802.15.4 LLNs). 344 There are a number of optional mechanisms in BRSKI. These mechanisms 345 are not mandatory to implement for the core applicability to ANIMA. 346 These mechanisms have been moved out of the main flow of the document 347 to appendices to emphasis that they are not considered normative, 348 mandatory to implement, while making it easier for another document 349 to normatively reference them. 351 In many target applications, the systems involved are large router 352 platforms with multi-gigabit inter-connections, mounted in controlled 353 access data centers. But this solution is not exclusive to the 354 large, it is intended to scale to thousands of devices located in 355 hostile environments, such as ISP provided CPE devices which are 356 drop-shipped to the end user. The situation where an order is 357 fulfilled from distributed warehouse from a common stock and shipped 358 directly to the target location at the request of the domain owner is 359 explicitly supported. That stock ("SKU") could be provided to a 360 number of potential domain owners, and the eventual domain owner will 361 not know a-priori which device will go to which location. 363 The bootstrapping process can take minutes to complete depending on 364 the network infrastructure and device processing speed. The network 365 communication itself is not optimized for speed; for privacy reasons, 366 the discovery process allows for the Pledge to avoid announcing it's 367 presence through broadcasting. This protocol is not intended for low 368 latency handoffs. In networks requiring such things, the pledge 369 SHOULD already have been enrolled. 371 Specifically, there are protocol aspects described here which might 372 result in congestion collapse or energy-exhaustion of intermediate 373 battery powered routers in an LLN. Those types of networks SHOULD 374 NOT use this solution. These limitations are predominately related 375 to the large credential and key sizes required for device 376 authentication. Defining symmetric key techniques that meet the 377 operational requirements is out-of-scope but the underlying protocol 378 operations (TLS handshake and signing structures) have sufficient 379 algorithm agility to support such techniques when defined. 381 The imprint protocol described here could, however, be used by non- 382 energy constrained devices joining a non-constrained network (for 383 instance, smart light bulbs are usually mains powered, and speak 384 802.11). It could also be used by non-constrained devices across a 385 non-energy constrained, but challenged network (such as 802.15.4). 387 This document presumes that network access control has either already 388 occurred, is not required, or is integrated by the proxy and 389 registrar in such a way that the device itself does not need to be 390 aware of the details. Although the use of an X.509 Initial Device 391 Identity is consistant with IEEE 802.1AR [IDevID], and allows for 392 alignment with 802.1X network access control methods, its use here is 393 for Pledge authentication rather than network access control. 395 Some aspects are in scope for constrained devices on challenged 396 networks: the certificate contents, and the process by which the four 397 questions above are resolved is in scope. It is simply the actual 398 on-the-wire imprint protocol which is likely inappropriate. 400 2. Architectural Overview 402 The logical elements of the bootstrapping framework are described in 403 this section. Figure 1 provides a simplified overview of the 404 components. Each component is logical and may be combined with other 405 components as necessary. 407 . 408 .+------------------------+ 409 +--------------Drop Ship-------------->.| Vendor Service | 410 | .+------------------------+ 411 | .| M anufacturer| | 412 | .| A uthorized |Ownership| 413 | .| S igning |Tracker | 414 | .| A uthority | | 415 | .+--------------+---------+ 416 | .............. ^ 417 V | 418 +-------+ ............................................|... 419 | | . | . 420 | | . +------------+ +-----------+ | . 421 | | . | | | | | . 422 |Pledge | . | Circuit | | Domain <-------+ . 423 | | . | Proxy | | Registrar | . 424 | <--------> <-------> | . 425 | | . | | | | . 426 | | . +------------+ +-----+-----+ . 427 |IDevID | . | . 428 | | . +-----------------+----------+ . 429 | | . | Domain Certification | . 430 | | . | Authority | . 431 +-------+ . | Management and etc | . 432 . +----------------------------+ . 433 . . 434 ................................................ 435 "Domain" components 437 Figure 1 439 We assume a multi-vendor network. In such an environment there could 440 be a Vendor Service for each vendor that supports devices following 441 this document's specification, or an integrator could provide a 442 generic service authorized by multiple vendors. It is unlikely that 443 an integrator could provide Ownership Tracking services for multiple 444 vendors due to the required sales channel integrations necessary to 445 track ownership. 447 The domain is the managed network infrastructure the Pledge is 448 managed by. The a domain provides initial device connectivity 449 minimally sufficient for bootstrapping through the Circuit Proxy. 450 The Domain registrar makes authorization decisions and handles 451 connectivity to the vendor services and authenticates the Pledge. 452 Optional cryptographic credential and configuration management 453 systems are expected. 455 This document describes a secure zero-touch approach to bootstrapping 456 a remote key infrastructure. Secure bootstrapping requires 457 mitigating the threat of an attacker domain establishing a management 458 role over the pledge device. In a "trust on first use" model, where 459 this threat is ignored, the attacker has an opportunity to install a 460 persistent malware component. This document uses Vouchers to address 461 the threat while maintaining a significant level of flexibility. 463 2.1. Secure Imprinting without Vouchers 465 There are pre-existing methods available for establishing initial 466 trust. For example the enrollment protocol EST [RFC7030] details a 467 set of non-autonomic bootstrapping methods such as: 469 o using the Implicit Trust Anchor database (not an autonomic 470 solution because the URL must be securely distributed), 472 o engaging a human user to authorize the CA certificate using out- 473 of-band data (not an autonomic solution because the human user is 474 involved), 476 o using a configured Explicit TA database (not an autonomic solution 477 because the distribution of an explicit TA database is not 478 autonomic), 480 o and using a Certificate-Less TLS mutual authentication method (not 481 an autonomic solution because the distribution of symmetric key 482 material is not autonomic). 484 These "touch" methods do not meet the requirements for zero-touch. 486 There are "call home" technologies where the Pledge first establishes 487 a connection to a well known vendor service using a common client- 488 server authentication model. After mutual authentication appropriate 489 credentials to authenticate the target domain are transfered to the 490 Pledge. This creates serveral problems and limitations: 492 o the pledge requires realtime connectivity to the vendor service, 494 o the domain identity is exposed to the vendor service (this is a 495 privacy concern), 497 o the vendor is responsible for making the authorization decisions 498 (this is a liability concern), 500 BRSKI addresses these issues by introducting an authorization layer 501 via "vouchers". The additional complexity provides for significant 502 flexibility. 504 2.2. Secure Imprinting using Vouchers 506 A voucher is a cryptographically protected statement to the Pledge 507 device authorizing a zero-touch imprint on the Registrar domain. 509 The format and cryptographic mechanism of vouchers is described in 510 detail in [I-D.ietf-anima-voucher]. 512 Vouchers provide a flexible mechanism to secure imprinting: the 513 Pledge device only imprints when a voucher can be validated. At the 514 lowest security levels the MASA server can indiscriminately issue 515 vouchers. At the highest security levels issuance of vouchers can be 516 integrated with complex sales channel integrations that are beyond 517 the scope of this document. This provides the flexability for a 518 number of use cases via a single common protocol mechanism on the 519 Pledge and Registrar devices that are to be widely deployed in the 520 field. The MASA vendor services have the flexibility to leverage 521 either the currently defined claim mechanisms or to experiment with 522 higher or lower security levels. 524 2.3. Initial Device Identifier 526 Pledge authentication is via an X.509 certificate installed during 527 the manufacturing process. This Initial Device Identifier provides a 528 basis for authenticating the Pledge during subsequent protocol 529 exchanges and informing the Registrar of the MASA URI. There is no 530 requirement for a common root PKI hierarchy. Each device vendor can 531 generate their own root certificate. 533 The following previously defined fields are in the X.509 IDevID 534 certificate: 536 o The subject field's DN encoding MUST include the "serialNumber" 537 attribute with the device's unique serial number. 539 o The subject alt field's encoding SHOULD include the a non-critical 540 version of the RFC4108 defined HardwareModuleName. 542 The following newly defined field SHOULD be in the X.509 IDevID 543 certificate: An X.509 non-critical certificate extension that 544 contains a single Uniform Resource Identifier (URI) that points to an 545 on-line Manufacturer Authorized Signing Authority. The URI is 546 represented as described in Section 7.4 of [RFC5280]. 548 Any Internationalized Resource Identifiers (IRIs) MUST be mapped to 549 URIs as specified in Section 3.1 of [RFC3987] before they are placed 550 in the certificate extension. 552 The semantics of the URI are defined in Section 7 of this document. 553 The new extension is identified as follows: 555 557 MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) 558 internet(1) security(5) mechanisms(5) pkix(7) 559 id-mod(0) id-mod-MASAURLExtn2016(TBD) } 561 DEFINITIONS IMPLICIT TAGS ::= BEGIN 563 -- EXPORTS ALL -- 565 IMPORTS 566 EXTENSION 567 FROM PKIX-CommonTypes-2009 568 { iso(1) identified-organization(3) dod(6) internet(1) 569 security(5) mechanisms(5) pkix(7) id-mod(0) 570 id-mod-pkixCommon-02(57) } 572 id-pe 573 FROM PKIX1Explicit-2009 574 { iso(1) identified-organization(3) dod(6) internet(1) 575 security(5) mechanisms(5) pkix(7) id-mod(0) 576 id-mod-pkix1-explicit-02(51) } ; 577 MASACertExtensions EXTENSION ::= { ext-MASAURL, ... } 578 ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax 579 IDENTIFIED BY id-pe-masa-url } 581 id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe TBD } 583 MASAURLSyntax ::= IA5String 585 END 587 589 The choice of id-pe is based on guidance found in Section 4.2.2 of 590 [RFC5280], "These extensions may be used to direct applications to 591 on-line information about the issuer or the subject". The MASA URL 592 is precisely that: online information about the particular subject. 594 3. Functional Overview 596 Entities behave in an autonomic fashion. They discover each other 597 and autonomically bootstrap into a key infrastructure delineating the 598 autonomic domain. See [RFC7575] for more information. 600 This section details the state machine and operational flow for each 601 of the main three entities. The pledge, the domain (primarily a 602 Registrar) and the MASA service. 604 A representative flow is shown in Figure 2: 606 +--------+ +---------+ +------------+ +------------+ 607 | Pledge | | Circuit | | Domain | | Vendor | 608 | | | Proxy | | Registrar | | Service | 609 | | | | | | | (Internet | 610 +--------+ +---------+ +------------+ +------------+ 611 | | | | 612 |<-RFC3927 IPv4 adr | Appendix A | | 613 or|<-RFC4862 IPv6 adr | | | 614 | | | | 615 |-------------------->| | | 616 | optional: mDNS query| Appendix B | | 617 | RFC6763/RFC6762 | | | 618 | | | | 619 |<--------------------| | | 620 | GRASP M_FLOOD | | | 621 | periodic broadcast| | | 622 | | | | 623 |<------------------->C<----------------->| | 624 | TLS via the Circuit Proxy | | 625 |<--Registrar TLS server authentication---| | 626 [PROVISIONAL accept of server cert] | | 627 P---X.509 client authentication---------->| | 628 P | | | 629 P---Request Voucher (include nonce)------>| | 630 P | | | 631 P | /---> | | 632 P | | [accept device?] | 633 P | | [contact Vendor] | 634 P | | |--Pledge ID-------->| 635 P | | |--Domain ID-------->| 636 P | | |--optional:nonce--->| 637 P | | | [extract DomainID] 638 P | | | | 639 P | optional: | [update audit log] 640 P | |can | | 641 P | |occur | | 642 P | |in | | 643 P | |advance | | 644 P | | | | 645 P | | |<-device audit log--| 646 P | | |<- voucher ---------| 647 P | \----> | | 648 P | | | 649 P | [verify audit log and voucher] | 650 P | | | 651 P<------voucher---------------------------| | 652 [verify voucher ] | | | 653 [verify provisional cert ]| | | 654 | | | | 655 |---------------------------------------->| | 656 | Continue with RFC7030 enrollment | | 657 | using now bidirectionally authenticated | | 658 | TLS session. | | | 659 | | | | 660 | | | | 661 | | | | 663 Figure 2 665 3.1. Behavior of a Pledge 667 A pledge that has not yet been bootstrapped attempts to find a local 668 domain and join it. A pledge MUST NOT automatically initiate 669 bootstrapping if it has already been configured or is in the process 670 of being configured. 672 States of a pledge are as follows: 674 +--------------+ 675 | Start | 676 | | 677 +------+-------+ 678 | 679 +------v-------+ 680 | Discover | 681 +------------> | 682 | +------+-------+ 683 | | 684 | +------v-------+ 685 | | Identity | 686 ^------------+ | 687 | rejected +------+-------+ 688 | | 689 | +------v-------+ 690 | | Request | 691 | | Join | 692 | +------+-------+ 693 | | 694 | +------v-------+ 695 | | Imprint | Optional 696 ^------------+ <--+Manual input (Appendix C) 697 | Bad Vendor +------+-------+ 698 | response | 699 | +------v-------+ 700 | | Enroll | 701 ^------------+ | 702 | Enroll +------+-------+ 703 | Failure | 704 | +------v-------+ 705 | | Being | 706 ^------------+ Managed | 707 Factory +--------------+ 708 reset 710 Figure 3 712 State descriptions for the pledge are as follows: 714 1. Discover a communication channel to a Registrar. 716 2. Identify itself. This is done by presenting an X.509 IDevID 717 credential to the discovered Registrar (via the Proxy) in a TLS 718 handshake. (The Registrar credentials are only provisionally 719 accepted at this time). 721 3. Requests to Join the discovered Registrar. A unique nonce can be 722 included ensuring that any responses can be associated with this 723 particular bootstrapping attempt. 725 4. Imprint on the Registrar. This requires verification of the 726 vendor service provided voucher. A voucher contains sufficient 727 information for the Pledge to complete authentication of a 728 Registrar. (It enables the Pledge to finish authentication of 729 the Registrar TLS server certificate). 731 5. Enroll. By accepting the domain specific information from a 732 Registrar, and by obtaining a domain certificate from a Registrar 733 using a standard enrollment protocol, e.g. Enrollment over 734 Secure Transport (EST) [RFC7030]. 736 6. The Pledge is now a member of, and can be managed by, the domain 737 and will only repeat the discovery aspects of bootstrapping if it 738 is returned to factory default settings. 740 The following sections describe each of these steps in more detail. 742 3.1.1. Discovery 744 The result of discovery is a logical communication with a Registrar, 745 through a Proxy. The Proxy is transparent to the Pledge but is 746 always assumed to exist. 748 To discover the Registrar the Pledge performs the following actions: 750 a. MUST: Obtains a local address using IPv6 methods as described in 751 [RFC4862] IPv6 Stateless Address AutoConfiguration. [RFC7217] is 752 encouraged. IPv4 methods are described in Appendix A 754 b. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) 755 announcements of the objective: "ACP+Proxy". See section 756 Section 5 for the details of the the objective. The Pledge may 757 listen concurrently for other sources of information, see 758 Appendix B. 760 Once a proxy is discovered the Pledge communicates with a Registrar 761 through the proxy using the bootstrapping protocol defined in 762 Section 7. 764 Each discovery method attempted SHOULD exponentially back-off 765 attempts (to a maximum of one hour) to avoid overloading the network 766 infrastructure with discovery. The back-off timer for each method 767 MUST be independent of other methods. Methods SHOULD be run in 768 parallel to avoid head of queue problems. Once a connection to a 769 Registrar is established (e.g. establishment of a TLS session key) 770 there are expectations of more timely responses, see Section 7.1. 772 Once all discovered services are attempted the device SHOULD return 773 to listening for GRASP M_FLOOD. It should periodically retry the 774 vendor specific mechanisms. The Pledge MAY prioritize selection 775 order as appropriate for the anticipated environment. 777 3.1.2. Identity 779 The Pledge identifies itself during the communication protocol 780 handshake. If the client identity is rejected (that is, the TLS 781 handshake does not complete) the Pledge repeats the Identity process 782 using the next proxy or discovery method available. 784 The bootstrapping protocol server is not initially authenticated. 785 Thus the connection is provisional and all data received is untrusted 786 until sufficiently validated even though it is over a TLS connection. 787 This is aligned with the existing provisional mode of EST [RFC7030] 788 during s4.1.1 "Bootstrap Distribution of CA Certificates". See 789 Section 7.3 for more information about when the TLS connection 790 authentication is completed. 792 All security associations established are between the new device and 793 the Bootstrapping server regardless of proxy operations. 795 3.1.2.1. Concurrent attempts to join 797 The Pledge MAY attempt multiple mechanisms concurrently, but if it 798 does so, it MUST wait in the provisional state until all mechanisms 799 have either succeeded or failed, and then MUST proceed with the 800 highest priority mechanism which has succeed. To proceed beyond this 801 point, specifically, to provide a nonce, could result in the MASA 802 gratuitously auditing a connection. 804 3.1.3. Request Join 806 The Pledge POSTs a request to join the domain to the Bootstrapping 807 server. This request contains a Pledge generated nonce and informs 808 the Bootstrapping server which imprint methods the Pledge will 809 accept. 811 The nonce ensures the Pledge can verify that responses are specific 812 to this bootstrapping attempt. This minimizes the use of global time 813 and provides a substantial benefit for devices without a valid clock. 815 3.1.3.1. Redirects during the Join Process 817 EST [RFC7030] describes situations where the bootstrapping server MAY 818 redirect the client to an alternate server via a 3xx status code. 819 Such redirects MAY be accepted if the pledge has used the methods 820 described in Appendix B, in combination with an implicit trust 821 anchor. Redirects during the provisional period are otherwise 822 unstrusted, and MUST cause a failure. 824 3.1.4. Imprint 826 The Pledge validates the voucher and accepts the Registrar ID. The 827 provisional TLS connection is validated using the Registrar ID from 828 the voucher. 830 3.1.5. Lack of realtime clock 832 Many devices when bootstrapping do not have knowledge of the current 833 time. Mechanisms like Network Time Protocols can not be secured 834 until bootstrapping is complete. Therefore bootstrapping is defined 835 in a method that does not require knowledge of the current time. 837 Unfortunately there are moments during bootstrapping when 838 certificates are verified, such as during the TLS handshake, where 839 validity periods are confirmed. This paradoxical "catch-22" is 840 resolved by the Pledge maintaining a concept of the current "window" 841 of presumed time validity that is continually refined throughout the 842 bootstrapping process as follows: 844 o Initially the Pledge does not know the current time. 846 o During Pledge authentiation by the Registrar a realtime clock can 847 be used by the Registrar. This bullet expands on a closely 848 related issue regarding Pledge lifetimes. RFC5280 indicates that 849 long lived Pledge certifiates "SHOULD be assigned the 850 GeneralizedTime value of 99991231235959Z" [RFC7030] so the 851 Registrar MUST support such lifetimes and SHOULD support ignoring 852 Pledge lifetimes if they did not follow the RFC5280 853 recommendations. 855 o The Pledge authenticates the voucher presented to it. During this 856 authentication the Pledge ignores certificate lifetimes (by 857 necessity because it does not have a clock). The voucher itself 858 SHOULD contain the nonce included in the original request which 859 proves the voucher is fresh. 861 o Once the voucher is accepted the validity period of the 862 domainCAcert in the voucher (see Section 7.3) now serves as a 863 valid time window. Any subsequent certificate validity periods 864 checked during RFC5280 path validation MUST occur within this 865 window. 867 o When accepting an enrollment certificate the validity period 868 within the new certificate is assumed to be valid by the Pledge. 869 The Pledge is now willing to use this credential for client 870 authentication. 872 3.1.6. Enrollment 874 As the final step of bootstrapping a Registrar helps to issue a 875 domain specific credential to the Pledge. For simplicity in this 876 document, a Registrar primarily facilitates issuing a credential by 877 acting as an RFC5280 Registration Authority for the Domain 878 Certification Authority. 880 Enrollment proceeds as described in [RFC7030]. Authentication of the 881 EST server is done using the Voucher rather than the methods defined 882 in EST. 884 Once the Voucher is received, as specified in this document, the 885 client has sufficient information to leverage the existing 886 communication channel with a Registrar to continue an EST RFC7030 887 enrollment. Enrollment picks up at RFC7030 section 4.1.1. 888 bootstrapping where the Voucher provides the "out-of-band" CA 889 certificate fingerprint (in this case the full CA certificate) such 890 that the client can now complete the TLS server authentication. At 891 this point the client continues with EST enrollment operations 892 including "CA Certificates Request", "CSR Attributes" and "Client 893 Certificate Request" or "Server-Side Key Generation". 895 For the purposes of creating the ANIMA Autonomic Control Plane, the 896 contents of the new certificate MUST be carefully specified. 897 [I-D.ietf-anima-autonomic-control-plane] section 5.1.1 contains 898 details. The Registrar MUST provide the the correct ACP information 899 to populate the subjectAltName / rfc822Name field in the "CSR 900 Attributes" step. 902 3.1.7. Being Managed 904 Functionality to provide generic "configuration" information is 905 supported. The parsing of this data and any subsequent use of the 906 data, for example communications with a Network Management System is 907 out of scope but is expected to occur after bootstrapping enrollment 908 is complete. This ensures that all communications with management 909 systems which can divulge local security information (e.g. network 910 topology or raw key material) is secured using the local credentials 911 issued during enrollment. 913 The Pledge uses bootstrapping to join only one domain. Management by 914 multiple domains is out-of-scope of bootstrapping. After the device 915 has successfully joined a domain and is being managed it is plausible 916 that the domain can insert credentials for other domains depending on 917 the device capabilities. 919 See Section 3.5. 921 3.2. Behavior of a Join Proxy 923 The role of the Proxy is to facilitate communications. The Proxy 924 forwards packets between the Pledge and a Registrar that has been 925 configured on the Proxy. 927 The Proxy does not terminate the TLS handshake. 929 A Proxy is always assumed even if it is directly integrated into a 930 Registrar. (In a completely autonomic network, the Registrar MUST 931 provide proxy functionality so that it can be discovered, and the 932 network can grow concentrically around the Registrar) 934 As a result of the Proxy Discovery process in section Section 3.1.1, 935 the port number exposed by the proxy does not need to be well known, 936 or require an IANA allocation. 938 If the Proxy joins an Autonomic Control Plane 939 ([I-D.ietf-anima-autonomic-control-plane]) it SHOULD use Autonomic 940 Control Plane secured GRASP ([I-D.ietf-anima-grasp]) to discovery the 941 Registrar address and port. As part of the discovery process, the 942 proxy mechanism (Circuit Proxy vs IPIP encapsulation) is agreed to 943 between the Registrar and Join Proxy. 945 For the IPIP encapsulation methods, the port announced by the Proxy 946 MUST be the same as on the registrar in order for the proxy to remain 947 stateless. 949 In order to permit the proxy functionality to be implemented on the 950 maximum variety of devices the chosen mechanism SHOULD use the 951 minimum amount of state on the proxy device. While many devices in 952 the ANIMA target space will be rather large routers, the proxy 953 function is likely to be implemented in the control plane CPU of such 954 a device, with available capabilities for the proxy function similar 955 to many class 2 IoT devices. 957 The document [I-D.richardson-anima-state-for-joinrouter] provides a 958 more extensive analysis of the alternative proxy methods. 960 3.2.1. CoAP connection to Registrar 962 The CoAP mechanism was depreciated. 964 3.2.2. HTTPS proxy connection to Registrar 966 The proxy SHOULD also provide one of: an IPIP encapsulation of HTTP 967 traffic on TCP port TBD to the registrar, or a TCP circuit proxy that 968 connects the Pledge to a Registrar. 970 When the Proxy provides a circuit proxy to a Registrar the Registrar 971 MUST accept HTTPS connections. 973 When the Proxy provides a stateless IPIP encapsulation to a 974 Registrar, then the Registrar will have to perform IPIP 975 decapsulation, remembering the originating outer IPIP source address 976 in order to qualify the inner link-local address. This is a kind of 977 encapsulation and processing which is similar in many ways to how 978 mobile IP works. 980 Being able to connect a TCP (HTTP) or UDP (CoAP) socket to a link- 981 local address with an encapsulated IPIP header requires API 982 extensions beyond [RFC3542] for UDP use, and requires a form of 983 connection latching (see section 4.1 of [RFC5386] and all of 984 [RFC5660], except that a simple IPIP tunnel is used rather than an 985 IPsec tunnel). 987 3.3. Behavior of the Registrar 989 A Registrar listens for Pledges and determines if they can join the 990 domain. A Registrar obtains a Voucher from the MASA service and 991 delivers them to the Pledge as well as facilitating enrollment with 992 the domain PKI. 994 A Registrar is typically configured manually. When the Registrar 995 joins an Autonomic Control Plane 996 ([I-D.ietf-anima-autonomic-control-plane]) it MUST respond to GRASP 997 ([I-D.ietf-anima-grasp]) M_DISCOVERY message. See Section 6 999 Registrar behavior is as follows: 1001 Contacted by Pledge 1002 + 1003 | 1004 +-------v----------+ 1005 | Entity | fail? 1006 | Authentication +---------+ 1007 +-------+----------+ | 1008 | | 1009 +-------v----------+ | 1010 | Entity | fail? | 1011 | Authorization +---------> 1012 +-------+----------+ | 1013 | | 1014 +-------v----------+ | 1015 | Claiming the | fail? | 1016 | Entity +---------> 1017 +-------+----------+ | 1018 | | 1019 +-------v----------+ | 1020 | Log Verification | fail? | 1021 | +---------> 1022 +-------+----------+ | 1023 | | 1024 +-------v----------+ +----v-------+ 1025 | Forward | | | 1026 | Voucher | | Reject | 1027 | to the Pledge | | Device | 1028 | | | | 1029 +------------------+ +------------+ 1031 Figure 4 1033 3.3.1. Pledge Authentication 1035 The applicable authentication methods detailed in EST [RFC7030] are: 1037 o the use of an X.509 IDevID credential during the TLS client 1038 authentication, 1040 o or the use of a secret that is transmitted out of band between the 1041 Pledge and a Registrar (this use case is not autonomic). 1043 In order to validate the X.509 IDevID credential a Registrar 1044 maintains a database of vendor trust anchors (e.g. vendor root 1045 certificates or keyIdentifiers for vendor root public keys). For 1046 user interface purposes this database can be mapped to colloquial 1047 vendor names. Registrars can be shipped with the trust anchors of a 1048 significant number of third-party vendors within the target market. 1050 3.3.2. Pledge Authorization 1052 In a fully automated network all devices must be securely identified 1053 and authorized to join the domain. 1055 A Registrar accepts or declines a request to join the domain, based 1056 on the authenticated identity presented. Automated acceptance 1057 criteria include: 1059 o allow any device of a specific type (as determined by the X.509 1060 IDevID), 1062 o allow any device from a specific vendor (as determined by the 1063 X.509 IDevID), 1065 o allow a specific device from a vendor (as determined by the X.509 1066 IDevID) against a domain white list. (The mechanism for checking 1067 a shared white list potentially used by multiple Registrars is out 1068 of scope). 1070 To look the Pledge up in a domain white list a consistent method for 1071 extracting device identity from the X.509 certificate is required. 1072 RFC6125 describes Domain-Based Application Service identity but here 1073 we require Vendor Device-Based identity. The subject field's DN 1074 encoding MUST include the "serialNumber" attribute with the device's 1075 unique serial number. In the language of RFC6125 this provides for a 1076 SERIALNUM-ID category of identifier that can be included in a 1077 certificate and therefore that can also be used for matching 1078 purposes. The SERIALNUM-ID whitelist is collated according to vendor 1079 trust anchor since serial numbers are not globally unique. 1081 The Registrar MUST use the vendor provided MASA service to verify 1082 that the device's history log does not include unexpected Registrars. 1083 If a device had previously registered with another domain, a 1084 Registrar of that domain would show in the log. 1086 The authorization performed during BRSKI MAY be used for EST 1087 enrollment requests by proceeding with EST enrollment using the 1088 authenticated and authorized TLS connection. This minimizes the 1089 number of cryptographic and protocol operations necessary to complete 1090 bootstraping of the local key infrastructure. 1092 3.3.3. Claiming the New Entity 1094 Claiming an entity establishes an audit log at the MASA server and 1095 provides a Registrar with proof, in the form of the Voucher, that the 1096 log entry has been inserted. As indicated in Section 3.1.4 a Pledge 1097 will only proceed with bootstrapping if a Voucher has been received. 1099 The Pledge therefore enforces that bootstrapping only occurs if the 1100 claim has been logged. There is no requirement for the vendor to 1101 definitively know that the device is owned by the Registrar. 1103 The Registrar obtains the MASA URI via static configuration or by 1104 extracting it from the X.509 IDevID credential. See Section 2.3. 1106 During initial bootstrapping the Pledge provides a nonce specific to 1107 the particular bootstrapping attempt. The Registrar SHOULD include 1108 this nonce when claiming the Pledge from the MASA service. Claims 1109 from an unauthenticated Registrar are only serviced by the MASA 1110 resource if a nonce is provided. 1112 The Registrar can claim a Pledge that is not online by forming the 1113 request using the entities unique identifier and not including a 1114 nonce in the claim request. Vouchers obtained in this way do not 1115 have a lifetime and they provide a permanent method for the domain to 1116 claim the device. Evidence of such a claim is provided in the audit 1117 log entries available to any future Registrar. Such claims reduce 1118 the ability for future domains to secure bootstrapping and therefore 1119 the Registrar MUST be authenticated by the MASA service although no 1120 requirement is implied that the MASA associates this authentication 1121 with ownership. 1123 An Ownership Voucher requires the vendor to definitively know that a 1124 device is owned by a specific domain. The method used to "claim" 1125 this are out-of-scope. A MASA ignores or reports failures when an 1126 attempt is made to claim a device that has a an Ownership Voucher. 1128 3.3.4. Log Verification 1130 A Registrar requests the log information for the Pledge from the MASA 1131 service. The log is verified to confirm that the following is true 1132 to the satisfaction of a Registrar's configured policy: 1134 o Any nonceless entries in the log are associated with domainIDs 1135 recognized by the registrar. 1137 o Any nonce'd entries are older than when the domain is known to 1138 have physical possession of the Pledge or that the domainIDs are 1139 recognized by the registrar. 1141 If any of these criteria are unacceptable to a Registrar the entity 1142 is rejected. A Registrar MAY be configured to ignore the history of 1143 the device but it is RECOMMENDED that this only be configured if 1144 hardware assisted NEA [RFC5209] is supported. 1146 This document specifies a simple log format as provided by the MASA 1147 service to the registar. This format could be improved by 1148 distributed consensus technologies that integrate vouchers with a 1149 technologies such as block-chain or hash trees or the like. Doing so 1150 is out of the scope of this document but are anticipated improvements 1151 for future work. 1153 3.4. Behavior of the MASA Service 1155 The Manufacturer Authorized Signing Authority service is directly 1156 provided by the manufacturer, or can be provided by a third party the 1157 manufacturer authorizes. It is a cloud resource. The MASA service 1158 provides the following functionalities to Registrars: 1160 Issue Vouchers: In response to Registrar requests the MASA service 1161 issues vouchers. Depending on the MASA policy the Registrar claim 1162 of device ownership is either accepted or verified using out-of- 1163 scope methods (that are expected to improve over time). 1165 Log Vouchers Issued: When a voucher is issued the act of issuing it 1166 includes updating the certifiable logs. Future work to enhance 1167 and distribute these logs is out-of-scope but expected over time. 1169 Provide Logs: As a baseline implementation of the certified logging 1170 mechanism the MASA is repsonsible for reporting logged 1171 information. The current method involves trusting the MASA. 1172 Other logging methods where the MASA is less trusted are expected 1173 to be developed over time. 1175 3.5. Leveraging the new key infrastructure / next steps 1177 As the devices have a common trust anchor, device identity can be 1178 securely established, making it possible to automatically deploy 1179 services across the domain in a secure manner. 1181 Examples of services: 1183 o Device management. 1185 o Routing authentication. 1187 o Service discovery. 1189 3.5.1. Network boundaries 1191 When a device has joined the domain, it can validate the domain 1192 membership of other devices. This makes it possible to create trust 1193 boundaries where domain members have higher level of trusted than 1194 external devices. Using the autonomic User Interface, specific 1195 devices can be grouped into to sub domains and specific trust levels 1196 can be implemented between those. 1198 3.6. Interactions with Network Access Control 1200 The assumption is that Network Access Control (NAC) completes using 1201 the Pledge 's X.509 IDevID credentials and results in the device 1202 having sufficient connectivity to discovery and communicate with the 1203 proxy. Any additional connectivity or quarantine behavior by the NAC 1204 infrastructure is out-of-scope. After the devices has completed 1205 bootstrapping the mechanism to trigger NAC to re-authenticate the 1206 device and provide updated network privileges is also out-of-scope. 1208 This achieves the goal of a bootstrap architecture that can integrate 1209 with NAC but does not require NAC within the network where it wasn't 1210 previously required. Future optimizations can be achieved by 1211 integrating the bootstrapping protocol directly into an initial EAP 1212 exchange. 1214 4. Domain Operator Activities 1216 This section describes how an operator interacts with a domain that 1217 supports the bootstrapping as described in this document. 1219 4.1. Instantiating the Domain Certification Authority 1221 This is a one time step by the domain administrator. This is an "off 1222 the shelf" CA with the exception that it is designed to work as an 1223 integrated part of the security solution. This precludes the use of 1224 3rd party certification authority services that do not provide 1225 support for delegation of certificate issuance decisions to a domain 1226 managed Registration Authority. 1228 4.2. Instantiating the Registrar 1230 This is a one time step by the domain administrator. One or more 1231 devices in the domain are configured take on a Registrar function. 1233 A device can be configured to act as a Registrar or a device can 1234 auto-select itself to take on this function, using a detection 1235 mechanism to resolve potential conflicts and setup communication with 1236 the Domain Certification Authority. Automated Registrar selection is 1237 outside scope for this document. 1239 4.3. Accepting New Entities 1241 For each Pledge the Registrar is informed of the unique identifier 1242 (e.g. serial number) along with the manufacturer's identifying 1243 information (e.g. manufacturer root certificate). This can happen in 1244 different ways: 1246 1. Default acceptance: In the simplest case, the new device asserts 1247 its unique identity to a Registrar. The registrar accepts all 1248 devices without authorization checks. This mode does not provide 1249 security against intruders and is not recommended. 1251 2. Per device acceptance: The new device asserts its unique identity 1252 to a Registrar. A non-technical human validates the identity, 1253 for example by comparing the identity displayed by the registrar 1254 (for example using a smartphone app) with the identity shown on 1255 the packaging of the device. Acceptance may be triggered by a 1256 click on a smartphone app "accept this device", or by other forms 1257 of pairing. See also [I-D.behringer-homenet-trust-bootstrap] for 1258 how the approach could work in a homenet. 1260 3. Whitelist acceptance: In larger networks, neither of the previous 1261 approaches is acceptable. Default acceptance is not secure, and 1262 a manual per device methods do not scale. Here, the registrar is 1263 provided a priori with a list of identifiers of devices that 1264 belong to the network. This list can be extracted from an 1265 inventory database, or sales records. If a device is detected 1266 that is not on the list of known devices, it can still be 1267 manually accepted using the per device acceptance methods. 1269 4. Automated Whitelist: an automated process that builds the 1270 necessary whitelists and inserts them into the larger network 1271 domain infrastructure is plausible. Once set up, no human 1272 intervention is required in this process. Defining the exact 1273 mechanisms for this is out of scope although the registrar 1274 authorization checks is identified as the logical integration 1275 point of any future work in this area. 1277 None of these approaches require the network to have permanent 1278 Internet connectivity. Even when the Internet based MASA service is 1279 used, it is possible to pre-fetch the required information from the 1280 MASA a priori, for example at time of purchase such that devices can 1281 enroll later. This supports use cases where the domain network may 1282 be entirely isolated during device deployment. 1284 Additional policy can be stored for future authorization decisions. 1285 For example an expected deployment time window or that a certain 1286 Proxy must be used. 1288 4.4. Automatic Enrollment of Devices 1290 The approach outlined in this document provides a secure zero-touch 1291 method to enroll new devices without any pre-staged configuration. 1292 New devices communicate with already enrolled devices of the domain, 1293 which proxy between the new device and a Registrar. As a result of 1294 this completely automatic operation, all devices obtain a domain 1295 based certificate. 1297 4.5. Secure Network Operations 1299 The certificate installed in the previous step can be used for all 1300 subsequent operations. For example, to determine the boundaries of 1301 the domain: If a neighbor has a certificate from the same trust 1302 anchor it can be assumed "inside" the same organization; if not, as 1303 outside. See also Section 3.5.1. The certificate can also be used 1304 to securely establish a connection between devices and central 1305 control functions. Also autonomic transactions can use the domain 1306 certificates to authenticate and/or encrypt direct interactions 1307 between devices. The usage of the domain certificates is outside 1308 scope for this document. 1310 5. Proxy Discovery Protocol Details 1312 The proxy uses the GRASP M_FLOOD mechanism to announce itself. This 1313 announcement is done with the same message as the ACP announcement 1314 detailed in [I-D.ietf-anima-autonomic-control-plane]. 1316 proxy-objective = ["Proxy", [ O_IPv6_LOCATOR, ipv6-address, 1317 transport-proto, port-number ] ] 1319 ipv6-address - the v6 LL of the proxy 1320 transport-proto - 6, for TCP 17 for UDP 1321 port-number - the TCP or UDP port number to find the proxy 1323 Figure 5 1325 6. Registrar Discovery Protocol Details 1327 The registrar responds to discovery messages from the proxy (or GRASP 1328 caches between them) as follows: (XXX changed from M_DISCOVERY) 1330 objective = ["AN_registrar", F_DISC, 255 ] 1331 discovery-message = [M_NEG_SYN, session-id, initiator, objective] 1333 Figure 6: Registrar Discovery 1334 The response from the registrar (or cache) will be a M_RESPONSE with 1335 the following parameters: 1337 response-message = [M_RESPONSE, session-id, initiator, ttl, 1338 (+locator-option // divert-option), ?objective)] 1339 initiator = ACP address of Registrar 1340 locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] 1341 locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] 1342 locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] 1344 Figure 7: Registrar Response 1346 The set of locators is to be interpreted as follows. A protocol of 6 1347 indicates that TCP proxying on the indicated port is desired. A 1348 protocol of 17 indicates that UDP proxying on the indicated port is 1349 desired. In each case, the traffic SHOULD be proxied to the same 1350 port at the ULA address provided. 1352 A protocol of 41 indicates that packets may be IPIP proxy'ed. The 1353 address in the locator In the case of that IPIP proxying is used, 1354 then the provided link-local address MUST be advertised on the local 1355 link using proxy neighbour discovery. The Join Proxy MAY limit 1356 forwarded traffic to the protocol (6 and 17) and port numbers 1357 indicated by locator1 and locator2. The address to which the IPIP 1358 traffic should be sent is the initiator address (an ACP address of 1359 the Registrar), not the address given in the locator. 1361 All Registrar MUST accept TCP / UDP traffic on the ports given at the 1362 ACP address of the Registrar. If the Registrar supports IPIP 1363 tunnelling, it MUST also accept traffic encapsulated with IPIP. 1365 Registrars MUST accept HTTPS/EST traffic on the ports indicated. 1366 Registrars MAY accept DTLS/CoAP/EST traffic in addition. 1368 7. Protocol Details 1370 A bootstrapping protocol could be implemented as an independent 1371 protocol from EST, but for simplicity and to reduce the number of TLS 1372 connections and crypto operations required on the Pledge, it is 1373 described specifically as extensions to EST. These extensions MUST 1374 be supported by the Registrar EST server within the same .well-known 1375 URI tree as the existing EST URIs as described in EST [RFC7030] 1376 section 3.2.2. 1378 A MASA URI is therefore "https:// authority "./well-known/est". The 1379 portion contained in the IDevID extension is only 1380 "https://example.com" since everything after that is well known. 1382 Establishment of the TLS connection for bootstrapping is as specified 1383 for EST [RFC7030]. In particular server identity and client identity 1384 are as described in EST [RFC7030] section 3.3. In EST [RFC7030] 1385 provisional server authentication for bootstrapping is described in 1386 section 4.1.1 wherein EST clients can "engage a human user to 1387 authorize the CA certificate using out-of-band data such as a CA 1388 certificate" or wherein a human user configures the URI of the EST 1389 server for Implicit TA based authentication. This documented 1390 establishes automated methods of authorizing the CA certificate using 1391 in-band vouchers. 1393 If the Pledge uses a well known URI for contacting a well known 1394 Registrar the EST Implicit Trust Anchor database is used to 1395 authenticate the well known URI. In this case the connection is not 1396 provisional and RFC6125 methods can be used to authenticate the 1397 Registrar 1399 The Pledge establishes a TLS connection with the Registrar through 1400 the circuit proxy (see Section 3.2) but the TLS connection is with 1401 the Registar; so for this section the "Pledge" is the TLS client and 1402 the "Registrar" is the TLS server. 1404 The extensions for the Pledge client are as follows: 1406 o The Pledge provisionally accept the EST server certificate during 1407 the TLS handshake as detailed in Section 7.3.1. 1409 o The Pledge requests and validates the Voucher as described below. 1410 At this point the Pledge has sufficient information to validate 1411 domain credentials. 1413 o The Pledge calls the EST defined /cacerts method to obtain the 1414 current CA certificate. These are validated using the Voucher. 1416 o The Pledge completes bootstrapping as detailed in EST section 1417 4.1.1. 1419 In order to obtain a Voucher and associated logs a Registrar contacts 1420 the MASA service Service using REST calls: 1422 +-----------+ +----------+ +-----------+ +----------+ 1423 | New | | Circuit | | | | | 1424 | Entity | | Proxy | | Registrar | | Vendor | 1425 | | | | | | | | 1426 ++----------+ +--+-------+ +-----+-----+ +--------+-+ 1427 | | | | 1428 | | | | 1429 | TLS hello | TLS hello | | 1430 Establish +---------------C---------------> | 1431 TLS | | | | 1432 connection | | Server Cert | | 1433 <---------------C---------------+ | 1434 | Client Cert | | | 1435 +---------------C---------------> | 1436 | | | | 1437 HTTP REST | POST /requestvoucher | | 1438 Data +--------------------nonce------> | 1439 | . | /requestvoucher| 1440 | . +----------------> 1441 | <----------------+ 1442 | | /requestlog | 1443 | +----------------> 1444 | voucher <----------------+ 1445 <-------------------------------+ | 1446 | (optional config information) | | 1447 | . | | 1448 | . | | 1450 Figure 8 1452 In some use cases the Registrar may need to contact the Vendor in 1453 advanced, for example when the target network is air-gapped. The 1454 nonceless request format is provided for this and the resulting flow 1455 is slightly different. The security differences associated with not 1456 knowing the nonce are discussed below: 1458 +-----------+ +----------+ +-----------+ +----------+ 1459 | New | | Circuit | | | | | 1460 | Entity | | Proxy | | Registrar | | Vendor | 1461 | | | | | | | | 1462 ++----------+ +--+-------+ +-----+-----+ +--------+-+ 1463 | | | | 1464 | | | | 1465 | | | /requestvoucher| 1466 | | (nonce +----------------> 1467 | | unknown) <----------------+ 1468 | | | /requestlog | 1469 | | +----------------> 1470 | | <----------------+ 1471 | TLS hello | TLS hello | | 1472 Establish +---------------C---------------> | 1473 TLS | | | | 1474 connection | | Server Cert | | 1475 <---------------C---------------+ | 1476 | Client Cert | | | 1477 | | | | 1478 HTTP REST | POST /requestvoucher | | 1479 Data +----------------------nonce----> (discard | 1480 | voucher | nonce) | 1481 <-------------------------------+ | 1482 | (optional config information) | | 1483 | . | | 1484 | . | | 1486 Figure 9 1488 The extensions for a Registrar server are as follows: 1490 o The Registrar requests and validates the Voucher from the vendor 1491 authorized MASA service. 1493 o The Registrar forwards the Voucher to the Pledge when requested. 1495 o The Registar performs log verifications in addition to local 1496 authorization checks before accepting the Pledge device. 1498 The provisional TLS connection introduces security risks that are 1499 addressed as follows: 1501 If the Registrar provides a redirect response the Pledge MUST follow 1502 the redirect but the connection remains provisional. The Pledge MUST 1503 only follow a single redirection. 1505 The Registar MAY respond with an HTTP 202 ("the request has been 1506 accepted for processing, but the processing has not been completed") 1507 as described in EST [RFC7030] section 4.2.3 wherein the client "MUST 1508 wait at least the specified 'retry-after' time before repeating the 1509 same request". The Pledge is RECOMMENDED to provide local feed 1510 (blinked LED etc) during this wait cycle if mechanisms for this are 1511 available. To prevent an attacker Registrar from significantly 1512 delaying bootstrapping the Pledge MUST limit the 'retry-after' time 1513 to 60 seconds. To avoid waiting on a single erroneous Registrar the 1514 Pledge MUST drop the connection after 5 seconds and proceed to other 1515 discovered Registrars. Ideally the Pledge could keep track of the 1516 appropriate retry-after value for any number of outstanding 1517 Registrars but this would involve a large state table on the Pledge. 1518 Instead the Pledge MAY ignore the exact retry-after value in favor of 1519 a single hard coded value that takes effect between discovery 1520 (Section 3.1.1) attempts. A Registrar that is unable to complete the 1521 transaction the first time due to timing reasons will have future 1522 chances. 1524 7.1. Request Voucher from the Registrar 1526 When the Pledge bootstraps it makes a request for a Voucher from a 1527 Registrar. 1529 This is done with an HTTPS POST using the operation path value of 1530 "/requestvoucher". 1532 The request format is JSON object containing a 64bit nonce generated 1533 by the client for each request. This nonce MUST be a 1534 cryptographically strong random or pseudo-random number that can not 1535 be easily predicted. The nonce MUST NOT be reused for multiple 1536 attempts to join a network domain. The nonce assures the Pledge that 1537 the Voucher response is associated with this bootstrapping attempt 1538 and is not a replay. 1540 Request media type: application/voucherrequest 1542 Request format: a JSON file with the following: 1544 { 1545 "version":"1", 1546 "nonce":"<64bit nonce value>", 1547 } 1549 [[EDNOTE: Even if the nonce was signed it would provide no defense 1550 against rogue registrars; although it would assure the MASA that a 1551 certified Pledge exists. To protect against rogue registrars a nonce 1552 component generated by the MASA (a new round trip) would be 1553 required). Instead this is addressed by requiring MASA & Registrar 1554 authentications but it is worth exploring additional protections. 1555 This to be explored more at IETF96.]] 1557 The Registrar validates the client identity as described in EST 1558 [RFC7030] section 3.3.2. The registrar performs authorization as 1559 detailed in Section 3.3.2. If authorization is successful the 1560 Registrar obtains an Voucher from the MASA service (see Section 5.2). 1562 The received Voucher is forwarded to the Pledge. 1564 7.2. Request Voucher from MASA 1566 A Registrar requests a Voucher from the MASA service using a REST 1567 interface. For simplicity this is defined as an optional EST message 1568 between a Registrar and an EST server running on the MASA service 1569 although the Registrar is not required to make use of any other EST 1570 functionality when communicating with the MASA service. (The MASA 1571 service MUST properly reject any EST functionality requests it does 1572 not wish to service; a requirement that holds for any REST 1573 interface). 1575 This is done with an HTTP POST using the operation path value of 1576 "/requestvoucher". 1578 Request media type: application/voucherrequest+cms 1580 The request format is a JSON object optionally containing the nonce 1581 value (as obtained from the bootstrap request) and the X.509 IDevID 1582 extracted serial number (the full certificate is not needed and no 1583 proof-of-possession information for the device identity is included). 1584 The AuthorityKeyIdentifier value from the certificate is included to 1585 ensure a statistically unique identity. The Pledge's serial number 1586 is extracted from the X.509 IDevID. See Section 2.3. 1588 { 1589 "version":"1", 1590 "nonce":"<64bit nonce value>", 1591 "IDevIDAuthorityKeyIdentifier":", 1592 "DevIDSerialNumber":"", 1594 } 1596 A Registrar MAY exclude the nonce from the request. Doing so allows 1597 the Registrar to request a Voucher when the Pledge is not online, or 1598 when the target bootstrapping environment is not on the same network 1599 as the MASA server (this requires the Registrar to learn the 1600 appropriate DevIDSerialNumber field from the physical device labeling 1601 or from the sales channel -- how this occurs is out-of-scope of this 1602 document). If a nonce is not provided the MASA server MUST 1603 authenticate the Registrar as described in EST [RFC7030] section 1604 3.3.2 to reduce the risk of DDoS attacks. The MASA performs 1605 authorization as detailed in Section 3.3.2. 1607 As described in [I-D.ietf-anima-voucher] vouchers are normally short 1608 lived to avoid revocation issues. If the request is for a previous 1609 (expired) voucher using the same Registrar (as determined by 1610 domainID) and the MASA has not been informed that the claim is no 1611 longer valid - the request for a renewed voucher SHOULD be 1612 automatically authorized. If authorization is successful the MASA 1613 responds with a [I-D.ietf-anima-voucher] voucher. The MASA SHOULD 1614 check for revocation of the Registrar certificate. The maximum 1615 lifetime of the voucher issued SHOULD NOT exceed the lifetime of the 1616 Registrar's revocation validation (for example if the Registrar 1617 revocation status is indicated in a CRL that is valid for two weeks 1618 then that is an appropriate lifetime for the voucher). 1620 The voucher request is encapsulated in a [RFC5652] Signed-data that 1621 is signed by the Registrar. The entire certificate chain, up to and 1622 including the Domain CA, MUST be included in the CertificateSet 1623 structure. The MASA service checks the internal consistency of the 1624 CMS but does not authenticate the domain identity information. The 1625 domain is not know to the MASA server in advance and a shared trust 1626 anchor is not implied. The MASA server MUST verify that the CMS is 1627 signed by a Registrar certificate (by checking for the cmc-idRA 1628 field) that was issued by a the root certificate included in the CMS. 1629 This ensures that the Registrar making the claim is an authorized 1630 Registrar of the unauthenticated domain. 1632 The root certificate is extracted and used to populate the Voucher. 1633 The domain ID (e.g. hash of the public key of the domain) is 1634 extracted from the root certificate and is used to update the audit 1635 log. 1637 7.3. Voucher Response 1639 The voucher response to requests from the device and requests from a 1640 Registrar are in the same format. A Registrar either caches prior 1641 MASA responses or dynamically requests a new Voucher based on local 1642 policy. 1644 If the the join operation is successful, the server response MUST 1645 contain an HTTP 200 response code. The server MUST answer with a 1646 suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. 1647 The response data from the MASA server MUST be a plaintext human- 1648 readable error message containing explanatory information describing 1649 why the request was rejected. 1651 Response media type: application/voucher+cms 1653 The syntactic details of vouchers are described in detail in 1654 [I-D.ietf-anima-voucher]. For example, the voucher consists of: 1656 { 1657 "version":"1", 1658 "nonce":"<64bit nonce value>", 1659 "IDevIDAuthorityKeyIdentifier":"", 1660 "DevIDSerialNumber":"", 1661 "domainCAcert":"" 1662 } 1664 The Voucher response is encapsulated in a [RFC5652] Signed-data that 1665 is signed by the MASA server. The Pledge verifies this signed 1666 message using the manufacturer installed trust anchor associated with 1667 the X.509 IDevID. [[EDNOTE: As detailed in netconf-zerotouch this 1668 might be a distinct trust anchor rather than re-using the trust 1669 anchor for the IDevID. This concept will need to be detailed in this 1670 document as well.]] 1672 The 'domainCAcert' element of this message contains the domain CA's 1673 public key. This is specific to bootstrapping a public key 1674 infrastructure. To support bootstrapping other key infrastructures 1675 additional domain identity types might be defined in the future. 1676 Clients MUST be prepared to ignore additional fields they do not 1677 recognize. Clients MUST be prepared to parse and fail gracefully 1678 from an Voucher response that does not contain a 'domainCAcert' field 1679 at all. 1681 To minimize the size of the Voucher response message the domainCAcert 1682 is not a complete distribution of the EST section 4.1.3 CA 1683 Certificate Response. The Pledge installs the domainCAcert trust 1684 anchor. As indicated in Section 3.1.2 the newly installed trust 1685 anchor is used as an EST RFC7030 Explicit Trust Anchor. The Pledge 1686 MUST use the domainCAcert trust anchor to immediately validate the 1687 currently provisional TLS connection to a Registrar. 1689 7.3.1. Completing authentication of Provisional TLS connection 1691 If a Registrar's credential can not be verified using the 1692 domainCAcert trust anchor the TLS connection is immediately discarded 1693 and the Pledge abandons attempts to bootstrap with this discovered 1694 registrar. 1696 The following behaviors on a Registrar and Pledge are in addition to 1697 normal PKIX operations: 1699 o The EST server MUST use a certificate that chains to the 1700 domainCAcert. This means that when the EST server obtains renewed 1701 credentials the credentials included in the Section 7.2 request 1702 match the chain used in the current provisional TLS connection. 1704 o The Pledge PKIX path validation of a Registrar validity period 1705 information is as described in Section 3.1.5. 1707 Because the domainCAcert trust anchor is installed as an Explicit 1708 Trust Anchor it can be used to authenticate any dynamically 1709 discovered EST server that contain the id-kp-cmcRA extended key usage 1710 extension as detailed in EST RFC7030 section 3.6.1; but to reduce 1711 system complexity the Pledge SHOULD avoid additional discovery 1712 operations. Instead the Pledge SHOULD communicate directly with the 1713 Registrar as the EST server to complete PKI local certificate 1714 enrollment. Additionally the Pledge SHOULD use the existing TLS 1715 connection to proceed with EST enrollment, thus reducing the total 1716 amount of cryptographic and round trip operations required during 1717 bootstrapping. [[EDNOTE: It is reasonable to mandate that the 1718 existing TLS connection be re-used? e.g. MUST >> SHOULD?]] 1720 7.4. Voucher Status Telemetry 1722 For automated bootstrapping of devices the adminstrative elements 1723 providing bootstrapping also provide indications to the system 1724 administrators concerning device lifecycle status. To facilitate 1725 this those elements need telemetry information concerning the 1726 device's status. 1728 To indicate Pledge status regarding the Voucher the client SHOULD 1729 post a status message. 1731 The posted data media type: application/json 1733 The client HTTP POSTs the following to the server at the EST well 1734 known URI /voucher_status. The Status field indicates if the Voucher 1735 was acceptable. If it was not acceptable the Reason string indicates 1736 why. In the failure case this message is being sent to an 1737 unauthenticated, potentially malicious Registrar and therefore the 1738 Reason string SHOULD NOT provide information beneficial to an 1739 attacker. The operational benefit of this telemetry information is 1740 balanced against the operational costs of not recording that an 1741 Voucher was ignored by a client the registar expected to continue 1742 joining the domain. 1744 { 1745 "version":"1", 1746 "Status":FALSE /* TRUE=Success, FALSE=Fail" 1747 "Reason":"Informative human readable message" 1748 } 1750 The server SHOULD respond with an HTTP 200 but MAY simply fail with 1751 an HTTP 404 error. The client ignores any response. Within the 1752 server logs the server SHOULD capture this telemetry information. 1754 7.5. MASA authorization log Request 1756 A registrar requests the MASA authorization log from the MASA service 1757 using this EST extension. 1759 This is done with an HTTP GET using the operation path value of 1760 "/requestauditlog". 1762 The client MUST HTTP POSTs the same Voucher Request as for requesting 1763 a Voucher. It is posted to the /requestauditlog URI instead. The 1764 IDevIDAuthorityKeyIdentifier and DevIDSerialNumber informs the MASA 1765 server which log is requested so the appropriate log can be prepared 1766 for the response. Using the same media type and message minimizes 1767 cryptographic and message operations although it results in 1768 additional network traffic. The relying MASA server implementation 1769 MAY leverage internal state to associate this request with the 1770 original, and by now already validated, voucher request so as to 1771 avoid an extra crypto validation. 1773 Request media type: application/voucherrequest+cms 1775 7.6. MASA authorization log Response 1777 A log data file is returned consisting of all log entries. For 1778 example: 1780 { 1781 "version":"1", 1782 "events":[ 1783 { 1784 "date":"", 1785 "domainID":"", 1787 "nonce":"" 1788 }, 1789 { 1790 "date":"", 1791 "domainID":"", 1793 "nonce":"" 1794 } 1795 ] 1796 } 1798 Distribution of a large log is less than ideal. This structure can 1799 be optimized as follows: All nonce-less entries for the same domainID 1800 MAY be condensed into the single most recent nonceless entry. 1802 A Registrar uses this log information to make an informed decision 1803 regarding the continued bootstrapping of the Pledge. For example if 1804 the log includes unexpected domainIDs this is indicative of 1805 problematic imprints by the Pledge. If the log includes nonce-less 1806 entries this is indicative of the permanent ability for the indicated 1807 domain to trigger a reset of the device and take over management of 1808 it. Equipment that is purchased pre-owned can be expected to have an 1809 extensive history. 1811 Log entries containing the Domain's ID can be compared against local 1812 history logs in search of discrepancies. 1814 7.7. EST Integration for PKI bootstrapping 1816 The prior sections describe EST extensions necessary to enable fully 1817 automated bootstrapping. Although the Voucher request/response 1818 structure members IDevIDAuthorityKeyIdentifier and DevIDSerialNumber 1819 are specific to PKI bootstrapping these are the only PKI specific 1820 aspects of the extensions and future work might replace them with 1821 non-PKI structures. 1823 The prior sections provide functionality for the Pledge to obtain a 1824 trust anchor representative of the Domain. The following section 1825 describe using EST to obtain a locally issued PKI certificate. The 1826 Pledge SHOULD leverage the discovered Registrar to proceed with 1827 certificate enrollment and, if they do, MUST implement the EST 1828 options described in this section. The Pledge MAY perform 1829 alternative enrollment methods including discovering an alternate EST 1830 server, or proceed to use its X.509 IDevID credential indefinitely. 1832 7.7.1. EST Distribution of CA Certificates 1834 The Pledge MUST request the full EST Distribution of CA Certificates 1835 message. See RFC7030, section 4.1. 1837 This ensures that the Pledge has the complete set of current CA 1838 certificates beyond the domainCAcert (see Section 7.3 for a 1839 discussion of the limitations). Although these restrictions are 1840 acceptable for a Registrar integrated with initial bootstrapping they 1841 are not appropriate for ongoing PKIX end entity certificate 1842 validation. 1844 7.7.2. EST CSR Attributes 1846 Automated bootstrapping occurs without local administrative 1847 configuration of the Pledge. In some deployments its plausible that 1848 the Pledge generates a certificate request containing only identity 1849 information known to the Pledge (essentially the X.509 IDevID 1850 information) and ultimately receives a certificate containing domain 1851 specific identity information. Conceptually the CA has complete 1852 control over all fields issued in the end entity certificate. 1853 Realistically this is operationally difficult with the current status 1854 of PKI certificate authority deployments where the CSR is submitted 1855 to the CA via a number of non-standard protocols. 1857 To alleviate operational difficulty the Pledge MUST request the EST 1858 "CSR Attributes" from the EST server. This allows the local 1859 infrastructure to inform the Pledge of the proper fields to include 1860 in the generated CSR. 1862 [[EDNOTE: The following is specific to anima purposes and should be 1863 moved to an appropriate anima document so as to keep bootstrapping as 1864 generic as possible: What we want are a 'domain name' stored in [TBD] 1865 and an 'ACP IPv6 address' stored in the iPAddress field as specified 1866 in RFC5208 s4.2.1.6. ref ACP draft where certificate verification 1867 [TBD]. These should go into the subjectaltname in the [TBD] 1868 fields.]]. If the hardwareModuleName in the X.509 IDevID is 1869 populated then it SHOULD by default be propagated to the LDevID along 1870 with the hwSerialNum. The registar SHOULD support local policy 1871 concerning this functionality. [[EDNOTE: extensive use of EST CSR 1872 Attributes might need an new OID definition]].]] 1874 The Registar MUST also confirm the resulting CSR is formatted as 1875 indicated before forwarding the request to a CA. If the Registar is 1876 communicating with the CA using a protocol like full CMC which 1877 provides mechanisms to override the CSR attributes, then these 1878 mechanisms MAY be used even if the client ignores CSR Attribute 1879 guidance. 1881 7.7.3. EST Client Certificate Request 1883 The Pledge MUST request a new client certificate. See RFC7030, 1884 section 4.2. 1886 7.7.4. Enrollment Status Telemetry 1888 For automated bootstrapping of devices the adminstrative elements 1889 providing bootstrapping also provide indications to the system 1890 administrators concerning device lifecycle status. This might 1891 include information concerning attempted bootstrapping messages seen 1892 by the client, MASA provides logs and status of credential 1893 enrollment. The EST protocol assumes an end user and therefore does 1894 not include a final success indication back to the server. This is 1895 insufficient for automated use cases. 1897 To indicate successful enrollment the client SHOULD re-negotiate the 1898 EST TLS session using the newly obtained credentials. This occurs by 1899 the client initiating a new TLS ClientHello message on the existing 1900 TLS connection. The client MAY simply close the old TLS session and 1901 start a new one. The server MUST support either model. 1903 In the case of a FAIL the Reason string indicates why the most recent 1904 enrollment failed. The SubjectKeyIdentifier field MUST be included 1905 if the enrollment attempt was for a keypair that is locally known to 1906 the client. If EST /serverkeygen was used and failed then the field 1907 is ommited from the status telemetry. 1909 In the case of a SUCCESS the Reason string is ommitted. The 1910 SubjectKeyIdentifier is included so that the server can record the 1911 successful certificate distribution. 1913 Status media type: application/json 1915 The client HTTP POSTs the following to the server at the new EST well 1916 known URI /enrollstatus. 1918 { 1919 "version":"1", 1920 "Status":TRUE /* TRUE=Success, FALSE=Fail" 1921 "Reason":"Informative human readable message" 1922 "SubjectKeyIdentifier":"" 1924 } 1926 The server SHOULD respond with an HTTP 200 but MAY simply fail with 1927 an HTTP 404 error. 1929 Within the server logs the server MUST capture if this message was 1930 recieved over an TLS session with a matching client certificate. 1931 This allows for clients that wish to minimize their crypto operations 1932 to simply POST this response without renegotiating the TLS session - 1933 at the cost of the server not being able to accurately verify that 1934 enrollment was truly successful. 1936 7.7.5. EST over CoAP 1938 [[EDNOTE: In order to support smaller devices the above section on 1939 Proxy behavior introduces mandatory to implement support for CoAP 1940 support by the Proxy. This implies similar support by the Pledge and 1941 Registrar and means that the EST protocol operation encapsulation 1942 into CoAP needs to be described. EST is HTTP based and "CoaP is 1943 designed to easily interface with HTTP for integration" [RFC7252]. 1944 Use of CoAP implies Datagram TLS (DTLS) wherever this document 1945 describes TLS handshake specifics. A complexity is that the large 1946 message sizes necessary for bootstrapping will require support for 1947 [draft-ietf-core-block].]] 1949 8. Reduced security operational modes 1951 A common requirement of bootstrapping is to support less secure 1952 operational modes for support specific use cases. The following 1953 sections detail specific ways that the Pledge, Registrar and MASA can 1954 be configured to run in a less secure mode for the indicated reasons. 1956 8.1. Trust Model 1958 +--------+ +---------+ +------------+ +------------+ 1959 | New | | Circuit | | Domain | | Vendor | 1960 | Entity | | Proxy | | Registrar | | Service | 1961 | | | | | | | (Internet | 1962 +--------+ +---------+ +------------+ +------------+ 1964 Figure 10 1965 Pledge: The Pledge could be compromised and providing an attack 1966 vector for malware. The entity is trusted to only imprint using 1967 secure methods described in this document. Additional endpoint 1968 assessment techniques are RECOMMENDED but are out-of-scope of this 1969 document. 1971 Proxy: Provides proxy functionalities but is not involved in 1972 security considerations. 1974 Registrar: When interacting with a MASA server a Registrar makes all 1975 decisions. When Ownership Vouchers are involved a Registrar is 1976 only a conduit and all security decisions are made on the vendor 1977 service. 1979 Vendor Service, MASA: This form of vendor service is trusted to 1980 accurately log all claim attempts and to provide authoritative log 1981 information to Registrars. The MASA does not know which devices 1982 are associated with which domains. These claims could be 1983 strengthened by using cryptographic log techniques to provide 1984 append only, cryptographic assured, publicly auditable logs. 1985 Current text provides only for a trusted vendor. 1987 Vendor Service, Ownership Validation: This form of vendor service is 1988 trusted to accurately know which device is owned by which domain. 1990 8.2. New Entity security reductions 1992 The Pledge MAY support "trust on first use" on physical interfaces 1993 but MUST NOT support "trust on first use" on network interfaces. 1994 This is because "trust on first use" permanently degrades the 1995 security for all other use cases. 1997 The Pledge MAY have an operational mode where it skips Voucher 1998 validation one time. For example if a physical button is depressed 1999 during the bootstrapping operation. This can be useful if the vendor 2000 service is unavailable. This behavior SHOULD be available via local 2001 configuration or physical presence methods to ensure new entities can 2002 always be deployed even when autonomic methods fail. This allows for 2003 unsecured imprint. 2005 It is RECOMMENDED that this only be available if hardware assisted 2006 NEA [RFC5209] is supported. 2008 8.3. Registrar security reductions 2010 A Registrar can choose to accept devices using less secure methods. 2011 These methods are acceptable when low security models are needed, as 2012 the security decisions are being made by the local administrator, but 2013 they MUST NOT be the default behavior: 2015 1. A registrar MAY choose to accept all devices, or all devices of a 2016 particular type, at the administrator's discretion. This could 2017 occur when informing all Registrars of unique identifiers of new 2018 entities might be operationally difficult. 2020 2. A registrar MAY choose to accept devices that claim a unique 2021 identity without the benefit of authenticating that claimed 2022 identity. This could occur when the Pledge does not include an 2023 X.509 IDevID factory installed credential. New Entities without 2024 an X.509 IDevID credential MAY form the Section 7.1 request using 2025 the Section 7.2 format to ensure the Pledge's serial number 2026 information is provided to the Registar (this includes the 2027 IDevIDAuthorityKeyIdentifier value which would be statically 2028 configured on the Pledge). The Pledge MAY refused to provide a 2029 TLS client certificate (as one is not available). The Pledge 2030 SHOULD support HTTP-based or certificate-less TLS authentication 2031 as described in EST RFC7030 section 3.3.2. A Registrar MUST NOT 2032 accept unauthenticated New Entities unless it has been configured 2033 to do so by an administrator that has verified that only expected 2034 new entities can communicate with a Registrar (presumably via a 2035 physically secured perimeter). 2037 3. A Registrar MAY request nonce-less Vouchers from the MASA service 2038 (by not including a nonce in the request). These Vouchers can 2039 then be transmitted to the Registrar and stored until they are 2040 needed during bootstrapping operations. This is for use cases 2041 where target network is protected by an air gap and therefore can 2042 not contact the MASA service during Pledge deployment. 2044 4. A registrar MAY ignore unrecognized nonce-less log entries. This 2045 could occur when used equipment is purchased with a valid history 2046 being deployed in air gap networks that required permanent 2047 Vouchers. 2049 8.4. MASA security reductions 2051 Lower security modes chosen by the MASA service effect all device 2052 deployments unless bound to the specific device identities. In which 2053 case these modes can be provided as additional features for specific 2054 customers. The MASA service can choose to run in less secure modes 2055 by: 2057 1. Not enforcing that a nonce is in the Voucher. This results in 2058 distribution of Voucher that never expires and in effect makes 2059 the Domain an always trusted entity to the Pledge during any 2060 subsequent bootstrapping attempts. That this occurred is 2061 captured in the log information so that the Domain registrar can 2062 make appropriate security decisions when a Pledge joins the 2063 Domain. This is useful to support use cases where Registrars 2064 might not be online during actual device deployment. Because 2065 this results in long lived Voucher and does not require the proof 2066 that the device is online this is only accepted when the 2067 Registrar is authenticated by the MASA server and authorized to 2068 provide this functionality. The MASA server is RECOMMENDED to 2069 use this functionality only in concert with an enhanced level of 2070 ownership tracking (out-of-scope). If the Pledge device is known 2071 to have a real-time-clock that is set from the factory use of a 2072 voucher validity period is RECOMMENDED. 2074 2. Not verifying ownership before responding with an Voucher. This 2075 is expected to be a common operational model because doing so 2076 relieves the vendor providing MASA services from having to 2077 tracking ownership during shipping and supply chain and allows 2078 for a very low overhead MASA service. A Registrar uses the audit 2079 log information as a defense in depth strategy to ensure that 2080 this does not occur unexpectedly (for example when purchasing new 2081 equipment the Registrar would throw an error if any audit log 2082 information is reported). 2084 9. Security Considerations 2086 There are uses cases where the MASA could be unavailable or 2087 uncooperative to the Registrar. They include planned and unplanned 2088 network partitions, changes to MASA policy, or other instances where 2089 MASA policy rejects a claim. These introduce an operational risk to 2090 the Registrar owner that MASA/vendor behavior might limit the ability 2091 to re-boostrap a Pledge device. For example this might be an issue 2092 during disaster recovery. This risk can be mitigated by Registrars 2093 that request and maintain long term copies of "nonceless" Vouchers. 2094 In that way they are guaranteed to be able to repeat bootstrapping 2095 for their devices. 2097 The issuance of nonceless vouchers themselves create a security 2098 concern. If the Registrar of a previous domain can intercept 2099 protocol communications then it can use a previously issued nonceless 2100 voucher to establish management control of a pledge device even after 2101 having sold it. This risk is mitigated by recording the issuance of 2102 such vouchers in the MASA audit log that is verified by the 2103 subsequent Registrar. This reduces the resale value of the equipment 2104 because future owners will detect the lowered security inherent in 2105 the existence of a nonceless voucher that would be trusted by their 2106 Pledge. This accurately reflects a balance between partition 2107 resistant recovery and security of future bootstrapping. Registrars 2108 take the Pledge's audit history into account when applying policy to 2109 new devices. 2111 The MASA server is exposed to DoS attacks wherein attackers claim an 2112 unbounded number of devices. Ensuring a Registrar is representative 2113 of a valid vendor customer, even without validating ownership of 2114 specific Pledge devices, helps to mitigate this. Inserting a 2115 cryptographic proof-of-possession step to the protocol operations is 2116 a possible area of future work. One method that would not introduce 2117 additional round-trips would be for the Registrar to share the Plege- 2118 Registrar TLS handshake with the MASA service when requesting a 2119 voucher. Doing so would allow the MASA service to verify that the 2120 Registrar's Server Certificate was signed by the Pledge's Certificate 2121 Verify message (which covers the entire handshake). 2123 It is possible for an attacker to request a voucher from the MASA 2124 service directly after the real Registrar obtains an audit log. If 2125 the attacker could also force the bootstrapping protocol to reset 2126 there is a theoretical opportunity for the attacker to use their 2127 voucher to take control of the Pledge but then proceed to enroll with 2128 the target domain. Possible prevention mechanisms include: 2130 o Per device rate limits on the MASA service ensure such timing 2131 attacks are difficult. 2133 o The Registrar can repeat the request for audit log information at 2134 some time after bootstrapping is complete. 2136 To facilitate logging and administrative oversight the Pledge reports 2137 on Voucher parsing status to the Registrar. In the case of a failure 2138 this information is informative to a potentially malicious Registar 2139 but this is RECOMMENDED anyway because of the operational benefits of 2140 an informed administrator in cases where the failure is indicative of 2141 a problem. 2143 To facilitate truely limited clients EST RFC7030 section 3.3.2 2144 requirements that the client MUST support a client authentication 2145 model have been reduced in Section 8 to a statement that clients only 2146 "SHOULD" support such a model. This reflects current (poor) 2147 practices that are NOT RECOMMENDED. 2149 During the provisional period of the connection all HTTP header and 2150 content data MUST treated as untrusted data. HTTP libraries are 2151 regularly exposed to non-secured HTTP traffic. 2153 10. Acknowledgements 2155 We would like to thank the various reviewers for their input, in 2156 particular Brian Carpenter, Toerless Eckert, Fuyu Eleven, Eliot Lear, 2157 Sergey Kasatkin, Markus Stenberg, and Peter van der Stok 2159 11. References 2161 11.1. Normative References 2163 [I-D.ietf-anima-autonomic-control-plane] 2164 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 2165 Control Plane", draft-ietf-anima-autonomic-control- 2166 plane-05 (work in progress), January 2017. 2168 [I-D.ietf-anima-voucher] 2169 Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 2170 "Voucher and Voucher Revocation Profiles for Bootstrapping 2171 Protocols", draft-ietf-anima-voucher-00 (work in 2172 progress), January 2017. 2174 [IDevID] IEEE Standard, , "IEEE 802.1AR Secure Device Identifier", 2175 December 2009, . 2178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2179 Requirement Levels", BCP 14, RFC 2119, 2180 DOI 10.17487/RFC2119, March 1997, 2181 . 2183 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 2184 "Advanced Sockets Application Program Interface (API) for 2185 IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003, 2186 . 2188 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 2189 Configuration of IPv4 Link-Local Addresses", RFC 3927, 2190 DOI 10.17487/RFC3927, May 2005, 2191 . 2193 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2194 Address Autoconfiguration", RFC 4862, 2195 DOI 10.17487/RFC4862, September 2007, 2196 . 2198 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2199 Housley, R., and W. Polk, "Internet X.509 Public Key 2200 Infrastructure Certificate and Certificate Revocation List 2201 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2202 . 2204 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 2205 Security: An Unauthenticated Mode of IPsec", RFC 5386, 2206 DOI 10.17487/RFC5386, November 2008, 2207 . 2209 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2210 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2211 . 2213 [RFC5660] Williams, N., "IPsec Channels: Connection Latching", 2214 RFC 5660, DOI 10.17487/RFC5660, October 2009, 2215 . 2217 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2218 DOI 10.17487/RFC6762, February 2013, 2219 . 2221 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2222 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2223 . 2225 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 2226 "Enrollment over Secure Transport", RFC 7030, 2227 DOI 10.17487/RFC7030, October 2013, 2228 . 2230 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2231 Constrained-Node Networks", RFC 7228, 2232 DOI 10.17487/RFC7228, May 2014, 2233 . 2235 11.2. Informative References 2237 [I-D.behringer-homenet-trust-bootstrap] 2238 Behringer, M., Pritikin, M., and S. Bjarnason, 2239 "Bootstrapping Trust on a Homenet", draft-behringer- 2240 homenet-trust-bootstrap-02 (work in progress), February 2241 2014. 2243 [I-D.ietf-anima-grasp] 2244 Bormann, C., Carpenter, B., and B. Liu, "A Generic 2245 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 2246 grasp-09 (work in progress), December 2016. 2248 [I-D.ietf-netconf-zerotouch] 2249 Watsen, K. and M. Abrahamsson, "Zero Touch Provisioning 2250 for NETCONF or RESTCONF based Management", draft-ietf- 2251 netconf-zerotouch-12 (work in progress), January 2017. 2253 [I-D.lear-mud-framework] 2254 Lear, E., "Manufacturer Usage Description Framework", 2255 draft-lear-mud-framework-00 (work in progress), January 2256 2016. 2258 [I-D.richardson-anima-state-for-joinrouter] 2259 Richardson, M., "Considerations for stateful vs stateless 2260 join router in ANIMA bootstrap", draft-richardson-anima- 2261 state-for-joinrouter-01 (work in progress), July 2016. 2263 [imprinting] 2264 Wikipedia, , "Wikipedia article: Imprinting", July 2015, 2265 . 2267 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2268 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2269 December 1998, . 2271 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2272 Interface Identifiers with IPv6 Stateless Address 2273 Autoconfiguration (SLAAC)", RFC 7217, 2274 DOI 10.17487/RFC7217, April 2014, 2275 . 2277 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 2278 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 2279 December 2014, . 2281 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 2282 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 2283 Networking: Definitions and Design Goals", RFC 7575, 2284 DOI 10.17487/RFC7575, June 2015, 2285 . 2287 [Stajano99theresurrecting] 2288 Stajano, F. and R. Anderson, "The resurrecting duckling: 2289 security issues for ad-hoc wireless networks", 1999, 2290 . 2293 Appendix A. IPv4 operations 2295 A.1. IPv4 Link Local addresses 2297 Instead of an IPv6 link-local address, an IPv4 address may be 2298 generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local 2299 Addresses. 2301 In the case that an IPv4 Local-Local address is formed, then the 2302 bootstrap process would continue as in the IPv6 case by looking for a 2303 (circuit) proxy. 2305 A.2. Use of DHCPv4 2307 The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP 2308 provided parameters for the Domain Name System can be used to perform 2309 DNS operations if all local discovery attempts fail. 2311 Appendix B. mDNS / DNSSD proxy discovery options 2313 The Pledge MAY perform DNS-based Service Discovery [RFC6763] over 2314 Multicast DNS [RFC6762] searching for the service 2315 "_bootstrapks._tcp.local.". 2317 To prevent unaccceptable levels of network traffic the congestion 2318 avoidance mechanisms specified in [RFC6762] section 7 MUST be 2319 followed. The Pledge SHOULD listen for an unsolicited broadcast 2320 response as described in [RFC6762]. This allows devices to avoid 2321 announcing their presence via mDNS broadcasts and instead silently 2322 join a network by watching for periodic unsolicited broadcast 2323 responses. 2325 Performs DNS-based Service Discovery [RFC6763] over normal DNS 2326 operations. The service searched for is 2327 "_bootstrapks._tcp.example.com". In this case the domain 2328 "example.com" is discovered as described in [RFC6763] section 11. 2329 This method is only available if the host has received a useable IPv4 2330 address via DHCPv4 as suggested in Appendix A. 2332 If no local bootstrapks service is located using the GRASP 2333 mechanisms, or the above mentioned DNS-based Service Discovery 2334 methods the Pledge MAY contact a well known vendor provided 2335 bootstrapping server by performing a DNS lookup using a well known 2336 URI such as "bootstrapks.vendor-example.com". The details of the URI 2337 are vendor specific. Vendors that leverage this method on the Pledge 2338 are responsible for providing the bootstrapks service. 2340 The current DNS services returned during each query is maintained 2341 until bootstrapping is completed. If bootstrapping fails and the 2342 Pledge returns to the Discovery state it picks up where it left off 2343 and continues attempting bootstrapping. For example if the first 2344 Multicast DNS _bootstrapks._tcp.local response doesn't work then the 2345 second and third responses are tried. If these fail the Pledge moves 2346 on to normal DNS-based Service Discovery. 2348 Appendix C. IPIP Join Proxy mechanism 2350 The Circuit Proxy mechanism suffers from requiring a state on the 2351 Join Proxy for each connection that is relayed. The Circuit Proxy 2352 can be considered a kind of Algorithm Gateway [FIND-good-REF]. 2354 An alternative to proxying at the TCP layer is to selectively forward 2355 at the IP layer. This moves all per-connection to the Join 2356 Registrar. The IPIP tunnel statelessly forwards packets. This 2357 section provides some explanation of some of the details of the 2358 Registrar discovery procotol which are not important to Circuit 2359 Proxy, and some implementation advice. 2361 The IPIP tunnel is described in [RFC2473]. Each such tunnel is 2362 considered a unidirectional construct, but two tunnels may be 2363 associated to form a bidirectional mechanism. An IPIP tunnel is 2364 setup as follows. The outer addresses are an ACP address of the Join 2365 Proxy, and the ACP address of the Join Registrar. The inner 2366 addresses seen in the tunnel are the link-local addresses of the 2367 network on which the join activity is occuring. 2369 One way to look at this construct is to consider that the Registrar 2370 is extending attaching an interface to the network on which the Join 2371 Proxy is physically present. The Registrar then interacts as if it 2372 were present on that network using link-local (fe80::) addresses. 2373 The Join node is unaware that the traffic is being proxied through a 2374 tunnel, and does not need any special routing. 2376 There are a number of considerations with this mechanism which 2377 require cause some minor amounts of complexity. Note that due to the 2378 tunnels, the Registrar sees multiple connections to a fe80::/10 2379 network on not just physical interfaces, but on each of the virtual 2380 interfaces represending the tunnels. 2382 C.1. Multiple Join networks on the Join Proxy side 2384 The Join Proxy will in the general case be a routing device with 2385 multiple interfaces. Even a device as simple as a wifi access point 2386 may have wired, and multiple frequencies of wireless interfaces, 2387 potentially with multiple ESSIDs. 2389 Each of these interfaces on the Join Proxy may be seperate L3 routing 2390 domains, and therefore will have a unique set of link-local 2391 addresses. An IPIP packet being returned by the Registrar needs to 2392 be forwarded to the correct interface, so the Join Proxy needs an 2393 additional key to distinguish which network the packet should be 2394 returned to. 2396 The simplest way to get this additional key is to allocate an 2397 additional ACP address; one address for each network on which join 2398 traffic is occuring. The Join Proxy SHOULD do a GRASP M_NEG_SYN for 2399 each interface which they wish to relay traffic, as this allows the 2400 Registrar to do any static tunnel configuration that may be required. 2402 C.2. Automatic configuration of tunnels on Registrar 2404 The Join Proxy is expected to do a GRASP negotiation with the proxy 2405 for each Join Interface that it needs to relay traffic from. This is 2406 to permit Registrars to configure the appropriate virtual interfaces 2407 before join traffic arrives. 2409 A Registrar serving a large number of interfaces may not wish to 2410 allocate resources to every interface at all times, but can instead 2411 dynamically allocate interfaces. It can do this by monitoring IPIP 2412 traffic that arrives on it's ACP interface, and when packets arrive 2413 from new Join Proxys, it can dynamically configure virtual 2414 interfaces. 2416 A more sophisticated Registrar willing to modify the behaviour of 2417 it's TCP and UDP stack could note the IPIP traffic origination in the 2418 socket control block and make information available to the TCP layer 2419 (for HTTPS connections), or to the the application (for CoAP 2420 connections) via a proprietary extension to the socket API. 2422 C.3. Proxy Neighbor Discovery by Join Proxy 2424 The Join Proxy MUST answer neighbor discovery messages for the 2425 address given by the Registrar as being it's link-local address. The 2426 Join Proxy must also advertise this address as the address to which 2427 to connect to when advertising it's existence. 2429 This proxy neighbor discovery means that the pledge will create TCP 2430 and UDP connections to the correct Registrar address. This matters 2431 as the TCP and UDP pseudo-header checksum includes the destination 2432 address, and for the proxy to remain completely stateless, it must 2433 not be necessary for the checksum to be updated. 2435 C.4. Use of connected sockets; or IP_PKTINFO for CoAP on Registrar 2437 TCP connections on the registrar SHOULD properly capture the ifindex 2438 of the incoming connection into the socket structure. This is normal 2439 IPv6 socket API processing. The outgoing responses will go out on 2440 the same (virtual) interface by ifindex. 2442 When using UDP sockets with CoAP, the application will have to pay 2443 attention to the incoming ifindex on the socket. Access to this 2444 information is available using the IP_PKTINFO auxiliary extension 2445 which is a standard part of the IPv6 sockets API. 2447 A registrar application could, after receipt of an initial CoAP 2448 message from the Pledge, create a connected UDP socket (including the 2449 ifindex information). The kernel would then take care of accurate 2450 demultiplexing upon receive, and subsequent transmission to the 2451 correct interface. 2453 C.5. Use of socket extension rather than virtual interface 2455 Some operating systems on which a Registrar need be implemented may 2456 find need for a virtual interface per Join Proxy to be problematic. 2457 There are other mechanism which can make be done. 2459 If the IPIP decapsulator can mark the (SYN) packet inside the kernel 2460 with the address of the Join Proxy sending the traffic, then an 2461 interface per Join Proxy may not be needed. The outgoing path need 2462 just pay attention to this extra information and add an appropriate 2463 IPIP header on outgoing. A CoAP over UDP mechanism may need to 2464 expose this extra information to the application as the UDP sockets 2465 are often not connected, and the application will need to specify the 2466 outgoing path on each packet send. 2468 Such an additional socket mechanism has not been standardized. 2469 Terminating L2TP connections over IPsec transport mode suffers from 2470 the same challenges. 2472 Authors' Addresses 2473 Max Pritikin 2474 Cisco 2476 Email: pritikin@cisco.com 2478 Michael C. Richardson 2479 Sandelman Software Works 2481 Email: mcr+ietf@sandelman.ca 2482 URI: http://www.sandelman.ca/ 2484 Michael H. Behringer 2485 Cisco 2487 Email: mbehring@cisco.com 2489 Steinthor Bjarnason 2490 Cisco 2492 Email: sbjarnas@cisco.com 2494 Kent Watsen 2495 Juniper Networks 2497 Email: kwatsen@juniper.net