Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

While recovering from today's telechat, I noticed that I seem to have never
replied to this one!  (Luckily, there's not much to say...)

On Mon, Sep 16, 2019 at 05:46:37PM -0400, Michael Richardson wrote:
> 
> Combining your August 9 and September 3 emails, and removing resolved items.
> 
> https://tinyurl.com/y2kmjqmm for diffs aginst -26.
> (also includes changes for Alexey)
> Submitting -27 in process.
> 
> Benjamin Kaduk <[e-mail]> wrote:
>     >> 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.
> 
> Subsequent discussion with my co-authors has pointed out that the
> certificate that will be pinned in the voucher (as pinned-domain-cert) is the
> *domain cert*, that is, the domain's CA.  As a CA, will most likely have the
> right SubjectKeyIdentifier calculated already.

Maybe I've just been reading too many copies of different text in flux, but
I'm not sure that the current text gives me a clear picture of who picks
what will be pinned and how much choice they have in the matter.  But, if
it's the "root" (last certificate in the chain) presented by the registrar
for the provisional TLS connection, I think things are pretty
self-consistent about it.

> We had updated section 5.8.2 in -26 to clarify things.
> We moved the domainID definition out of the terminology section (which is
> where the SHA-1 stuff was), to point at 5.8.2, and point to rfc7469, which
> provides an algorithm agile definition.
> 
>     >> > 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
> 
> missing "be" added to section 2.1, point 5.
> 
>     doc> 1.  Uniquely identifying the pledge by the Distinguished Name (DN)
>     doc> and subjectAltName (SAN) parameters in the IDevID.  The unique
>     doc> identification of a pledge in the voucher objects are derived
>     doc> 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.
> 
> I've tweaked some text, in section 10.3, but I feel I am just moving the
> chairs around on the Titanic here.
> 
>     doc> 3.  Secure auto-discovery of the pledge's MASA by the registrar (see
>     doc> Section 2.8).
> 
>     ben> I don't think this is an ironclad property, since the crypto chain is
>     ben> slightly limited and you are in effect trusting the pledge to hand you
>     ben> something that says "use this issuer" but without as much crypto to back
>     ben> that up as we might want.  We have to know that the given manufacturer
>     ben> that signed the IDevID actually is associated with the device we're
>     ben> trying to bootstrap, which can probably be arranged but I don't remember
>     ben> being called out explicitly.
> 
>     mcr> There are two issues here.
> 
>     mcr> One is the question of what is the list of acceptable manufacturers (below).
>     mcr> The second part is whether a pledge could provide a fake IDevID to
>     mcr> the Registrar.  The pledge is doing TLS ClientCertificate, so the TLS
>     mcr> has proven that the pledge has the private key corresponding to the
>     mcr> certificate presented.  I conclude that an arbitrary IDevID can not be
>     mcr> 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.
> 
> Yes.  Even if we throw full Remote Attestation at the problem, if the
> Registrar decides to trust Malware Inc. to attest to it's BFR's then it's
> gonna have Malware.
> 
>     mcr> manufacturer A could point it's product at MASA B, but I don't see how this
>     mcr> is an issue if MASA B will issues vouchers that pledge A can verify.
> 
>     mcr> (The pledge could have a variety of certificates from
>     mcr> a variety of sources, perhaps all bound to the same public key, I guess, and
>     mcr> since the Registrar sends it's certificate first, the pledge could present
>     mcr> different identities to different networks. I think that this is a feature,
>     mcr> not a bug.  It reminds that "Kenmore" brand appliances were made by a variety
>     mcr> of manufacturers, but I don't see my dishwasher can know what identity
>     mcr> to use until after there is communication with the MASA)
> 
>     ben> Sure, that is probably a feature at least in some cases.
>     ben> But can we assume that a given pledge has a single distinguished
>     ben> MASA?
> 
> Yes.

Okay.  I think that means I don't want to ask for any text changes as a
result.

