On Wed, Aug 14, 2019 at 09:10:26PM -0400, Michael Richardson wrote: > > Benjamin Kaduk <[email protected]> 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 _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
