Given how we didn't have the time to pass the document on so far, please find
attached my editorial review of the document. I think its in very good
functional
description state, but the lange gould be improved via the suggestions i made
Thanks a lot
Toerless
On Thu, Dec 01, 2022 at 09:43:30AM +0800, Sheng JIANG wrote:
> During the WGLC period, this drafts has received no objections, but comments,
> particularly for editional issues. Therefore, the chairs would draw on
> conclusiong on a conditional pass. The authors should make a thoroughly
> editional check, particularly suggestion from Brian and Esko. The chairs
> would check it with them after the authors made an update version. Till it
> meet the condition, the chairs would push it forward.
>
>
> Regards,
>
>
> Sheng
>
> ------------------ Original ------------------
> From: "Sheng JIANG"<[email protected]>;
> Date: Mon, Nov 14, 2022 10:50 AM
> To:
>
> Subject: WGLC for draft-ietf-anima-brski-cloud-05, ends Nov. 28th, 2022
>
>
> Dear ANIMAers,
>
> This message starts the two-week (*) ANIMA Working Group Last Call to advance
> draft-ietf-anima-brski-cloud-05, which specifies the behavior of a BRSKI
> Cloud Registrar, and how a pledge can interact with a BRSKI Cloud Registrar
> when bootstrapping.
>
> This document's intended status is Standards Track.
> At present, there is no IPR filed against this document.This document has
> been ANIMA WG document since May, 2021 and has received a lot of feedback
> from the WG and work from its authors. The authors therefore think is ready
> for WGLC.
> Please send your comments by Nov. 28th 2022. If you do not feel this document
> should advance, please state your reasons why.Sheng Jiang is now the document
> shepherd.
>
> Regards,
>
>
> Sheng
--
---
[email protected]
Line number are from idnits 2.17.1
draft-ietf-anima-brski-cloud-05.txt:
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
== Unused Reference: 'IEEE802.1AR' is defined on line 913, but no explicit
reference was found in the text
-- Duplicate reference: RFC7030, mentioned in 'RFC7030', was also mentioned
in 'EST'.
2 Network Working Group O. Friel
3 Internet-Draft Cisco
4 Intended status: Standards Track R. Shekh-Yusef
5 Expires: 17 May 2023 Auth0
6 M. Richardson
7 Sandelman Software Works
8 13 November 2022
10 BRSKI Cloud Registrar
11 draft-ietf-anima-brski-cloud-05
13 Abstract
15 This document specifies the behavior of a BRSKI Cloud Registrar, and
16 how a pledge can interact with a BRSKI Cloud Registrar when
17 bootstrapping.
If you can, add an explanation what the core aspects of a Cloud Registrar
are for tthe purpose of this document... discovery ? untrusted connection,.... ?
19 RFCED REMOVE: It is being actively worked on at https://github.com/
20 anima-wg/brski-cloud
22 Status of This Memo
24 This Internet-Draft is submitted in full conformance with the
25 provisions of BCP 78 and BCP 79.
27 Internet-Drafts are working documents of the Internet Engineering
28 Task Force (IETF). Note that other groups may also distribute
29 working documents as Internet-Drafts. The list of current Internet-
30 Drafts is at https://datatracker.ietf.org/drafts/current/.
32 Internet-Drafts are draft documents valid for a maximum of six months
33 and may be updated, replaced, or obsoleted by other documents at any
34 time. It is inappropriate to use Internet-Drafts as reference
35 material or to cite them other than as "work in progress."
37 This Internet-Draft will expire on 17 May 2023.
39 Copyright Notice
41 Copyright (c) 2022 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents (https://trustee.ietf.org/
46 license-info) in effect on the date of publication of this document.
47 Please review these documents carefully, as they describe your rights
48 and restrictions with respect to this document. Code Components
49 extracted from this document must include Revised BSD License text as
50 described in Section 4.e of the Trust Legal Provisions and are
51 provided without warranty as described in the Revised BSD License.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
57 1.2. Target Use Cases . . . . . . . . . . . . . . . . . . . . 3
58 1.2.1. Owner Registrar Discovery . . . . . . . . . . . . . . 4
59 1.2.2. Bootstrapping with no Owner Registrar . . . . . . . . 4
60 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
61 2.1. Interested Parties . . . . . . . . . . . . . . . . . . . 6
62 2.2. Network Connectivity . . . . . . . . . . . . . . . . . . 6
63 2.3. Pledge Certificate Identity Considerations . . . . . . . 6
64 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7
65 3.1. Pledge Requests Voucher from Cloud Registrar . . . . . . 7
66 3.1.1. Cloud Registrar Discovery . . . . . . . . . . . . . . 7
67 3.1.2. Pledge - Cloud Registrar TLS Establishment Details . 7
68 3.1.3. Pledge Issues Voucher Request . . . . . . . . . . . . 8
69 3.2. Cloud Registrar Handles Voucher Request . . . . . . . . . 8
70 3.2.1. Pledge Ownership Lookup . . . . . . . . . . . . . . . 8
71 3.2.2. Cloud Registrar Redirects to Owner Registrar . . . . 9
72 3.2.3. Cloud Registrar Issues Voucher . . . . . . . . . . . 9
73 3.3. Pledge Handles Cloud Registrar Response . . . . . . . . . 9
74 3.3.1. Redirect Response . . . . . . . . . . . . . . . . . . 9
75 3.3.2. Voucher Response . . . . . . . . . . . . . . . . . . 10
76 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 10
77 4.1. Voucher Request Redirected to Local Domain Registrar . . 10
78 4.2. Voucher Request Handled by Cloud Registrar . . . . . . . 12
79 5. YANG extension for Voucher based redirect . . . . . . . . . . 14
80 5.1. YANG Tree . . . . . . . . . . . . . . . . . . . . . . . . 14
81 5.2. YANG Voucher . . . . . . . . . . . . . . . . . . . . . . 15
82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
83 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 17
84 6.2. The YANG Module Names Registry . . . . . . . . . . . . . 17
85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
86 7.1. Issues with Security of HTTP Redirect . . . . . . . . . . 18
87 7.2. Security Updates for the Pledge . . . . . . . . . . . . . 19
88 7.3. Trust Anchors for Cloud Registrar . . . . . . . . . . . . 19
89 7.4. Issues with Redirect via Voucher . . . . . . . . . . . . 20
90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
91 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
92 8.2. Informative References . . . . . . . . . . . . . . . . . 21
93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
95 1. Introduction
97 Bootstrapping Remote Secure Key Infrastructures [BRSKI] specifies
98 automated bootstrapping of an Autonomic Control Plane. BRSKI
Suggest to replace after BRSKI with:
... BRSKI specifies automated and secure provisioning of nodes (which are
called pledges)
with cryptographic keying material (trust anchors and certificates) to enable
authenticated and
confidential communication with other similarily enrolled nodes. This is also
called enrolment.
No need to mention Autonomic Control Plane here IMHO (just sounds like limiting
scope
of BRSKI Cloud).
If you really want folks to understand what is happening here, i suggest to
include explanations such as the following.
In BRSKI, the pledge performs enrolment by communicating with a BRSKI Registrar
belonging to the domain that provides the cryptopgraphic keying material and
usually is or acts upon the owner of the pledge. The pledge does not know
who its owner is. Insted, in BRSKI it is assumed that the network to which the
pledge connects belongs to the owner of the pledge and therefore
network-supported
discovery mechanisms can resolve generic, non-owner specific names to the
owners Registrar.
To support enrolment of pledges without such an owner based access network, the
mechanisms
of BRSKI Cloud are required which assume that Pledge and Registrar simply
connect to the
Internet. The Internet ("Cloud") connected Registrar will then determine
ownership of the Pledge
and redirect the Plege to its owners Registar.
99 Section 2.7 describes how a pledge "MAY contact a well-known URI of a
100 cloud registrar if a local registrar cannot be discovered or if the
101 pledge's target use cases do not include a local registrar".
I would remove parenthesis and lowercase the MAY. No need for this formalism to
expose
your internal repetition of sentence. This is still introduction, repetition is
perfectly fine.
103 This document further specifies use of a BRSKI cloud registrar and
104 clarifies operations that are not sufficiently specified in BRSKI.
106 1.1. Terminology
108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
110 "OPTIONAL" in this document are to be interpreted as described in
111 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
112 capitals, as shown here.
114 This document uses the terms Pledge, Registrar, MASA, and Voucher
115 from [BRSKI] and [RFC8366].
117 * Local Domain: The domain where the pledge is physically located
118 and bootstrapping from. This may be different to the pledge
119 owner's domain.
121 * Owner Domain: The domain that the pledge needs to discover and
122 bootstrap with.
124 * Cloud Registrar: The default Registrar that is deployed at a URI
125 that is well known to the pledge.
127 * Owner Registrar: The Registrar that is operated by the Owner, or
128 the Owner's delegate. There may not be an Owner Registrar in all
129 deployment scenarios.
131 * Local Domain Registrar: The Registrar discovered on the Local
132 Domain. There may not be a Local Domain Registrar in all
133 deployment scenarios.
Isn't one core aspect of interest (which should be discussed in the text),
that the pledge does discover a Registar locally, but its not of its owner ?
135 1.2. Target Use Cases
137 Two high level use cases are documented here. There are more details
This document specifies and standardizes procedures for two high level use
cases.
(use case documentation is fine, but the beef of standard tracks RFCs is the
specification of
standardized procedures).
138 provided in sections Section 4.1 and Section 4.2. While both use
139 cases aid with incremental deployment of BRSKI infrastructure, for
140 many smaller sites (such as teleworkers) no further infrastructure
141 are expected.
Last sentence is not correct english and reads weird. How about:
Common to both uses cases is that they aid with the use of BRSKI
in the presence of many small sites (such as teleworkers) with minimum
expectations against their network infrastructure.
143 The pledge is not expected to know which of these two situations it
144 is in. The pledge determines this based upon signals that it
145 receives from the Cloud Registrar. The Cloud Registrar is expected
rephrase/explain: "determines this" -> determines what ? which of the two cases
?
146 to make the determination based upon the identity presented by the
147 pledge.
rephrase/explain: make determination of what ?
149 While a Cloud Registrar will typically handle all the devices of a
150 particular product line from a particular manufacturer there are no
151 restrictions on how the Cloud Registrar is horizontally (many sites)
152 or vertically (more equipment at one site) scaled. It is also
This is very hard to grasp if you did not know in before what the paragraph
means to confer. I hope i get it right. How about:
A Cloud Registrar will receive BRSKI communications from all devices configured
with its URI. This could (for example) all devices of a particular product line
from
a particular manufacturer. When this is a significantly large number, a Cloud
Registrar may need to be scaled with the usual web-service scaling mechansisms.
(btw: This is useful text, i am just not sure if its best positioned here
upfront. I would prefer if this was a detail explained later because i don't
feel its so super important or non-obvious).
Insert new paragraph after sentence because you're starting a completely new
piece of information following.
152 or vertically (more equipment at one site) scaled. It is also
153 entirely possible that all devices sold by through a particular VAR
^^^^^^^^^^
154 might be preloaded with a configuration that changes the Cloud
155 Registrar URL to point to a VAR. Such an effort would require
156 unboxing each device in a controlled environment, but the
157 provisioning could occur using a regular BRSKI or SZTP [RFC8572]
158 process.
I think VAR is an unnecessary term and the whole paragraph is somewhat
confusing.
If i understand it correctly, the core argument is like this:
The procedures specified in this document are an alternative to mechanisms
possible with just BRSKI to reduce operational cost.
Consider pledges are to be enrolled when being connected solely to the
Internet, but no owner based network. Likewise, the Registar is assumed to be
only connected to the Internet. The challenge in this case is for the pledge to
discover a URI for the Oners Registar. In the absence of the procdures described
in this doument, BRSKI could be used, but the pledge would need to be
pre-staged with that URI. In one instance, the seller of the pledge could
attach to the shipment of the pledge a USB stick pre-populated with a file
containing that Owner Registar URI, and that USB stick would need to be
inserted into the pledge to enavble enrolment. This is but one option,
and compared to similar alternatives, it does not require
unpacking/configuration/repackaging
of the pledge at the sellers site, but only configuration of a USB stick
Yada yada... i really don't know how to make this shorter without looking
readers
who do not live & breathe this stuff, so it probably is all better suited to be
put later into the document and only put a pointer to such a chapter here into
the
Introduction.
160 1.2.1. Owner Registrar Discovery
See also note in 1.2.2 - i would suggest "Bootstrap via Cloud Registrar and
Owner Registrar" as better title
162 A pledge is bootstrapping from a remote location with no local domain
You didn't define remote location.
163 registrar (specifically: with no local infrastructure to provide for
164 automated discovery), and needs to discover its owner registrar. The
165 cloud registrar is used by the pledge to discover the owner
166 registrar. The cloud registrar redirects the pledge to the owner
167 registrar, and the pledge completes bootstrap against the owner
168 registrar.
170 A typical example is an enduser deploying a pledge in a home or small
s/enduser/employee who is/
171 branch office, where the pledge belongs to the enduser's employer.
s/enduser's employer/employer/
172 There is no local domain registrar, and the pledge needs to discover
173 and bootstrap with the employer's registrar which is deployed in
174 headquarters. For example, an enduser is deploying an IP phone in a
175 home office and the phone needs to register to an IP PBX deployed in
...needs the keying material from BRSKI to register..
176 their employer's office.
178 1.2.2. Bootstrapping with no Owner Registrar
How about Bootstrapping from via "Cloud Registrar and Owner EST-Server"
180 A pledge is bootstrapping where the owner organization does not yet
^^^
181 have an owner registrar deployed. The cloud registrar issues a
^
... but it has an [RFC7030] EST-Server for enrolment of pledges.
(aka: pull up this sentence here, because later in the paagraph it reads weird.
182 voucher, and the pledge completes trust bootstrap using the cloud
183 registrar. The voucher issued by the cloud includes domain
184 information for the owner's [EST] service the pledge should use for
185 certificate enrollment.
I should have tried to understand this earlier ;-), but i really like this
case. WOuld love to see the following type of explanation here:
This option can be used to introduce the benefits of BRSKI for an initial
period when BRSKI is not available in existing EST-Servers. But it can also
be used long-term as an security-equivalent solution in which BRSKI and
EST-Server are set up in a modular fashion.
Would also suggest to add:
The use of an EST-Server instead of a BRSKI Registrar may mean that
not all the EST options required by [BRSKI] may be available and hence
this option may not support all BRSKI deployment cases. For example,
certificates to enroll into an ACP [RFC8994] needs to include an
AcpNodeName (see [RFC8994], Section 6.2.2), which non-BRSKI capable EST-Servers
ma not support.
At this point in the doc you need to insert 1.2.3 Summary
187 In one use case, an organization has an EST service deployed, but
188 does not have yet a BRSKI capable Registrar service deployed. The
189 pledge is deployed in the organization's domain, but does not
190 discover a local domain, or owner, registrar. The pledge uses the
191 cloud registrar to bootstrap, and the cloud registrar provides a
192 voucher that includes instructions on finding the organization's EST
193 service.
195 2. Architecture
197 The high level architecture is illustrated in Figure 1.
199 The pledge connects to the cloud registrar during bootstrap.
201 The cloud registrar may redirect the pledge to an owner registrar in
202 order to complete bootstrap against the owner registrar.
s/against/with/
204 If the cloud registrar issues a voucher itself without redirecting
205 the pledge to an owner registrar, the cloud registrar will inform the
206 pledge what domain to use for accessing EST services in the voucher
207 response.
These two paragrapsh need to be specifically referring to which of the section 1
mentioned use cases they are. Aka: in case of 1.2.2 ..., In case of 1.2.2...
209 Finally, when bootstrapping against an owner registrar, this
210 registrar may interact with a backend CA to assist in issuing
211 certificates to the pledge. The mechanisms and protocols by which
212 the registrar interacts with the CA are transparent to the pledge and
213 are out-of-scope of this document.
"will interact with a CA" (aka: i don't think we hacve a case where a CA is not
involved,
but no need to express opinion about where it's located "backend..."
superflous).
More importantly: This paragraph applies to both owner registar and owner
EST-Server,
rewrite all occurrances within paragraph to cover both cases.
(i think...!)
215 The architecture shows the cloud registrar and MASA as being
216 logically separate entities. The two functions could of course be
217 integrated into a single service.
s/single service/single entity/
(much as the owner registrar and CA could be integrated into a single entity).
219 TWO CHOICES: 1. Cloud Registrar redirects to Owner Registrar 2.
220 Cloud Registrar returns VOUCHER pinning Owner Register.
This paragraph comes totall unexpected without context. Pinning is unexplained.
Maybe less ternse explanation here.
222 |<--------------OWNER------------------------>| MANUFACTURER
224 On-site Cloud
225 +--------+ +-----------+
226 | Pledge |---------------------------------------->| Cloud |
227 +--------+ | Registrar |
228 | +---+ +----+
229 | |??|
230 | +-----------+ +---+ +----+
231 +---------------->| Owner |--------------->| MASA |
232 | VR-sign(N) | Registrar |sign(VR-sign(N))+-----------+
233 | +-----------+
234 | | +-----------+
235 | +--->| CA |
236 | +-----------+
237 |
238 | +-----------+
239 +---------------->| Services |
240 +-----------+
242 Figure 1: High Level Architecture
This picture does not show the EST-Server option. Gap ?!
What is "Services" ??
The end-to-end lines look like explicit connections. This is confiusing.
Maybe the connections can be repainted in two ways:
1. replace lines with just some "Internet" in the middle with some dotted
lines from each box connecting to it.
Then insert some rough lines, e.g.:
<--(1) cloud register--->
between Pledge and Cloud Registar
<--(2) VR-sign(N)--->
<--(3) sign(VR-sign(N))-->
Finally, you should add a paragraph with text explaining what the picture shows.
For example saying that all nodes only need to connect over the Internet, and
that it shows the three high-level stages of communication (1) (2), (3)
jut roughly so readers understand it.
244 2.1. Interested Parties
246 1. OEM - Equipment manufacturer. Operate the MASA.
The rest of the document does not use the term OEM. Delete
248 2. Network operator. Operate the Owner Registrar. Often operated
249 by end owner (company), or by outsourced IT entity.
This is only used twice below and the second time its not clear its the same
operator.
251 3. Network integrator. They operate a Cloud Registrar.
You never use the term Network integrator in the rest of the document. Delete
Aka: This whole section doesn't make sense unless you add some more explanation
(but likely it can just go).
253 2.2. Network Connectivity
255 The assumption is that the pledge already has network connectivity
256 prior to connecting to the cloud registrar. The pledge must have an
257 IP address, must be able to make DNS queries, and must be able to
258 send HTTP requests to the cloud registrar. The pledge operator has
I would remove the "able to send HTTP requests" as this opens a rathole of
questions re. HTTP and mutual authentication, which are just resolved later in
the doc.
259 already connected the pledge to the network, and the mechanism by
"The peldge is already connected to the network" ("plege operator" is not a good
term when yo think of employee/enduser... IMHO, i'd avoid it).
260 which this has happened is out of scope of this document.
There are power cables and strange sockets... kidding.
262 2.3. Pledge Certificate Identity Considerations
264 BRSKI section 5.9.2 specifies that the pledge MUST send an EST
265 [RFC7030] CSR Attributes request to the registrar. The registrar MAY
which registrar - cloud or owner ?
266 use this mechanism to instruct the pledge about the identities it
267 should include in the CSR request it sends as part of enrollment.
268 The registrar may use this mechanism to tell the pledge what Subject
269 or Subject Alternative Name identity information to include in its
270 CSR request. This can be useful if the Subject must have a specific
271 value in order to complete enrollment with the CA.
So... In case of using an owner EST-Server instead of the Owner BRSKI
Registrar, this paragraph seems to hint at the option that the pledge
does the CSR Attribute request so that the Cloud registrar provides this
information because the EST-Server may not ? That should be said more
explicitly.
For the case of Cloud and Owner Registrar it seems that the CSR attr request
could also be sent to the cloud registrar, but also to owner registrar.
Should both be sent ?? Be more explicit please.
273 EST [RFC7030] is not clear on how the CSR Attributes response should
274 be structured, and in particular is not clear on how a server can
275 instruct a client to include specific attribute values in its CSR.
276 [I-D.richardson-lamps-rfc7030-csrattrs] clarifies how a server can
277 use CSR Attributes response to specify specific values for attributes
278 that the client should include in its CSR.
This is now IETF draft draft-ietf-lamps-rfc7030-csrattrs, fi up reference.
Also make this normative reference.
280 For example, the pledge may only be aware of its IDevID Subject which
281 includes a manufacturer serial number, but must include a specific
282 fully qualified domain name in the CSR in order to complete domain
283 ownership proofs required by the CA.
puuh... interesting, but bring up security challenge if i understand it
correctly:
So the pledge would learn attributes from the cloud registrar via CSRattr
request/reply
and later on uses them in the cert enrolment step with the
EST-Server/Owner-Registrar.
Yes ?
Because in this case we would just upgradr the trust requirement against the
Cloud Registrar. Without this step, the Cloud Registrar is just a glorified
traffic guide to redirect the pledge to the Owner and deliver a a voucher to
it. But really doesn't have to be well trusted - just good enough to oppress
the worst of DoS attack opportunities. (I hope i get this right).
But with such aditional attributes, the cloud-registar has to be trusted
much more.
I would suggest that for this case, if feasible, the voucher would also vouch
for the cloud registar - that would upgrade all the information received from
the cloud registrar to the same level of trust that the pledge has against the
owner registrar - by virtue of the voucher.
Alternatively, i think we should explicitly call for authenticartion of the
Cloud Registrar only via explicit TA for the purpose of Cloud Registrar
connections, but not general purpose WebPKI TA (which a lot of pledges
may also have...).
285 As another example, the registrar may deem the manufacturer serial
286 number in an IDevID as personally identifiable information, and may
287 want to specify a new random opaque identifier that the pledge should
288 use in its CSR.
But this is now only about what's in the ultimate LDevID, right ? SO this
is not a new issue for BRSKI Cloud, but for BRSKI too, right ?
If this is applicable to non-BRSKI Cloud cases, can this please go into
draft-ietf-lamps-rfc7030-csrattrs instead ?
290 3. Protocol Operation
292 3.1. Pledge Requests Voucher from Cloud Registrar
294 3.1.1. Cloud Registrar Discovery
296 BRSKI defines how a pledge MAY contact a well-known URI of a cloud
297 registrar if a local domain registrar cannot be discovered.
Actually, it would really be good if some text in the introduction of brski
cloud
would discus/refer to RFC8995 section 2.7 "Cloud Registar", such as:
"RFC8995 2.7 introduces concept of Cloud Registar, but does not define how a
Cloud
Registrar should perform BRSKI enrolment for pledges from potentially multiple
domain.
This document provides a specification for Cloud Registar in which the Cloud
Registar either only provides a Voucher and then redirects the pledge to its
owners EST server, or where it only redirects the pledge to its owners BRSKI
Registar.
This whole scope of this document also makes me wonder if we should amend the
title
of the docuemtn to "Redirecting BRSKI Cloud Registar". Because there could
still be
perfectly well an "all-in-one" BRSKI Cloud Registar, perfectly well fitting
RFC8995
section 2.7 - bit not requiring any of this documents procedures, right ? Aka:
The key identifying property is not that of the Cloud Registrar but the fact
that it
is redirecting (i think).
298 Additionally, certain pledge types may never attempt to discover a
299 local domain registrar and may automatically bootstrap against a
300 cloud registrar.
302 The details of the URI are manufacturer specific, with BRSKI giving
303 the example "brski-registrar.manufacturer.example.com".
Hmm. RFC8995 says:
performing a DNS lookup using a well-known URI such as
"brski-registrar.manufacturer.example.com"
but i think thats wrong text because "brski-..." is not a URI given how it has
no
scheme. Sentence should have been "DNS lookup using the host of the well-known
URI".
I am actually not even sure how a BRSKI URI would look like. E.g.: when the
pledge just has a URI - how does it know that the protocol should be BRSKI -
let's say
it does support multiple different enrolment protocols... ???
https://brski-registrar.manufacturer.example.com/.well-known/brski
Is that a correct URI that fully identifies BRSKI ???
(i think it is...)
305 The Pledge SHOULD be provided with the entire URL of the Cloud
306 Registrar, including the path component, which is typically "/.well-
307 known/brski/requestvoucher", but may be another value.
See.. now you're saying URL instead of URI, is that necessary/beneficial ?
And how would i determine whether "requestvoucher" is required in the URI ?
Isn't
that implied by the protocol we're describing here ???
309 3.1.2. Pledge - Cloud Registrar TLS Establishment Details
311 The pledge MUST use an Implicit Trust Anchor database (see [EST]) to
^
According to RFC8995, Section 2.7,
312 authenticate the cloud registrar service. The Pledge can be done
313 with pre-loaded trust-anchors that are used to validate the TLS
314 connection. This can be using a public Web PKI trust anchors using
315 [RFC6125] DNS-ID mechanisms, a pinned certification authority, or
316 even a pinned raw public key. This is a local implementation
317 decision.
I am mostly worried of this being mis-read such that it could be appropriate
to include the teirrbly long list of WebPKI Trust Anchors and think thats
good security. If we sa WebPKI it would certainlt be good to suggest limiting
WebPKI Trust anchros to only the ones known to be required for the Cloud
Registar.
319 The pledge MUST NOT establish a provisional TLS connection (see BRSKI
320 section 5.1) with the cloud registrar.
Reads confusingly here. Suggest to remove paragraph here and explain after the
following paragraph that compared to BRSKI, the TLS connection is immediately
mutually authenticated and not first a provisional TLS connection as in BRSKI.
322 The cloud registrar MUST validate the identity of the pledge by
323 sending a TLS CertificateRequest message to the pledge during TLS
324 session establishment. The cloud registrar MAY include a
325 certificate_authorities field in the message to specify the set of
326 allowed IDevID issuing CAs that pledges may use when establishing
327 connections with the cloud registrar.
329 The cloud registrar MAY only allow connections from pledges that have
330 an IDevID that is signed by one of a specific set of CAs, e.g.
331 IDevIDs issued by certain manufacturers.
How about we upgrade this ?
To protect itself against DoS attacks, the cloud registrar SHOULD reject TLS
connections
when it can determine during TLS authentication that it can not support the
pledge, for example because
the plege can not provide an IDevID signed by a CA recognized/supported
by the cloud registrar.
333 The cloud registrar MAY allow pledges to connect using self-signed
s/connect/authenticate/ ?
334 identity certificates or using Raw Public Key [RFC7250] certificates.
I think you're mention this because you have a good business case, such as
reduction
in manufacturing cost by doing self enrolment or raw public keys during
manufacturing
and capturing those into MASA and manufacturing databases - instead of also
having
to bother about a CA. It might be useful to add a paragraph about this benefit,
although
it is AFAIK not really BRSKI Cloud specific - but it seems like this could be
even
a more common case as peldges with non-self-signed certs.
336 3.1.3. Pledge Issues Voucher Request
338 After the pledge has established a full TLS connection with the cloud
s/full/mutually authenticated/ ?
339 registrar and has verified the cloud registrar PKI identity, the
s/and has verified the cloud registrar PKI identity,// ??
340 pledge generates a voucher request message as outlined in BRSKI
341 section 5.2, and sends the voucher request message to the cloud
342 registrar.
344 3.2. Cloud Registrar Handles Voucher Request
346 The cloud registrar must determine pledge ownership. Once ownership
347 is determined, or if no owner can be determined, then the registrar
348 may:
350 * return a suitable 4xx or 5xx error response to the pledge if the
351 registrar is unwilling or unable to handle the voucher request
call this " * error: " ?
353 * redirect the pledge to an owner register via 307 response code
^ ra
call this " * redirect to owner registrar:" ?
355 * issue a voucher and return a 200 response code
call this " * redirect to owner EST server" ?? Although i don't see
any redirect... Forgot initial text is there no redirect, pledge should assume
to know where to find EST-Server ?
357 3.2.1. Pledge Ownership Lookup
359 The cloud registrar needs some suitable mechanism for knowing the
360 correct owner of a connecting pledge based on the presented identity
361 certificate. For example, if the pledge establishes TLS using an
^ or raw keys
362 IDevID that is signed by a known manufacturing CA, the registrar
363 could extract the serial number from the IDevID and use this to
364 lookup a database of pledge IDevID serial numbers to owners.
366 Alternatively, if the cloud registrar allows pledges to connect using
367 self-signed certificates, the registrar could use the thumbprint of
368 the self-signed certificate to lookup a database of pledge self-
369 signed certificate thumbprints to owners.
is there any spec for thumbprint you could cite ?
371 The mechanism by which the cloud registrar determines pledge
372 ownership is out-of-scope of this document.
... but as Figure 1 intends to imply, it could obtain this information from the
MASA of the pledges manufacturer.
Btw: Self-signed certs and raw keys sound like a fun cloud registrar / masa
integration.
Seems like if you want to implement a cloud registrar for multiple manufacturers
that use raw keys or self-signed certs, that the cloud registrar better have
different URIs for every manufacturer if it does not always want to get a full
dump of all the tumbprints of those self-signed certs and/or raw keys. After all
the cloud registrar can not figure out who the manufacturer is with raw keys
or thumbprints unless it already has that info - unless the pledge does provide
a second piece of information (who is my manufacturer) by mean of the URI
of the cloud server that it connects to.
If i am not missing something, this condition may or may not be worthwhile to
explain. I think to remember that in BRSKI and/or ACP, and because back then
we expected still to maybe get only TLS 1.2, that we asked for support of
SNI (Server Name Indication) on pledges. Something that would especially be
applicable here. In TLS 1.3 that is standard. But i guess when we are not saying
aything then this RFC will still permit use of TLS 1.2 and hence a requirement
for
pledge side SNI support seems appropriate.
374 3.2.2. Cloud Registrar Redirects to Owner Registrar
376 Once the cloud registrar has determined pledge ownership, the cloud
377 registrar may redirect the pledge to the owner registrar in order to
378 complete bootstrap. Ownership registration will require the owner to
379 register their local domain. The mechanism by which pledge owners
380 register their domain with the cloud registrar is out-of-scope of
381 this document.
Reads a bit confusing. Maybe rephrase:
If the owner wants the Cloud Registrr
to redirect pledges to the Owner Registrar, the owner needs to register the
Owner Registrars URI with cloud Registar. The mechanisms...
383 The cloud registrar replies to the voucher request with a suitable
384 HTTP 307 response code, including the owner's local domain in the
385 HTTP Location header.
387 3.2.3. Cloud Registrar Issues Voucher
389 If the cloud registrar issues a voucher, it returns the voucher in a
390 HTTP response with a 200 response code.
392 The cloud registrar MAY issue a 202 response code if it is willing to
393 issue a voucher, but will take some time to prepare the voucher.
395 The voucher MUST include the "est-domain" field as defined below.
396 This tells the pledge where the domain of the EST service to use for
397 completing certificate enrollment.
Seems "est-domain" is a new voucher field not in rfc8366 or rfc8995. SO please
say so and point to at least the section here pointing to i gues rfc8366bis so
reader know where this magial "est-domain" is. 'New "est-domain"' would also
help to make this understood.
399 The voucher MAY include the "additional-configuration" field. This
400 points the pledge to a URI where application specific additional
s/application/pledge/ ??? (don't introduce additional new terms like aplication
without defining them).
401 configuration information may be retrieved. Pledge and Registrar
402 behavior for handling and specifying the "additional-configuration"
403 field is out-of-scope of this document.
But it seems as if the Manufacturer and/or owner may want to be able to specify
the
value of this field to the Cloud Registrar.
405 3.3. Pledge Handles Cloud Registrar Response
407 3.3.1. Redirect Response
409 The cloud registrar returned a 307 response to the voucher request.
411 The pledge should restart the process using a new voucher request
412 using the location provided in the HTTP redirect. Note if the pledge
413 is able to validate the new server using a trust anchor found in its
414 Implicit Trust Anchor database, then it MAY accept another 307
415 redirect. The pledge MUST never visit a location that it has already
416 been to. If that happens then the pledge MUST fail the onboarding
^^^^^^^^^^
bootstrap, onboarding, enrollment - pick at most two, ideally one, and use
consistently
throughout document.
417 attempt and go back to the beginning, which includes listening to
418 other sources of onboarding information as specified in [BRSKI]
419 section 4.1 and 5.0.
421 The pledge should establish a provisional TLS connection with
422 specified local domain registrar. The pledge should not use its
...with the registar at the redirect specified location.
423 Implicit Trust Anchor database for validating the local domain
424 registrar identity. The pledge should send a voucher request message
425 via the local domain registrar. When the pledge downloads a voucher,
426 it can validate the TLS connection to the local domain registrar and
427 continue with enrollment and bootstrap as per standard BRSKI
428 operation.
Is this chapter not already saying to much ? E.g.: with the redirect from the
Cloud Registrar, we just in this case have a new form of (Owner) Registrar and
everythinf else would be as it is in BRSKI ? Aka: at line 421 write that from
here on behavior is as in BRSKI Section (find right section).
430 3.3.2. Voucher Response
432 The cloud registrar returned a voucher to the pledge. The pledge
433 should perform voucher verification as per standard BRSKI operation.
434 The pledge should verify the voucher signature using the
435 manufacturer-installed trust anchor(s), should verify the serial
436 number in teh voucher, and must verify any nonce information in the
437 voucher.
439 The pledge should extract the "est-domain" field from the voucher,
440 and should continue with EST enrollment as per standard BRSKI
441 operation.
This section too would IMHO be better if it could incldue the BRSKI section
for the validation etc..
Then i wonder about CSR attrributes... where does it happen.
And then EST enrolment: Is that as perr standard BRSKI operation, which is
more than ESTE7030, or is it according to RFC7030. With the use case of
a legacy EST server, it probably is only only RFC7030 and not BRSKI, right ???
443 4. Protocol Details
445 4.1. Voucher Request Redirected to Local Domain Registrar
447 This flow illustrates the Owner Registrar Discovery flow. A pledge
448 is bootstrapping in a remote location with no local domain registrar.
449 The assumption is that the owner registrar domain is accessible and
450 the pledge can establish a network connection with the owner
451 registrar. This may require that the owner network firewall exposes
452 the registrar on the public internet.
registrar or EST-server enrollment port to the public internet ??
454 +--------+ +----------+
455 | Pledge | | Cloud RA |
456 | | | |
457 +--------+ +----------+
458 | |
459 | 1. Mutual-authenticated TLS |
460 |<----------------------------------------------->|
461 | |
462 | 2. Voucher Request |
463 |------------------------------------------------>|
464 | |
465 | 3. 307 Location: owner-ra.example.com |
466 |<------------------------------------------------|
467 |
468 | +-----------+ +---------+
469 | | Owner | | MASA |
470 | | Registrar | | |
471 | +-----------+ +---------+
472 | 4. Provisional TLS | |
473 |<-------------------->| |
474 | | |
475 | 5. Voucher Request | |
476 |--------------------->| 6. Voucher Request |
477 | |------------------------->|
478 | | |
479 | | 7. Voucher Response |
480 | |<-------------------------|
481 | 8. Voucher Response | |
482 |<---------------------| |
483 | | |
484 | 9. Validate TLS | |
485 |<-------------------->| |
486 | | |
487 | 10. etc. | |
488 |--------------------->| |
490 The process starts, in step 1, when the Pledge establishes a Mutual
491 TLS channel with the Cloud RA using artifacts created during the
s/RA/registrar/g - not a new term this late in the doc please unless there is a
good reason
that should be explained in text.
492 manufacturing process of the Pledge.
494 In step 2, the Pledge sends a voucher request to the Cloud RA.
496 The Cloud RA completes pledge ownership lookup as outlined in
s/completes/determines/
497 Section 3.2.1, and determines the owner registrar domain. In step 3,
498 the Cloud RA redirects the pledge to the owner registrar domain.
500 Steps 4 and onwards follow the standard BRSKI flow. The pledge
501 establishes a provisional TLS connection with the owner registrar,
502 and sends a voucher request to the owner registrar. The registrar
503 forwards the voucher request to the MASA. Assuming the MASA issues a
504 voucher, then the pledge validates the TLS connection with the
505 registrar using the pinned-domain-cert from the voucher and completes
506 the BRSKI flow.
508 4.2. Voucher Request Handled by Cloud Registrar
would suggest for 4.1 and 4.2 the same titles as for 1.2.1 and 1.2.2
so they can easier be matched up
510 The Voucher includes the EST domain to use for EST enroll. It is
s/enroll/enrollment/
511 assumed services are accessed at that domain too. As trust is
512 already established via the Voucher, the pledge does a full TLS
513 handshake against the local RA indicated by the voucher response.
515 The returned voucher contains an attribute, "est-domain", defined in
516 Section 5 below. The pledge is directed to continue enrollment using
517 the EST registrar found at that URI. The pledge uses the pinned-
518 domain-cert from the voucher to authenticate the EST registrar.
I am not sure these two paragraphs are needed given how the explanation after
the picture should cover it all in chronological order. But if you want to
keep this text, please reorder from benjaming button order to chronological.
520 +--------+ +----------+
521 | Pledge | | Cloud RA |
522 | | | / MASA |
523 +--------+ +----------+
524 | |
525 | 1. Mutual TLS |
526 |<----------------------------------------------->|
527 | |
528 | 2. Voucher Request |
529 |------------------------------------------------>|
530 | |
531 | 3. Voucher Response {est-domain:fqdn} |
532 |<------------------------------------------------|
533 | |
534 | +----------+ |
535 | | RFC7030 | |
536 | | EST | |
537 | | Registrar| |
538 | +----------+ |
539 | | |
540 | 4. Full TLS | |
541 |<-------------------->| |
542 | |
543 | 3a. /voucher_status POST success |
544 |------------------------------------------------>|
545 | ON FAILURE 3b. /voucher_status POST |
546 | |
547 | 5. EST Enrol | |
548 |--------------------->| |
549 | | |
550 | 6. Certificate | |
551 |<---------------------| |
552 | | |
553 | 7. /enrollstatus | |
554 |--------------------->| |
556 The process starts, in step 1, when the Pledge establishes a Mutual
557 TLS channel with the Cloud RA/MASA using artifacts created during the
558 manufacturing process of the Pledge. In step 2, the Pledge sends a
559 voucher request to the Cloud RA/MASA, and in response the Pledge
560 receives an [RFC8366] format voucher from the Cloud RA/MASA that
^^^^^^^^^
This should ultimately be the rfc8366bis format voucher because of est-domain,
right ?
I see right now we still have the extension here. In any case, point to the
right
place, not just RFC8366.
561 includes its assigned EST domain in the est-domain attribute.
563 At this stage, the Pledge should be able to establish a TLS channel
s/channel/connection/
564 with the EST Registrar. The connection may involve crossing the
565 Internet requiring a DNS lookup on the provided name. It may also be
566 a local address that includes an IP address literal including both
567 [RFC1918] and IPv6 Unique Local Address. The EST Registrar is
Whow a local address that includes both RFC1918 and IPv6 Unique Local address.
Never seen that!
s/and/or/ ;-)
please add reference for ULA (RFC4193)
568 validated using the pinned-domain-cert value provided in the voucher
569 as described in [BRSKI] section 5.6.2. This involves treating the
570 artifact provided in the pinned-domain-cert as a trust anchor, and
571 attempting to validate the EST Registrar from this anchor only.
s/validate/authenticate/
573 There is a case where the pinned-domain-cert is the identical End-
574 Entity (EE) Certificate as the EST Registrar. It also explicitly
575 includes the case where the EST Registrar has a self-signed EE
576 Certificate, but it may also be an EE certificate that is part of a
577 larger PKI. If the certificate is not a self-signed or EE
578 certificate, then the Pledge SHOULD apply [RFC6125] DNS-ID validation
579 on the certificate against the URL provided in the est-domain
580 attribute. If the est-domain was provided by with an IP address
581 literal, then it is unlikely that it can be validated, and in that
582 case, it is expected that either a self-signed certificate or an EE
583 certificate will be pinned.
Maybe "pinned by the voucher" to avoid confusion ? (maybe also in other places
where you use pinning).
585 The Pledge also has the details it needs to be able to create the CSR
586 request to send to the RA based on the details provided in the
587 voucher.
589 In step 4, the Pledge establishes a TLS channel with the Cloud RA/
590 MASA, and optionally the pledge should send a request, steps 3.a and
591 3.b, to the Cloud RA/MASA to inform it that the Pledge was able to
592 establish a secure TLS channel with the EST Registrar.
594 The Pledge then follows that, in step 5, with an EST Enroll request
595 with the CSR and obtains the requested certificate. The Pledge must
596 validate that the issued certificate has the expected identifier
597 obtained from the Cloud RA/MASA in step 3.
599 5. YANG extension for Voucher based redirect
601 An extension to the [RFC8366] voucher is needed for the case where
602 the client will be redirected to a local EST Registrar.
604 5.1. YANG Tree
605 module: ietf-voucher-redirected
607 grouping voucher-redirected-grouping
608 +-- voucher
609 +-- created-on yang:date-and-time
610 +-- expires-on? yang:date-and-time
611 +-- assertion enumeration
612 +-- serial-number string
613 +-- idevid-issuer? binary
614 +-- pinned-domain-cert binary
615 +-- domain-cert-revocation-checks? boolean
616 +-- nonce? binary
617 +-- last-renewal-date? yang:date-and-time
618 +-- est-domain? ietf:uri
619 +-- additional-configuration? ietf:uri
621 5.2. YANG Voucher
623 <CODE BEGINS> file "[email protected]"
624 module ietf-voucher-redirected {
625 yang-version 1.1;
627 namespace
628 "urn:ietf:params:xml:ns:yang:ietf-voucher-redirected";
629 prefix "redirected";
631 import ietf-restconf {
632 prefix rc;
633 description
634 "This import statement is only present to access
635 the yang-data extension defined in RFC 8040.";
636 reference "RFC 8040: RESTCONF Protocol";
637 }
639 import ietf-inet-types {
640 prefix ietf;
641 reference "RFC 6991: Common YANG Data Types";
642 }
644 import ietf-voucher {
645 prefix "v";
646 }
648 organization
649 "IETF ANIMA Working Group";
651 contact
652 "WG Web: <http://tools.ietf.org/wg/anima/>
653 WG List: <mailto:[email protected]>
654 Author: Michael Richardson
655 <mailto:[email protected]>
656 Author: Owen Friel
657 <mailto: [email protected]>
658 Author: Rifaat Shekh-Yusef
659 <mailto: [email protected]>";
660 description
661 "This module extendes the base RFC8366 voucher format to
662 include a redirect to an EST server to which enrollment
663 should continue.
665 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
666 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
667 and 'OPTIONAL' in the module text are to be interpreted as
668 described in BCP14, RFC 2119, and RFC8174.";
670 revision "2020-09-23" {
671 description
672 "Initial version";
673 reference
674 "RFC XXXX: Voucher Profile for Cloud redirected Devices";
675 }
677 rc:yang-data voucher-redirected-artifact {
678 // YANG data template for a voucher.
679 uses voucher-redirected-grouping;
680 }
682 // Grouping defined for future usage
683 grouping voucher-redirected-grouping {
684 description
685 "Grouping to allow reuse/extensions in future work.";
687 uses v:voucher-artifact-grouping {
689 augment "voucher" {
690 description "Base the constrained voucher
691 upon the regular one";
692 leaf est-domain {
693 type ietf:uri;
694 description
695 "The est-domain is a URL to which the Pledge should
696 continue doing enrollment rather than with the
697 Cloud Registrar.
698 The pinned-domain-cert contains a trust-anchor
699 which is to be used to authenticate the server
700 found at this URI.
702 ";
703 }
704 leaf additional-configuration {
705 type ietf:uri;
706 description
707 "The additional-configuration attribute contains a
708 URL to which the Pledge can retrieve additional
709 configuration information.
710 The contents of this URL are vendor specific.
711 This is intended to do things like configure
712 a VoIP phone to point to the correct hosted
713 PBX, for example.";
714 }
715 }
716 }
717 }
718 }
719 <CODE ENDS>
721 6. IANA Considerations
723 6.1. The IETF XML Registry
725 This document registers one URI in the IETF XML registry [RFC3688].
726 Following the format in [RFC3688], the following registration is
727 requested:
729 {: newline="true"}
730 URI:
731 : urn:ietf:params:xml:ns:yang:ietf-voucher-redirected
733 Registrant Contact:
734 : The ANIMA WG of the IETF.
736 XML:
737 : N/A, the requested URI is an XML namespace.
739 6.2. The YANG Module Names Registry
741 This document registers two YANG modules in the YANG Module Names
742 registry [RFC6020]. Following the format defined in [RFC6020], the
743 the following registration is requested:
745 {: newline="true"}
746 name:
747 : ietf-voucher-redirected
749 namespace:
750 : urn:ietf:params:xml:ns:yang:ietf-voucher-redirected
752 prefix:
753 : vch
755 reference:
756 : THIS DOCUMENT
758 7. Security Considerations
760 The Cloud-Registrar described in this document inherits all of the
761 issues that are described in [BRSKI]. This includes dependency upon
^
applicable to the stages of BRSKI that it also performsn (i have no idea
wheter or what security considerations we've written into 8995 for e.g.:
the cert enrollment stages, but those for example would not apply here, but
are a problem of the EST-server for example.
762 continued operation of the manufacturer provided MASA, as well as
763 potential complications where a manufacturer might interfere with
764 resale of a device.
766 In addition to the dependency upon the MASA, the successful
767 enrollment of a device using a Cloud Registrar depends upon the
768 correct and continued operation of this new service. This internet
769 accessible service may be operated by the manufacturer and/or by one
770 or more value-added-resellers. All of the considerations for
771 operation of the MASA also apply to operation of the Cloud Registrar.
The way i see it overall, the Cloud Registrar opens up (based on deployment
details) new opportunities for attackers to perform DoS against successful
enrolment,
starting from the use of the Internet itself, public DNS and all that. BUT it
seems to me that
we do not introduce new security problems for inappropriate LDevID enrolment
(e.g.: into the wrong domain), because that still all depend solely on unchanged
behavior on an Owner EST-Server/Registrar.
Aka: that should be rephrased and be on top as reassuring high level property.
773 7.1. Issues with Security of HTTP Redirect
775 If the Redirect to Registrar method is used, as described in
776 Section 4.1, there may be a series of 307 redirects. An example of
777 why this might occur is that the manufacturer only knows that it
778 resold the device to a particular value added reseller (VAR), and
779 there may be a chain of such VARs. It is important the pledge avoid
780 being drawn into a loop of redirects. This could happen if a VAR
"the Cloud Registrar of a VAR" - also in other uses here. Check what sentence
refers to the VAR at large vs. its Cloud Registrar.
781 does not think they are authoritative for a particular device. A
782 "helpful" programmer might instead decide to redirect back to the
783 manufacturer in an attempt to restart at the top: perhaps there is
784 another process that updates the manufacturer's database and this
785 process is underway. Instead, the VAR MUST return a 404 error if it
786 cannot process the device. This will force the device to stop,
787 timeout, and then try all mechanisms again.
789 There is another case where a connection problem may occur: when the
790 pledge is behind a captive portal or an intelligent home gateway that
791 provides access control on all connections. Captive portals that do
792 not follow the requirements of [RFC8952] section 1 may forcibly
793 redirect HTTPS connections. While this is a deprecated practice as
794 it breaks TLS in a way that most users can not deal with, it is still
795 common in many networks.
797 On the first connection, the incorrect connection will be discovered
798 because the Pledge will be unable to validate the connection to its
799 cloud registrar via DNS-ID. That is, the certificate returned from
800 the captive portal will not match.
802 At this point a network operator who controls the captive portal,
803 noticing the connection to what seems a legitimate destination (the
804 cloud registrar), may then permit that connection. This enables the
805 first connection to go through.
807 The connection is then redirected to the Registrar, either via 307,
808 or via est-domain in a voucher. If it is a 307 redirect, then a
809 provisional TLS connection will be initiated, and it will succeed.
810 The provisional TLS connection does not do [RFC6125] DNS-ID
811 validation at the beginning of the connection, so a forced
812 redirection to a captive portal system will not be detected. The
813 subsequent BRSKI POST of a voucher will most likely be met by a 404
814 or 500 HTTP code. As the connection is provisional, the pledge will
815 be unable to determine this.
I don't think that programming problems of friendly implementors that don't
understand this are actually part of security considerations. So maybe the mayor
part of this should go into a different section on implementation
considerations.
In such a section you can be liberal and mention everything, and then in the
formally required security considerations here you may jsut that that if
an attacker manages to create one of the problems that are outlined in that
implementations ection, then he can create a DoS attack against timely
enrolment,
but nothing worse.
817 It is RECOMMENDED therefore that the pledge look for [RFC8910]
818 attributes in DHCP, and if present, use the [RFC8908] API to learn if
819 it is captive.
821 7.2. Security Updates for the Pledge
823 Unlike many other uses of BRSKI, in the Cloud Registrar case it is
824 assumed that the Pledge has connected to a network on which there is
I don't think the Internet is Voldemort. Aka: feel free to globally replace
"the Internet". If it really could be another network than the Internet, thats
fine to keep explicitly, but for something like firmware updates specifically,
it clearly seems to be just the Internet.
825 addressing and connectivity, but there is no other local
826 configuration available.
828 There is another advantage to being online: the pledge may be able to
829 contact the manufacturer before onboarding in order to apply the
830 latest firmware updates. This may also include updates to the
831 Implicit list of Trust Anchors. In this way, a Pledge that may have
832 been in a dusty box in a warehouse for a long time can be updated to
833 the latest (exploit-free) firmware before attempting onboarding.
835 7.3. Trust Anchors for Cloud Registrar
837 The Implicit TA database is used to authenticate the Cloud Registrar.
838 This list is built-in by the manufacturer along with a DNS name to
839 which to connect. (The manufacturer could even build in IP addresses
840 as a last resort)
841 The Cloud Registrar does not have a certificate that can be validated
842 using a public (WebPKI) anchor. The pledge may have any kind of
843 Trust Anchor built in: from full multi-level WebPKI to the single
844 self-signed certificate used by the Cloud Registrar. There are many
The first and second sentences here do seem to contradict each other WebPKI
yes/no/maybe ???...
844 self-signed certificate used by the Cloud Registrar. There are many
845 tradeoffs to having more or less of the PKI present in the Pledge,
846 which is addresses in part in
847 [I-D.richardson-t2trg-idevid-considerations] in sections 3 and 5.
849 7.4. Issues with Redirect via Voucher
851 The second redirect case is handled by returning a special extension
852 in the voucher. The Cloud Registrar actually does all of the voucher
853 processing as specified in [BRSKI]. In this case, the Cloud
854 Registrar may be operated by the same entity as the MASA, and it
855 might even be combined into a single server. Whether or not this is
856 the case, it behaves as if it was separate.
I think this is not correct. IN either of the flows, the Cloud Registrar can
be operated by the same entity as the MASA and both might be combined into a
single
server. I also wouldn't know what "behaves as if it was separate" means.
What i think is true is this:
A Cloud Registrar supporting the same set of pledges as a MASA can be integrated
MASA to avoid the need for a network based API between them, and without
changing
their external behaviror as specified here.
If the Cloud Registrar issues a voucher, there is no need anymore for
BRSKI-MASA.
It is left up to the exercise of a more advanced security expert than myself
to claim whether or not this improves security, but likely it does, because now
the
whole flow up to the point of getting a pledge to a voucher can only involve
code from one party (the manufacturer).
858 It may be the case that one or more 307-Redirects have taken the
859 Pledge from the built-in Cloud Registrar to one operated by a VAR.
861 When the Pledge is directed to the Owner's [EST] Registrar, the
862 Pledge validates the TLS connection with this server using the
863 "pinned-domain-cert" attribute in the voucher. There is no
864 provisional TLS connection, and therefore there are no risks
865 associated with being behind a captive portal.
Was that being behind captive portal a real security risk or just a possible
failure issue (failure is not a security problem AFAIK...)
867 8. References
869 8.1. Normative References
871 [BRSKI] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
872 and K. Watsen, "Bootstrapping Remote Secure Key
873 Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
874 May 2021, <https://www.rfc-editor.org/info/rfc8995>.
876 [EST] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
877 "Enrollment over Secure Transport", RFC 7030,
878 DOI 10.17487/RFC7030, October 2013,
879 <https://www.rfc-editor.org/info/rfc7030>.
881 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
882 Requirement Levels", BCP 14, RFC 2119,
883 DOI 10.17487/RFC2119, March 1997,
884 <https://www.rfc-editor.org/info/rfc2119>.
886 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
887 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
888 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
890 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
891 "A Voucher Artifact for Bootstrapping Protocols",
892 RFC 8366, DOI 10.17487/RFC8366, May 2018,
893 <https://www.rfc-editor.org/info/rfc8366>.
895 8.2. Informative References
897 [I-D.richardson-lamps-rfc7030-csrattrs]
898 Richardson, M., Friel, O., von Oheimb, D., and D. Harkins,
899 "Clarification of RFC7030 CSR Attributes definition", Work
900 in Progress, Internet-Draft, draft-richardson-lamps-
901 rfc7030-csrattrs-04, 24 July 2022,
902 <https://www.ietf.org/archive/id/draft-richardson-lamps-
903 rfc7030-csrattrs-04.txt>.
905 [I-D.richardson-t2trg-idevid-considerations]
906 Richardson, M., "A Taxonomy of operational security
907 considerations for manufacturer installed keys and Trust
908 Anchors", Work in Progress, Internet-Draft, draft-
909 richardson-t2trg-idevid-considerations-09, 6 November
910 2022, <https://www.ietf.org/archive/id/draft-richardson-
911 t2trg-idevid-considerations-09.txt>.
913 [IEEE802.1AR]
914 IEEE Standard, "IEEE 802.1AR Secure Device Identifier",
915 2018, <http://standards.ieee.org/findstds/
916 standard/802.1AR-2018.html>.
918 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
919 J., and E. Lear, "Address Allocation for Private
920 Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
921 February 1996, <https://www.rfc-editor.org/info/rfc1918>.
923 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
924 DOI 10.17487/RFC3688, January 2004,
925 <https://www.rfc-editor.org/info/rfc3688>.
927 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
928 the Network Configuration Protocol (NETCONF)", RFC 6020,
929 DOI 10.17487/RFC6020, October 2010,
930 <https://www.rfc-editor.org/info/rfc6020>.
932 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
933 Verification of Domain-Based Application Service Identity
934 within Internet Public Key Infrastructure Using X.509
935 (PKIX) Certificates in the Context of Transport Layer
936 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
937 2011, <https://www.rfc-editor.org/info/rfc6125>.
939 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
940 "Enrollment over Secure Transport", RFC 7030,
941 DOI 10.17487/RFC7030, October 2013,
942 <https://www.rfc-editor.org/info/rfc7030>.
944 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
945 Weiler, S., and T. Kivinen, "Using Raw Public Keys in
946 Transport Layer Security (TLS) and Datagram Transport
947 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
948 June 2014, <https://www.rfc-editor.org/info/rfc7250>.
950 [RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
951 Touch Provisioning (SZTP)", RFC 8572,
952 DOI 10.17487/RFC8572, April 2019,
953 <https://www.rfc-editor.org/info/rfc8572>.
955 [RFC8908] Pauly, T., Ed. and D. Thakore, Ed., "Captive Portal API",
956 RFC 8908, DOI 10.17487/RFC8908, September 2020,
957 <https://www.rfc-editor.org/info/rfc8908>.
959 [RFC8910] Kumari, W. and E. Kline, "Captive-Portal Identification in
960 DHCP and Router Advertisements (RAs)", RFC 8910,
961 DOI 10.17487/RFC8910, September 2020,
962 <https://www.rfc-editor.org/info/rfc8910>.
964 [RFC8952] Larose, K., Dolson, D., and H. Liu, "Captive Portal
965 Architecture", RFC 8952, DOI 10.17487/RFC8952, November
966 2020, <https://www.rfc-editor.org/info/rfc8952>.
968 Authors' Addresses
970 Owen Friel
971 Cisco
972 Email: [email protected]
974 Rifaat Shekh-Yusef
975 Auth0
976 Email: [email protected]
978 Michael Richardson
979 Sandelman Software Works
980 Email: [email protected]
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
