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

[Benjamin Kaduk <[e-mail]>]

On Wed, Aug 14, 2019 at 09:10:26PM -0400, Michael Richardson wrote:
> 
> 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>

Thanks!

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

I agree that we don't need to talk about all the different ways by which a
previously unknown manufacturer could become trusted.  Mostly just the word
"secure" caught me up.

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

Definitely!

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

Proof of concept in https://github.com/anima-wg/anima-bootstrap/pull/135 .
Feel free to say it doesn't make sense :)

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

Thanks.

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

Um.  I think I meant LTE, along the lines of how I can buy a car these days
that will "phone home" to the dealer when I need to go in for service.

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

Ah, that is much clearer to me; thanks.

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

I don't think we have an IETF spec for unicorns, no.  Maybe there's an ISO
standard unicorn?

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

That works for me.  And, honestly, leaving it as-is would be okay.

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

Oh sure, the link-local IPv6 of the proto-ACP would be a great way to show
locality.  Please do add some text regarding the ACP applicability.

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

It probably does (and we should feel free to forward-reference it from
here).

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

Oh my; keep up the good work!  But do take breaks periodically...

Thanks,

Ben