Dear BRSKI-cloud authors,
Earlier this year, i did a review of draft-ietf-anima-brski-cloud-05: https://mailarchive.ietf.org/arch/msg/anima/fxFBwoUUUc31eHUcDhdTmWdkFdk The acknowledgemeent section of -08 does not mention my name. There is no changelog in the document explaining whether or not my review was taking into account. I tried to look through the github closed issues, but could not figure out if any of them where opened in response to my review. I tried to compare -08 with -05 to determine if / what of my review was taken into account but couldn't find much. There is also no email thread on anima WG mailing list replying to my review. If we should have discussed any of this review in the BRSKI meetings, i apologize, but i do not remember. Below, i am not repeating what i wrote for the -05 review, which i think was often editorial to improve text quality. Instead, i'll try below to raise mostly functional issues in the core spec. Feel free to also go back to the -05 review and check if stuff from there is still relevant. Some better tracking of what feedback was or was not taken into account would be helpful. Cheers Toerless idnits 2.17.1 draft-ietf-anima-brski-cloud-08.txt: Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-ietf-lamps-rfc7030-csrattrs-06 -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Friel 3 Internet-Draft Cisco 4 Intended status: Standards Track R. Shekh-Yusef 5 Expires: 25 February 2024 Auth0 6 M. Richardson 7 Sandelman Software Works 8 24 August 2023 10 BRSKI Cloud Registrar 11 draft-ietf-anima-brski-cloud-08 13 Abstract 15 Bootstrapping Remote Secure Key Infrastructures defines how to 16 onboard a device securely into an operator maintained infrastructure. 17 It assumes that there is local network infrastructure for the device 18 to discover and to help the device. This document extends the new 19 device behaviour so that if no local infrastructure is available, 20 such as in a home or remote office, that the device can use a well 21 defined "call-home" mechanism to find the operator maintained 22 infrastructure. 24 To this, this document defines how to contact a well-known Cloud 25 Registrar, and two ways in which the new device may be redirected 26 towards the operator maintained infrastructure. 28 About This Document 30 This note is to be removed before publishing as an RFC. 32 Status information for this document may be found at 33 https://datatracker.ietf.org/doc/draft-ietf-anima-brski-cloud/. 35 Discussion of this document takes place on the anima Working Group 36 mailing list (mailto:anima@ietf.org), which is archived at 37 https://mailarchive.ietf.org/arch/browse/anima/. 39 Source for this draft and an issue tracker can be found at 40 https://github.com/anima-wg/brski-cloud. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on 25 February 2024. 59 Copyright Notice 61 Copyright (c) 2023 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 66 license-info) in effect on the date of publication of this document. 67 Please review these documents carefully, as they describe your rights 68 and restrictions with respect to this document. Code Components 69 extracted from this document must include Revised BSD License text as 70 described in Section 4.e of the Trust Legal Provisions and are 71 provided without warranty as described in the Revised BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.2. Target Use Cases . . . . . . . . . . . . . . . . . . . . 4 78 1.2.1. Owner Registrar Discovery . . . . . . . . . . . . . . 4 79 1.2.2. Bootstrapping with no Owner Registrar . . . . . . . . 5 80 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 81 2.1. Network Connectivity . . . . . . . . . . . . . . . . . . 7 82 2.2. Pledge Certificate Identity Considerations . . . . . . . 7 83 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 8 84 3.1. Pledge Requests Voucher from Cloud Registrar . . . . . . 8 85 3.1.1. Cloud Registrar Discovery . . . . . . . . . . . . . . 8 86 3.1.2. Pledge - Cloud Registrar TLS Establishment Details . 8 87 3.1.3. Pledge Issues Voucher Request . . . . . . . . . . . . 9 88 3.2. Cloud Registrar Handles Voucher Request . . . . . . . . . 9 89 3.2.1. Pledge Ownership Lookup . . . . . . . . . . . . . . . 10 90 3.2.2. Cloud Registrar Redirects to Owner Registrar . . . . 10 91 3.2.3. Cloud Registrar Issues Voucher . . . . . . . . . . . 10 92 3.3. Pledge Handles Cloud Registrar Response . . . . . . . . . 11 93 3.3.1. Redirect Response . . . . . . . . . . . . . . . . . . 11 94 3.3.2. Voucher Response . . . . . . . . . . . . . . . . . . 12 96 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 12 97 4.1. Voucher Request Redirected to Local Domain Registrar . . 12 98 4.2. Voucher Request Handled by Cloud Registrar . . . . . . . 14 99 5. YANG extension for Voucher based redirect . . . . . . . . . . 16 100 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 102 7.1. Issues with Security of HTTP Redirect . . . . . . . . . . 17 103 7.2. Security Updates for the Pledge . . . . . . . . . . . . . 18 104 7.3. Trust Anchors for Cloud Registrar . . . . . . . . . . . . 18 105 7.4. Issues with Redirect via Voucher . . . . . . . . . . . . 19 106 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 107 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 108 Normative References . . . . . . . . . . . . . . . . . . . . . 19 109 Informative References . . . . . . . . . . . . . . . . . . . . 20 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 112 1. Introduction 114 Bootstrapping Remote Secure Key Infrastructures [BRSKI] and [RFC8994] 115 specifies automated network onboarding of devices, referred to as 116 pledges, within an Autonomic Control Plane or other managed network 117 infrastructure. BRSKI Section 2.7 describes how a pledge "MAY 118 contact a well-known URI of a Cloud Registrar if a local Registrar 119 cannot be discovered or if the pledge's target use cases do not 120 include a local Registrar". 122 This document further specifies use of a BRSKI Cloud Registrar and 123 clarifies operations that are not sufficiently specified in BRSKI. 125 1.1. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in 130 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 This document uses the terms Pledge, Registrar, MASA, and Voucher 134 from [BRSKI] and [RFC8366]. 136 Local Domain: The domain where the pledge is physically located and 137 bootstrapping from. This may be different to the pledge owner's 138 domain. 140 Owner Domain: The domain that the pledge needs to discover and 141 bootstrap with. 143 Cloud Registrar: The default Registrar that is deployed at a URI 144 that is well known to the pledge. 146 Owner Registrar: The Registrar that is operated by the Owner, or the 147 Owner's delegate. There may not be an Owner Registrar in all 148 deployment scenarios. 150 Local Domain Registrar: The Registrar discovered on the Local 151 Domain. There may not be a Local Domain Registrar in all 152 deployment scenarios. 154 EST: Enrollment over Secure Transport [RFC7030] 156 VAR: Value Added Reseller 158 1.2. Target Use Cases 160 Two high level use cases are documented here. There are more details add after "here" references to 1.2.1 and 1.2.2, or else the sentence is difficult to grasp because you are first derailing into other considerations in the following sentences. Also, and i think that would be textually better, you could move all text after "here" into a new section 1.2.3 further considerations - because a lot of the text from 161 - 182 makes a lot more sense after one has read 1.2.1 / 1.2.2 161 provided in sections Section 4.1 and Section 4.2. While both use 162 cases aid with incremental deployment of BRSKI infrastructure, for 163 many smaller sites (such as teleworkers) no further infrastructure is 164 expected. 166 The pledge is not expected to know which of these two situations it 167 is in. The pledge determines this based upon signals that it 168 receives from the Cloud Registrar. The Cloud Registrar is expected 169 to make the determination based upon the identity presented by the 170 pledge. 172 A Cloud Registrar will typically handle all the devices of a 173 particular product line from a particular manufacturer. This 174 document places no restrictions on how many different deployments or 175 owner sites the Cloud Registrar can handle, or how many devices per 176 site that the Cloud Registrar can handle. It is also entirely 177 possible that all devices sold by through a particular Value Added 178 Reseller (VAR) might be preloaded with a configuration that changes 179 the Cloud Registrar URL to point to a VAR. Such an effort would 180 require unboxing each device in a controlled environment, but the 181 provisioning could occur using a regular BRSKI or SZTP [RFC8572] 182 process. 184 1.2.1. Owner Registrar Discovery 186 A pledge is bootstrapping from a remote location with no local domain 187 Registrar (specifically: with no local infrastructure to provide for 188 automated discovery), and needs to discover its owner Registrar. The 189 Cloud Registrar is used by the pledge to discover the owner 190 Registrar. The Cloud Registrar redirects the pledge to the owner 191 Registrar, and the pledge completes bootstrap against the owner 192 Registrar. 194 A typical example is an enduser deploying a pledge in a home or small 195 branch office, where the pledge belongs to the enduser's employer. 196 There is no local domain Registrar, and the pledge needs to discover 197 and bootstrap with the employer's Registrar which is deployed in 198 headquarters. For example, an enduser is deploying an IP phone in a 199 home office and the phone needs to register to an IP PBX deployed in 200 their employer's office. 202 1.2.2. Bootstrapping with no Owner Registrar 204 A pledge is bootstrapping where the owner organization does not yet 205 have an owner Registrar deployed. The Cloud Registrar issues a 206 voucher, and the pledge completes trust bootstrap using the Cloud 207 Registrar. The voucher issued by the cloud includes domain 208 information for the owner's Enrollment over Secure Transport (EST) 209 [RFC7030] service the pledge should use for certificate enrollment. 211 In one use case, an organization has an EST service deployed, but 212 does not have yet a BRSKI capable Registrar service deployed. The 213 pledge is deployed in the organization's domain, but does not 214 discover a local domain Registrar or owner Registrar. The pledge 215 uses the Cloud Registrar to bootstrap, and the Cloud Registrar 216 provides a voucher that includes instructions on finding the 217 organization's EST service. 219 2. Architecture 221 The high level architecture is illustrated in Figure 1. 223 The pledge connects to the Cloud Registrar during bootstrap. 225 The Cloud Registrar may redirect the pledge to an owner Registrar in 226 order to complete bootstrap against the owner Registrar. 228 If the Cloud Registrar issues a voucher itself without redirecting 229 the pledge to an owner Registrar, the Cloud Registrar will inform the 230 pledge what domain to use for accessing EST services in the voucher 231 response. 233 Finally, when bootstrapping against an owner Registrar, this 234 Registrar may interact with a backend CA to assist in issuing 235 certificates to the pledge. The mechanisms and protocols by which 236 the Registrar interacts with the CA are transparent to the pledge and 237 are out-of-scope of this document. 239 The architecture shows the Cloud Registrar and MASA as being 240 logically separate entities. The two functions could of course be 241 integrated into a single service. 243 There are two different mechanisms for a Cloud Registrar to handle 244 voucher requests. It can redirect the request to Owner Registrar for 245 handling, or it can return a voucher that pins the actual Owner 246 Registrar. When returning a voucher, additional bootstrapping 247 information embedded in the voucher. Both mechanisms are described 248 in detail later in this document. 250 |<--------------OWNER--------------------------->| MANUFACTURER 252 On-site Cloud 253 +--------+ +-----------+ 254 | Pledge |----------------------------------------->| Cloud | 255 +--------+ | Registrar | 256 | +-----+-----+ 257 | | 258 | +-----------+ +-----+-----+ 259 +---------------->| Owner |---------------->| MASA | 260 | VR-sign(N) | Registrar |sign(VR-sign(N)) +-----------+ 261 | +-----------+ 262 | | +-----------+ 263 | +--->| CA | 264 | +-----------+ 265 | 266 | +-----------+ 267 +---------------->| Services | 268 +-----------+ 270 Figure 1: High Level Architecture 272 As depicted in Figure 1, there are a number of parties involve in the 273 process. The Manufacturer, or Original Equipment Maker (OEM) builds 274 the device, but also is expected to run the MASA, or arrange for it 275 to exist. 277 The network operator or enterprise is the intended owner of the new 278 device: the pledge. This could be the enterprise itself, or in many 279 cases there is some outsourced IT department that might be involved. 280 They are the operator of the Registrar or EST Server. They may also 281 operate the CA, or they may contract those services from another 282 entity. 284 Unlike in [BRSKI] there is a potential additional party involved, the 285 network integrator, who may operate the Cloud Registrar. This is 286 typically a value added reseller who works with the OEM to ship 287 products with the right configuration to the owner. For example, SIP 288 telephones or other conferencing systems may be installed by this 289 VAR, often shipped directly from a warehouse to the customer's remote 290 office location. The network integrator and manufacturer are aware 291 of which devices have been shipped to the integrator through sales 292 channel integrations, and so the manufacturer's Cloud Registrar is 293 able to redirect the pledge through a chain of Cloud Registrars, as 294 explained in Section 3.3.1. 296 2.1. Network Connectivity 298 The assumption is that the pledge already has network connectivity 299 prior to connecting to the Cloud Registrar. The pledge must have an 300 IP address that is able to make DNS queries, and be able to send HTTP 301 requests to the Cloud Registrar. There are many ways to accomplish 302 this, from routeable IPv4 or IPv6 addresses, to use of NAT44, to 303 using HTTP or SOCKS proxies. There are are DHCP options that a 304 network operator can configure to accomplish any of these options. 305 The pledge operator has already connected the pledge to the network, 306 and the mechanism by which this has happened is out of scope of this 307 document. For many telephony applications, this is typically going 308 to be a wired connection. For wireless use cases, some kind of 309 existing WiFi onboarding mechanism such as WPS. Similarly, what 310 address space the IP address belongs to, whether it is an IPv4 or 311 IPv6 address, or if there are firewalls or proxies deployed between 312 the pledge and the cloud registar are all out of scope of this 313 document. 315 2.2. Pledge Certificate Identity Considerations 317 BRSKI section 5.9.2 specifies that the pledge MUST send an EST 318 [RFC7030] CSR Attributes request to the Registrar. The Registrar MAY 319 use this mechanism to instruct the pledge about the identities it 320 should include in the CSR request it sends as part of enrollment. 321 The Registrar may use this mechanism to tell the pledge what Subject 322 or Subject Alternative Name identity information to include in its 323 CSR request. This can be useful if the Subject must have a specific 324 value in order to complete enrollment with the CA. 326 EST [RFC7030] is not clear on how the CSR Attributes response should 327 be structured, and in particular is not clear on how a server can 328 instruct a client to include specific attribute values in its CSR. 329 [I-D.ietf-lamps-rfc7030-csrattrs] clarifies how a server can use CSR 330 Attributes response to specify specific values for attributes that 331 the client should include in its CSR. 333 For example, the pledge may only be aware of its IDevID Subject which 334 includes a manufacturer serial number, but must include a specific 335 fully qualified domain name in the CSR in order to complete domain 336 ownership proofs required by the CA. 338 As another example, the Registrar may deem the manufacturer serial 339 number in an IDevID as personally identifiable information, and may 340 want to specify a new random opaque identifier that the pledge should 341 use in its CSR. 343 3. Protocol Operation 345 3.1. Pledge Requests Voucher from Cloud Registrar 347 3.1.1. Cloud Registrar Discovery 349 BRSKI defines how a pledge MAY contact a well-known URI of a Cloud Add section number - BRSKI, Section 2.7 350 Registrar if a local domain Registrar cannot be discovered. s/local domain Registrar/local Registrar/ - BRSKI does not say "domain Registar" (see below why this may be relevant). 351 Additionally, certain pledge types might never attempt to discover a 352 local domain Registrar and might automatically bootstrap against a 353 Cloud Registrar. 355 The details of the URI are manufacturer specific, with BRSKI giving 356 the example "brski-registrar.manufacturer.example.com". Add section number to reference (BRSKI, Appendix B.). 358 The Pledge SHOULD be provided with the entire URL of the Cloud 359 Registrar, including the path component, which is typically "/.well- 360 known/brski/requestvoucher", but may be another value. a) I think 347-356 summarizes/restates relevant text from BRSKI. But 358-360 does then introduce additional / new requirements. Hence it would be good to put a sentence that makes that clear before 358, e.g.: The following detail are added by this document: b) I would like to see a description like the following: For a local registrar to be useable by a pledge according to the procedures described in BRSKI, the discovered local registar needs to be an owner registrar for the pledge. Pledges supporting discovery of local registrars as well as cloud registar SHOULD perform discovery of a cloud registrar not only when they fail to find any local registrar, but also when they only discover local registrars that are not owners of the pledge - and thus fail enrolment by not being able or willing to present a valid voucher to the pledge. The order in which pleges perform discovery and probing of local registrars versus discovery of cloud registrar is a pledge manufacturer choice. When such pledges perform cloud registrar discovery and enrolment before they attempt local registrar discovery and enrolment, it is easier to avoid that pledges are enrolled into the wrong domain, such as when the MASA policy allows to issue vouchers purely based on ownership claims by registrars instead of sales integration. 362 3.1.2. Pledge - Cloud Registrar TLS Establishment Details 364 The pledge MUST use an Implicit Trust Anchor database (see EST 365 [RFC7030]) to authenticate the Cloud Registrar service. In order to 366 make use of a Cloud Registrar, the Pledge MUST be manufactured with 367 pre-loaded trust-anchors that are used to validate the TLS 368 connection. The TLS connection can be validated using a public Web 369 PKI trust anchors using [RFC6125] DNS-ID mechanisms, a pinned 370 certification authority, or even a pinned raw public key. This is a 371 local implementation decision. 373 The pledge MUST NOT establish a provisional TLS connection (see BRSKI 374 section 5.1) with the Cloud Registrar. Would read better if 373-374 was prepended before 364: The pledge MUST NOT establish a provisional TLS connection with the Cloud Registrar as described in BRSKI section 5.1. Instead ... the pledge MUST use an Implicit ... 376 The Cloud Registrar MUST validate the identity of the pledge by 377 sending a TLS CertificateRequest message to the pledge during TLS 378 session establishment. The Cloud Registrar MAY include a 379 certificate_authorities field in the message to specify the set of 380 allowed IDevID issuing CAs that pledges may use when establishing 381 connections with the Cloud Registrar. 383 The Cloud Registrar MAY only allow connections from pledges that have 384 an IDevID that is signed by one of a specific set of CAs, e.g. 385 IDevIDs issued by certain manufacturers. 387 The Cloud Registrar MAY allow pledges to connect using self-signed 388 identity certificates or using Raw Public Key [RFC7250] certificates. I have read area directors ranting about many MAY requirements where it is unclear why one would want to do the MAY because they run the risk of creating a large interoperability matrix that is hard to validate. Hence it is always useful to consider explaining when a MAY is useful, or even upgrade the MAY to a SHOULD with appropriate condition. For example, i have absolutely no idea about the MAY in 378, i am guessing this could help diagnostics on the pledge - which is always difficult, or the pledge could have multipled IDevID. But i would be surprised if the authors consider such a case. I have seen large equipment that has components from multiple vendors, so i could imagine such a case, and the sentence could then be "If the pledge is known by the manufacturer to potentially have multiple IDevID from different manufacturers, such as for different HW components, then the Cloud Registar SHOULD include ... In any case, it seems as if reordering the text might be helpful, e.g.: put 383-385 before 378-381. 390 3.1.3. Pledge Issues Voucher Request 392 After the pledge has established a full TLS connection with the Cloud 393 Registrar and has verified the Cloud Registrar PKI identity, the 394 pledge generates a voucher request message as outlined in BRSKI 395 section 5.2, and sends the voucher request message to the Cloud 396 Registrar. 398 3.2. Cloud Registrar Handles Voucher Request 400 The Cloud Registrar must determine pledge ownership. Prior to 401 ownership determination, the Registrar checks the request for 402 correctness and if it is unwilling or unable to handle the request, 403 it MUST return a suitable 4xx or 5xx error response to the pledge as 404 defined by [BRSKI] and HTTP. In the case of an unknown pledge a 404 405 is returned, for a malformed request 400 is returned, or in case of 406 server overload 503. 408 If the request is correct and the Registrar is able to handle it, but 409 unable to determine ownership, then it MUST return a 401 Unauthorized 410 response to the pledge. This signals to the Pledge that there is 411 currently no known owner domain for it, but that retrying later might 412 resolve this situation. The Registrar MAY also include a Retry-After 413 header that includes a time to defer. A pledge with some kind of 414 indicator (such as a screen or LED) SHOULD consider this an 415 onboarding failure, and indicate this to the operator. 417 If the Cloud Registrar successfully determines ownership, then it 418 MUST take one of the following actions: 420 * return a suitable 4xx or 5xx error response (as defined by [BRSKI] 421 and HTTP) to the pledge if the request processing failed for any 422 reason Its somewhat weird to re-read error conditions here again when they have been detailled in 402-406. One wonders if there are specific cases for which 420-422 exists that falls outside of 402-406. If there are such cases, it would be good to explain them. Otherwise, i would suggest to remove 420-422 and maybe just rewrite 417-418 to say If the Cloud Registrar successfully determines ownership and is willing and able to handle the request, then it must take one of the following actions: 424 * redirect the pledge to an owner register via 307 response code Add to end: See 3.2.2 for further details of this option. 426 * issue a voucher and return a 200 response code Add to end: See 3.2.3 for further details of this option. 428 3.2.1. Pledge Ownership Lookup 430 The Cloud Registrar needs some suitable mechanism for knowing the 431 correct owner of a connecting pledge based on the presented identity 432 certificate. For example, if the pledge establishes TLS using an 433 IDevID that is signed by a known manufacturing CA, the Registrar 434 could extract the serial number from the IDevID and use this to 435 lookup a database of pledge IDevID serial numbers to owners. 437 Alternatively, if the Cloud Registrar allows pledges to connect using 438 self-signed certificates, the Registrar could use the thumbprint of 439 the self-signed certificate to lookup a database of pledge self- 440 signed certificate thumbprints to owners. I think this 437-440 needs additional text following it: The mechanism by which the pledge identifies itself does not only need to be supported by the cloud registrar, but it also needs to be used by the pledge in the TLS authentication to the owner registrar if the redirection option is used. It hence needs to be supported by that owner registrar. BRSKI only specifies identification by IDevID with a meaningful serial number (see BRSKI 2.3.1). If you want to keep this thumbprint option here i think you need to include MAY against the cloud registrar and owner registrar supporting it. Or else IETF review would rightfully ask for it to go into appendix: Without an actual requirement, we can not guarantee interoperability between pledge pledge, cloud-registrar and owner registar when pledges want to use thumbprints. Alternatively, if you don't feel strong enough about this going up to at least MAY, move it into an appendix. 442 The mechanism by which the Cloud Registrar determines pledge 443 ownership is out-of-scope of this document. 445 3.2.2. Cloud Registrar Redirects to Owner Registrar 447 Once the Cloud Registrar has determined pledge ownership, the Cloud 448 Registrar MAY redirect the pledge to the owner Registrar in order to 449 complete bootstrap. Ownership registration will require the owner to 450 register their local domain. The mechanism by which pledge owners 451 register their domain with the Cloud Registrar is out-of-scope of 452 this document. I would remove the sentence "Ownership registration ..." - primarily because the overloading of "registration" is i think confusing to readers. Then in the sentence starting at 450, s/register/indicate/ to avoid this overloading of "register" completely. 454 In case of redirection, the Cloud Registrar replies to the voucher 455 request with a HTTP 307 Temporary Redirect response code, including 456 the owner's local domain in the HTTP Location header. 458 3.2.3. Cloud Registrar Issues Voucher 460 If the Cloud Registrar issues a voucher, it returns the voucher in a 461 HTTP response with a 200 response code. 463 The Cloud Registrar MAY issue a 202 response code if it is willing to 464 issue a voucher, but will take some time to prepare the voucher. 466 The voucher MUST include the "est-domain" field as defined in 467 [RFC8366bis]. This tells the pledge where the domain of the EST 468 service to use for completing certificate enrollment. 470 The voucher MAY include the "additional-configuration" field. This 471 points the pledge to a URI where application specific additional 472 configuration information may be retrieved. Pledge and Registrar 473 behavior for handling and specifying the "additional-configuration" 474 field is out-of-scope of this document. I guess IETF security experts may worry about the need for such an additional, vendor specific side-channel. A positive example would be nice and likely helpful. As a network operator i would primarily worry about the security/network-filtering aspects. If one for example uses MUD, then a dynamically received new URL with which the pledge needs to communicate would make the setup of filtering much more difficult (as the voucher is only inside a TLS connection). Aka. A requirement such as the following would make sense: If such a URI is a URL, it SHOULD have a well-known domain name such that networks using mechanisms like RFC8520 could accordingly permit communications to that URL. An IMHO useful example for additional configuration would be to state: IN one example, the URI could be a URN indicating pledge device parameters such as enabling licenses from the manufacturerfor specific pledge software functions. Overall, unless there is a good example why this additional configuration field is tied to a cloud registrar as opposed to just any voucher issued by any MASA, it might be better to move the text about additional configuration into a separate section of "Further voucher extensions" and write that the use of this field is not specific to vouchers issued by cloud registrar/MASA but applicable to any MASA issuing vouchers. 476 3.3. Pledge Handles Cloud Registrar Response 478 3.3.1. Redirect Response 480 The Cloud Registrar returned a 307 response to the voucher request. Maybe prepend: "In this option, " 482 The pledge SHOULD restart the process using a new voucher request 483 using the location provided in the HTTP redirect. Note if the pledge 484 is able to validate the new server using a trust anchor found in its 485 Implicit Trust Anchor database, then it MAY accept additional 307 486 redirects. 488 The pledge MUST never visit a location that it has already been to, 489 in order to avoid any kind of cycle. If it happens that a location 490 is repeated, then the pledge MUST fail the onboarding attempt and go 491 back to the beginning, which includes listening to other sources of 492 onboarding information as specified in [BRSKI] section 4.1 and 5.0. 493 The pledge MUST also have a limit on the number of redirects it will 494 a follow, as the cycle detection requires that it keep track of the ^ remove 495 places it has been. That limit MUST be in the dozens or more 496 redirects such that no reasonable delegation path would be affected. 498 The pledge MUST establish a provisional TLS connection with specified 499 local domain Registrar. The pledge MUST NOT use its Implicit Trust 500 Anchor database for validating the local domain Registrar identity. 501 The pledge MUST send a voucher request message via the local domain 502 Registrar. 504 After the pledge receives the voucher, it validates the TLS 505 connection to the local domain Registrar and continues with That registrar is most likely NOT a local domain Registar, or else we wouldn't have needed a cloud registar. Aka: it has to be an owner registar, but most likely it will be remote via the Internet. How about: s/it validates the TLS connection to the local domain Registrar/ /authenticates the TLS peer as an owner registar/ 506 enrollment and bootstrap as per standard BRSKI operation. 508 The pledge MUST process any error messages as defined in [BRSKI], and 509 in case of error MUST restart the process from its provisioned Cloud 510 Registrar. 512 The exception is that a 401 Unauthorized code SHOULD cause the Pledge 513 to retry a number of times over a period of a few hours. 515 3.3.2. Voucher Response 517 The Cloud Registrar returned a voucher to the pledge. The pledge Maybe prepend: "In this option, ". And start new paragraph befor "The pledge" to be consistent in style with 3.3.1. 518 SHOULD perform voucher verification as per standard BRSKI operation. 519 The pledge SHOULD verify the voucher signature using the 520 manufacturer-installed trust anchor(s), SHOULD verify the serial 521 number in the voucher, and SHOULD verify any nonce information in the 522 voucher. BRSKI 5.6.1 has all these steps with a MUST. If you want to downgrade to a SHOULD, i think you MUST provide some good reason for that. Otherwise i would recommend to remove and rewrite: After receiving the voucher, the pledge performs voucher verification according to BRSKI section 5.6.1. 524 The pledge SHOULD extract the "est-domain" field from the voucher, 525 and SHOULD continue with EST enrollment as per standard BRSKI 526 operation. I think 524 doesn't say a lot of things it should say. Here is what i think it should say: If the voucher contains the "est-domain" field, the pledge MUST open a new TLS connection to the indicated domain, perform TLS authentication against the voucher indicated trust anchor and perform all BRSKI EST enrollment steps against that EST server except for the voucher_status endpoint, which instead is still performed with the Cloud Registrar/MASA. See section 4.2 for the exact message flows. 528 4. Protocol Details In the following section, you are using often the term "Cloud RA" instead of "Cloud Registrar" without any definition or explanation as to what the difference is between a Clooud Registrar or a Cloud RA. If you want to keep the term Cloud RA, then please add it to the Terminology section. I would instead recommend to completely eliminate the term in this document and solely use the term Cloud Registrar. 530 4.1. Voucher Request Redirected to Local Domain Registrar 532 This flow illustrates the Owner Registrar Discovery flow. A pledge 533 is bootstrapping in a remote location with no local domain Registrar. s/local domain Registrar/local owner Registrar/ 534 The assumption is that the owner Registrar domain is accessible and s/domain// 535 the pledge can establish a network connection with the owner 536 Registrar. This may require that the owner network firewall exposes 537 the Registrar on the public internet. 539 +--------+ +----------+ 540 | Pledge | | Cloud RA | 541 | | | | 542 +--------+ +----------+ 543 | | 544 | 1. Mutual-authenticated TLS | 545 |<----------------------------------------------->| 546 | | 547 | 2. Voucher Request | 548 |------------------------------------------------>| 549 | | 550 | 3. 307 Location: owner-ra.example.com | 551 |<------------------------------------------------| 552 | 553 | +-----------+ +---------+ 554 | | Owner | | MASA | 555 | | Registrar | | | 556 | +-----------+ +---------+ 557 | 4. Provisional TLS | | 558 |<-------------------->| | 559 | | | 560 | 5. Voucher Request | | 561 |--------------------->| 6. Voucher Request | 562 | |------------------------->| 563 | | | 564 | | 7. Voucher Response | 565 | |<-------------------------| 566 | 8. Voucher Response | | 567 |<---------------------| | 568 | | | 569 | 9. Validate TLS | | 570 |<-------------------->| | 571 | | | 572 | 10. etc. | | 573 |--------------------->| | 575 The process starts, in step 1, when the Pledge establishes a Mutual 576 TLS channel with the Cloud RA using artifacts created during the s/artifacts/credentials/ (also further below). rfc8995 and other docs only use artifact for voucher, not for other credentials. Lets not start confusion on terminology now. 577 manufacturing process of the Pledge. 579 In step 2, the Pledge sends a voucher request to the Cloud RA. 581 The Cloud RA completes pledge ownership lookup as outlined in 582 Section 3.2.1, and determines the owner Registrar domain. In step 3, 583 the Cloud RA redirects the pledge to the owner Registrar domain. suggest to replace "domain" with URI, because that is what is in the Location: field of the 307. 585 Steps 4 and onwards follow the standard BRSKI flow. The pledge 586 establishes a provisional TLS connection with the owner Registrar, 587 and sends a voucher request to the owner Registrar. The Registrar 588 forwards the voucher request to the MASA. Assuming the MASA issues a 589 voucher, then the pledge validates the TLS connection with the 590 Registrar using the pinned-domain-cert from the voucher and completes 591 the BRSKI flow. 593 4.2. Voucher Request Handled by Cloud Registrar 595 The Voucher includes the EST domain to use for EST enroll. It is 596 assumed services are accessed at that domain too. As trust is 597 already established via the Voucher, the pledge does a full TLS 598 handshake against the local RA indicated by the voucher response. 595-598 duplicates what 600-603 writes as well. Suggest to remove 595-598 600 The returned voucher will contain the attribute "est-domain". The 601 pledge is directed to continue enrollment using the EST server found 602 at that URI. The pledge uses the pinned-domain-cert from the voucher 603 to authenticate the EST server. s/the/that/ 605 +--------+ +----------+ 606 | Pledge | | Cloud RA | 607 | | | / MASA | 608 +--------+ +----------+ 609 | | 610 | 1. Mutual TLS | 611 |<----------------------------------------------->| 612 | | 613 | 2. Voucher Request | 614 |------------------------------------------------>| 615 | | 616 | 3. Voucher Response {est-domain:fqdn} | 617 |<------------------------------------------------| RFC8366bis says the parameter is a URI, not an fqdn: s/fqdn/uri/ 618 | | 619 | +----------+ | 620 | | RFC7030 | | 621 | | EST | | 622 | | Server | | 623 | +----------+ | 624 | | | 625 | 4. Full TLS | | 626 |<-------------------->| | 627 | | 628 | 3a. /voucher_status POST success | 629 |------------------------------------------------>| 630 | ON FAILURE 3b. /voucher_status POST | 631 | | 632 | 5. EST Enrol | | 633 |--------------------->| | 634 | | | 635 | 6. Certificate | | 636 |<---------------------| | 637 | | | 638 | 7. /enrollstatus | | 639 |--------------------->| | I think /enrollstatus should also go to the Cloud Registrar/MASA as it is defined by BRSKI, not EST. And the text below should reflect this. 641 The process starts, in step 1, when the Pledge establishes a Mutual 642 TLS channel with the Cloud RA/MASA using artifacts created during the 643 manufacturing process of the Pledge. In step 2, the Pledge sends a 644 voucher request to the Cloud RA/MASA, and in response the Pledge 645 receives an [RFC8366] format voucher from the Cloud RA/MASA that 646 includes its assigned EST domain in the est-domain attribute. s/domain/URI/ 648 At this stage, the Pledge should be able to establish a TLS channel s/channel/connection/ 649 with the EST server. The connection may involve crossing the 650 Internet requiring a DNS lookup on the provided name. It may also be s/name/URI/ 651 a local address that includes an IP address literal including both 652 [RFC1918] and IPv6 Unique Local Address. The EST server is validated suggest to change sentence to: It may also be an address including an IP [RFC1918] local address or an IPv6 [RFC4193] Unique Local Address. 653 using the pinned-domain-cert value provided in the voucher as 654 described in [BRSKI] section 5.6.2. This involves treating the 655 artifact provided in the pinned-domain-cert as a trust anchor, and s/artifact/credential/ 656 attempting to validate the EST server from this anchor only. 658 There is a case where the pinned-domain-cert is the identical End- 659 Entity (EE) Certificate as the EST server. It also explicitly 660 includes the case where the EST server has a self-signed EE 661 Certificate, but it may also be an EE certificate that is part of a 662 larger PKI. If the certificate is not a self-signed or EE 663 certificate, ... I can not parse this. first you say there are self-signed EE certs and EE certs part of a larger PKI. Then you say if the cert is not self-signed or EE cert. "or EE cert" - non-self-signed ?? Huh ?? IMHO: If the certificate of the EST-server is self-signed, then the pinned-domain-cert in the voucher MUST be that certificate. If the certificate of the EST-server is signed by a private PKI, then the pinned-domain-cert can be the cert of the EST server or the cert that signed the EST-server cert. Self-signed or private PKI certificates are assumed not to have DNS-ID and hence [RFC6125] DNS-ID validation is not performed on them. For these certificate, the est-domain can also use literal IP addresses. 663 ... then the Pledge SHOULD apply [RFC6125] DNS-ID validation 664 on the certificate against the URL provided in the est-domain 665 attribute. If the est-domain was provided by with an IP address 666 literal, then it is unlikely that it can be validated, and in that 667 case, it is expected that either a self-signed certificate or an EE 668 certificate will be pinned. IMHO: If the certificate of the EST-server uses a WebPKI certificate, the pledge MUST apply [RFC6125] DNS-ID validation of it and it MUST match the domain privded in the est-domain URI. If the pinned-domain-certificate is present, DNS-ID validation MUST be performed against that pinned-domain-certficate. If the pipnned-domain-certificate is not present in the voucher, DNS-ID validation MUST be performed by the pledge against manufacturer installed WebPKI trust anchors. If DNS-ID validation of the EST server is used, the est-domain URI can not use literal IP addresses. I suggest to simply consider using the three paragraphs provided as IMHO. Note that RFC8366bis does not mention the above suggested option of falling back to manufacturer supplied WebPKI trust anchors when there is no pinned-domain-certificate. If you think that option is useful, we should also add that commentary text to the est-domain field in rfc8366bis. 670 The Pledge also has the details it needs to be able to create the CSR 671 request to send to the RA based on the details provided in the 672 voucher. 674 In step 4, the Pledge establishes a TLS channel with the Cloud RA/ 675 MASA, and optionally the pledge should send a request, steps 3.a and 676 3.b, to the Cloud RA/MASA to inform it that the Pledge was able to 677 establish a secure TLS channel with the EST server. 679 The Pledge then follows that, in step 5, with an EST Enroll request 680 with the CSR and obtains the requested certificate. The Pledge must 681 validate that the issued certificate has the expected identifier 682 obtained from the Cloud RA/MASA in step 3. Which identifier ? Please rewrite sentence. Unclear which identifier is meant. Also: Please add sentence about /enrolstatus. 684 5. YANG extension for Voucher based redirect 686 [RFC8366bis] contains the two needed voucher extensions: est-domain 687 and additional-configuration which are needed when a client is 688 redirected to a local EST server. 690 6. IANA Considerations 692 This document makes no IANA requests. 694 7. Security Considerations 696 The Cloud Registrar described in this document inherits all of the s/all of the// not true, see below ;-) 697 issues that are described in [BRSKI]. This includes dependency upon 698 continued operation of the manufacturer provided MASA, as well as 699 potential complications where a manufacturer might interfere with 700 resale of a device. Suggest to add: In BRSKI, local registrars may simply assert ownership of pledges if a MASA permit this. It allows lightweight ownership models purely based on pledges connecting to the network of an owner, but without prior ownership knowledge by the MASA. The audit log can later allow to track prior or potentially false ownership claims. The security model for this option is: If i can prove that i can connect the device to my network, that suffices to claim ownership. When Cloud Registrar is used, it is not possible to exactly replicate this lightweight ownership "claim" model because the required local owner registar infrastructure does not exist. The mechanisms by which an owner has to assert ownership with the VAR/manufacturer are out of scope of BRSKI cloud, but they are a prerequisitefor BRSKI cloud to function, Any such mechanism needs to be aware of the significant attack opportunity against pledges if such a mechanism would allow to claim ownership of pledges solely by for example guessing or learning their IDevID's serial number or any other identifier that is not protected from spoofing by malicious observers. 702 In addition to the dependency upon the MASA, the successful 703 enrollment of a device using a Cloud Registrar depends upon the 704 correct and continued operation of this new service. This internet 705 accessible service may be operated by the manufacturer and/or by one 706 or more value-added-resellers. All of the considerations for 707 operation of the MASA also apply to operation of the Cloud Registrar. 709 7.1. Issues with Security of HTTP Redirect 711 If the Redirect to Registrar method is used, as described in 712 Section 4.1, there may be a series of 307 redirects. An example of 713 why this might occur is that the manufacturer only knows that it 714 resold the device to a particular value added reseller (VAR), and 715 there may be a chain of such VARs. It is important the pledge avoid 716 being drawn into a loop of redirects. This could happen if a VAR 717 does not think they are authoritative for a particular device. A 718 "helpful" programmer might instead decide to redirect back to the 719 manufacturer in an attempt to restart at the top: perhaps there is 720 another process that updates the manufacturer's database and this 721 process is underway. Instead, the VAR MUST return a 404 error if it 722 cannot process the device. This will force the device to stop, 723 timeout, and then try all mechanisms again. 725 There is another case where a connection problem may occur: when the 726 pledge is behind a captive portal or an intelligent home gateway that 727 provides access control on all connections. Captive portals that do 728 not follow the requirements of [RFC8952] section 1 may forcibly 729 redirect HTTPS connections. While this is a deprecated practice as 730 it breaks TLS in a way that most users can not deal with, it is still 731 common in many networks. 733 On the first connection, the incorrect connection will be discovered 734 because the Pledge will be unable to validate the connection to its 735 Cloud Registrar via DNS-ID. That is, the certificate returned from 736 the captive portal will not match. 738 At this point a network operator who controls the captive portal, 739 noticing the connection to what seems a legitimate destination (the 740 Cloud Registrar), may then permit that connection. This enables the 741 first connection to go through. 743 The connection is then redirected to the Registrar, either via 307, 744 or via est-domain in a voucher. If it is a 307 redirect, then a 745 provisional TLS connection will be initiated, and it will succeed. 746 The provisional TLS connection does not do [RFC6125] DNS-ID 747 validation at the beginning of the connection, so a forced 748 redirection to a captive portal system will not be detected. The 749 subsequent BRSKI POST of a voucher will most likely be met by a 404 750 or 500 HTTP code. As the connection is provisional, the pledge will 751 be unable to determine this. 753 It is RECOMMENDED therefore that the pledge look for [RFC8910] 754 attributes in DHCP, and if present, use the [RFC8908] API to learn if 755 it is captive. This is all good stuff, but i am not so sure it fits into security considerations. Security considerations should discuss attack vectors, but the above is more about implementation considerations for complex cases. You could prepend the text with: The complexities of HTTP redirect may lead to possible attack vectors if misbehavior can be injected. The following outlines important aspects for performing HTTP redirects. Or else move this all into a separate section and just point to it with a sentence like that. 757 7.2. Security Updates for the Pledge 759 Unlike many other uses of BRSKI, in the Cloud Registrar case it is 760 assumed that the Pledge has connected to a network on which there is 761 addressing and connectivity, but there is no other local s/addressing and connectivity/Internet addressing and connectivity/ ?? 762 configuration available. 764 There is another advantage to being online: the pledge may be able to 765 contact the manufacturer before onboarding in order to apply the 766 latest firmware updates. This may also include updates to the 767 Implicit list of Trust Anchors. In this way, a Pledge that may have 768 been in a dusty box in a warehouse for a long time can be updated to 769 the latest (exploit-free) firmware before attempting onboarding. No change request here, just two rants: a) Ask me, and i am happy to give a rant about how to brick devices with automatic firmware updates;-) b) More importantly though: I am not sure if SUIT has defined anything for this, but firmware updates SHOULD NOT be a reason to force Internet connectivity. secure environments might prefer to have local copies of authentic vendor firmware updates. 771 7.3. Trust Anchors for Cloud Registrar 773 The Implicit TA database is used to authenticate the Cloud Registrar. 774 This list is built-in by the manufacturer along with a DNS name to 775 which to connect. (The manufacturer could even build in IP addresses 776 as a last resort) remove parenthesis. The text is worth a normal sentence. 778 The Cloud Registrar does not have a certificate that can be validated s/does not have/does not need to have/ 779 using a public (WebPKI) anchor. The pledge may have any kind of 780 Trust Anchor built in: from full multi-level WebPKI to the single 781 self-signed certificate used by the Cloud Registrar. There are many 782 tradeoffs to having more or less of the PKI present in the Pledge, 783 which is addressed in part in 784 [I-D.irtf-t2trg-taxonomy-manufacturer-anchors] in sections 3 and 5. 786 7.4. Issues with Redirect via Voucher 788 The second redirect case is handled by returning a special extension 789 in the voucher. The Cloud Registrar actually does all of the voucher 790 processing as specified in [BRSKI]. In this case, the Cloud 791 Registrar may be operated by the same entity as the MASA, and it 792 might even be combined into a single server. Whether or not this is 793 the case, it behaves as if it was separate. 795 It may be the case that one or more 307-Redirects have taken the 796 Pledge from the built-in Cloud Registrar to one operated by a VAR. 798 When the Pledge is directed to the owner [RFC7030] Registrar, the 799 Pledge validates the TLS connection with this server using the s/validates/can validate/ - depending on prior discussion whether or not you do want the DNS-ID validation option or not. 800 "pinned-domain-cert" attribute in the voucher. There is no 801 provisional TLS connection, and therefore there are no risks 802 associated with being behind a captive portal. 804 Acknowledgements 806 The authors would like to thank for following for their detailed 807 reviews: (ordered by last name): Esko Dijk, Sheng Jiang. 809 References 811 Normative References 813 [BRSKI] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 814 and K. Watsen, "Bootstrapping Remote Secure Key 815 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, 816 May 2021, <https://www.rfc-editor.org/info/rfc8995>. 818 [I-D.ietf-lamps-rfc7030-csrattrs] 819 Richardson, M., Friel, O., von Oheimb, D., and D. Harkins, 820 "Clarification of RFC7030 CSR Attributes definition", Work 821 in Progress, Internet-Draft, draft-ietf-lamps-rfc7030- 822 csrattrs-06, 1 August 2023, 823 <https://datatracker.ietf.org/doc/html/draft-ietf-lamps- 824 rfc7030-csrattrs-06>. 826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 827 Requirement Levels", BCP 14, RFC 2119, 828 DOI 10.17487/RFC2119, March 1997, 829 <https://www.rfc-editor.org/info/rfc2119>. 831 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 832 "Enrollment over Secure Transport", RFC 7030, 833 DOI 10.17487/RFC7030, October 2013, 834 <https://www.rfc-editor.org/info/rfc7030>. 836 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 837 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 838 May 2017, <https://www.rfc-editor.org/info/rfc8174>. 840 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 841 "A Voucher Artifact for Bootstrapping Protocols", 842 RFC 8366, DOI 10.17487/RFC8366, May 2018, 843 <https://www.rfc-editor.org/info/rfc8366>. 845 [RFC8366bis] 846 Watsen, K., Richardson, M., Pritikin, M., Eckert, T. T., 847 and Q. Ma, "A Voucher Artifact for Bootstrapping 848 Protocols", Work in Progress, Internet-Draft, draft-ietf- 849 anima-rfc8366bis-10, 22 August 2023, 850 <https://datatracker.ietf.org/doc/html/draft-ietf-anima- 851 rfc8366bis-10>. 853 Informative References 855 [I-D.irtf-t2trg-taxonomy-manufacturer-anchors] 856 Richardson, M., "A Taxonomy of operational security 857 considerations for manufacturer installed keys and Trust 858 Anchors", Work in Progress, Internet-Draft, draft-irtf- 859 t2trg-taxonomy-manufacturer-anchors-02, 6 August 2023, 860 <https://datatracker.ietf.org/doc/html/draft-irtf-t2trg- 861 taxonomy-manufacturer-anchors-02>. 863 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 864 J., and E. Lear, "Address Allocation for Private 865 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, 866 February 1996, <https://www.rfc-editor.org/info/rfc1918>. 868 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 869 Verification of Domain-Based Application Service Identity 870 within Internet Public Key Infrastructure Using X.509 871 (PKIX) Certificates in the Context of Transport Layer 872 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 873 2011, <https://www.rfc-editor.org/info/rfc6125>. 875 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 876 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 877 Transport Layer Security (TLS) and Datagram Transport 878 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 879 June 2014, <https://www.rfc-editor.org/info/rfc7250>. 881 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero 882 Touch Provisioning (SZTP)", RFC 8572, 883 DOI 10.17487/RFC8572, April 2019, 884 <https://www.rfc-editor.org/info/rfc8572>. 886 [RFC8908] Pauly, T., Ed. and D. Thakore, Ed., "Captive Portal API", 887 RFC 8908, DOI 10.17487/RFC8908, September 2020, 888 <https://www.rfc-editor.org/info/rfc8908>. 890 [RFC8910] Kumari, W. and E. Kline, "Captive-Portal Identification in 891 DHCP and Router Advertisements (RAs)", RFC 8910, 892 DOI 10.17487/RFC8910, September 2020, 893 <https://www.rfc-editor.org/info/rfc8910>. 895 [RFC8952] Larose, K., Dolson, D., and H. Liu, "Captive Portal 896 Architecture", RFC 8952, DOI 10.17487/RFC8952, November 897 2020, <https://www.rfc-editor.org/info/rfc8952>. 899 [RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An 900 Autonomic Control Plane (ACP)", RFC 8994, 901 DOI 10.17487/RFC8994, May 2021, 902 <https://www.rfc-editor.org/info/rfc8994>. 904 Authors' Addresses 906 Owen Friel 907 Cisco 908 Email: ofr...@cisco.com 910 Rifaat Shekh-Yusef 911 Auth0 912 Email: rifaat.s.i...@gmail.com 914 Michael Richardson 915 Sandelman Software Works 916 Email: mcr+i...@sandelman.ca _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
