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 <ka...@mit.edu> 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 [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
