On Fri, Aug 09, 2019 at 04:17:17PM -0400, Michael Richardson wrote:
>
> https://tinyurl.com/yylruorn contains a diff against -24.
>
> Benjamin Kaduk via Datatracker <nore...@ietf.org> wrote:
> > [disclaimer: some of these comments get pretty blunt at the end; it's a
> > long document and I'm tired. Please try not to get too annoyed if I'm
> > failing to see something that's right in front of me.]
>
> > I concur with the directorate reviewers that expected a
> > high-level security analysis of what information flows where, and what
> > policy choices can be made that affect it. At a *very* high level
> > (skipping over a lot of things that I would expect to see), this would
> > be structured like:
>
> > On initial bootstrap, a new device uses local service autodiscovery to
> > locate a (proxy to a) local registrar. Having found a candidate
>
> I have included an edited version of this text. It was very well done, thank
> you!
>
> > Abstract
>
> > (side note?) Is there a quick explanation of why bootstrapping can
> > complete with just installation of the PKI (trust anchor?) and
> > provisioning a locally issued certificate is not mandatory?
>
> I don't think that we can fit a quick explanation into the Abstract.
> I did split up the last sentence.
This was a side note, so for my own edification more than the good of the
document...
> The hard thing that BRSKI provides is the trust of the network by the pledge.
> The trust of the device by the network is generally an "easy" problem solved
> by use of 802.1AR/IDevID. This is presently done in many existing EST and CMP
> users.
> So I'm not sure what further to do here.
....and this helps; thank you!
> > Section 1
>
> > This document describes how pledges discover (or be discovered by) an
> > element of the network domain to which the pledge belongs to perform
> > the bootstrap. [...]
>
> > nit: s/be/are/, IIUC.
> > I think there's also something funky with the wording of "to perform the
> > bootstrap"; we may be looking for an element "that will perform the
> > bootstrap".
>
> yes, done.
>
> > 4. Pledge authorizing the registrar: "Should I join it?"
>
> > nit: what is "it"? Surely not the registrar, and presumably the
> > "network domain" in question?
>
> yes, it = "network"
>
> > This document details protocols and messages to answer the above
> > questions. It uses a TLS connection and an PKIX (X.509v3)
> > certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer
> > points 1 and 2. It uses a new artifact called a "voucher" that the
>
> > I'm kind of confused by "[IDevID] LDevID", since my understanding was
> > that the LDevID is issued only after all four steps are complete.
>
> Yes, that seems to be a typo.
>
> > Also, following the IDevID link lands me at a page that claims to be for
> > a standard of status "superseded".
>
> Yes, the IEEE apparently put out 802.1AR-2018 replacing -2009 last year.
> I don't have a copy, and the getieee program just goes in loops of logging
> in, or results in servlet errors.
> I even emailed support, and they were basically useless.
> {fetching coffee to avoid rant}
>
> > nit: one can use X.509v3 without being PKIX, and it's not entirely clear
> > that the IDevIDs will chain up to the Internet PKI.
>
> You didn't respond to my suggestion that PKIX!=Internet PKI.
> I do think that we want many things the IETF PKIX WG has produced
> since X.509v3, so I don't think that X.509v3 is an appropriate noun
> to describe things.
I think this discussion is continuing in the other thread, right?
> > Section 1.2
>
> > RFC 8174 has an updated version of the BCP 14 boilerplate.
>
> done already.
>
> > I'd suggest adding "MASA Audit Log" as a defined term to give advance
> > warning that this is an explicit protocol feature.
>
> added.
>
> > domainID: The domain IDentity is the 160-bit SHA-1 hash of the BIT
> > STRING of the subjectPublicKey of the pinned-domain-cert leaf,
> > i.e. the Registrars' certificate. This is consistent with the
> > subject key identifier (Section 4.2.1.2 [RFC5280]).
>
> > What would it take to move away from SHA-1 for this purpose? It's
> > unclear how long it will be before finding a second preimage of the SPKI
> > hash is feasible and thus using it as an identifier no longer serves to
> > uniquely identify something.
>
> This was asked by Eric as well.
> It's the Subject Key Identifier that we want.
> https://tools.ietf.org/html/rfc5280#section-4.2.1.2
>
> It's only guaranteed to exist in CA certificates.
> Do you think we can demand that the extension be present in IDevID?
I'm doubtful that we have enough leverage to make that stick.
> If so, we could just use that value in the MASA Audit Log.
> But, if we did, it would often still be the SHA-1 hash of the public key, but
> RFC5280 says:
> "Other methods of generating unique numbers are also acceptable."
>
> When https://tools.ietf.org/html/rfc5758 defined SHA-2 usage,
> it didn't specify a way to identify keys with SHA-2, although the mechanism
> is pretty clear.
So, if all we're going for is "consistent with the 5280 SKI", then "the
SHA-256 hash of the BIT STRING of the [...] certificate" is still going to
meet that bar.
I guess the pithy version of my stance here is that "from a standards
point of view it's easy to move to SHA-2, and we should only think about
sticking with SHA-1 if there's an implemnetation or deployment reason to do
so".
> > enrollment: The process where a device presents key material to a
> > network and acquires a network specific identity. For example
>
> > nit: hyphenate "network-specific".
>
> ok.
>
> > Section 1.4
>
> > As a result of the protocol described herein, the bootstrapped
> > devices have the Domain CA trust anchor in common. An end entity
> > certificate has optionally been issued from the Domain CA. [...]
>
> > This end-entity certificate is supposed "to authenticate each
> > bootstrapped device to other parties in the domain", right?
>
> > The major beneficiary is that it possible to use the credentials
> > deployed by this protocol to secure the Autonomic Control Plane (ACP)
> > ([I-D.ietf-anima-autonomic-control-plane]).
>
>
>
> > I might humbly suggest "major intended beneficiary", as there seem to be
> > many possibilities involving BRSKI.
>
> ok
>
> > Section 1.5
>
> > The pledge must perform discovery of the proxy as described in
> > Section 4.1 using GRASP M_FLOOD announcements.
>
> > Is this DULL GRASP or full-on ACP GRASP flooding?
>
> DULL GRASP, word inserted.
>
> > Upon successfully validating a voucher artiface, a status telemetry
> > MUST be returned. See Section 5.7.
>
> > nit: artifact (right?)
>
> previously fixed.
>
> > The ANI Join Registrar ASA MUST support all the BRSKI and above
> > listed EST operations.
>
> > nit: probably need to expand ASA the first time.
>
> done.
>
> > Section 2
>
> > The text following Figure 1 suggests that the Domain Registrar is not
> > always (also) a PKI RA, but the parentheticals in the figure itself are
> > easy to read as a clarification and not an optional thing, especially
> > since parentheticals are used in a different manner for the Key
> > Infrastructure box.
>
> text: Optionally the registrar also acts as a PKI Registration
> Authority.
>
> I think that the text should read:
> Optionally the registrar also acts as a PKI Certification
> Authority.
>
>
>
> > Section 2.1
>
> > 3. Request to join the discovered registrar. A unique nonce is
> > included ensuring that any responses can be associated with this
> > particular bootstrapping attempt.
>
> > But the nonce is not always present!
>
> I have been thinking hard about this problem, and I agree it is hard to
> understand here. Part of the issue is that the decision as to when and how
> to accept nonceless non-expiring ("offline") vouchers is a complex question,
> but it's also a private decision between the manufacturer's MASA and
> the manufacturer's device.
>
> The non-expiring nonceless voucher is a bit like kryptonite: once the
> manufacturer signs such a thing, it pretty much trumps everything else.
>
> I think that we need to add a section on nonce-less offline operation.
>
> > 5. Enroll. After imprint an authenticated TLS (HTTPS) connection
> > exists between pledge and registrar. Enrollment over Secure
> > Transport (EST) [RFC7030] is then used to obtain a domain
> > certificate from a registrar.
>
> > Isn't this step optional?
>
> so, I can change the word to "can" rather than "is"
(and fix up the grammar, but) sure
> > Section 2.2
>
> > A voucher is a cryptographically protected artifact (a digital
> > signature) to the pledge device authorizing a zero-touch imprint on
> > the registrar domain.
>
> > nit: "using a digital signature"
>
> ok.
>
> > Vouchers provide a signed but non-encrypted communication channel
> > among the pledge, the MASA, and the registrar. The registrar
> > maintains control over the transport and policy decisions allowing
> > the local security policy of the domain network to be enforced.
>
> > nit: is there supposed to be a comma after "policy decisions" (in that
> > both the transport and policy decisions allow for policy enforcement)?
>
> okay.
>
> > 1. Uniquely identifying the pledge by the Distinguished Name (DN)
> > and subjectAltName (SAN) parameters in the IDevID. The unique
> > identification of a pledge in the voucher objects are derived
> > from those parameters as described below.
>
> > These unique identifiers can (by design) be used for tracking, so let's
> > be sure that we talk about any privacy considerations with them, later.
> > I see a mention in passing in Section 10.2, at least...
>
> Are you asking for a forward reference to 10.2? I will add this.
> I think that section 10.2 is pretty clear about this.
> I don't think it's mentioned just in passing.
It looks like the main coverage here is:
o the identity of the device being enrolled (down to the serial-
number!).
and the discussion in the last three paragraphs or so.
I do appreciate the importance of distinguishing between the high-end
router and the human users (and we will have a long hard think about it
again when BRSKI profiles for IoT use come through, I'm sure), so thank you
for that. But I'm not sure that we clearly draw the connection to "the
manufacturer knows the identity of the device being enrolled" to "and can
guess where it is, and definitely knows who the owner is, and can
potentially follow that over time if the device has to reenroll". Now, for
the high-end router case there is literally nothing new here -- the vendor
is assumed to already be doing inventory tracking of which customers have
which routers! But I think it's important to make the connection from
"knows identity" to "tracking", since this topic will come up for any use
of BRSKI in other situations.
> > 3. Secure auto-discovery of the pledge's MASA by the registrar (see
> > Section 2.8).
>
> > I don't think this is an ironclad property, since the crypto chain is
> > slightly limited and you are in effect trusting the pledge to hand you
> > something that says "use this issuer" but without as much crypto to back
> > that up as we might want. We have to know that the given manufacturer
> > that signed the IDevID actually is associated with the device we're
> > trying to bootstrap, which can probably be arranged but I don't remember
> > being called out explicitly.
>
> There are two issues here.
>
> One is the question of what is the list of acceptable manufacturers (below).
> The second part is whether a pledge could provide a fake IDevID to
> the Registrar. The pledge is doing TLS ClientCertificate, so the TLS
> has proven that the pledge has the private key corresponding to the
> certificate presented. I conclude that an arbitrary IDevID can not be
> provided by the Pledge; it has to be linked to SOME manufacturer. Some
Well, it has to be linked to some entity that signed the IDevID. That may
or may not be a manufacturer, but the Registrar does have the capability to
look at what signed the IDevID and apply a whitelist of known, verified,
manufacturers.
> manufacturer A could point it's product at MASA B, but I don't see how this
> is an issue if MASA B will issues vouchers that pledge A can verify.
>
> (The pledge could have a variety of certificates from
> a variety of sources, perhaps all bound to the same public key, I guess, and
> since the Registrar sends it's certificate first, the pledge could present
> different identities to different networks. I think that this is a feature,
> not a bug. It reminds that "Kenmore" brand appliances were made by a variety
> of manufacturers, but I don't see my dishwasher can know what identity
> to use until after there is communication with the MASA)
Sure, that is probably a feature at least in some cases.
But can we assume that a given pledge has a single distinguished MASA?
The pledge gives the registrar a thing that says "go here for my MASA", and
the registrar can do a fair bit of validation on that, but there's still
potentially some control in the pledge's hands about where the registrar
goes to, and lots of room for attack by hostile pledges if the registrar is
buggy.
It's not like there's a single authoritative (global) database of (device,
MASA) pairs that we can query and have unconditional trust is giving the
right result (and validating what device we're looking up, even). Things
are fragmented, and at the protocol level, we can't be confident that we
wouldn't get a different (valid!) answer if we asked somewhere else, or
asked a slightly different question. (And, given the track record of Web
PKI CAs, I expect some baseline level of bogus IDevIDs to be out there.)
> The question then becomes how the Registrar comes to trust/verify the
> pledge's IDevID. We had a long discussion about this during the directorate
> reviews and going back to Feb. 2018. I thought that we resolved this.
> Issues
> https://github.com/anima-wg/anima-bootstrap/issues/120
> https://github.com/anima-wg/anima-bootstrap/issues/43
> https://github.com/anima-wg/anima-bootstrap/issues/46
> A thread starts here:
> https://mailarchive.ietf.org/arch/msg/anima/p7pUw1HKq6Ot0gV8JPeRWhwvQTs
>
> Some changes that we made for this:
>
> https://github.com/anima-wg/anima-bootstrap/commit/e5ffec4cc703626012d62c0b3138d851b61a2f54
Maybe, "Configuration or distribution of these trust anchor databases is
out-of-scope of this specification. Note that the trust anchors
in/excluded from the database will affect which manufacturers' devices are
acceptable to the registrar as pledges, and can also be used to limit the
set of MASAs that are trusted for enrollment."?
> > Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage
> > extensions in the IDevID certificate. Any restrictions included
>
> > I only got my hands on the 2018 rev of [IDevID], but that one does not
> > actually talk about extendedKeyUsage.
>
> Max was the editor of the 2009 edition, and we pointed at it.
> I don't seem to be able to get the 2018 edition.
I think we could probably reword this to just acknowledge that [IDevID]
acknowledges that adding restrictions in the certificate can limit
applicability, and since these are long-lived, usually you don't want to
throw random extra restrictions into them.
> 7.2.13:
>
> 7.2.13 extensions
>
> The optional extensions field defined in RFC 5280 shall not be used for
> critical extensions in any IDevID credential with the exception of the
> keyUsage extension. The non-critical extensions included are specified
> in 7.2.5 (authorityKeyIdentifier) and 7.2.9 (subjectAltName).
> The key usage field defined in RFC 5280 is intended to restrict the
> associated key material to only the
> specified usages. The intention of an IDevID is to provide a long lived
> credential useful for identifying the
> device in any future protocol uses. Restrictions applied during issuance may
> limit the future usefulness of
> the DevID. If a critical keyUsage extension is included in the IDevID, it
> shall include digitalSignature as
> defined in RFC 5280. The keyUsage extension may include keyEncipherment.
> The optional extensions field defined in RFC 5280 should not be used for
> critical extensions in any LDevID
> credential. As specified in RFC 5280 a network solution that uses the LDevID
> credentials and encounters a
> critical extension it does not understand will signal an error and fail
> validation of the LDevID credential.
>
> I don't know why this advice against EKU is gone from the 2018 edition.
"Which part is the advice against EKU?"
> > Section 2.3.1
>
> > In the context of BRSKI, pledges are uniquely identified by a
> > "serial-number". This serial-number is used both in the "serial-
> > number" field of voucher or voucher-requests (see Section 3) and in
> > local policies on registrar or MASA (see Section 5).
>
> > (editorial) if the IDevID is supposed to be a unique identifier, why do
> > we need another one?
>
> The pledge extracts it from it's IDevID.
> The registrar extracts it again from the IDevID that it sees.
> It's seems hard to construct an attack where the provisional TLS connection
> is MITM (replacing the certificates). So I'm gonna claim belt-and-suspenders
> here.... the cross-check seems useful, but maybe in the end, it's a left-over
> From when voucher-requests could be unsigned.
I don't actually have a big complaint, here (and am definitely not asking
to change the wire bits!). Perhaps we could go easy on "unique" or maybe
just acknowledge that there's supposed to be a 1:1 map between serial
number and IDevID. (Or not, of course.)
> > o The subject field's DN encoding MUST include the "serialNumber"
> > attribute with the device's unique serial number. (from [IDevID]
> > section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard
> > attributes)
>
> > side note: I had to think a bit to convince myself that DN is the right
> > thing here; when we use dnsNames it's preferred to put them in
> > subjectAltName to avoid having to pick a preferred/privileged one, but
> > the serial number does seem to be in a privileged position for
> > distinguishing the subject.
>
> The dnsNames are hard to use when we have no FQDN to attach to :-)
>
> > o The subject-alt field's encoding MAY include a non-critical
> > version of the RFC4108 defined HardwareModuleName. (from [IDevID]
> > section 7.2.9) If the IDevID is stored in a Trusted Platform
> > Module (TPM), then this field MAY contain the TPM identification
> > rather than the device's serial number. If both fields are
> > present, then the subject field takes precedence.
>
> > "if both fields are present", but the subject field MUST be present, so
> > this field can never take precedence.
>
> I'm willing to drop, because I never got proper clarification.
> We were told by implementors that if the IDevID is contained in a TPM that
> the resulting IDevID often has the serialNumber of the TPM,not the device
> itself.
>
> *** MAX ***
>
> > 1. [RFC4519] section 2.31 provides an example ("WI-3005") of the
> > Distinguished Name "serialNumber" attribute. [RFC4514] indicates
> > this is a printable string so no encoding is necessary.
>
> > I don't understand why these references were chosen. Why are LDAP specs
> > authoritative about what the encoding format for the serialNumber DN
> > attribute is? E.g., one could look at RFC 5280 to see that
> > X520SerialNumber is a PrintableString.
>
> *** MAX ***
>
> > 2. The HardwareModuleName hwSerialNum OCTET STRING. This value is
> > base64 encoded to convert it to a printable string format.
>
> > Please cite Section 4 of RFC 4648 (unless you mean base64url, in which
> > case use Section 5).
> > Also, it might be nice to somehow (maybe enumerate the first list in
> the same
> > way) tie these two items to the respective subject ND/subjectAltName
> > fields, to clarify why these are the only two choices.
>
> > As explained in Section 5.5 the Registrar MUST extract the serial-
> > number again itself from the pledge's TLS certificate. [...]
>
> > To be clear, this is still the device's IDevID certificate, that just
> > happens to be getting used as a TLS client certificate.
>
> Yes, that's right.
>
> > Section 2.3.2
>
> > nit: maybe put a blank line after the IMPORTS are over?
>
> done.
>
> > Section 2.4
>
> > In Figure 3, I had to think a bit to figure out whether the text that
> > did not fit mid-arrow was supposed to apply to the arrow above or below
> > the text (e.g., "optional: mDNS query RFC6763/RFC6762").
>
> Yes... we did struggle to fit it into a single page.
> It applies to both the arrow above and below, and there are M_FLOOD
> and mDNS possible here. Do you have suggestions on making it clearer.
Hmm, maybe give each one a unique symbol (+*&$#?) and put that in the
middle of the relevant arrows as well as in the text?
> > [Hmm, so we send our TLS client cert on the provisional connection,
> > meaning that we have to trust the proxy and registrar to be doing the
> > right thing w.r.t. broadcasting our identity to the world]
>
> Yes. TLS1.3 makes the certificate less visible to onlookers, but still a MITM
> would be able to collect it.
>
> We spent some time considering if we could turn the connection around so that
> the Registrar spoke first, giving the Pledge the opportunity to decide
> whether to provide it's identity or not.
> But, how would it decide?
Indeed.
> In the ANI case, we are likely doing this over wired links (long-haul fiber
> or internal to DC), but in the anticipated TEAP-BRSKI use case or 6tisch
> use, this would be WIFI / 802.15.4.
>
> What is needed is a three-party zero-knowledge proof, but how would the
> Registrar identify the third party (the MASA)?
>
> You are right to worry, but I don't know what to do about this.
I don't, either. Well, I do: "document it and move on", but that still
leaves a bad taste in my mouth.
> > Section 2.5.1
>
> > The pledge is the device that is attempting to join. Until the
> > pledge completes the enrollment process, it has link-local network
> > connectivity only to the proxy.
>
> > nit(?): I think there is a subtle difference in meaning between "only
> > has link-local network connectivity to the proxy" and this text, and I'm
> > not sure which is intended.
>
> I'm confused.
The current text asserts that it has link-local connectivity, and further
that the extent of this connectivity is limited to the proxy. My
alternative asserts that it can only talk to the proxy over this link-local
connectivity, but leaves open the possibility of other avenues of
communication (e.g., a WWAN card).
> > Section 2.5.3
>
> > This may just be my personal preference (so feel free to ignore), but
> > talking about a "trust store used to authenticate the MASA" and "trust
> > store used to authenticate the pledge" would feel more readable than
> > "trust anchor database for authenticating the [thing] TLS connection
> > [thing] certificate".
>
> > It may be worth some comment about how this requirement for out-of-band
> > distribution of implicit trust anchors is something that BRSKI is
> > designed to avoid, but that distributing to just the registrar is a much
> > more manageable task than distributing them to all devices/pledges.
>
> I think that the words "Implicit Trust Anchor" are supposed to invoke
> RFC7030's section 3.6.2. *** MAX ***
> I'm okay with your text too.
I have no way to tell what is just my personal preference and what is
objectively better, so feel free to ignore.
> > Section 2.5.5
>
> > The Public Key Infrastructure (PKI) administers certificates for the
> > domain of concerns, providing the trust anchor(s) for it and allowing
>
> > nit: "domain of concern" singular
>
> fixed.
>
> > The voucher provides a method for the distribution of a single PKI
> > trust anchor (as the "pinned-domain-cert"). A distribution of the
>
> > Earlier we talked about the "pinned-domain-cert leaf" in the domainID
> > definition. Was that supposed to be "leaf" in the YANG sense and not
> > in the PKIX "leaf certificate"/"end-entity certificate" sense?
>
> Yes.
> I'll change "leaf" above to "attribute"
>
> > The expectations of the PKI are unchanged from EST [[RFC7030]]. This
> > Which parts of RFC 7030 talk about its expectations of the PKI?
>
> The fact that the public key infrastructure can enroll new
> end-entity certificates? I agree that 7030 doesn't really set out
> the expectations in one place.
> *** MAX ***
>
> > Section 2.6.1
>
> > Many devices when bootstrapping do not have knowledge of the current
> > time. Mechanisms such as Network Time Protocols cannot be secured
> > until bootstrapping is complete. Therefore bootstrapping is defined
> > in a method that does not require knowledge of the current time. A
>
> > nit: I'd suggest maybe "framework", "scenario", or "environment" rather
> > than "method".
>
> done.
>
> > Section 2.6.2
>
> > [RFC5280] explains that long lived pledge certificates "SHOULD be
> > assigned the GeneralizedTime value of 99991231235959Z". Registrars
>
> > This misses the important "for the notAfter field" part.
(The above and below were separate comments; not sure if that came
through.)
> > Why is 3 years the relevant cutoff here?
>
> That's a good question. *** MAX ***
>
> > Section 2.7
>
> > There exist operationally open network wherein devices gain
>
> > nit: "networks" plural
>
> fixed.
>
> > unauthenticated access to the internet at large. In these use cases
> > the management domain for the device needs to be discovered within
> > the larger internet. These are less likely within the anima scope
> > but may be more important in the future.
>
> > nit: less likely than what?
>
> changed to:
> The case where a device can boot and get access to
> larger Internet are less likely within the ANIMA ACP scope but may
> be more important in the future.
> In the ANIMA ACP scope, new
> devices will be quarantined behind a Join Proxy.
>
> > In order to support these scenarios, the pledge MAY contact a well
> > known URI of a cloud registrar if a local registrar cannot be
> > discovered or if the pledge's target use cases do not include a local
> > registrar.
>
> ben> I don't see the connection between "configure itself to become the
> ben> local registrar" and "contact a well-known URI of a cloud registrar".
>
> In a completely Greenfield situation, where there is no local infrastructure
> at all, given an appropriately magic "Intent" (remember where this WG
> started...), then a cloud registrar could inform a device that it is
> to become the Registrar. How this would work depends upon the details
> of the magic unicorn Intent (see failed SUPA WG).
Ah. So the cloud registrar is an extra-featureful registrar that can do
more than just register things. I get it now, but am not sure how to best
word it.
> > If the pledge uses a well known URI for contacting a cloud registrar
> > an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
> > authenticate service as described in [RFC6125]. This is consistent
>
> ben> Would this be more likely to be installed by the manufacturer or
> ben> device owner?
>
> Manufacturer, as it's implicit. That's how EST works today.
So you think "implicit" is enough and adding something like "burned-in" or
"manufacturer-assigned" is overkill?
> > nit: "service" needs an article.
>
> add "that"
>
> > Section 2.8
>
> > approach if they ensure a single MASA URL works for all pledge's
> > associated with each trust anchor.
>
> > nit: "pledges" non-possessive
>
> Seems pledges should be plural to be.
> Changed to:
> This is useful for Registrars which are servicing pledges on directly
> connected networks.or plural
>
> > Section 3
>
> > A pledge forms the "pledge voucher-request" and submits it to the
> > registrar.
>
> already fixed.
>
> > The "proximity-registrar-cert" leaf is used in the pledge voucher-
> > requests. This provides a method for the pledge to assert the
> > registrar's proximity.
>
> > "proximity" in what sense? How much verification/confidence needs to be
> > done? (Also, I would have expected the assertion to go the other way;
> > that the registrar asserts the pledge's proximity -- how does the pledge
> > have a way to know that the registrar is nearby when the proxy is
> > transparent?)
>
> There is a TLS connection between them. Yes, it could go anywhere.
> The proxy was link-local, and the proxy pointed the connection at the
> Registrar. I guess it would be useful if the proxy was stateful, and
> contributed another cryptographic layer for non-ACP cases.
>
> In the ACP case, the Registrar knows it can trust the proxy because it's on
> the ACP, and is connecting from an ULA address that is part of the ACP.
>
> Yes, the Registrar could be anywhere, but the proxy makes it appear
> to be on the local link.
>
> I'm not sure what else I can add to the text.
"There is a TLS connection between a and b" says almost nothing without
some additional context -- there are millions of machines I can make a TLS
connection to from here. I assume that the unstated context here is that
the pledge is expected to be in a limited-connectivity environment, so the
fact that the network allowed the connection through to the registrar
conveys meaning. But I don't remember anything in this document that
actually validates that the pledge really is in a limited network
environment. Could some rogue node ("attacker") be trying to talk to a
proxy or registrar directly, from somewhere else in the network? How would
we tell?
> > Section 3.3
>
> > Example (1) The following example illustrates a pledge voucher-
> > request. The assertion leaf is indicated as 'proximity'
> > and the registrar's TLS server certificate is included
> > in the 'proximity-registrar-cert' leaf. See
> > Section 5.2.
>
> > {
> > "ietf-voucher-request:voucher": {
> > "nonce": "62a2e7693d82fcda2624de58fb6722e5",
> > "created-on": "2017-01-01T00:00:00.000Z",
> > "proximity-registrar-cert": "base64encodedvalue=="
> > }
> > }
>
> > I do not see an 'assertion' leaf populated.
>
> added.
>
> > Example (2) The following example illustrates a registrar voucher-
> > request. The 'prior-signed-voucher-request' leaf is
> > populated with the pledge's voucher-request (such as the
> > prior example). The pledge's voucher-request is a
> > binary object. In the JSON encoding used here it must
>
> > Why is it a binary object? We just saw a previous example with a JSON
> > (non-binary) encoding. (Hint: CMS-signed,but we didn't say that.)
>
> okay, I'll say that.
>
> > There is (again) no assertion, and the created-on does not match
> > exactly.
>
> added.
>
> > Section 3.4
>
> > The RFC 8174 version of the BCP 14 boilerplate could be used in the
> > module, too.
> > Also, is the 2017 copyright still correct, especially given that it is a
> > 2018-02-14 revision?
>
> already fixed.
> fixing date.
>
> > For example, a pledge might sign a voucher request
> > with a proximity-registrar-cert, and the registrar
> > then includes it in the prior-signed-voucher-request field.
>
> > nit: maybe "includes it" could be disambiguated (perhaps s/in/as/)?
>
> okay.
>
> > This is a simple mechanism for a chain of trusted
> > parties to change a voucher request, while
> > maintaining the prior signature information.
>
> > "chain" seems to admit the possibility of more than one
> > modification/resigning event, but the architecture as described seems to
> > only have the registrar doing this.
>
> Yes. prior-signed-voucher-request could be used in new ways.
>
> > registrar agree on proximity assertions. The MASA SHOULD
> > remove all prior-signed-voucher-request information when
> > signing a voucher for imprinting so as to minimize the
> > final voucher size.";
>
> > (side note?) This removal would open up some minor exotic attacks in
> > cases where a pledge reuses an existing nonce (potentially from a
> > different device), but is probably an okay tradeoff to make.
>
> agreed.
>
> > The first certificate in the Registrar TLS server
> > certificate_list sequence (see [RFC5246]) presented by
> > the Registrar to the Pledge. This MUST be populated in a
> > Pledge's voucher request if a proximity assertion is
> > requested.";
>
> > 5246 is replaced by 8446.
>
> okay. Annoying to have references in the YANG module itself.
>
> > It might be simplest to just say the "end-entity TLS certificate", at
> > least for TLS practitioners. (Maybe nof for a different audience,
> > though.)
> > How do I know that a proximity assertion is requested?
>
> That is, How does the pledge knows it wants one?
> Because it's been programmed that way.
> I have removed "if", and replaced it with "when".
> I have added the words "end-entity TLS certificate" to hammer the point.
>
> > Section 4
>
> > The role of the proxy is to facilitate communications. The proxy
> > forwards packets between the pledge and a registrar that has been
> > provisioned to the proxy via GRASP discovery.
>
> > [same DULL question as above]
>
> It's not DULL, because this is the Proxy speaking within the ACP.
> I will write "full GRASP".
>
> > The proxy does not terminate the TLS handshake: it passes streams of
> > bytes onward without examination. A proxy MUST NOT assume any
> > specific TLS version.
>
> > Passing bytes without examination is by definition not assuming any
> > version of TLS. So while I think it would make the most sense to just
> > remove that sentence, if it's going to say it might be worth also
> > noting the TLS invariants discussed in
> > https://tools.ietf.org/html/rfc8446#section-9.3 .
>
> added reference.
>
> > Section 4.1
>
> > through a proxy. The proxy is transparent to the pledge. The
> > communication between the pledge is over IPv6 Link-Local addresses.
>
> > nit: between the pledge and what?
>
> Join Proxy added.
>
> > M_FLOOD. The active methods SHOULD exponentially back-off to a
> > maximum of one hour to avoid overloading the network with discovery
> > attempts. Detection of change of physical link status (ethernet
> > carrier for instance) SHOULD reset the exponential back off.
>
> > Mathematically, "exponential" requires to specify the base of the
> > exponent (or just say "by doubling"). (Also later in the section.)
>
> Well, of course the base should be "e" :-)
> I'll write doubling.
>
> > Once all discovered services are attempted (assuming that none
> > succeeded) the device MUST return to listening for GRASP M_FLOOD. It
> > SHOULD periodically retry the manufacturer specific mechanisms. The
> > pledge MAY prioritize selection order as appropriate for the
> > anticipated environment.
>
> > nit: "manufacturer-specific" takes a hyphen
> > not-nit: what are "the manufacturer-specific mechanisms"? (I don't
> > remember such discussion yet.)
>
> 1) Appendix A and Appendix B.
> 2) a bunch of manufacturers have proprietary equivalent of BRSKI.
> I think that this includes both Cisco and Juniper.
>
> > Section 4.1.1
>
> > Is Figure 6b supposed to be using JSON diagnostic notation for CBOR or
> > some other notation?
> > Also, I'm not sure that picking an arbitrary (representative) session-id
> > value, LL address, and port is helpful when describing the formatting of
> > the message. Maybe some different introductory text would change
> > things.
>
> I have placed the example after the CDDL.
>
> > Section 4.3
>
> > If we're only defining an EST-TLS objective, how will proxies know that
> > the registrar supports BRSKI?
>
> > It's a little weird to put the reference for GRASP but not ACP. Either
> > none or both would feel more natural (given that we've seen both already
> > a couple times).
>
> The name is "AN_join_registrar", which implies BRSKI.
> The objective-value of "EST-TLS" means EST. (vs CMP or some other enrollment
> mechanism that people have asked for). There could be many announcements
> From different things.
Ah, I was misparsing the diagnostic notation, sorry.
> This announcement and the Join Proxy described here only applies to ACP.
>
> Added:
> <t>
> This section applies is normative for uses with an ANIMA ACP.
> The use of GRASP mechanism part of the ACP.
> Other users of BRSKI will need to define an equivalent proxy
> mechanism, and an equivalent mechanism to configure the proxy.
> </t>
>
> the beginning of section 4.
and thank you for the clarification!
> > Section 5
>
> > MASA URI is "https://"; iauthority "/.well-known/est".
>
> > nit: "The MASA URI".
> > Is this always the case, with no opportunity for modification, even as
> > included in an IDevID certificate extension?
>
> Either just the iauthority (now "authority") is present in the IDevID, or the
> entire URL (with ports numbers and paths) is present. I think that is what
> you want.
>
> > BRSKI uses JSON [RFC7159] for all new operations defined here, and
>
> > RFC 7159 is obsoleted by RFC 8259.
>
> already fixed.
>
> > While EST section 3.2 does not insist upon use of HTTP 1.1 persistent
> > connections, BRSKI-EST connections SHOULD use persistent connections.
> > The intention of this guidance is to ensure the provisional TLS state
> > occurs only once, and that the subsequent resolution of the provision
> > state is not subject to a MITM attack during a critical phase.
>
> > I think we probably want a requirement that if persistent connections
> > are not used (and what about HTTP/2 or HTTP/3 ones?), the pledge MUST
> > check that the exact same certificate is used to authenticate the
> > registrar for all transactions. If the signature in the handshake is
> > valid but you can only chain the certificate up to your trust anchor
> > once you finish imprinting, you still know that the entire session's
> > data has been talking to the now-authenticated party (as opposed to the
> > TLS case where you try to add a new certificate mid-connection, where
> > that boundary is unclear), but things are much easier to reason about if
> > you are sure that each EST transaction is talking to the same peer.
>
> We had a conversation two years ago about what we might need to say about
> HTTP/2, and aside from being unable to handle QUIC (due to proxy), we don't
> see any issue.
>
> I have added:
> <t>
> If non-persistent connections are used, then both the pledge and
> the registrar MUST remember the certificates seen, and also sent
> for the first connection. They MUST check each subsequent
> connections for the same certificates, and each end MUST use
> the same certificates as well. This places a difficult restriction
> on rolling certificates on the Registrar.
> </t>
>
> But, that's why we have SHOULD, and the SHOULD (vs MUST) part was really to
> allow for some fancy HTTP/3 we know nothing about :-)
:)
Do we still want to say "HTTP 1.1 persistent connections" vs. "HTTP
persistent connections", though?
> > o In the language of [RFC6125] this provides for a SERIALNUM-ID
> > category of identifier that can be included in a certificate and
> > therefore that can also be used for matching purposes. The
> > SERIALNUM-ID whitelist is collated according to manufacturer trust
> > anchor since serial numbers are not globally unique.
>
> > RFC 6125 does not define a SERIALNUM-ID, so maybe we could reword to "in
> > the model of RFC 6125" or "provides a new SERIAL-ID category" or
> > similar.
>
> I have an open request to *** MAX *** to clarify this part.
>
> > o The registrar performs log verifications in addition to local
> > authorization checks before accepting optional pledge device
> > enrollment requests.
>
> > Maybe give us a section reference to what the "log validations" are?
>
> We decided that we did not have enough experience to write normative language
> here. (It's not an Internet Standard)
It doesn't have to be normative, but some discussion of things that might
come into consideration during that process could still be useful.
-Ben
> > Section 5.1
>
> > Establishment of the BRSKI-EST TLS connection is as specified in EST
> > [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates"
> > [RFC7030] wherein the client is authenticated with the IDevID
> > certificate, and the EST server (the registrar) is provisionally
> > authenticated with an unverified server certificate.
>
> > I'd consider noting that the signature (or other operation) made by the
> > certificate must be validated, and that the received certificate and
> > chain must be retained for later validation.
>
> Added:
> <t>
> The signatures in the certificate MUST be validated even if a
> signing key can not (yet) be validated. The certificate (or
> chain) MUST be retained for later validation.
> </t>
> <t>
> A self-signed
> certificate for the Registrar is acceptable as the voucher
> will validate it.
> </t>
>
>
> > The pledge maintains a security paranoia concerning the provisional
> > state, and all data received, until a voucher is received and
> > verified as specified in Section 5.6.1
>
> > Since section 5.6.1 just talks about the voucher verification process, I
> > think we need to say more about what "security paranoia" entails:
> > acknowledging that all data transmitted is sent to an unauthenticated
> > peer, with corresponding privacy considerations, and that all received
> > data is not authenticated by the TLS connection and must be
> > self-authenticating or otherwise considered untrusted.
>
> <t>
> The pledge code needs to be written with the assumption that
> all data is being transmitted at this point to an
> unauthenticated peer, and that received data, while inside a
> TLS connection, MUST be considered untrusted. This
> particularly applies to HTTP headers and CMS structures that
> make up the voucher.
> </t>
>
>
> > A pledge that can not maintain as many connections as there are
> > eligible proxies. If no connection is making process after 5 seconds
>
> > nit: that's not a complete sentence.
>
> already fixed to:
> <t>
> A pledge that can not maintain as many connections as there are
> eligible proxies will need to rotate among the various choices,
> terminating connections that do not appear to be making
> progress.
>
> stopping here for today.
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | IoT architect [
> ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails
> [
>
>
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