>     ben> The pledge gives the registrar a thing that says "go here for my MASA", and
>     ben> the registrar can do a fair bit of validation on that, but there's still
>     ben> potentially some control in the pledge's hands about where the registrar
>     ben> goes to, and lots of room for attack by hostile pledges if the registrar is
>     ben> buggy.
> 
> Buggy in what way?
> A registrar which allows any manufacturer's IDevID can be fooled^Wconvinced into talking
> to a MASA of a malicious pledge's choice.
> 
>     ben> It's not like there's a single authoritative (global) database of (device,
>     ben> MASA) pairs that we can query and have unconditional trust is giving the
>     ben> right result (and validating what device we're looking up, even).  Things
>     ben> are fragmented, and at the protocol level, we can't be confident that we
>     ben> wouldn't get a different (valid!) answer if we asked somewhere else, or
>     ben> asked a slightly different question.
> 
> It's not inconceivable to me that some specialized CAs (akin to the Extended
> Validation certificates) could come to be that would sign the
> ServerCertificates for MASA from entities that comply to some industry led criteria.
> 
>     ben> (And, given the track record of Web
>     ben> PKI CAs, I expect some baseline level of bogus IDevIDs to be out
>     ben> there.)
> 
> I'm not exactly sure how this would occur, but I concede that this could be
> the case.
> 
>     mcr> The question then becomes how the Registrar comes to trust/verify the
>     mcr> pledge's IDevID.  We had a long discussion about this during the directorate
>     mcr> reviews and going back to Feb. 2018.  I thought that we resolved this.
>     mcr> Issues
>     mcr> https://github.com/anima-wg/anima-bootstrap/issues/120
>     mcr> https://github.com/anima-wg/anima-bootstrap/issues/43
>     mcr> https://github.com/anima-wg/anima-bootstrap/issues/46
>     mcr> A thread starts here:
>     mcr> https://mailarchive.ietf.org/arch/msg/anima/p7pUw1HKq6Ot0gV8JPeRWhwvQTs
>     mcr>
>     mcr> Some changes that we made for this:
>     mcr> https://github.com/anima-wg/anima-bootstrap/commit/e5ffec4cc703626012d62c0b3138d851b61a2f54
> 
>     ben> Maybe, "Configuration or distribution of these trust anchor databases is
>     ben> out-of-scope of this specification.  Note that the trust anchors
>     ben> in/excluded from the database will affect which manufacturers' devices are
>     ben> acceptable to the registrar as pledges, and can also be used to limit the
>     ben> set of MASAs that are trusted for enrollment."?
> 
> Added.
> 
>     doc> Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage
>     doc> 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.
>     >>
>     mcr> Max was the editor of the 2009 edition, and we pointed at it.
>     mcr> I don't seem to be able to get the 2018 edition.
> 
>     ben> I think we could probably reword this to just acknowledge that [IDevID]
>     ben> acknowledges that adding restrictions in the certificate can limit
>     ben> applicability, and since these are long-lived, usually you don't want to
>     ben> throw random extra restrictions into them.
> 
>          <t>
>            Section 7.2.13 (2009 edition) and section 8.10.3 (2018 edition) of
>            <xref target="IDevID" /> discusses keyUsage and
> -          extendedKeyUsage extensions in the IDevID certificate.  Any
> -          restrictions included reduce the utility of the IDevID and so
> -          this specification RECOMMENDS that no key usage restrictions be included.
> -          Additionally, <xref target="RFC5280" /> section 4.2.1.3 does not
> +          extendedKeyUsage extensions in the IDevID certificate.
> +          <xref target="IDevID" /> acknowledges that adding restrictions
> +          in the certificate limits applicability of these long-lived
> +          certificates.  This specification emphasizes this point, and
> +          therefore RECOMMENDS that no key usage restrictions be included.
> +          This is consistent with <xref target="RFC5280" /> section 4.2.1.3,
> +          which does not
>            require key usage restrictions for end entity certificates.
>          </t>
> 
> 
>     mcr> The pledge extracts it from it's IDevID.
>     mcr> The registrar extracts it again from the IDevID that it sees.
>     mcr> It's seems hard to construct an attack where the provisional TLS connection
>     mcr> is MITM (replacing the certificates). So I'm gonna claim belt-and-suspenders
>     mcr> here.... the cross-check seems useful, but maybe in the end, it's a left-over
>     mcr> From when voucher-requests could be unsigned.
> 
>     ben> I don't actually have a big complaint, here (and am definitely not asking
>     ben> to change the wire bits!).  Perhaps we could go easy on "unique" or maybe
>     ben> just acknowledge that there's supposed to be a 1:1 map between serial
>     ben> number and IDevID.  (Or not, of course.)
> 
> Text previously added:
>             In the context of BRSKI, pledges have a 1:1 relationship
>             with a "serial-number".
> 
>     >> 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.
> 
> Just added:
> 
>           <t>
>             The certificate of the Registrar is rather arbtirary from the
>             point of view of the BRSKI protocol. As no <xref target="RFC6125" />
>             validations are expected to be done, the contents could be easily
>             pseudonymized.  Any device that can see a join proxy would be
>             able to connect to the Registrar and learn the identity of the
>             network in question.  Even if the contents of the certificate
>             are pseudonymized, it would be possible to coorelate different
>             connections in different locations belong to the same
>             entity. This is unlikely to present a significant privacy concern
>             to ANIMA ACP uses of BRSKI, but may be a concern to other users
>             of BRSKI.
>           </t>
>           <t>
>             The certificate of the Pledge could be revealed by a malicious
>             Join Proxy that performed a MITM attack on the provisional TLS
>             connection.   Such an attacker would be able to reveal the
>             identity of the Pledge to third parties if it chose to so.
>           </t>
>           <t>
>             Research into a mechanism to do multi-step, multi-party authenticated
>             key agreement, incorporating some kind of zero-knowledge proof
>             would be valuable.  Such a mechanism would ideally avoid
>             disclosing identities until pledge, registrar and MASA agree to
>             the transaction.  Such a mechanism would need to discover the
>             location of the MASA without knowing the identity of the pledge,
>             or the identity of the MASA.  This part of the problem may be unsolveable.
>           </t>
> 
>     >> > 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).
> 
> changed to:
>           <t>
>             The pledge is the device that is attempting to join.
>             The pledge can talk to the Join Proxy using link-local network
>             connectivity.  In most cases, the pledge has no other
>             connectivity until the pledge completes the enrollment process
>             and receives some kind of network credential.
>           </t>
> 
>     >> > 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.)
> 
> I think that I got it. It says:
> 
>           <t>
>             <xref target="RFC5280" /> explains that
>             long lived pledge certificates "SHOULD be assigned the
>             GeneralizedTime value of 99991231235959Z" for the notAfter field.
>           </t>
> 
>     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.
> 
> I don't know what it can do, because it's not in scope.
> 
>     >> > 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?
> 
> It says:
>       a manufacturer-assigned Implicit Trust Anchor database (see <xref target="RFC7030"/>) MUST
> 
> now.
> 
>     >> 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?
> 
> There is a TLS connection from the ACP's ULA/128 to ULA/128 implies that it's not going
> the Internet directly.
> 
> A rogue node could be on the join network (the one with link-local
> connectivity), and could operate and announce a Join Proxy.
> 
> What could it do?
> a) it could have some other backhaul (1200-baud modem, LTE, 100G, etc.) that
>    connects it to some (other?) Registrar.  Whether or not this is a malicious
>    attack, or just another possible network depends upon intent (in the legal
>    sense, not the SUPA sense)
> 
> b) it could double proxy the traffic to another Join Proxy on the real
>    network. It could then observe TLS framing, which for TLS 1.2 means
>    observing certificates.  If it does not mount a MITM attack, then
>    it is not clear to me what it causes.
>    If it does mount a MITM attack, then it is just a malicious registrar,
>    and either it succeeds in getting a voucher issued (because the MASA
>    agrees), or it fails and the pledge moves on.
> 
> If the legitimate Registrar has a rogue Proxy on it's ACP network, then
> that's a great concern, but it's really not any different than (b).
> 
> I'm not sure what point I'm missing is.

