idnits 2.17.1 draft-ietf-anima-bootstrapping-keyinfra-08.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 12, 2017) is 2381 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3987' is mentioned on line 608, but not defined == Missing Reference: 'RFC2616' is mentioned on line 1569, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Missing Reference: 'RFC5209' is mentioned on line 2000, but not defined == Missing Reference: 'RFC2131' is mentioned on line 2482, but not defined == Missing Reference: 'FIND-good-REF' is mentioned on line 2527, but not defined == Unused Reference: 'RFC3542' is defined on line 2330, but no explicit reference was found in the text == Unused Reference: 'RFC5386' is defined on line 2366, but no explicit reference was found in the text == Unused Reference: 'RFC5652' is defined on line 2371, but no explicit reference was found in the text == Unused Reference: 'RFC5660' is defined on line 2375, but no explicit reference was found in the text == Unused Reference: 'I-D.behringer-homenet-trust-bootstrap' is defined on line 2411, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netconf-zerotouch' is defined on line 2422, but no explicit reference was found in the text == Unused Reference: 'RFC7217' is defined on line 2446, but no explicit reference was found in the text == Unused Reference: 'RFC7575' is defined on line 2456, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-10 == Outdated reference: A later version (-07) exists of draft-ietf-anima-voucher-05 == Outdated reference: A later version (-04) exists of draft-vanderstok-ace-coap-est-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'IDevID' ** Downref: Normative reference to an Informational RFC: RFC 3542 ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Downref: Normative reference to an Informational RFC: RFC 7228 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-17 == Outdated reference: A later version (-25) exists of draft-ietf-opsawg-mud-12 == Outdated reference: A later version (-03) exists of draft-richardson-anima-state-for-joinrouter-01 Summary: 6 errors (**), 0 flaws (~~), 20 warnings (==), 3 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: Standards Track M. Richardson 5 Expires: April 15, 2018 SSW 6 M. Behringer 7 Cisco 8 S. Bjarnason 9 Arbor Networks 10 K. Watsen 11 Juniper Networks 12 October 12, 2017 14 Bootstrapping Remote Secure Key Infrastructures (BRSKI) 15 draft-ietf-anima-bootstrapping-keyinfra-08 17 Abstract 19 This document specifies automated bootstrapping of a remote secure 20 key infrastructure (BRSKI) using vendor installed X.509 certificate, 21 in combination with a vendor's authorizing service, both online and 22 offline. Bootstrapping a new device can occur using a routable 23 address and a cloud service, or using only link-local connectivity, 24 or on limited/disconnected networks. Support for lower security 25 models, including devices with minimal identity, is described for 26 legacy reasons but not encouraged. Bootstrapping is complete when 27 the cryptographic identity of the new key infrastructure is 28 successfully deployed to the device but the established secure 29 connection can be used to deploy a locally issued certificate to the 30 device as well. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 15, 2018. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Other Bootstrapping Approaches . . . . . . . . . . . . . 4 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.3. Scope of solution . . . . . . . . . . . . . . . . . . . . 8 70 1.4. Leveraging the new key infrastructure / next steps . . . 9 71 2. Architectural Overview . . . . . . . . . . . . . . . . . . . 9 72 2.1. Behavior of a Pledge . . . . . . . . . . . . . . . . . . 11 73 2.2. Secure Imprinting using Vouchers . . . . . . . . . . . . 12 74 2.3. Initial Device Identifier . . . . . . . . . . . . . . . . 13 75 2.4. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 14 76 2.4.1. Architectural component: Pledge . . . . . . . . . . . 16 77 2.4.2. Architectural component: Circuit Proxy . . . . . . . 16 78 2.4.3. Architectural component: Domain Registrar . . . . . . 16 79 2.4.4. Architectural component: Vendor Service . . . . . . . 16 80 2.5. Lack of realtime clock . . . . . . . . . . . . . . . . . 16 81 2.6. Cloud Registrar . . . . . . . . . . . . . . . . . . . . . 17 82 2.7. Determining the MASA to contact . . . . . . . . . . . . . 17 83 3. Voucher Request artifact . . . . . . . . . . . . . . . . . . 18 84 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 18 85 3.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 19 86 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 21 87 4. Proxy details . . . . . . . . . . . . . . . . . . . . . . . . 23 88 4.1. Pledge discovery of Proxy . . . . . . . . . . . . . . . . 24 89 4.1.1. Proxy Grasp announcements . . . . . . . . . . . . . . 25 90 4.2. CoAP connection to Registrar . . . . . . . . . . . . . . 26 91 4.3. HTTPS proxy connection to Registrar . . . . . . . . . . . 26 92 4.4. Proxy discovery of Registrar . . . . . . . . . . . . . . 26 93 5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 27 94 5.1. BRSKI-EST TLS establishment details . . . . . . . . . . . 29 95 5.2. Pledge Requests Voucher from the Registrar . . . . . . . 30 96 5.3. BRSKI-MASA TLS establishment details . . . . . . . . . . 31 97 5.4. Registrar Requests Voucher from MASA . . . . . . . . . . 31 98 5.5. Voucher Response . . . . . . . . . . . . . . . . . . . . 34 99 5.5.1. Completing authentication of Provisional TLS 100 connection . . . . . . . . . . . . . . . . . . . . . 35 101 5.6. Voucher Status Telemetry . . . . . . . . . . . . . . . . 36 102 5.7. MASA authorization log Request . . . . . . . . . . . . . 37 103 5.7.1. MASA authorization log Response . . . . . . . . . . . 38 104 5.8. EST Integration for PKI bootstrapping . . . . . . . . . . 39 105 5.8.1. EST Distribution of CA Certificates . . . . . . . . . 39 106 5.8.2. EST CSR Attributes . . . . . . . . . . . . . . . . . 40 107 5.8.3. EST Client Certificate Request . . . . . . . . . . . 41 108 5.8.4. Enrollment Status Telemetry . . . . . . . . . . . . . 41 109 5.8.5. EST over CoAP . . . . . . . . . . . . . . . . . . . . 42 110 6. Reduced security operational modes . . . . . . . . . . . . . 42 111 6.1. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 42 112 6.2. Pledge security reductions . . . . . . . . . . . . . . . 43 113 6.3. Registrar security reductions . . . . . . . . . . . . . . 44 114 6.4. MASA security reductions . . . . . . . . . . . . . . . . 44 115 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 116 7.1. PKIX Registry . . . . . . . . . . . . . . . . . . . . . . 45 117 7.2. MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 46 118 7.3. Voucher Status Telemetry . . . . . . . . . . . . . . . . 47 119 8. Security Considerations . . . . . . . . . . . . . . . . . . . 47 120 8.1. Freshness in Voucher Requests . . . . . . . . . . . . . . 49 121 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 50 122 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 123 10.1. Normative References . . . . . . . . . . . . . . . . . . 50 124 10.2. Informative References . . . . . . . . . . . . . . . . . 52 125 Appendix A. IPv4 operations . . . . . . . . . . . . . . . . . . 53 126 A.1. IPv4 Link Local addresses . . . . . . . . . . . . . . . . 53 127 A.2. Use of DHCPv4 . . . . . . . . . . . . . . . . . . . . . . 54 128 Appendix B. mDNS / DNSSD proxy discovery options . . . . . . . . 54 129 Appendix C. IPIP Join Proxy mechanism . . . . . . . . . . . . . 55 130 C.1. Multiple Join networks on the Join Proxy side . . . . . . 55 131 C.2. Automatic configuration of tunnels on Registrar . . . . . 56 132 C.3. Proxy Neighbor Discovery by Join Proxy . . . . . . . . . 56 133 C.4. Use of connected sockets; or IP_PKTINFO for CoAP on 134 Registrar . . . . . . . . . . . . . . . . . . . . . . . . 56 135 C.5. Use of socket extension rather than virtual interface . . 57 136 Appendix D. MUD Extension . . . . . . . . . . . . . . . . . . . 57 137 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 139 1. Introduction 141 BRSKI provides a foundation to securely answer the following 142 questions between an element of the network domain called the 143 "Registrar" and an unconfigured and untouched device called a 144 "Pledge": 146 o Registrar authenticating the Pledge: "Who is this device? What is 147 its identity?" 149 o Registrar authorization the Pledge: "Is it mine? Do I want it? 150 What are the chances it has been compromised?" 152 o Pledge authenticating the Registrar/Domain: "What is this domain's 153 identity?" 155 o Pledge authorization the Registrar: "Should I join it?" 157 This document details protocols and messages to the endpoints to 158 answer the above questions. The Registrar actions derive from Pledge 159 identity, third party cloud service communications, and local access 160 control lists. The Pledge actions derive from a cryptographically 161 protected "voucher" message delivered through the Registrar but 162 originating at a Manufacturer Authorized Signing Authority. 164 The syntactic details of vouchers are described in detail in 165 [I-D.ietf-anima-voucher]. This document details automated protocol 166 mechanisms to obtain vouchers, including the definition of a 167 necessary 'voucher request' message that is a minor extension to the 168 voucher format (see Section 3). 170 BRSKI results in the Pledge storing an X.509 root certificate 171 sufficient for verifying the Registrar identity. In the process a 172 TLS connection is established which can be directly used for 173 Enrollment over Secure Transport (EST). In effect BRSKI provides an 174 automated mechanism for the "Bootstrap Distribution of CA 175 Certificates" described in [RFC7030] Section 4.1.1 wherein the Pledge 176 "MUST [...]. engage a human user to authorize the CA certificate 177 using out-of-band" information". With BRSKI the Pledge now can 178 automate this process using the voucher. Integration with a complete 179 EST enrollment is optional but trivial. 181 BRSKI is agile enough to support bootstrapping alternative key 182 infrastructures, such as a symmetric key solutions, but no such 183 system is described in this document. 185 1.1. Other Bootstrapping Approaches 187 To literally "pull yourself up by the bootstraps" is an impossible 188 action. Similarly the secure establishment of a key infrastructure 189 without external help is also an impossibility. Today it is commonly 190 accepted that the initial connections between nodes are insecure, 191 until key distribution is complete, or that domain-specific keying 192 material is pre-provisioned on each new device in a costly and non- 193 scalable manner. Existing mechanisms are known as non-secured 'Trust 194 on First Use' (TOFU) [RFC7435], 'resurrecting duckling' 195 [Stajano99theresurrecting] or 'pre-staging'. 197 Another approach is to try and minimize user actions during 198 bootstrapping. The enrollment protocol EST [RFC7030] details a set 199 of non-autonomic bootstrapping methods in this vein: 201 o using the Implicit Trust Anchor database (not an autonomic 202 solution because the URL must be securely distributed), 204 o engaging a human user to authorize the CA certificate using out- 205 of-band data (not an autonomic solution because the human user is 206 involved), 208 o using a configured Explicit TA database (not an autonomic solution 209 because the distribution of an explicit TA database is not 210 autonomic), 212 o and using a Certificate-Less TLS mutual authentication method (not 213 an autonomic solution because the distribution of symmetric key 214 material is not autonomic). 216 These "touch" methods do not meet the requirements for zero-touch. 218 There are "call home" technologies where the Pledge first establishes 219 a connection to a well known vendor service using a common client- 220 server authentication model. After mutual authentication appropriate 221 credentials to authenticate the target domain are transfered to the 222 Pledge. This creates serveral problems and limitations: 224 o the pledge requires realtime connectivity to the vendor service, 226 o the domain identity is exposed to the vendor service (this is a 227 privacy concern), 229 o the vendor is responsible for making the authorization decisions 230 (this is a liability concern), 232 BRSKI addresses these issues by defining extensions to the EST 233 protocol for the automated distribution of vouchers. 235 1.2. Terminology 237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 239 "OPTIONAL" in this document are to be interpreted as described in 240 [RFC2119]. 242 The following terms are defined for clarity: 244 DomainID: The domain identity is the 160-bit SHA-1 hash of the BIT 245 STRING of the subjectPublicKey of the domain trust anchor that is 246 stored by the Domain CA. This is consistent with the 247 Certification Authority subject key identifier (Section 4.2.1.2 248 [RFC5280]) of the Domain CA's self signed root certificate. (A 249 string value bound to the Domain CA's self signed root certificate 250 subject and issuer fields is often colloquially used as a 251 humanized identity value but during protocol discussions the more 252 exact term as defined here is used). 254 drop ship: The physical distribution of equipment containing the 255 "factory default" configuration to a final destination. In zero- 256 touch scenarios there is no staging or pre-configuration during 257 drop-ship. 259 imprint: The process where a device obtains the cryptographic key 260 material to identify and trust future interactions with a network. 261 This term is taken from Konrad Lorenz's work in biology with new 262 ducklings: during a critical period, the duckling would assume 263 that anything that looks like a mother duck is in fact their 264 mother. An equivalent for a device is to obtain the fingerprint 265 of the network's root certification authority certificate. A 266 device that imprints on an attacker suffers a similar fate to a 267 duckling that imprints on a hungry wolf. Securely imprinting is a 268 primary focus of this document.[imprinting]. The analogy to 269 Lorenz's work was first noted in [Stajano99theresurrecting]. 271 enrollment: The process where a device presents key material to a 272 network and acquires a network specific identity. For example 273 when a certificate signing request is presented to a certification 274 authority and a certificate is obtained in response. 276 Pledge: The prospective device, which has an identity installed by a 277 third-party (e.g., vendor, manufacturer or integrator). 279 Voucher A signed statement from the MASA service that indicates to a 280 Pledge the cryptographic identity of the Registrar it should 281 trust. There are different types of vouchers depending on how 282 that trust asserted. Multiple voucher types are defined in 283 [I-D.ietf-anima-voucher] 285 Domain: The set of entities that trust a common key infrastructure 286 trust anchor. This includes the Proxy, Registrar, Domain 287 Certificate Authority, Management components and any existing 288 entity that is already a member of the domain. 290 Domain CA: The domain Certification Authority (CA) provides 291 certification functionalities to the domain. At a minimum it 292 provides certification functionalities to a Registrar and stores 293 the trust anchor that defines the domain. Optionally, it 294 certifies all elements. 296 Join Registrar (and Coordinator): A representative of the domain 297 that is configured, perhaps autonomically, to decide whether a new 298 device is allowed to join the domain. The administrator of the 299 domain interfaces with a Join Registrar (and Coordinator) to 300 control this process. Typically a Join Registrar is "inside" its 301 domain. For simplicity this document often refers to this as just 302 "Registrar". The term JRC is used in common with other bootstrap 303 mechanisms. 305 Join Proxy: A domain entity that helps the pledge join the domain. 306 A Proxy facilitates communication for devices that find themselves 307 in an environment where they are not provided connectivity until 308 after they are validated as members of the domain. The pledge is 309 unaware that they are communicating with a proxy rather than 310 directly with a Registrar. 312 MASA Service: A third-party Manufacturer Authorized Signing 313 Authority (MASA) service on the global Internet. The MASA signs 314 vouchers. It also provides a repository for audit log information 315 of privacy protected bootstrapping events. It does not track 316 ownership. 318 Ownership Tracker: An Ownership Tracker service on the global 319 internet. The Ownership Tracker uses business processes to 320 accurately track ownership of all devices shipped against domains 321 that have purchased them. Although optional this component allows 322 vendors to provide additional value in cases where their sales and 323 distribution channels allow for accurately tracking of such 324 ownership. Ownership tracking information is indicated in 325 vouchers as described in [I-D.ietf-anima-voucher] 327 IDevID: An Initial Device Identity X.509 certificate installed by 328 the vendor on new equipment. 330 TOFU: Trust on First Use. Used similarly to [RFC7435]. This is 331 where a Pledge device makes no security decisions but rather 332 simply trusts the first Registrar it is contacted by. This is 333 also known as the "resurrecting duckling" model. 335 1.3. Scope of solution 337 Questions have been posed as to whether this solution is suitable in 338 general for Internet of Things (IoT) networks. This depends on the 339 capabilities of the devices in question. The terminology of 340 [RFC7228] is best used to describe the boundaries. 342 The solution described in this document is aimed in general at non- 343 constrained (i.e. class 2+) devices operating on a non-Challenged 344 network. The entire solution as described here is not intended to be 345 useable as-is by constrained devices operating on challenged networks 346 (such as 802.15.4 LLNs). 348 In many target applications, the systems involved are large router 349 platforms with multi-gigabit inter-connections, mounted in controlled 350 access data centers. But this solution is not exclusive to the 351 large, it is intended to scale to thousands of devices located in 352 hostile environments, such as ISP provided CPE devices which are 353 drop-shipped to the end user. The situation where an order is 354 fulfilled from distributed warehouse from a common stock and shipped 355 directly to the target location at the request of the domain owner is 356 explicitly supported. That stock ("SKU") could be provided to a 357 number of potential domain owners, and the eventual domain owner will 358 not know a-priori which device will go to which location. 360 The bootstrapping process can take minutes to complete depending on 361 the network infrastructure and device processing speed. The network 362 communication itself is not optimized for speed; for privacy reasons, 363 the discovery process allows for the Pledge to avoid announcing it's 364 presence through broadcasting. 366 This protocol is not intended for low latency handoffs. In networks 367 requiring such things, the pledge SHOULD already have been enrolled. 369 Specifically, there are protocol aspects described here which might 370 result in congestion collapse or energy-exhaustion of intermediate 371 battery powered routers in an LLN. Those types of networks SHOULD 372 NOT use this solution. These limitations are predominately related 373 to the large credential and key sizes required for device 374 authentication. Defining symmetric key techniques that meet the 375 operational requirements is out-of-scope but the underlying protocol 376 operations (TLS handshake and signing structures) have sufficient 377 algorithm agility to support such techniques when defined. 379 The imprint protocol described here could, however, be used by non- 380 energy constrained devices joining a non-constrained network (for 381 instance, smart light bulbs are usually mains powered, and speak 382 802.11). It could also be used by non-constrained devices across a 383 non-energy constrained, but challenged network (such as 802.15.4). 384 The certificate contents, and the process by which the four questions 385 above are resolved do apply to constrained devices. It is simply the 386 actual on-the-wire imprint protocol which could be inappropriate. 388 This document presumes that network access control has either already 389 occurred, is not required, or is integrated by the proxy and 390 registrar in such a way that the device itself does not need to be 391 aware of the details. Although the use of an X.509 Initial Device 392 Identity is consistant with IEEE 802.1AR [IDevID], and allows for 393 alignment with 802.1X network access control methods, its use here is 394 for Pledge authentication rather than network access control. 395 Integrating this protocol with network access control, perhaps as an 396 Extensible Authentication Protocol (EAP) method (see [RFC3748]), is 397 out-of-scope. 399 1.4. Leveraging the new key infrastructure / next steps 401 As a result of the protocol described herein the bootstrapped devices 402 have a common trust anchor and a certificate has optionally been 403 issued from a local PKI. This makes it possible to automatically 404 deploy services across the domain in a secure manner. 406 Services which benefit from this: 408 o Device management. 410 o Routing authentication. 412 o Service discovery. 414 The major beneficiary is that it possible to use the credentials 415 deployed by this protocol to secure the Autonomic Control Plane (ACP) 416 ([I-D.ietf-anima-autonomic-control-plane]). 418 2. Architectural Overview 420 The logical elements of the bootstrapping framework are described in 421 this section. Figure 1 provides a simplified overview of the 422 components. Each component is logical and may be combined with other 423 components as necessary. 425 +------------------------+ 426 +--------------Drop Ship--------------->| Vendor Service | 427 | +------------------------+ 428 | | M anufacturer| | 429 | | A uthorized |Ownership| 430 | | S igning |Tracker | 431 | | A uthority | | 432 | +--------------+---------+ 433 | ^ 434 | | BRSKI- 435 V | MASA 436 +-------+ ............................................|... 437 | | . | . 438 | | . +------------+ +-----------+ | . 439 | | . | | | | | . 440 |Pledge | . | Circuit | | Domain <-------+ . 441 | | . | Proxy | | Registrar | . 442 | <-------->............<-------> (PKI RA) | . 443 | | | BRSKI-EST | | . 444 | | . | | +-----+-----+ . 445 |IDevID | . +------------+ | EST RFC7030 . 446 | | . +-----------------+----------+ . 447 | | . | Key Infrastructure | . 448 | | . | (e.g. PKI Certificate | . 449 +-------+ . | Authority) | . 450 . +----------------------------+ . 451 . . 452 ................................................ 453 "Domain" components 455 Figure 1 457 We assume a multi-vendor network. In such an environment there could 458 be a Vendor Service for each vendor that supports devices following 459 this document's specification, or an integrator could provide a 460 generic service authorized by multiple vendors. It is unlikely that 461 an integrator could provide Ownership Tracking services for multiple 462 vendors due to the required sales channel integrations necessary to 463 track ownership. 465 The domain is the managed network infrastructure with a Key 466 Infrastructure the Pledge is joining. The a domain provides initial 467 device connectivity sufficient for bootstrapping with a Circuit 468 Proxy. The Domain Registrar authenticates the Pledge, makes 469 authorization decisions, and distributes vouchers obtained from the 470 Vendor Service. Optionally the Registrar also acts as a PKI 471 Registration Authority. 473 2.1. Behavior of a Pledge 475 The pledge goes through a series of steps which are outlined here at 476 a high level. 478 +--------------+ 479 | Factory | 480 | default | 481 +------+-------+ 482 | 483 +------v-------+ 484 | Discover | 485 +------------> | 486 | +------+-------+ 487 | | 488 | +------v-------+ 489 | | Identity | 490 ^------------+ | 491 | rejected +------+-------+ 492 | | 493 | +------v-------+ 494 | | Request | 495 | | Join | 496 | +------+-------+ 497 | | 498 | +------v-------+ 499 | | Imprint | Optional 500 ^------------+ <--+Manual input (Appendix C) 501 | Bad Vendor +------+-------+ 502 | response | send Voucher Status Telemetry 503 | +------v-------+ 504 | | Enroll | 505 ^------------+ | 506 | Enroll +------+-------+ 507 | Failure | 508 | +------v-------+ 509 | | Enrolled | 510 ^------------+ | 511 Factory +--------------+ 512 reset 514 Figure 2 516 State descriptions for the pledge are as follows: 518 1. Discover a communication channel to a Registrar. 520 2. Identify itself. This is done by presenting an X.509 IDevID 521 credential to the discovered Registrar (via the Proxy) in a TLS 522 handshake. (The Registrar credentials are only provisionally 523 accepted at this time). 525 3. Requests to Join the discovered Registrar. A unique nonce can be 526 included ensuring that any responses can be associated with this 527 particular bootstrapping attempt. 529 4. Imprint on the Registrar. This requires verification of the 530 vendor service provided voucher. A voucher contains sufficient 531 information for the Pledge to complete authentication of a 532 Registrar. (It enables the Pledge to finish authentication of 533 the Registrar TLS server certificate). 535 5. Enroll. By accepting the domain specific information from a 536 Registrar, and by obtaining a domain certificate from a Registrar 537 using a standard enrollment protocol, e.g. Enrollment over 538 Secure Transport (EST) [RFC7030]. 540 6. The Pledge is now a member of, and can be managed by, the domain 541 and will only repeat the discovery aspects of bootstrapping if it 542 is returned to factory default settings. 544 2.2. Secure Imprinting using Vouchers 546 A voucher is a cryptographically protected statement to the Pledge 547 device authorizing a zero-touch imprint on the Registrar domain. 549 The format and cryptographic mechanism of vouchers is described in 550 detail in [I-D.ietf-anima-voucher]. 552 Vouchers provide a flexible mechanism to secure imprinting: the 553 Pledge device only imprints when a voucher can be validated. At the 554 lowest security levels the MASA server can indiscriminately issue 555 vouchers. At the highest security levels issuance of vouchers can be 556 integrated with complex sales channel integrations that are beyond 557 the scope of this document. This provides the flexibility for a 558 number of use cases via a single common protocol mechanism on the 559 Pledge and Registrar devices that are to be widely deployed in the 560 field. The MASA vendor services have the flexibility to leverage 561 either the currently defined claim mechanisms or to experiment with 562 higher or lower security levels. 564 Vouchers provide a signed but non-encrypted communication channel 565 between the Pledge, the MASA, and the Registrar. The Registrar 566 maintains control over the transport and policy decisions allowing 567 the local security policy of the domain network to be enforced. 569 2.3. Initial Device Identifier 571 Pledge authentication and voucher request signing is via an X.509 572 certificate installed during the manufacturing process. This Initial 573 Device Identifier provides a basis for authenticating the Pledge 574 during subsequent protocol exchanges and informing the Registrar of 575 the MASA URI. There is no requirement for a common root PKI 576 hierarchy. Each device vendor can generate their own root 577 certificate. 579 The following previously defined fields are in the X.509 IDevID 580 certificate: 582 o The subject field's DN encoding MUST include the "serialNumber" 583 attribute with the device's unique serial number. 585 o The subject-alt field's encoding SHOULD include a non-critical 586 version of the RFC4108 defined HardwareModuleName. 588 In order to build the voucher "serial-number" field these IDevID 589 fields need to be converted into a serial-number of "type string". 590 The following methods is used depending on the first available IDevID 591 certificate field (attempted in this order): 593 o An RFC4514 String Representation of the Distinguished Name 594 "serialNumber" attribute. 596 o The HardwareModuleName hwSerialNum OCTET STRING base64 encoded. 598 o The RFC4514 String Representation of the Distinguished Name 599 "common name" attribute. 601 The following newly defined field SHOULD be in the X.509 IDevID 602 certificate: An X.509 non-critical certificate extension that 603 contains a single Uniform Resource Identifier (URI) that points to an 604 on-line Manufacturer Authorized Signing Authority. The URI is 605 represented as described in Section 7.4 of [RFC5280]. 607 Any Internationalized Resource Identifiers (IRIs) MUST be mapped to 608 URIs as specified in Section 3.1 of [RFC3987] before they are placed 609 in the certificate extension. The URI provides the authority 610 information. The BRSKI .well-known tree is described in Section 5 612 The new extension is identified as follows: 614 616 MASAURLExtnModule-2016 { iso(1) identified-organization(3) dod(6) 617 internet(1) security(5) mechanisms(5) pkix(7) 618 id-mod(0) id-mod-MASAURLExtn2016(TBD) } 620 DEFINITIONS IMPLICIT TAGS ::= BEGIN 622 -- EXPORTS ALL -- 624 IMPORTS 625 EXTENSION 626 FROM PKIX-CommonTypes-2009 627 { iso(1) identified-organization(3) dod(6) internet(1) 628 security(5) mechanisms(5) pkix(7) id-mod(0) 629 id-mod-pkixCommon-02(57) } 631 id-pe 632 FROM PKIX1Explicit-2009 633 { iso(1) identified-organization(3) dod(6) internet(1) 634 security(5) mechanisms(5) pkix(7) id-mod(0) 635 id-mod-pkix1-explicit-02(51) } ; 636 MASACertExtensions EXTENSION ::= { ext-MASAURL, ... } 637 ext-MASAURL EXTENSION ::= { SYNTAX MASAURLSyntax 638 IDENTIFIED BY id-pe-masa-url } 640 id-pe-masa-url OBJECT IDENTIFIER ::= { id-pe TBD } 642 MASAURLSyntax ::= IA5String 644 END 646 648 The choice of id-pe is based on guidance found in Section 4.2.2 of 649 [RFC5280], "These extensions may be used to direct applications to 650 on-line information about the issuer or the subject". The MASA URL 651 is precisely that: online information about the particular subject. 653 2.4. Protocol Flow 655 A representative flow is shown in Figure 3: 657 +--------+ +---------+ +------------+ +------------+ 658 | Pledge | | Circuit | | Domain | | Vendor | 659 | | | Proxy | | Registrar | | Service | 660 | | | | | (JRC) | | (MASA) | 661 +--------+ +---------+ +------------+ +------------+ 662 | | | Internet | 663 |<-RFC4862 IPv6 addr | | | 664 |<-RFC3927 IPv4 addr | Appendix A | | 665 | | | | 666 |-------------------->| | | 667 | optional: mDNS query| Appendix B | | 668 | RFC6763/RFC6762 | | | 669 | | | | 670 |<--------------------| | | 671 | GRASP M_FLOOD | | | 672 | periodic broadcast| | | 673 | | | | 674 |<------------------->C<----------------->| | 675 | TLS via the Circuit Proxy | | 676 |<--Registrar TLS server authentication---| | 677 [PROVISIONAL accept of server cert] | | 678 P---X.509 client authentication---------->| | 679 P | | | 680 P---Voucher Request (include nonce)------>| | 681 P | | | 682 P | /---> | | 683 P | | [accept device?] | 684 P | | [contact Vendor] | 685 P | | |--Pledge ID-------->| 686 P | | |--Domain ID-------->| 687 P | | |--optional:nonce--->| 688 P | | | [extract DomainID] 689 P | | | | 690 P | optional: | [update audit log] 691 P | |can | | 692 P | |occur | | 693 P | |in | | 694 P | |advance | | 695 P | |if | | 696 P | |nonceless | | 697 P | | |<- voucher ---------| 698 P | \----> | | 699 P | | | 700 P<------voucher---------------------------| | 701 [verify voucher ] | | | 702 [verify provisional cert| | | 703 | | | | 704 |---------------------------------------->| | 705 | [voucher status telemetry] |<-device audit log--| 706 | | [verify audit log and voucher] | 707 | | | | 708 |<--------------------------------------->| | 709 | Continue with RFC7030 enrollment | | 710 | using now bidirectionally authenticated | | 711 | TLS session. | | | 712 | | | | 714 Figure 3 716 2.4.1. Architectural component: Pledge 718 The Pledge is the device which is attempting to join. Until the 719 pledge completes the enrollment process, it does has network 720 connectivity only to the Proxy. 722 2.4.2. Architectural component: Circuit Proxy 724 The (Circuit) Proxy provides HTTPS connectivity between the pledge 725 and the registrar. The proxy mechanism is described in Section 4, 726 with an optional stateless mechanism described in Appendix C. 728 2.4.3. Architectural component: Domain Registrar 730 The Domain Registrar (having the formal name Join Registrar/ 731 Coordinator (JRC)), operates as a CMC Registrar, terminating the EST 732 and BRSKI connections. The Registrar is manually configured or 733 distributed with a list of trust anchors necessary to authenticate 734 any Pledge device expected on the network. The Registrar 735 communicates with the Vendor supplied MASA to establish ownership. 737 2.4.4. Architectural component: Vendor Service 739 The Vendor Service provides two logically seperate functions: the 740 Manufacturer Authorized Signing Authority (MASA), and an ownership 741 tracking/auditing function. 743 2.5. Lack of realtime clock 745 Many devices when bootstrapping do not have knowledge of the current 746 time. Mechanisms like Network Time Protocols can not be secured 747 until bootstrapping is complete. Therefore bootstrapping is defined 748 in a method that does not require knowledge of the current time. 750 Unfortunately there are moments during bootstrapping when 751 certificates are verified, such as during the TLS handshake, where 752 validity periods are confirmed. This paradoxical "catch-22" is 753 resolved by the Pledge maintaining a concept of the current "window" 754 of presumed time validity that is continually refined throughout the 755 bootstrapping process as follows: 757 o Initially the Pledge does not know the current time. 759 o During Pledge authentiation by the Registrar a realtime clock can 760 be used by the Registrar. This bullet expands on a closely 761 related issue regarding Pledge lifetimes. RFC5280 indicates that 762 long lived Pledge certifiates "SHOULD be assigned the 763 GeneralizedTime value of 99991231235959Z" [RFC7030] so the 764 Registrar MUST support such lifetimes and SHOULD support ignoring 765 Pledge lifetimes if they did not follow the RFC5280 766 recommendations. 768 o The Pledge authenticates the voucher presented to it. During this 769 authentication the Pledge ignores certificate lifetimes (by 770 necessity because it does not have a realtime clock). 772 o If the voucher contains a nonce then the Pledge MUST confirm the 773 nonce matches the original voucher request. This ensures the 774 voucher is fresh. See / (Section 5.2). 776 o Once the voucher is accepted the validity period of the pinned- 777 domain-cert in the voucher now serves as a valid time window. Any 778 subsequent certificate validity periods checked during RFC5280 779 path validation MUST occur within this window. 781 o When accepting an enrollment certificate the validity period 782 within the new certificate is assumed to be valid by the Pledge. 783 The Pledge is now willing to use this credential for client 784 authentication. 786 2.6. Cloud Registrar 788 The Pledge MAY contact a well known URI of a cloud Registrar if a 789 local Registrar can not be discovered or if the Pledge's target use 790 cases do not include a local Registrar. 792 If the Pledge uses a well known URI for contacting a cloud Registrar 793 an Implicit Trust Anchor database (see [RFC7030]) MUST be used to 794 authenticate service as described in RFC6125. This is consistent 795 with the human user configuration of an EST server URI in [RFC7030] 796 which also depends on RFC6125. 798 2.7. Determining the MASA to contact 800 The registrar needs to be able to contact a MASA that is trusted by 801 the Pledge in order to obtain vouchers. There are three mechanisms 802 described: 804 The device's Initial Device Identifier will normally contain the MASA 805 URL as detailed in Section 2.3. This is the RECOMMENDED mechanism. 807 If the Registrar is integrated with [I-D.ietf-opsawg-mud] and the 808 Pledge IDevID contains the id-pe-mud-url then the Registrar MAY 809 attempt to obtain the MASA URL from the MUD file. The MUD file 810 extension for the MASA URL is defined in Appendix D. 812 It can be operationally difficult to ensure the necessary X.509 813 extensions are in the Pledge's' IDevID due to the difficulty of 814 aligning current Pledge manufacturing with software releases and 815 development. As a final fallback the Registrar MAY be manually 816 configured or distributed with a MASA URL for each vendor. Note that 817 the Registrar can only select the configured MASA URL based on the 818 trust anchor -- so vendors can only leverage this approach if they 819 ensure a single MASA URL works for all Pledge's associated with each 820 trust anchor. 822 3. Voucher Request artifact 824 The voucher request is how an entity requests a voucher. The Pledge 825 forms a voucher request and submits it to the Registrar. The 826 Registrar in turn submits a voucher request to the MASA server. A 827 voucher request is a voucher structure with an additional "prior- 828 signed-voucher-request" "leaf to support forwarding the Pledge's 829 initial voucher request. 831 Unless otherwise signaled (outside the voucher artifact), the signing 832 structure is as defined for vouchers, see [I-D.ietf-anima-voucher]. 834 3.1. Tree Diagram 836 The following tree diagram illustrates a high-level view of a voucher 837 request document. The notation used in this diagram is described in 838 [I-D.ietf-anima-voucher]. Each node in the diagram is fully 839 described by the YANG module in Section 3.3. Please review the YANG 840 module for a detailed description of the voucher request format. 842 module: ietf-voucher-request 843 groupings: 844 voucher-request-grouping 845 +---- voucher 846 +---- created-on? yang:date-and-time 847 +---- expires-on? yang:date-and-time 848 +---- assertion enumeration 849 +---- serial-number string 850 +---- idevid-issuer? binary 851 +---- pinned-domain-cert? binary 852 +---- domain-cert-revocation-checks? boolean 853 +---- nonce? binary 854 +---- last-renewal-date? yang:date-and-time 855 +---- prior-signed-voucher-request? binary 856 +---- proximity-registrar-cert? binary 858 3.2. Examples 860 This section provides voucher examples for illustration purposes. 861 That these examples conform to the encoding rules defined in 862 [RFC7951]. 864 Example (1) The following example illustrates a Pledge generated 865 voucher-request. The assertion leaf is indicated as 866 'proximity' and the Registrar's TLS server certificate 867 is included in the 'pinned-domain-cert' leaf. See 868 Section 5.2. 870 { 871 "ietf-voucher-request:voucher": { 872 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 873 "created-on": "2017-01-01T00:00:00.000Z", 874 "assertion": "proximity", 875 "proximity-registrar-cert": "base64encodedvalue==" 876 } 877 } 879 Example (2) The following example illustrates a Registrar generated 880 voucher-request. The 'prior-signed-voucher-request' 881 leaf is populated with the Pledge's voucher request 882 (such as the prior example). See Section 5.4. 884 { 885 "ietf-voucher-request:voucher": { 886 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 887 "created-on": "2017-01-01T00:00:02.000Z", 888 "assertion": "proximity", 889 "idevid-issuer": "base64encodedvalue==" 890 "serial-number": "JADA123456789" 891 "prior-signed-voucher": "base64encodedvalue==" 892 } 893 } 895 Example (3) The following example illustrates a Registrar generated 896 voucher-request. The 'prior-signed-voucher-request' 897 leaf is not populated with the Pledge's voucher request 898 nor is the nonce leaf. This form might be used by a 899 Registrar requesting a voucher when the Pledge is 900 offline or when the Registrar expects to be offline 901 during deployment. See Section 5.4. 903 { 904 "ietf-voucher-request:voucher": { 905 "created-on": "2017-01-01T00:00:02.000Z", 906 "assertion": "TBD", 907 "idevid-issuer": "base64encodedvalue==" 908 "serial-number": "JADA123456789" 909 } 910 } 912 Example (4) The following example illustrates a Registrar generated 913 voucher-request. The 'prior-signed-voucher-request' 914 leaf is not populated with the Pledge's voucher request 915 because the Pledge did not sign it's own request. This 916 form might be used when more constrained Pledges are 917 being deployed. The nonce is populated from the 918 Pledge's request. See Section 5.4. 920 { 921 "ietf-voucher-request:voucher": { 922 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 923 "created-on": "2017-01-01T00:00:02.000Z", 924 "assertion": "proximity", 925 "idevid-issuer": "base64encodedvalue==" 926 "serial-number": "JADA123456789" 927 } 928 } 930 3.3. YANG Module 932 Following is a YANG [RFC7950] module formally extending the 933 [I-D.ietf-anima-voucher] voucher into the voucher request. 935 file "ietf-voucher-request@2017-10-13.yang" 936 module ietf-voucher-request { 937 yang-version 1.1; 939 namespace 940 "urn:ietf:params:xml:ns:yang:ietf-voucher-request"; 941 prefix "vch"; 943 import ietf-restconf { 944 prefix rc; 945 description 946 "This import statement is only present to access 947 the yang-data extension defined in RFC 8040."; 948 reference "RFC 8040: RESTCONF Protocol"; 949 } 951 import ietf-voucher { 952 prefix v; 953 description 954 "FIXME"; 955 reference "RFC ????: Voucher Profile for Bootstrapping Protocols"; 956 } 958 organization 959 "IETF ANIMA Working Group"; 961 contact 962 "WG Web: 963 WG List: 964 Author: Kent Watsen 965 966 Author: Max Pritikin 967 968 Author: Michael Richardson 969 970 Author: Toerless Eckert 971 "; 973 description 974 "This module... FIXME 976 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 977 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in 978 the module text are to be interpreted as described in RFC 2119. 980 Copyright (c) 2017 IETF Trust and the persons identified as 981 authors of the code. All rights reserved. 983 Redistribution and use in source and binary forms, with or without 984 modification, is permitted pursuant to, and subject to the license 985 terms contained in, the Simplified BSD License set forth in Section 986 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents 987 (http://trustee.ietf.org/license-info). 989 This version of this YANG module is part of RFC XXXX; see the RFC 990 itself for full legal notices."; 992 revision "2017-10-13" { 993 description 994 "Initial version"; 995 reference 996 "RFC XXXX: Voucher Profile for Bootstrapping Protocols"; 997 } 999 // Top-level statement 1000 rc:yang-data voucher-request-artifact { 1001 uses voucher-request-grouping; 1002 } 1004 // Grouping defined for future usage 1005 grouping voucher-request-grouping { 1006 description 1007 "Grouping to allow reuse/extensions in future work."; 1009 uses v:voucher-artifact-grouping { 1010 refine "voucher/created-on" { 1011 mandatory false; 1012 } 1014 refine "voucher/pinned-domain-cert" { 1015 mandatory false; 1016 } 1018 augment "voucher" { 1019 description 1020 "Adds leaf nodes appropriate for requesting vouchers."; 1022 leaf prior-signed-voucher-request { 1023 type binary; 1024 description 1025 "If it is necessary to change a voucher, or re-sign and 1026 forward a voucher that was previously provided along a 1027 protocol path, then the previously signed voucher SHOULD be 1028 included in this field. 1030 For example, a pledge might sign a proximity voucher, which 1031 an intermediate registrar then re-signs to make its own 1032 proximity assertion. This is a simple mechanism for a 1033 chain of trusted parties to change a voucher, while 1034 maintaining the prior signature information. 1036 The pledge MUST ignore all prior voucher information when 1037 accepting a voucher for imprinting. Other parties MAY 1038 examine the prior signed voucher information for the 1039 purposes of policy decisions. For example this information 1040 could be useful to a MASA to determine that both pledge and 1041 registrar agree on proximity assertions. The MASA SHOULD 1042 remove all prior-signed-voucher information when signing 1043 a voucher for imprinting so as to minimize the final 1044 voucher size."; 1045 } 1047 leaf proximity-registrar-cert { 1048 type binary; 1049 description 1050 "An X.509 v3 certificate structure as specified by RFC 5280, 1051 Section 4 encoded using the ASN.1 distinguished encoding 1052 rules (DER), as specified in ITU-T X.690. 1054 The first certificate in the Registrar TLS server 1055 certificate_list sequence (see [RFC5246]) presented by 1056 the Registrar to the Pledge. This MUST be populated in a 1057 Pledge's voucher request if the proximity assertion is 1058 populated."; 1059 } 1060 } 1061 } 1062 } 1064 } 1066 1068 4. Proxy details 1070 The role of the Proxy is to facilitate communications. The Proxy 1071 forwards packets between the Pledge and a Registrar that has been 1072 configured on the Proxy. 1074 The Proxy does not terminate the TLS handshake: it passes streams of 1075 bytes onward without examination. 1077 A proxy MAY assume TLS framing for auditing purposes, but MUST NOT 1078 assume any TLS version. 1080 A Proxy is always assumed even if it is directly integrated into a 1081 Registrar. (In a completely autonomic network, the Registrar MUST 1082 provide proxy functionality so that it can be discovered, and the 1083 network can grow concentrically around the Registrar) 1085 As a result of the Proxy Discovery process in section Section 4.1.1, 1086 the port number exposed by the proxy does not need to be well known, 1087 or require an IANA allocation. 1089 If the Proxy joins an Autonomic Control Plane 1090 ([I-D.ietf-anima-autonomic-control-plane]) it SHOULD use Autonomic 1091 Control Plane secured GRASP ([I-D.ietf-anima-grasp]) to discovery the 1092 Registrar address and port. As part of the discovery process, the 1093 proxy mechanism (Circuit Proxy vs IPIP encapsulation) is agreed to 1094 between the Registrar and Join Proxy. 1096 For the IPIP encapsulation methods (described in Appendix C), the 1097 port announced by the Proxy SHOULD be the same as on the registrar in 1098 order for the proxy to remain stateless. 1100 In order to permit the proxy functionality to be implemented on the 1101 maximum variety of devices the chosen mechanism SHOULD use the 1102 minimum amount of state on the proxy device. While many devices in 1103 the ANIMA target space will be rather large routers, the proxy 1104 function is likely to be implemented in the control plane CPU of such 1105 a device, with available capabilities for the proxy function similar 1106 to many class 2 IoT devices. 1108 The document [I-D.richardson-anima-state-for-joinrouter] provides a 1109 more extensive analysis and background of the alternative proxy 1110 methods. 1112 4.1. Pledge discovery of Proxy 1114 The result of discovery is a logical communication with a Registrar, 1115 through a Proxy. The Proxy is transparent to the Pledge but is 1116 always assumed to exist. 1118 To discover the Proxy the Pledge performs the following actions: 1120 1. MUST: Obtains a local address using IPv6 methods as described in 1121 [RFC4862] IPv6 Stateless Address AutoConfiguration. Use of 1123 [RFC4941] temporary addresses is encouraged. A new temporary 1124 address SHOULD be allocated whenever the discovery process is 1125 forced to restart due to failures. Pledges will generally prefer 1126 use of IPv6 Link-Local addresses, and discovery of Proxy will be 1127 by Link-Local mechanisms. IPv4 methods are described in 1128 Appendix A 1130 2. MUST: Listen for GRASP M_FLOOD ([I-D.ietf-anima-grasp]) 1131 announcements of the objective: "AN_Proxy". See section 1132 Section 4.1.1 for the details of the objective. The Pledge may 1133 listen concurrently for other sources of information, see 1134 Appendix B. 1136 Once a proxy is discovered the Pledge communicates with a Registrar 1137 through the proxy using the bootstrapping protocol defined in 1138 Section 5. 1140 Each discovery method attempted SHOULD exponentially back-off 1141 attempts (to a maximum of one hour) to avoid overloading the network 1142 infrastructure with discovery. The back-off timer for each method 1143 MUST be independent of other methods. 1145 Methods SHOULD be run in parallel to avoid head of queue problems 1146 wherein an attacker running a fake proxy or registrar can operate 1147 protocol actions intentionally slowly. 1149 Once a connection to a Registrar is established (e.g. establishment 1150 of a TLS session key) there are expectations of more timely 1151 responses, see Section 5.2. 1153 Once all discovered services are attempted the device SHOULD return 1154 to listening for GRASP M_FLOOD. It should periodically retry the 1155 vendor specific mechanisms. The Pledge MAY prioritize selection 1156 order as appropriate for the anticipated environment. 1158 4.1.1. Proxy Grasp announcements 1160 A proxy uses the GRASP M_FLOOD mechanism to announce itself. The 1161 pledge SHOULD listen for messages of these form. This announcement 1162 can be within the same message as the ACP announcement detailed in 1163 [I-D.ietf-anima-autonomic-control-plane]. 1165 proxy-objective = ["AN_Proxy", [ O_IPv6_LOCATOR, ipv6-address, 1166 transport-proto, port-number ] ] 1168 ipv6-address - the v6 LL of the proxy 1169 transport-proto - 6, for TCP 17 for UDP 1170 port-number - the TCP or UDP port number to find the proxy 1172 Figure 5 1174 4.2. CoAP connection to Registrar 1176 The use of CoAP to connect from Pledge to Registrar is out of scope 1177 for this document, and may be described in future work. 1179 4.3. HTTPS proxy connection to Registrar 1181 The proxy SHOULD also provide one of: an IPIP encapsulation of HTTP 1182 traffic to the registrar, or a TCP circuit proxy that connects the 1183 Pledge to a Registrar. 1185 When the Proxy provides a circuit proxy to a Registrar the Registrar 1186 MUST accept HTTPS connections. 1188 4.4. Proxy discovery of Registrar 1190 The Registrar SHOULD announce itself so that proxies can find it and 1191 determine what kind of connections can be terminated. 1193 When the Registrar joins an Autonomic Control Plane 1194 ([I-D.ietf-anima-autonomic-control-plane]) it MUST respond to GRASP 1195 ([I-D.ietf-anima-grasp]) M_NEG_SYN message. 1197 The registrar responds to discovery messages from the proxy (or GRASP 1198 caches between them) as follows: (XXX changed from M_DISCOVERY) 1200 objective = ["AN_registrar", F_DISC, 255 ] 1201 discovery-message = [M_NEG_SYN, session-id, initiator, objective] 1203 Figure 6: Registrar Discovery 1205 The response from the registrar (or cache) will be a M_RESPONSE with 1206 the following parameters: 1208 response-message = [M_RESPONSE, session-id, initiator, ttl, 1209 (+locator-option // divert-option), ?objective)] 1210 initiator = ACP address of Registrar 1211 locator1 = [O_IPv6_LOCATOR, fd45:1345::6789, 6, 443] 1212 locator2 = [O_IPv6_LOCATOR, fd45:1345::6789, 17, 5683] 1213 locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, nil] 1215 Figure 7: Registrar Response 1217 The set of locators is to be interpreted as follows. A protocol of 6 1218 indicates that TCP proxying on the indicated port is desired. A 1219 protocol of 17 indicates that UDP proxying on the indicated port is 1220 desired. In each case, the traffic SHOULD be proxied to the same 1221 port at the ULA address provided. 1223 A protocol of 41 indicates that packets may be IPIP proxy'ed. In the 1224 case of that IPIP proxying is used, then the provided link-local 1225 address MUST be advertised on the local link using proxy neighbour 1226 discovery. The Join Proxy MAY limit forwarded traffic to the 1227 protocol (6 and 17) and port numbers indicated by locator1 and 1228 locator2. The address to which the IPIP traffic should be sent is 1229 the initiator address (an ACP address of the Registrar), not the 1230 address given in the locator. 1232 Registrars MUST accept TCP / UDP traffic on the ports given at the 1233 ACP address of the Registrar. If the Registrar supports IPIP 1234 tunnelling, it MUST also accept traffic encapsulated with IPIP. 1236 Registrars MUST accept HTTPS/EST traffic on the TCP ports indicated. 1237 Registrars MAY accept DTLS/CoAP/EST traffic on the UDP in addition to 1238 TCP traffic. 1240 5. Protocol Details 1242 The Pledge MUST initiate BRSKI after boot if it is unconfigured. The 1243 Pledge MUST NOT automatically initiate BRSKI if it has been 1244 configured or is in the process of being configured. 1246 BRSKI is described as extensions to EST [RFC7030] to reduce the 1247 number of TLS connections and crypto operations required on the 1248 Pledge. The Registrar implements the BRSKI REST interface within the 1249 same .well-known URI tree as the existing EST URIs as described in 1250 EST [RFC7030] section 3.2.2. The communication channel between the 1251 Pledge and the Registrar is referred to as "BRSKI-EST" (see 1252 Figure 1). 1254 The communication channel between the Registrar and MASA is similarly 1255 described as extensions to EST within the same ./well-known tree. 1257 For clarity this channel is referred to as "BRSKI-MASA". (See 1258 Figure 1). 1260 MASA URI is "https:// authority "./well-known/est". 1262 BRSKI uses EST message formats for existing operations, uses JSON 1263 [RFC7159] for all new operations defined here, and voucher formats. 1265 While EST section 3.2 does not insist upon use of HTTP 1.1 persistent 1266 connections, BRSKI-EST connections SHOULD use persistent connections. 1267 The intention of this guidance is to ensure the provisional TLS 1268 authentication occurs only once and is properly managed. 1270 Summarized automation extensions for the BRSKI-EST flow are: 1272 o The Pledge provisionally accepts the Registrar certificate during 1273 the TLS handshake as detailed in Section 5.1. 1275 o If the Registrar responds with a redirection to other web origins 1276 the Pledge MUST follow only a single redirection. (EST supports 1277 redirection but does not allow redirections to other web origins 1278 without user input). 1280 o The Registar MAY respond with an HTTP 202 ("the request has been 1281 accepted for processing, but the processing has not been 1282 completed") as described in EST [RFC7030] section 4.2.3 wherein 1283 the client "MUST wait at least the specified 'retry-after' time 1284 before repeating the same request". The Pledge is RECOMMENDED to 1285 provide local feed (blinked LED etc) during this wait cycle if 1286 mechanisms for this are available. To prevent an attacker 1287 Registrar from significantly delaying bootstrapping the Pledge 1288 MUST limit the 'retry-after' time to 60 seconds. To avoid 1289 blocking on a single erroneous Registrar the Pledge MUST drop the 1290 connection after 5 seconds in which there has been no progress on 1291 the TCP connection. It should proceed to other discovered 1292 Registrars if there are any. If there were no other Registrars 1293 discovered, the pledge MAY continue to wait, as long as it is 1294 concurrently listening for new proxy announcements. 1296 o Ideally the Pledge could keep track of the appropriate retry-after 1297 value for any number of outstanding Registrars but this would 1298 involve a large state table on the Pledge. Instead the pledge MAY 1299 ignore the exact retry-after value in favor of a single hard coded 1300 value that takes effect between discovery ([[ProxyDiscovery]]) 1301 attempts. A Registrar that is unable to complete the transaction 1302 the first time due to timing reasons will have future chances. 1304 o The Pledge requests and validates a voucher using the new REST 1305 calls described below. 1307 o If necessary the Pledge calls the EST defined /cacerts method to 1308 obtain the domain owners' CA certificate. The pinned-domain- 1309 certificate element from the voucher should validate this 1310 certificate, or be identical to it. 1312 o The Pledge completes authentication of the server certificate as 1313 detailed in Section 5.5.1. This moves the BRSKI-EST TLS 1314 connection out of the provisional state. Optionally, the BRSKI- 1315 EST TLS connection can now be used for EST enrollment. 1317 The extensions for a Registrar (equivalent to EST server) are: 1319 o Client authentication is automated using Initial Device Identity 1320 (IDevID) as per the EST certificate based client authentication. 1321 The subject field's DN encoding MUST include the "serialNumber" 1322 attribute with the device's unique serial number. In the language 1323 of RFC6125 this provides for a SERIALNUM-ID category of identifier 1324 that can be included in a certificate and therefore that can also 1325 be used for matching purposes. The SERIALNUM-ID whitelist is 1326 collated according to vendor trust anchor since serial numbers are 1327 not globally unique. 1329 o The Registrar requests and validates the Voucher from the vendor 1330 authorized MASA service. 1332 o The Registrar forwards the Voucher to the Pledge when requested. 1334 o The Registar performs log verifications in addition to local 1335 authorization checks before accepting optional Pledge device 1336 enrollment requests. 1338 5.1. BRSKI-EST TLS establishment details 1340 The Pledge establishes the TLS connection with the Registrar through 1341 the circuit proxy (see Section 4) but the TLS handshake is with the 1342 Registar. The BRSKI-EST Pledge is the TLS client and the BRSKI-EST 1343 Registrar is the TLS server. All security associations established 1344 are between the Pledge and the Registrar regardless of proxy 1345 operations. 1347 Establishment of the BRSKI-EST TLS connection is as specified in EST 1348 [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" 1349 [RFC7030] wherein the client is authenticated with the IDevID 1350 certificate, and the EST server (the Registrar) is provisionally 1351 authenticated with a unverified server certificate. 1353 The Pledge maintains a security paranoia concerning the provisional 1354 state, and all data recieved, until a voucher is received and 1355 verified as specified in Section 5.5.1 1357 5.2. Pledge Requests Voucher from the Registrar 1359 When the Pledge bootstraps it makes a request for a Voucher from a 1360 Registrar. 1362 This is done with an HTTPS POST using the operation path value of 1363 "/requestvoucher". 1365 The request media types are: 1367 application/pkcs7-mime; smime-type=voucher-request The request is a 1368 "YANG-defined JSON document that has been signed using a PKCS#7 1369 structure" as described in Section 3 using the JSON encoding 1370 described in [RFC7951]. The Pledge SHOULD sign the request using 1371 the Section 2.3 credential. 1373 application/json The request is the "YANG-defined JSON document" as 1374 described in Section 3 with exception that it is not within a 1375 PKCS#7 structure. It is protected only by the TLS client 1376 authentication. This reduces the cryptographic requirements on 1377 the Pledge. 1379 For simplicity the term 'voucher request' is used to refer to either 1380 of these media types. Registrar impementations SHOULD anticipate 1381 future media types but of course will simply fail the request if 1382 those types are not yet known. 1384 The Pledge populates the voucher request fields as follows: 1386 created-on: Pledges that have a realtime clock are RECOMMENDED to 1387 populate this field. This provides additional information to the 1388 MASA. 1390 nonce: The voucher request MUST contain a cryptographically strong 1391 random or pseudo-random number nonce. Doing so ensures 1392 Section 2.5 functionality. The nonce MUST NOT be reused for 1393 bootstrapping attempts. 1395 assertion: The voucher request MAY contain an assertion of 1396 "proximity". 1398 proximity-registrar-cert: In a Pledge voucher request this is the 1399 first certificate in the TLS server 'certificate_list' sequence 1400 (see [RFC5246]) presented by the Registrar to the Pledge. This 1401 MUST be populated in a Pledge's voucher request if the "proximity" 1402 assertion is populated. 1404 All other fields MAY be omitted in the voucher request. 1406 An example JSON payload of a voucher request from a Pledge is in 1407 Section 3.2 Example 1. 1409 The Registrar validates the client identity as described in EST 1410 [RFC7030] section 3.3.2. If the request is signed the Registrar 1411 confirms the 'proximity' asserion and associated 'proximity- 1412 registrar-cert' are correct. The registrar performs authorization as 1413 detailed in [[EDNOTE: UNRESOLVED. See Appendix D "Pledge 1414 Authorization"]]. If these validations fail the Registrar SHOULD 1415 respond with an appropriate HTTP error code. 1417 If authorization is successful the Registrar obtains a voucher from 1418 the MASA service (see Section 5.4) and returns that MASA signed 1419 voucher to the pledge as described in Section 5.5. 1421 5.3. BRSKI-MASA TLS establishment details 1423 The BRSKI-MASA TLS connection is a 'normal' TLS connection 1424 appropriate for HTTPS REST interfaces. The Registrar initiates the 1425 connection and uses the MASA URL obtained as described in Section 2.7 1426 for RFC6125 authentication of the MASA server. 1428 The primary method of Registrar "authentication" by the MASA is 1429 detailed in Section 5.4. As detailed in Section 8 the MASA might 1430 find it necessary to request additional Registrar authentication. 1431 Registrars MUST be prepared to support TLS client certificate 1432 authentication and HTTP Basic or Digest authentication as described 1433 in RFC7030 for EST clients. Implementors are advised that contacting 1434 the MASA is to establish a secured REST connection with a web service 1435 and that there are a number of authentication models being explored 1436 within the industry. Registrars are RECOMMENDED to fail gracefully 1437 and generate useful administrative notifications or logs in the 1438 advent of unexpected HTTP 401 (Unauthorized) responses from the MASA. 1440 5.4. Registrar Requests Voucher from MASA 1442 When a Registrar receives a voucher request from a Pledge it in turn 1443 requests a voucher from the MASA service. For simplicity this is 1444 defined as an optional EST message between a Registrar and an EST 1445 server running on the MASA service although the Registrar is not 1446 required to make use of any other EST functionality when 1447 communicating with the MASA service. (The MASA service MUST properly 1448 reject any EST functionality requests it does not wish to service; a 1449 requirement that holds for any REST interface). 1451 This is done with an HTTP POST using the operation path value of 1452 "/requestvoucher". 1454 The request media type is: 1456 application/pkcs7-mime; smime-type=voucher-request The request is a 1457 "YANG-defined JSON document that has been signed using a PKCS#7 1458 structure" as described in [I-D.ietf-anima-voucher] using the JSON 1459 encoding described in [RFC7951]. The Registrar MUST sign the 1460 request. The entire Registrar certificate chain, up to and 1461 including the Domain CA, MUST be included in the PKCS#7 structure. 1463 For simplicity the term 'voucher request' is used. MASA 1464 impementations SHOULD anticipate future media types but of course 1465 will simply fail the request if those types are not yet known. 1467 The Registrar populates the voucher request fields as follows: 1469 created-on: Registrars are RECOMMENDED to populate this field. This 1470 provides additional information to the MASA. 1472 nonce: The optional nonce value from the Pledge request if desired 1473 (see below). 1475 serial-number: The serial number of the Pledge the Registrar would 1476 like a voucher for. 1478 idevid-issuer: The idevid-issuer value from the pledge certificate 1479 is included to ensure a statistically unique identity. The 1480 Pledge's serial number is extracted from the X.509 IDevID. See 1481 Section 2.3. 1483 prior-signed-voucher: If the Pledge provided a signed voucher 1484 request then it SHOULD be included in the voucher request built by 1485 the Registrar. (NOTE: this is the Pledge's complete voucher 1486 request, inclusive of the 'assertion', 'proximity-registrar-cert', 1487 etc wrapped by the pledge's original PKCS#7 signature). 1489 A Registrar MAY exclude the nonce from the voucher request it submits 1490 to the MASA. Doing so allows the Registrar to request a Voucher when 1491 the Pledge is offline, or when the Registrar is expected to be 1492 offline when the Pledge is being deployed. These use cases require 1493 the Registrar to learn the appropriate IDevID SerialNumber field from 1494 the physical device labeling or from the sales channel (out-of-scope 1495 of this document). If a nonce is not provided the MASA server MUST 1496 authenticate the Registrar as described in EST [RFC7030] section 1497 3.3.2 to reduce the risk of DDoS attacks and to provide an 1498 authenticated identity as an input to sales channel integration and 1499 authorizations (also out-of-scope of this document). 1501 All other fields MAY be omitted in the voucher request. 1503 Example JSON payloads of voucher requests from a Registrar are in 1504 Section 3.2 Example 2 through 4. 1506 The MASA verifies that the voucher request is internally consistent 1507 but does not authenticate the registrar certificate since the 1508 registrar is not know to the MASA server in advance. The MASA 1509 validation checks before issuing a voucher are as follows: 1511 Renew for expired voucher: As described in [I-D.ietf-anima-voucher] 1512 vouchers are normally short lived to avoid revocation issues. If 1513 the request is for a previous (expired) voucher using the same 1514 Registrar (as determined by the Registrar pinned-domain-cert) and 1515 the MASA has not been informed that the claim is invalid then the 1516 request for a renewed voucher SHOULD be automatically authorized. 1518 Voucher signature consistency: The MASA MUST verify that the voucher 1519 request is signed by a Registrar. This is confirmed by verifying 1520 that the id-kp-cmcRA extended key usage extension field (as 1521 detailed in EST RFC7030 section 3.6.1) exists in the certificate 1522 of the entity that signed the voucher request. This verification 1523 is only a consistency check that the unauthenticated domain CA 1524 intended this to be a Registrar. Performing this check provides 1525 value to domain PKI by assuring the domain administrator that the 1526 MASA service will only respect claims from authorized Registration 1527 Authorities of the domain. (The requirement for the Registrar to 1528 include the Domain CA certificate in the signature structure was 1529 stated above). 1531 Registrar revocation consistency: The MASA SHOULD check for 1532 revocation of the Registrar certificate. The maximum lifetime of 1533 the voucher issued SHOULD NOT exceed the lifetime of the 1534 Registrar's revocation validation (for example if the Registrar 1535 revocation status is indicated in a CRL that is valid for two 1536 weeks then that is an appropriate lifetime for the voucher). 1537 Because the Registar certificate authority is unknown to the MASA 1538 in advance this is only an extended consistency check and is not 1539 required. The maximum lifetime of the voucher issued SHOULD NOT 1540 exceed the lifetime of the Registrar's revocation validation (for 1541 example if the Registrar revocation status is indicated in a CRL 1542 that is valid for two weeks then that is an appropriate lifetime 1543 for the voucher). 1545 Pledge proximity assertion: The MASA server MAY verify that the 1546 Registrar signed voucher includes the 'prior-signed-voucher' field 1547 populated with a Pledge signed voucher that includes a 'proximity- 1548 registrar-cert' that is consistent with the certificate the 1549 Registrar used to sign the voucher request. The MASA server is 1550 aware of which Pledge's support signing of their voucher requests 1551 and can use this information to confirm proximity of the Pledge 1552 with the Registrar. 1554 The Registrar certificate chain root certificate is extracted from 1555 the signature method and used to populate the "pinned-domain-cert" of 1556 the Voucher being issued. The domain ID (e.g. hash of the public key 1557 of the domain) is extracted from the root certificate and is used to 1558 update the audit log. 1560 5.5. Voucher Response 1562 The voucher response to requests from the Pledge and requests from a 1563 Registrar are in the same format. A Registrar either caches prior 1564 MASA responses or dynamically requests a new Voucher based on local 1565 policy. 1567 If the join operation is successful, the server response MUST contain 1568 an HTTP 200 response code. The server MUST answer with a suitable 1569 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. The 1570 response data from the MASA server MUST be a plaintext human-readable 1571 (ASCII, english) error message containing explanatory information 1572 describing why the request was rejected. 1574 A 403 (Forbidden) response is appropriate if the voucher request is 1575 not signed correctly, stale, or if the pledge has another outstanding 1576 voucher which can not be overridden. 1578 A 404 (Not Found) response is appropriate when the request is for a 1579 device which is not known to the MASA. 1581 A 406 (Not Acceptable) response is appropriate if a voucher of the 1582 desired type, or using the desired algorithms (as indicated by the 1583 Accept: headers, and algorithms used in the signature) can not be 1584 issued, such as because the MASA knows the pledge can not process 1585 that type. 1587 A 415 (Unsupported Media Type) response is approriate for a request 1588 that has a voucher encoding that is not understood. 1590 The response media type is: 1592 application/pkcs7-mime; smime-type=voucher The response is a "YANG- 1593 defined JSON document that has been signed using a PKCS#7 1594 structure" as described in [I-D.ietf-anima-voucher] using the JSON 1595 encoded described in [RFC7951]. The MASA MUST sign the request. 1597 The syntactic details of vouchers are described in detail in 1598 [I-D.ietf-anima-voucher]. For example, the voucher consists of: 1600 { 1601 "ietf-voucher:voucher": { 1602 "nonce": "62a2e7693d82fcda2624de58fb6722e5", 1603 "assertion": "logging" 1604 "pinned-domain-cert": "base64encodedvalue==" 1605 "serial-number": "JADA123456789" 1606 } 1607 } 1609 The Pledge verifies the signed voucher using the manufacturer 1610 installed trust anchor associated with the vendor's selected 1611 Manufacturer Authorized Signing Authority. 1613 The 'pinned-domain-cert' element of the voucher contains the domain 1614 CA's public key. The Pledge MUST use the 'pinned-domain-cert' trust 1615 anchor to immediately complete authentication of the provisional TLS 1616 connection. 1618 The Pledge MUST be prepared to parse and fail gracefully from a 1619 Voucher response that does not contain a 'pinned-domain-cert' field. 1620 The Pledge MUST be prepared to ignore additional fields it does not 1621 recognize. 1623 5.5.1. Completing authentication of Provisional TLS connection 1625 If a Registrar's credentials can not be verified using the pinned- 1626 domain-cert trust anchor from the voucher then the TLS connection is 1627 immediately discarded and the Pledge abandons attempts to bootstrap 1628 with this discovered registrar. The pledge SHOULD send voucher 1629 status telemetry (described below) before closing the TLS connection. 1630 The pledge MUST attempt to enroll using any other proxies it has 1631 found. It SHOULD return to the same proxy again after attempting 1632 with other proxies. Attempts should be attempted in the exponential 1633 backoff described earlier. Attempts SHOULD be repeated as failure 1634 may be the result of a temporary inconsistently (an inconsistently 1635 rolled Registrar key, or some other mis-configuration). The 1636 inconsistently could also be the result an active MITM attack on the 1637 EST connection. 1639 The Registrar MUST use a certificate that chains to the pinned- 1640 domain-cert as its TLS server certificate. 1642 The Pledge's PKIX path validation of a Registrar certificate's 1643 validity period information is as described in Section 2.5. Once the 1644 PKIX path validation is successful the TLS connection is no longer 1645 provisional. 1647 The pinned-domain-cert is installed as an Explicit Trust Anchor for 1648 future operations. It can therefore can be used to authenticate any 1649 dynamically discovered EST server that contain the id-kp-cmcRA 1650 extended key usage extension as detailed in EST RFC7030 section 1651 3.6.1; but to reduce system complexity the Pledge SHOULD avoid 1652 additional discovery operations. Instead the Pledge SHOULD 1653 communicate directly with the Registrar as the EST server. The ' 1654 pinned-domain-cert' is not a complete distribution of the EST section 1655 4.1.3 CA Certificate Response which is an additional justification 1656 for the recommendation to proceed with EST key management operations. 1657 Once a full CA Certificate Response is obtained it is more 1658 authoritative for the domain than the limited 'pinned-domain-cert' 1659 response.' 1661 5.6. Voucher Status Telemetry 1663 The domain is expected to provide indications to the system 1664 administrators concerning device lifecycle status. To facilitate 1665 this it needs telemetry information concerning the device's status. 1667 To indicate Pledge status regarding the Voucher, the pledge MUST post 1668 a status message. 1670 The posted data media type: application/json 1672 The client HTTP POSTs the following to the server at the EST well 1673 known URI /voucher_status. The Status field indicates if the Voucher 1674 was acceptable. If it was not acceptable the Reason string indicates 1675 why. In the failure case this message is being sent to an 1676 unauthenticated, potentially malicious Registrar and therefore the 1677 Reason string SHOULD NOT provide information beneficial to an 1678 attacker. The operational benefit of this telemetry information is 1679 balanced against the operational costs of not recording that an 1680 Voucher was ignored by a client the registar expected to continue 1681 joining the domain. 1683 { 1684 "version":"1", 1685 "Status":FALSE /* TRUE=Success, FALSE=Fail" 1686 "Reason":"Informative human readable message" 1687 "reason-context": { additional JSON } 1688 } 1690 The server SHOULD respond with an HTTP 200 but MAY simply fail with 1691 an HTTP 404 error. The client ignores any response. Within the 1692 server logs the server SHOULD capture this telemetry information. 1694 The reason-context attribute is an arbitrary JSON object (literal 1695 value or hash of values) which provides additional information 1696 specific to this pledge. The contents of this field are not subject 1697 to standardization." 1699 Additional standard responses MAY be added via Specification 1700 Required. 1702 5.7. MASA authorization log Request 1704 After receiving the voucher status telemetry Section 5.6, the 1705 Registrar SHOULD request the MASA authorization log from the MASA 1706 service using this EST extension. If a device had previously 1707 registered with another domain, a Registrar of that domain would show 1708 in the log. 1710 This is done with an HTTP GET using the operation path value of 1711 "/requestauditlog". 1713 The registrar MUST HTTP POSTs the same Voucher Request as when 1714 requesting a Voucher. It is posted to the /requestauditlog URI 1715 instead. The "idevid-issuer" and "serial-number" informs the MASA 1716 server which log is requested so the appropriate log can be prepared 1717 for the response. Using the same media type and message minimizes 1718 cryptographic and message operations although it results in 1719 additional network traffic. The relying MASA server implementation 1720 MAY leverage internal state to associate this request with the 1721 original, and by now already validated, voucher request so as to 1722 avoid an extra crypto validation. 1724 The request media type is: 1726 application/pkcs7-mime; smime-type=voucher-request The request is a 1727 "YANG-defined JSON document that has been signed using a PKCS#7 1728 structure" as described in Section 3 using the JSON encoded 1729 described in [RFC7951]. The Registrar MUST sign the request. The 1730 entire Registrar certificate chain, up to and including the Domain 1731 CA, MUST be included in the PKCS#7 structure. 1733 5.7.1. MASA authorization log Response 1735 A log data file is returned consisting of all log entries. For 1736 example: 1738 { 1739 "version":"1", 1740 "events":[ 1741 { 1742 "date":"", 1743 "domainID":"", 1745 "nonce":"" 1746 }, 1747 { 1748 "date":"", 1749 "domainID":"", 1751 "nonce":"" 1752 } 1753 ] 1754 } 1756 Distribution of a large log is less than ideal. This structure can 1757 be optimized as follows: All nonce-less entries for the same domainID 1758 MAY be condensed into the single most recent nonceless entry. 1760 A Registrar SHOULD use this log information to make an informed 1761 decision regarding the continued bootstrapping of the Pledge. For 1762 example if the log includes unexpected domainIDs this is indicative 1763 of problematic imprints by the Pledge. If the log includes nonce- 1764 less entries this is indicative of the permanent ability for the 1765 indicated domain to trigger a reset of the device and take over 1766 management of it. Equipment that is purchased pre-owned can be 1767 expected to have an extensive history. A Registrar MAY request logs 1768 at future times. A Registrar MAY be configured to ignore the history 1769 of the device but it is RECOMMENDED that this only be configured if 1770 hardware assisted NEA [RFC5209] is supported. 1772 Log entries containing the Domain's ID can be compared against local 1773 history logs in search of discrepancies. 1775 This document specifies a simple log format as provided by the MASA 1776 service to the registar. This format could be improved by 1777 distributed consensus technologies that integrate vouchers with a 1778 technologies such as block-chain or hash trees or the like. Doing so 1779 is out of the scope of this document but are anticipated improvements 1780 for future work. As such, the Registrar client SHOULD anticipate new 1781 kinds of responses, and SHOULD provide operator controls to indicate 1782 how to process unknown responses. 1784 5.8. EST Integration for PKI bootstrapping 1786 The Pledge SHOULD follow the BRSKI operations with EST enrollment 1787 operations including "CA Certificates Request", "CSR Attributes" and 1788 "Client Certificate Request" or "Server-Side Key Generation" etc. 1789 This is a relatively seamless integration since BRSKI REST calls 1790 provide an automated alternative to the manual bootstrapping method 1791 described in [RFC7030]. As noted above, use of HTTP 1.1 persistent 1792 connections simplifies the Pledge state machine. 1794 The Pledge is also RECOMMENDED to implement the following EST 1795 automation extensions. They supplement the RFC7030 EST to better 1796 support automated devices that do not have an end user. 1798 Although EST allows clients to obtain multiple certificates by 1799 sending multiple CSR requests BRSKI mandates use of the CSR 1800 Attributes request and mandates that the Registrar validate the CSR 1801 against the expected attributes. This implies that client requests 1802 will "look the same" and therefore result in a single logical 1803 certificate being issued even if the client were to make multiple 1804 requests. Registrars MAY contain more complex logic but doing so is 1805 out-of-scope of this specification. BRSKI does not signal any 1806 enhancement or restriction to this capability. Pledges that require 1807 multiple certificates could establish direct EST connections to the 1808 Registrar. 1810 5.8.1. EST Distribution of CA Certificates 1812 The Pledge MUST request the full EST Distribution of CA Certificates 1813 message. See RFC7030, section 4.1. 1815 This ensures that the Pledge has the complete set of current CA 1816 certificates beyond the pinned-domain-cert (see Section 5.5.1 for a 1817 discussion of the limitations inherent in having a single certificate 1818 instead of a full CA Certificates response). Although these 1819 limitations are acceptable during initial bootstrapping they are not 1820 appropriate for ongoing PKIX end entity certificate validation. 1822 5.8.2. EST CSR Attributes 1824 Automated bootstrapping occurs without local administrative 1825 configuration of the Pledge. In some deployments its plausible that 1826 the Pledge generates a certificate request containing only identity 1827 information known to the Pledge (essentially the X.509 IDevID 1828 information) and ultimately receives a certificate containing domain 1829 specific identity information. Conceptually the CA has complete 1830 control over all fields issued in the end entity certificate. 1831 Realistically this is operationally difficult with the current status 1832 of PKI certificate authority deployments where the CSR is submitted 1833 to the CA via a number of non-standard protocols. Even with all 1834 standardized protocols used, it could operationally be problematic to 1835 expect that service specific certificate fields can be created by a 1836 CA that is likely operated by a group that has no insight into 1837 different network services/protocols used. For example, the CA could 1838 even be outsourced. 1840 To alleviate these operational difficulties, the Pledge MUST request 1841 the EST "CSR Attributes" from the EST server and the EST server needs 1842 to be able to reply with the attributes necessary for use of the 1843 certificate in its intended protocols/services. This approach allows 1844 for minimal CA integrations and instead the local infrastructure (EST 1845 server) informs the Pledge of the proper fields to include in the 1846 generated CSR. This approach is beneficial to automated boostrapping 1847 in the widest number of environments. 1849 If the hardwareModuleName in the X.509 IDevID is populated then it 1850 SHOULD by default be propagated to the LDevID along with the 1851 hwSerialNum. The EST server SHOULD support local policy concerning 1852 this functionality. 1854 In networks using the BRSKI enrolled certificate to authenticate the 1855 ACP (Autonomic Control Plane), the EST attributes MUST include the 1856 "ACP information" field. See 1857 [I-D.ietf-anima-autonomic-control-plane] for more details. 1859 The Registar MUST also confirm the resulting CSR is formatted as 1860 indicated before forwarding the request to a CA. If the Registar is 1861 communicating with the CA using a protocol like full CMC which 1862 provides mechanisms to override the CSR attributes, then these 1863 mechanisms MAY be used even if the client ignores CSR Attribute 1864 guidance. 1866 5.8.3. EST Client Certificate Request 1868 The Pledge MUST request a new client certificate. See RFC7030, 1869 section 4.2. 1871 5.8.4. Enrollment Status Telemetry 1873 For automated bootstrapping of devices the adminstrative elements 1874 providing bootstrapping also provide indications to the system 1875 administrators concerning device lifecycle status. This might 1876 include information concerning attempted bootstrapping messages seen 1877 by the client, MASA provides logs and status of credential 1878 enrollment. The EST protocol assumes an end user and therefore does 1879 not include a final success indication back to the server. This is 1880 insufficient for automated use cases. 1882 To indicate successful enrollment the client SHOULD re-negotiate the 1883 EST TLS session using the newly obtained credentials. This occurs by 1884 the client initiating a new TLS ClientHello message on the existing 1885 TLS connection. The client MAY simply close the old TLS session and 1886 start a new one. The server MUST support either model. 1888 In the case of a FAIL the Reason string indicates why the most recent 1889 enrollment failed. The SubjectKeyIdentifier field MUST be included 1890 if the enrollment attempt was for a keypair that is locally known to 1891 the client. If EST /serverkeygen was used and failed then the field 1892 is omitted from the status telemetry. 1894 In the case of a SUCCESS the Reason string is omitted. The 1895 SubjectKeyIdentifier is included so that the server can record the 1896 successful certificate distribution. 1898 Status media type: application/json 1900 The client HTTP POSTs the following to the server at the new EST well 1901 known URI /enrollstatus. 1903 { 1904 "version":"1", 1905 "Status":TRUE /* TRUE=Success, FALSE=Fail" 1906 "Reason":"Informative human readable message" 1907 "reason-context": "Additional information" 1908 } 1910 The server SHOULD respond with an HTTP 200 but MAY simply fail with 1911 an HTTP 404 error. 1913 Within the server logs the server MUST capture if this message was 1914 received over an TLS session with a matching client certificate. 1915 This allows for clients that wish to minimize their crypto operations 1916 to simply POST this response without renegotiating the TLS session - 1917 at the cost of the server not being able to accurately verify that 1918 enrollment was truly successful. 1920 5.8.5. EST over CoAP 1922 This document describes extensions to EST for the purposes of 1923 bootstrapping of remote key infrastructures. Bootstrapping is 1924 relevant for CoAP enrollment discussions as well. The defintion of 1925 EST and BRSKI over CoAP is not discussed within this document beyond 1926 ensuring proxy support for CoAP operations. Instead it is 1927 anticipated that a definition of CoAP mappings will occur in 1928 subsequent documents such as [I-D.vanderstok-ace-coap-est] and that 1929 CoAP mappings for BRSKI will be discussed either there or in future 1930 work. 1932 6. Reduced security operational modes 1934 A common requirement of bootstrapping is to support less secure 1935 operational modes for support specific use cases. The following 1936 sections detail specific ways that the Pledge, Registrar and MASA can 1937 be configured to run in a less secure mode for the indicated reasons. 1939 6.1. Trust Model 1941 +--------+ +---------+ +------------+ +------------+ 1942 | Pledge | | Circuit | | Domain | | Vendor | 1943 | | | Proxy | | Registrar | | Service | 1944 | | | | | | | (Internet | 1945 +--------+ +---------+ +------------+ +------------+ 1947 Figure 10 1949 Pledge: The Pledge could be compromised and providing an attack 1950 vector for malware. The entity is trusted to only imprint using 1951 secure methods described in this document. Additional endpoint 1952 assessment techniques are RECOMMENDED but are out-of-scope of this 1953 document. 1955 Proxy: Provides proxy functionalities but is not involved in 1956 security considerations. 1958 Registrar: When interacting with a MASA server a Registrar makes all 1959 decisions. When Ownership Vouchers are involved a Registrar is 1960 only a conduit and all security decisions are made on the vendor 1961 service. 1963 Vendor Service, MASA: This form of vendor service is trusted to 1964 accurately log all claim attempts and to provide authoritative log 1965 information to Registrars. The MASA does not know which devices 1966 are associated with which domains. These claims could be 1967 strengthened by using cryptographic log techniques to provide 1968 append only, cryptographic assured, publicly auditable logs. 1969 Current text provides only for a trusted vendor. 1971 Vendor Service, Ownership Validation: This form of vendor service is 1972 trusted to accurately know which device is owned by which domain. 1974 6.2. Pledge security reductions 1976 The Pledge can choose to accept vouchers using less secure methods. 1977 These methods enable offline and emergency (touch based) deployment 1978 use cases: 1980 1. The Pledge MUST accept nonceless vouchers. This allows for 1981 offline use cases. Logging and validity periods address the 1982 inherent security considerations of supporting these use cases. 1984 2. The Pledge MAY support "trust on first use" for physical 1985 interfaces such as a local console port or physical user 1986 interface but MUST NOT support "trust on first use" on network 1987 interfaces. This is because "trust on first use" permanently 1988 degrades the security for all use cases. 1990 3. The Pledge MAY have an operational mode where it skips Voucher 1991 validation one time. For example if a physical button is 1992 depressed during the bootstrapping operation. This can be useful 1993 if the vendor service is unavailable. This behavior SHOULD be 1994 available via local configuration or physical presence methods to 1995 ensure new entities can always be deployed even when autonomic 1996 methods fail. This allows for unsecured imprint. 1998 It is RECOMMENDED that "trust on first use" or skipping voucher 1999 validation only be available if hardware assisted Network Endpoint 2000 Assessment [RFC5209] is supported. This recommendation ensures that 2001 domain network monitoring can detect innappropriate use of offline or 2002 emergency deployment procedures. 2004 6.3. Registrar security reductions 2006 A Registrar can choose to accept devices using less secure methods. 2007 These methods are acceptable when low security models are needed, as 2008 the security decisions are being made by the local administrator, but 2009 they MUST NOT be the default behavior: 2011 1. A registrar MAY choose to accept all devices, or all devices of a 2012 particular type, at the administrator's discretion. This could 2013 occur when informing all Registrars of unique identifiers of new 2014 entities might be operationally difficult. 2016 2. A registrar MAY choose to accept devices that claim a unique 2017 identity without the benefit of authenticating that claimed 2018 identity. This could occur when the Pledge does not include an 2019 X.509 IDevID factory installed credential. New Entities without 2020 an X.509 IDevID credential MAY form the Section 5.2 request using 2021 the Section 5.4 format to ensure the Pledge's serial number 2022 information is provided to the Registar (this includes the IDevID 2023 AuthorityKeyIdentifier value which would be statically configured 2024 on the Pledge). The Pledge MAY refuse to provide a TLS client 2025 certificate (as one is not available). The Pledge SHOULD support 2026 HTTP-based or certificate-less TLS authentication as described in 2027 EST RFC7030 section 3.3.2. A Registrar MUST NOT accept 2028 unauthenticated New Entities unless it has been configured to do 2029 so by an administrator that has verified that only expected new 2030 entities can communicate with a Registrar (presumably via a 2031 physically secured perimeter). 2033 3. A Registrar MAY request nonce-less Vouchers from the MASA service 2034 (by not including a nonce in the request). These Vouchers can 2035 then be transmitted to the Registrar and stored until they are 2036 needed during bootstrapping operations. This is for use cases 2037 where target network is protected by an air gap and therefore can 2038 not contact the MASA service during Pledge deployment. 2040 4. A registrar MAY ignore unrecognized nonce-less log entries. This 2041 could occur when used equipment is purchased with a valid history 2042 being deployed in air gap networks that required permanent 2043 Vouchers. 2045 6.4. MASA security reductions 2047 Lower security modes chosen by the MASA service effect all device 2048 deployments unless bound to the specific device identities. In which 2049 case these modes can be provided as additional features for specific 2050 customers. The MASA service can choose to run in less secure modes 2051 by: 2053 1. Not enforcing that a nonce is in the Voucher. This results in 2054 distribution of Voucher that never expires and in effect makes 2055 the Domain an always trusted entity to the Pledge during any 2056 subsequent bootstrapping attempts. That this occurred is 2057 captured in the log information so that the Registrar can make 2058 appropriate security decisions when a Pledge joins the Domain. 2059 This is useful to support use cases where Registrars might not be 2060 online during actual device deployment. Because this results in 2061 long lived Voucher and does not require the proof that the device 2062 is online this is only accepted when the Registrar is 2063 authenticated by the MASA server and authorized to provide this 2064 functionality. The MASA server is RECOMMENDED to use this 2065 functionality only in concert with an enhanced level of ownership 2066 tracking (out-of-scope). If the Pledge device is known to have a 2067 real-time-clock that is set from the factory use of a voucher 2068 validity period is RECOMMENDED. 2070 2. Not verifying ownership before responding with an Voucher. This 2071 is expected to be a common operational model because doing so 2072 relieves the vendor providing MASA services from having to track 2073 ownership during shipping and supply chain and allows for a very 2074 low overhead MASA service. A Registrar uses the audit log 2075 information as a defense in depth strategy to ensure that this 2076 does not occur unexpectedly (for example when purchasing new 2077 equipment the Registrar would throw an error if any audit log 2078 information is reported). The MASA should verify the 'prior- 2079 signed-voucher' information for Pledge's that support that 2080 functionality. This provides a proof-of-proximity check that 2081 reduces the need for ownership verification. 2083 7. IANA Considerations 2085 This document requests the following Parameter Values for the "smime- 2086 type" Parameters: 2088 o voucher-request 2090 o voucher 2092 7.1. PKIX Registry 2094 IANA is requested to register the following: 2096 This document requests a number for id-mod-MASAURLExtn2016(TBD) from 2097 the pkix(7) id-mod(0) Registry. [[EDNOTE: fix names]] 2099 This document requests a number from the id-pe registry for id-pe- 2100 masa-url. XXX 2102 7.2. MIME 2104 Type name: 2106 Subtype name: 2108 Required parameters: 2110 Optional parameters: 2112 Encoding considerations: 2114 Security considerations: 2116 Interoperability considerations: 2118 Published specification: 2120 Applications that use this media type: 2122 Fragment identifier considerations: 2124 Additional information: 2126 Deprecated alias names for this type: 2128 Magic number(s): 2130 File extension(s): 2132 Macintosh file type code(s): 2134 Person and email address to contact for further information: 2136 Intended usage: LIMITED USED 2138 Restrictions on usage: 2140 Author: 2142 Change controller: 2144 Provisional registration? (standards tree only): 2146 7.3. Voucher Status Telemetry 2148 IANA is requested to create a registry entitled: _Voucher Status 2149 Telemetry Attributes_. New items can be added using the 2150 Specification Required. The following items are to be in the initial 2151 registration, with this document as the reference: 2153 o version 2155 o Status 2157 o Reason 2159 o reason-context 2161 8. Security Considerations 2163 There are uses cases where the MASA could be unavailable or 2164 uncooperative to the Registrar. They include planned and unplanned 2165 network partitions, changes to MASA policy, or other instances where 2166 MASA policy rejects a claim. These introduce an operational risk to 2167 the Registrar owner that MASA/vendor behavior might limit the ability 2168 to re-boostrap a Pledge device. For example this might be an issue 2169 during disaster recovery. This risk can be mitigated by Registrars 2170 that request and maintain long term copies of "nonceless" Vouchers. 2171 In that way they are guaranteed to be able to repeat bootstrapping 2172 for their devices. 2174 The issuance of nonceless vouchers themselves create a security 2175 concern. If the Registrar of a previous domain can intercept 2176 protocol communications then it can use a previously issued nonceless 2177 voucher to establish management control of a pledge device even after 2178 having sold it. This risk is mitigated by recording the issuance of 2179 such vouchers in the MASA audit log that is verified by the 2180 subsequent Registrar. This reduces the resale value of the equipment 2181 because future owners will detect the lowered security inherent in 2182 the existence of a nonceless voucher that would be trusted by their 2183 Pledge. This reflects a balance between partition resistant recovery 2184 and security of future bootstrapping. Registrars take the Pledge's 2185 audit history into account when applying policy to new devices. 2187 The MASA server is exposed to DoS attacks wherein attackers claim an 2188 unbounded number of devices. Ensuring a Registrar is representative 2189 of a valid vendor customer, even without validating ownership of 2190 specific Pledge devices, helps to mitigate this. Pledge signatures 2191 on the initial voucher request, as forwarded by the Registrar in the 2192 prior-signed-voucher field, significantly reduce this risk by 2193 ensuring the MASA can confirm proximity between the Pledge and the 2194 Registrar making the request. This mechanism is optional to allow 2195 for constrained devices. 2197 It is possible for an attacker to request a voucher from the MASA 2198 service directly after the real Registrar obtains an audit log. If 2199 the attacker could also force the bootstrapping protocol to reset 2200 there is a theoretical opportunity for the attacker to use their 2201 voucher to take control of the Pledge but then proceed to enroll with 2202 the target domain. Possible prevention mechanisms include: 2204 o Per device rate limits on the MASA service ensure such timing 2205 attacks are difficult. 2207 o The Registrar can repeat the request for audit log information at 2208 some time after bootstrapping is complete. 2210 To facilitate logging and administrative oversight the Pledge reports 2211 on Voucher parsing status to the Registrar. In the case of a failure 2212 this information is informative to a potentially malicious Registar 2213 but this is RECOMMENDED anyway because of the operational benefits of 2214 an informed administrator in cases where the failure is indicative of 2215 a problem. 2217 To facilitate truely limited clients EST RFC7030 section 3.3.2 2218 requirements that the client MUST support a client authentication 2219 model have been reduced in Section 6 to a statement that the 2220 Registrar "MAY" choose to accept devices that fail cryptographic 2221 authentication. This reflects current (poor) practices in shipping 2222 devices without a cryptographic identity that are NOT RECOMMENDED. 2224 During the provisional period of the connection all HTTP header and 2225 content data MUST treated as untrusted data. HTTP libraries are 2226 regularly exposed to non-secured HTTP traffic: mature libraries 2227 should not have any problems. 2229 Pledge's might chose to engage in protocol operations with multiple 2230 discovered Registrars in parallel. As noted above they will only do 2231 so with distinct nonce values, but the end result could be multple 2232 voucher's issued from the MASA if all registrars attempt to claim the 2233 device. This is not a failure and the Pledge choses whichever 2234 voucher to accept based on internal logic. The Registrar's verifying 2235 log information will see multiple entries and take this into account 2236 for their analytics purposes. 2238 8.1. Freshness in Voucher Requests 2240 A concern has been raised that the voucher request produced by the 2241 Pledge should contain some content (a nonce) from the Registrar and/ 2242 or MASA in order for those actors to verify that the voucher request 2243 is fresh. 2245 There are a number of operational problems with getting a nonce from 2246 the MASA to the pledge. It is somewhat easier to collect a random 2247 value from the Registrar, but as the Registrar is not yet vouched 2248 for, such a Registrar nonce has little value. There are privacy and 2249 logistical challenges to addressing these operational issues, so if 2250 such a thing were to be considered, it would have to provide some 2251 clear value. This section examines the impacts of not having a fresh 2252 voucher request from the pledge. 2254 Because the Registrar authenticates the Pledge a full Man-in-the- 2255 Middle attack is not possible, despite the provisional TLS 2256 authentication by the Pledge (see Section 5). Instead we examine the 2257 case of a fake Registrar (Rm) that communicates with the Pledge in 2258 parallel or in close time proximity with the intended Registrar. 2259 (This scenario is intentionally supported as described in 2260 Section 4.1). 2262 The fake Registrar (Rm) can obtain a voucher signed by the MASA 2263 either directly or through arbitrary intermediaries. Assuming that 2264 the MASA accepts the voucher request (either because Rm is 2265 collaborating with a legitimate Registrar according to supply chain 2266 information, or because the MASA is in audit-log only mode), then a 2267 voucher linking the pledge to the Registrar Rm is issued. 2269 Such a voucher, when passed back to the Pledge, would link the pledge 2270 to Registrar Rm, and would permit the Pledge to end the provisional 2271 state. It now trusts Rm and, if it has any security vulnerabilities 2272 leveragable by an Rm with full administrative control, can be assumed 2273 to be a threat against the intended Registrar. 2275 This flow is mitigated by the intended Registar verifying the audit 2276 logs available from the MASA as described in Section 5.7. Rm might 2277 chose to wait until after the intended Registrar completes the 2278 authorization process before submitting the now-stale voucher 2279 request. The Rm would need to remove the Pledge's nonce. 2281 In order to successfully use the resulting "stale voucher" Rm would 2282 have to attack the Pledge and return it to a bootstrapping enabled 2283 state. This would require wiping the Pledge of current configuration 2284 and triggering a re-bootstrapping of the Pledge. This is no more 2285 likely than simply taking control of the Pledge directly but if this 2286 is a consideration the target network is RECOMMENDED to take the 2287 following steps: 2289 o Ongoing network monitoring for unexpected bootstrapping attempts 2290 by Pledges. 2292 o Retreival and examination of MASA log information upon the 2293 occurance of any such unexpected events. Rm will be listed in the 2294 logs. 2296 9. Acknowledgements 2298 We would like to thank the various reviewers for their input, in 2299 particular Brian Carpenter, Toerless Eckert, Fuyu Eleven, Eliot Lear, 2300 Sergey Kasatkin, Markus Stenberg, and Peter van der Stok 2302 10. References 2304 10.1. Normative References 2306 [I-D.ietf-anima-autonomic-control-plane] 2307 Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic 2308 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 2309 plane-10 (work in progress), September 2017. 2311 [I-D.ietf-anima-voucher] 2312 Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 2313 "Voucher Profile for Bootstrapping Protocols", draft-ietf- 2314 anima-voucher-05 (work in progress), August 2017. 2316 [I-D.vanderstok-ace-coap-est] 2317 Kumar, S., Stok, P., Kampanakis, P., Furuhed, M., and S. 2318 Raza, "EST over secure CoAP (EST-coaps)", draft- 2319 vanderstok-ace-coap-est-02 (work in progress), June 2017. 2321 [IDevID] IEEE Standard, "IEEE 802.1AR Secure Device Identifier", 2322 December 2009, . 2325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2326 Requirement Levels", BCP 14, RFC 2119, 2327 DOI 10.17487/RFC2119, March 1997, 2328 . 2330 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 2331 "Advanced Sockets Application Program Interface (API) for 2332 IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003, 2333 . 2335 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2336 Levkowetz, Ed., "Extensible Authentication Protocol 2337 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 2338 . 2340 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 2341 Configuration of IPv4 Link-Local Addresses", RFC 3927, 2342 DOI 10.17487/RFC3927, May 2005, 2343 . 2345 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2346 Address Autoconfiguration", RFC 4862, 2347 DOI 10.17487/RFC4862, September 2007, 2348 . 2350 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 2351 Extensions for Stateless Address Autoconfiguration in 2352 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 2353 . 2355 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2356 (TLS) Protocol Version 1.2", RFC 5246, 2357 DOI 10.17487/RFC5246, August 2008, 2358 . 2360 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2361 Housley, R., and W. Polk, "Internet X.509 Public Key 2362 Infrastructure Certificate and Certificate Revocation List 2363 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 2364 . 2366 [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing 2367 Security: An Unauthenticated Mode of IPsec", RFC 5386, 2368 DOI 10.17487/RFC5386, November 2008, 2369 . 2371 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2372 RFC 5652, DOI 10.17487/RFC5652, September 2009, 2373 . 2375 [RFC5660] Williams, N., "IPsec Channels: Connection Latching", 2376 RFC 5660, DOI 10.17487/RFC5660, October 2009, 2377 . 2379 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 2380 DOI 10.17487/RFC6762, February 2013, 2381 . 2383 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 2384 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 2385 . 2387 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 2388 "Enrollment over Secure Transport", RFC 7030, 2389 DOI 10.17487/RFC7030, October 2013, 2390 . 2392 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 2393 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2394 2014, . 2396 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2397 Constrained-Node Networks", RFC 7228, 2398 DOI 10.17487/RFC7228, May 2014, 2399 . 2401 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 2402 RFC 7950, DOI 10.17487/RFC7950, August 2016, 2403 . 2405 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 2406 RFC 7951, DOI 10.17487/RFC7951, August 2016, 2407 . 2409 10.2. Informative References 2411 [I-D.behringer-homenet-trust-bootstrap] 2412 Behringer, M., Pritikin, M., and S. Bjarnason, 2413 "Bootstrapping Trust on a Homenet", draft-behringer- 2414 homenet-trust-bootstrap-02 (work in progress), February 2415 2014. 2417 [I-D.ietf-anima-grasp] 2418 Bormann, C., Carpenter, B., and B. Liu, "A Generic 2419 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 2420 grasp-15 (work in progress), July 2017. 2422 [I-D.ietf-netconf-zerotouch] 2423 Watsen, K., Abrahamsson, M., and I. Farrer, "Zero Touch 2424 Provisioning for NETCONF or RESTCONF based Management", 2425 draft-ietf-netconf-zerotouch-17 (work in progress), 2426 September 2017. 2428 [I-D.ietf-opsawg-mud] 2429 Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 2430 Description Specification", draft-ietf-opsawg-mud-12 (work 2431 in progress), October 2017. 2433 [I-D.richardson-anima-state-for-joinrouter] 2434 Richardson, M., "Considerations for stateful vs stateless 2435 join router in ANIMA bootstrap", draft-richardson-anima- 2436 state-for-joinrouter-01 (work in progress), July 2016. 2438 [imprinting] 2439 Wikipedia, "Wikipedia article: Imprinting", July 2015, 2440 . 2442 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2443 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 2444 December 1998, . 2446 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 2447 Interface Identifiers with IPv6 Stateless Address 2448 Autoconfiguration (SLAAC)", RFC 7217, 2449 DOI 10.17487/RFC7217, April 2014, 2450 . 2452 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 2453 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 2454 December 2014, . 2456 [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 2457 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 2458 Networking: Definitions and Design Goals", RFC 7575, 2459 DOI 10.17487/RFC7575, June 2015, 2460 . 2462 [Stajano99theresurrecting] 2463 Stajano, F. and R. Anderson, "The resurrecting duckling: 2464 security issues for ad-hoc wireless networks", 1999, 2465 . 2468 Appendix A. IPv4 operations 2470 A.1. IPv4 Link Local addresses 2472 Instead of an IPv6 link-local address, an IPv4 address may be 2473 generated using [RFC3927] Dynamic Configuration of IPv4 Link-Local 2474 Addresses. 2476 In the case that an IPv4 Local-Local address is formed, then the 2477 bootstrap process would continue as in the IPv6 case by looking for a 2478 (circuit) proxy. 2480 A.2. Use of DHCPv4 2482 The Plege MAY obtain an IP address via DHCP [RFC2131]. The DHCP 2483 provided parameters for the Domain Name System can be used to perform 2484 DNS operations if all local discovery attempts fail. 2486 Appendix B. mDNS / DNSSD proxy discovery options 2488 The Pledge MAY perform DNS-based Service Discovery [RFC6763] over 2489 Multicast DNS [RFC6762] searching for the service 2490 "_bootstrapks._tcp.local.". 2492 To prevent unaccceptable levels of network traffic the congestion 2493 avoidance mechanisms specified in [RFC6762] section 7 MUST be 2494 followed. The Pledge SHOULD listen for an unsolicited broadcast 2495 response as described in [RFC6762]. This allows devices to avoid 2496 announcing their presence via mDNS broadcasts and instead silently 2497 join a network by watching for periodic unsolicited broadcast 2498 responses. 2500 Performs DNS-based Service Discovery [RFC6763] over normal DNS 2501 operations. The service searched for is 2502 "_bootstrapks._tcp.example.com". In this case the domain 2503 "example.com" is discovered as described in [RFC6763] section 11. 2504 This method is only available if the host has received a useable IPv4 2505 address via DHCPv4 as suggested in Appendix A. 2507 If no local bootstrapks service is located using the GRASP 2508 mechanisms, or the above mentioned DNS-based Service Discovery 2509 methods the Pledge MAY contact a well known vendor provided 2510 bootstrapping server by performing a DNS lookup using a well known 2511 URI such as "bootstrapks.vendor-example.com". The details of the URI 2512 are vendor specific. Vendors that leverage this method on the Pledge 2513 are responsible for providing the bootstrapks service. 2515 The current DNS services returned during each query is maintained 2516 until bootstrapping is completed. If bootstrapping fails and the 2517 Pledge returns to the Discovery state it picks up where it left off 2518 and continues attempting bootstrapping. For example if the first 2519 Multicast DNS _bootstrapks._tcp.local response doesn't work then the 2520 second and third responses are tried. If these fail the Pledge moves 2521 on to normal DNS-based Service Discovery. 2523 Appendix C. IPIP Join Proxy mechanism 2525 The Circuit Proxy mechanism suffers from requiring a state on the 2526 Join Proxy for each connection that is relayed. The Circuit Proxy 2527 can be considered a kind of Algorithm Gateway [FIND-good-REF]. 2529 An alternative to proxying at the TCP layer is to selectively forward 2530 at the IP layer. This moves all per-connection to the Join 2531 Registrar. The IPIP tunnel statelessly forwards packets. This 2532 section provides some explanation of some of the details of the 2533 Registrar discovery procotol which are not important to Circuit 2534 Proxy, and some implementation advice. 2536 The IPIP tunnel is described in [RFC2473]. Each such tunnel is 2537 considered a unidirectional construct, but two tunnels may be 2538 associated to form a bidirectional mechanism. An IPIP tunnel is 2539 setup as follows. The outer addresses are an ACP address of the Join 2540 Proxy, and the ACP address of the Join Registrar. The inner 2541 addresses seen in the tunnel are the link-local addresses of the 2542 network on which the join activity is occuring. 2544 One way to look at this construct is to consider that the Registrar 2545 is extending attaching an interface to the network on which the Join 2546 Proxy is physically present. The Registrar then interacts as if it 2547 were present on that network using link-local (fe80::) addresses. 2548 The Join node is unaware that the traffic is being proxied through a 2549 tunnel, and does not need any special routing. 2551 There are a number of considerations with this mechanism which 2552 require cause some minor amounts of complexity. Note that due to the 2553 tunnels, the Registrar sees multiple connections to a fe80::/10 2554 network on not just physical interfaces, but on each of the virtual 2555 interfaces represending the tunnels. 2557 C.1. Multiple Join networks on the Join Proxy side 2559 The Join Proxy will in the general case be a routing device with 2560 multiple interfaces. Even a device as simple as a wifi access point 2561 may have wired, and multiple frequencies of wireless interfaces, 2562 potentially with multiple ESSIDs. 2564 Each of these interfaces on the Join Proxy may be seperate L3 routing 2565 domains, and therefore will have a unique set of link-local 2566 addresses. An IPIP packet being returned by the Registrar needs to 2567 be forwarded to the correct interface, so the Join Proxy needs an 2568 additional key to distinguish which network the packet should be 2569 returned to. 2571 The simplest way to get this additional key is to allocate an 2572 additional ACP address; one address for each network on which join 2573 traffic is occuring. The Join Proxy SHOULD do a GRASP M_NEG_SYN for 2574 each interface which they wish to relay traffic, as this allows the 2575 Registrar to do any static tunnel configuration that may be required. 2577 C.2. Automatic configuration of tunnels on Registrar 2579 The Join Proxy is expected to do a GRASP negotiation with the proxy 2580 for each Join Interface that it needs to relay traffic from. This is 2581 to permit Registrars to configure the appropriate virtual interfaces 2582 before join traffic arrives. 2584 A Registrar serving a large number of interfaces may not wish to 2585 allocate resources to every interface at all times, but can instead 2586 dynamically allocate interfaces. It can do this by monitoring IPIP 2587 traffic that arrives on it's ACP interface, and when packets arrive 2588 from new Join Proxys, it can dynamically configure virtual 2589 interfaces. 2591 A more sophisticated Registrar willing to modify the behaviour of 2592 it's TCP and UDP stack could note the IPIP traffic origination in the 2593 socket control block and make information available to the TCP layer 2594 (for HTTPS connections), or to the application (for CoAP connections) 2595 via a proprietary extension to the socket API. 2597 C.3. Proxy Neighbor Discovery by Join Proxy 2599 The Join Proxy MUST answer neighbor discovery messages for the 2600 address given by the Registrar as being it's link-local address. The 2601 Join Proxy must also advertise this address as the address to which 2602 to connect to when advertising it's existence. 2604 This proxy neighbor discovery means that the pledge will create TCP 2605 and UDP connections to the correct Registrar address. This matters 2606 as the TCP and UDP pseudo-header checksum includes the destination 2607 address, and for the proxy to remain completely stateless, it must 2608 not be necessary for the checksum to be updated. 2610 C.4. Use of connected sockets; or IP_PKTINFO for CoAP on Registrar 2612 TCP connections on the registrar SHOULD properly capture the ifindex 2613 of the incoming connection into the socket structure. This is normal 2614 IPv6 socket API processing. The outgoing responses will go out on 2615 the same (virtual) interface by ifindex. 2617 When using UDP sockets with CoAP, the application will have to pay 2618 attention to the incoming ifindex on the socket. Access to this 2619 information is available using the IP_PKTINFO auxiliary extension 2620 which is a standard part of the IPv6 sockets API. 2622 A registrar application could, after receipt of an initial CoAP 2623 message from the Pledge, create a connected UDP socket (including the 2624 ifindex information). The kernel would then take care of accurate 2625 demultiplexing upon receive, and subsequent transmission to the 2626 correct interface. 2628 C.5. Use of socket extension rather than virtual interface 2630 Some operating systems on which a Registrar need be implemented may 2631 find need for a virtual interface per Join Proxy to be problematic. 2632 There are other mechanism which can make be done. 2634 If the IPIP decapsulator can mark the (SYN) packet inside the kernel 2635 with the address of the Join Proxy sending the traffic, then an 2636 interface per Join Proxy may not be needed. The outgoing path need 2637 just pay attention to this extra information and add an appropriate 2638 IPIP header on outgoing. A CoAP over UDP mechanism may need to 2639 expose this extra information to the application as the UDP sockets 2640 are often not connected, and the application will need to specify the 2641 outgoing path on each packet send. 2643 Such an additional socket mechanism has not been standardized. 2644 Terminating L2TP connections over IPsec transport mode suffers from 2645 the same challenges. 2647 Appendix D. MUD Extension 2649 The following extension augments the MUD model to include a single 2650 node, as described in [I-D.ietf-opsawg-mud] section 3.6, using the 2651 following sample module that has the following tree structure: 2653 module: ietf-mud-brski-masa 2654 augment /ietf-mud:mud: 2655 +--rw masa-server? inet:uri 2657 The model is defined as follows: 2659 2660 module ietf-mud-brski-masa { 2661 yang-version 1.1; 2662 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa"; 2663 prefix ietf-mud-brski-masa; 2664 import ietf-mud { 2665 prefix ietf-mud; 2666 } 2667 import ietf-inet-types { 2668 prefix inet; 2669 } 2671 organization 2672 "IETF ANIMA (Autonomic Networking Integrated Model and 2673 Approach) Working Group"; 2674 contact 2675 "WG Web: http://tools.ietf.org/wg/anima/ 2676 WG List: anima@ietf.org 2677 "; 2678 description 2679 "BRSKI extension to a MUD file to indicate the 2680 MASA URL."; 2682 revision 2017-10-09 { 2683 description 2684 "Initial revision."; 2685 reference 2686 "RFC XXXX: Manufacturer Usage Description 2687 Specification"; 2688 } 2690 augment "/ietf-mud:mud" { 2691 description 2692 "BRSKI extension to a MUD file to indicate the 2693 MASA URL."; 2694 leaf masa-server { 2695 type inet:uri; 2696 description 2697 "This value is the URI of the MASA server"; 2698 } 2699 } 2700 } 2701 2703 Authors' Addresses 2705 Max Pritikin 2706 Cisco 2708 Email: pritikin@cisco.com 2710 Michael C. Richardson 2711 Sandelman Software Works 2713 Email: mcr+ietf@sandelman.ca 2714 URI: http://www.sandelman.ca/ 2716 Michael H. Behringer 2717 Cisco 2719 Email: mbehring@cisco.com 2721 Steinthor Bjarnason 2722 Arbor Networks 2724 Email: sbjarnason@arbor.net 2726 Kent Watsen 2727 Juniper Networks 2729 Email: kwatsen@juniper.net