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

[Michael Richardson <[e-mail]>]

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.

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.

    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.

    >> 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.

    >> 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.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [





--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-