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

[Michael Richardson <[e-mail]>]

Benjamin Kaduk <[e-mail]> wrote:
    >> 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.

we added the following to the end of the point list:
          <t>
            Based upon the above information, the manufacturer is able to
            track a specific device from pseudonymous domain identity to the
            next pseudonymous domain identity.  If there is sales-channel
            integration, then the identities are not pseudonymous.
          </t>

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

One either has a list of trusted manufacturers or one does not.
This can be done via a list of trust anchors for the IDevID signing entity,
or can be done via a list of trust anchors for the MASA URL.

If not (in a residential use of BRSKI perhaps), then there has to be some
process by which a not previously known manufacturer can become trusted.
There are a great number of layer-8 or layer-9 solutions for this,
perhaps involving new industry CAs or attestations, or ...  I think it is out
of scope.
(for instance RFC5280 section 4.2.2.1 could provide the right references,
but this section has not been well used as yet.  Or we could extend the
MASA EST to include additional information)

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

we have added this to section 5.1.

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

We have determined that section 8.10.3 of the -2018 has the same text.
Neither Max nor I have the official -2018 version, so we are writing:

          Section 7.2.13 (2009 edition) and section 8.10.3 (2018 edition) of
          <xref target="IDevID" /> discusses keyUsage and

Our recommendation continues to be that no EKU be added (consistent
with 1AR, if you have to, then it has to include digitalSignature).

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

I went with 1:1 text.

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

I'm not sure what you mean.
  https://github.com/anima-wg/anima-bootstrap/edit/master/time-sequence-diagram.txt

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

new section added:

 	10.2.  What BRSKI-EST reveals to the registrar

 	   During the provisional phase of the BRSKI-EST connection between the
 	   Pledge and the Registrar, each party reveals it's certificates to
 	   each other.  For the Pledge, this includes the serialNumber
 	   attribute, the MASA URL, and the identity that signed the IDevID
 	   certificate.

 	   TLS 1.2 reveals the certificate identities to on-path observers,
 	   including the Join Proxy.

 	   TLS 1.3 reveals the certificate identities only to the end parties,
 	   but as the connection if provisional, an on-path attacker will see
 	   the certificates.  This includes not just malicious attackers, but
 	   also Registrars which are visible to the Pledge, but which are not
 	   part of the the intended domain.

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

I guess by WWAN card, you mean some kind of LTE or 5G connection?
Or do you mean 802.11/802.15.4?  The distinction matters, because LTE
cards have SIM cards, and therefore are not zero-touch.

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

Oh, I get it.  Added "for the notAfter field"

    >> > Why is 3 years the relevant cutoff here?
    >>
    >> That's a good question. *** MAX ***

okay, changed text.

    [RFC5280] explains that long lived pledge certificates "SHOULD be
-   assigned the GeneralizedTime value of 99991231235959Z".  Registrars
-   MUST support such lifetimes and SHOULD support ignoring pledge
-   lifetimes if they did not follow the RFC5280 recommendations.
+   assigned the GeneralizedTime value of 99991231235959Z" for the
+   notAfter field.

-   For example, IDevID may have incorrect lifetime of N <= 3 years,
-   rendering replacement pledges from storage useless after N years
-   unless registrars support ignoring such a lifetime.
+   Some deployed IDevID management systems are not compliant with the
+   802.1AR requirement for infinite lifetimes, and put in typical <= 3
+   year certificate lifetimes.  Registrars SHOULD be configurable on a
+   per-manufacturer basis to ignore pledge lifetimes when they did not
+   follow the RFC5280 recommendations.

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

The point of that section is to rule (magic unicorns) out of scope.
It doesn't really matter if we describe the magic correctly, does 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?

We are trying to use the EST terminology here.... how about:

-              an Implicit Trust Anchor database (see <xref target="RFC7030"/>) MUST
+              a manufacturer-assigned Implicit Trust Anchor database (see <xref target="RFC7030"/>) MUST

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

The pledge has made a connection over a Link-Local IPv6 connection.
The Registrar has a connection from a ULA numbered Join Proxy across
the ACP.   That's not a connection across the Internet.  It's true
that neither end can validate what the other end sees.

The Join Proxy could be doing something else: it could punt the connection
elsewhere, or it could channel (in the séance sense) a pledge from some
other place.  If that were occuring, there would indeed be some problem.

Other proposed uses of BRSKI (TEAP-BRSKI) would connect using EAP
over 1x+radius/diameter.

Would some addition to the ACP applicability stating the above
be useful?

    >> 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'll remove the 1.1.
At the time, we didn't know what HTTP/2 would have.
I think we asked, and were told that HTTP/2 always had persistent
connections, so there was nothing really to say.  I see this as a
statement to some product manager that they really do need to
upgrade their 1998 era HTTP library with something newer.

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

I really think that 5.8.3 says enough.

I have 39 emails in my to-read relating to other DISCUSS.

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