[Anima] Review draft-ietf-anima-brski-cloud-08

Toerless Eckert <tte@cs.fau.de> Mon, 04 December 2023 21:34 UTC

Date: Mon, 04 Dec 2023 22:34:10 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: anima@ietf.org, anima-chairs@ietf.org, draft-ietf-anima-brski-cloud@ietf.org
Message-ID: <ZW5F0r4qRi8F3cLJ@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/QsJv_CmcPoO6CTSgjYbRi6ZKvtM>
Subject: [Anima] Review draft-ietf-anima-brski-cloud-08
Precedence: list

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

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: ofriel@cisco.com

910 Rifaat Shekh-Yusef
911 Auth0
912 Email: rifaat.s.ietf@gmail.com

914 Michael Richardson
915 Sandelman Software Works
916 Email: mcr+ietf@sandelman.ca

[Anima] Review draft-ietf-anima-brski-cloud-08 Toerless Eckert
Re: [Anima] Review draft-ietf-anima-brski-cloud-08 Michael Richardson
Re: [Anima] Review draft-ietf-anima-brski-cloud-08 Toerless Eckert
Re: [Anima] Review draft-ietf-anima-brski-cloud-08 Michael Richardson
Re: [Anima] Review draft-ietf-anima-brski-cloud-08 Toerless Eckert
Re: [Anima] Review draft-ietf-anima-brski-cloud-08 Michael Richardson