I'm just reiterating that we have to be careful how we talk about the
proximity assertion; in the absence of knowing that the pledge is trying to
join the ACP and is talking to a member of the ACP over a link-local
address, there's not much to draw from the fact that there's a TLS
connection.  The -28 is in pretty decent shape about this, though I think I
noted one or two places in ballot.

>     >> 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?
> 
> I am using the latter now.

Please double-check; I think I saw one in the -28 (but didn't make a note
of where).

>     >> 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.
> 
> Section 5.8.3 has a fair bit of text on the log verificiations.
> I've added a forward reference.  Section 5.8.3 finishes with:
> 
>    A relatively simple policy is to white list known (internal or
>    external) domainIDs.  To require all vouchers to have a nonce.
>    Alternatively to require that all nonceless vouchers be from a subset
>    (e.g. only internal) of domainIDs.  If the policy is violated a
>    simple action is to revoke any locally issued credentials for the
>    pledge in question or to refuse to forward the voucher.  The
>    Registrar MUST then refuse any EST actions, and SHOULD inform a human
>    via a log.  A registrar MAY be configured to ignore (i.e. override
>    the above policy) the history of the device but it is RECOMMENDED
>    that this only be configured if hardware assisted (i.e.  TPM
>    anchored) Network Endpoint Assessment (NEA) [RFC5209] is supported.
> 
> And that's all the comments that I see.
> I believe I'm done.

We need to get you a prize for responding to so many comments.

Thanks again!

-Ben