Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Benjamin Kaduk wrote: doc> The MASA and the registrars SHOULD be prepared to support TLS client doc> certificate authentication and/or HTTP Basic or Digest doc> authentication as described in [RFC7030] for EST clients. This doc> connection MAY also have no client authentication at all (Section doc> 7.4) >> > I don't see discussion of skipping client authentication in Section >> 7.4. > It would be great to have some, there! >> It's buried in point 2. > Oh, the "not verifying ownership" part? I somehow was interpreting > that as "we still require client authentication, but don't have a fancy > database mapping owner to hardware, so any authenticated registrar can > get a voucher for any device". There are multiple models on how to operate a MASA. We think that which one is right depends a lot on the value of the device (in the ACP space, $100K routers vs $100 CPE devices), and also at the degree of sales channel integration. There is value in authenticating the Registrar, even if one does not know which device has been deployed. In particular, this model supports the <4h SLA on service repair that most vendors have, and which they support by stocking spares in the local city, but not for a specific customer. I see that I've answered the rest already. The perils of all these CCs. -- ] 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[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Benjamin Kaduk wrote: > Apparently I only have one comment buried inline. We must be making > progress :) >> > The audit log is a defense against this in that it allows for >> post-facto > discovery of misuse? Or is there some pre-issuance >> authorization check > going on. > I think I may need some section >> references to where the authorization > policy (options) are >> documented; I've lost a bit of state on this one. >> >> That's right, the audit log provides discovery of mis-use. The check >> belongs prior to issurance of an LDevID, and may be repeated regularly >> afterwards. >> >> I think you are asking for a list of MASA authorization policy >> options. We do not have such a menu of options, and I'm reluctant to >> write them down normatively at this point, as I think that there are >> combinations we do not yet understand. >> >> 5.5.3 points out that nonceless vouchers need more authorization. >> Other parts of 5.5 provide other options. Please let me know if you >> think this is insufficient for a Proposed Standard. > I think I'd like to see a small addition after/near "[t]his > verification is only a consistency check that the unauthenticated > domain CA intended the voucher-request signer to be a registrar" > (perhaps at the end of the paragraph?) noting something like "since the > domain CA is unauthenticated to the MASA, depending on MASA policy, > vouchers not authorized by the pledge owner may be issued; the MASA > audit log can be used to detect such missisuance". I've added: Even when a domain CA is authenticated to the MASA, and there is strong sales channel integration to understand who the legitimate owner is, the above cmcRC check prevents arbitrary End-Entity certificates (such as an LDevID certificate) from having vouchers issued against them. Other cases of inappropriate voucher issuance are detected by examination of the audit log. -- ] 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[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Benjamin Kaduk wrote: >> + directly. This is because BRSKI pledges MUST use the CSR Attributes > (This may not need to be a 2119 MUST since we cite 7030.) It turns out, in pracice, that many EST clients do not use the CSR Attributes, so I need this line as a hammer. >> > "intended" implies that the EST server has some knowledge of what >> the > pledge is expected to be doing in the network, right? >> >> Yes. The ACP document is quite specific about the (rfc822Name) >> attributes to assign. Certainly the attributes could include stuff >> like "ve608.core1.tor1.example.net" if the Registrar knew how this >> device was to be used, but more likely that would be set up >> afterwards. > Hmm, maybe later when we say "the local infrastructure (EST server) > informs the pledge of the proper fields to include in the generated > CSR" we could reiterate that the EST server has local configuration > information to inform this messaging, though it's probably not > necessary. I've added the (). + fields to include in the generated CSR (such as rfc822Name). doc> To alleviate these operational difficulties, the pledge MUST request doc> the EST "CSR Attributes" from the EST server and the EST server doc> needs to be able to reply with the attributes necessary for use of doc> the certificate in its intended protocols/services. This approach doc> allows for minimal CA integrations and instead the local doc> infrastructure (EST server) informs the pledge of the proper fields doc> to include in the generated CSR. This approach is beneficial to doc> automated boostrapping in the widest number of environments. >> >> > This is convenient, but has some security considerations in that it >> > implies that the validation policy on the CA is somewhat lax, since >> the > EST server is expected to be doing most of the policy controls. >> Thus, > a compromised pledge/device could send a CSR with unauthorized >> fields > and it is likely to be signed, allowing for some level of >> privilege > escalation. When the registrar acts as a proxy to the CA >> as well as > its EST role, as described later, this risk is >> diminished. >> >> I don't really understand. EST servers are Registration Authorities, >> and they have some kind of priviledged access to the CA, and are >> mandated to check the CSR. I expected to find a statement to this >> effect in RFC7030, in section 4.2.1, but I don't see any particularly >> strong language. This seems like a quality of implementation issue in >> the Registrar. > The high-level intended workflow described here is roughly "(1) pledge > asks registrar for config; (2) pledge puts that config in a CSR, signs > the CSR, and sends the CSR to registrar; (3) registrar passes CSR to CA > using registrar's implicit authority. We don't describe any crypto to > check that (2) happens as intended, as opposed to the pledge > dishonestly claiming "oh, and I'm a CA" or "I can provide all ACP > services, even privileged ones", so that has to be done by policy in > the registrar, as you note. I'm wary of suggesting the workflow that > relies on the registrar's implicit authority at the CA without also > noting the registrar's policy enforcement obligations. Though it's > possible this is covered elsewhere and doesn't need to be duplicated > here. I think it goes back to the RA and more specifically, the CA, being boss of what going into a certificate. To the point where it generally seems really hard to deploy new extensions in the public WebPKI. It does say: The registrar MUST also confirm that the resulting CSR is formatted as indicated before forwarding the request to a CA. If the registrar is communicating with the CA using a protocol such as full CMC, which provides mechanisms to override the CSR attributes, then these mechanisms MAY be used even if the client ignores CSR Attribute guidance. >> > Section 7 >> >> > If this is non-normative and will need to be fleshed out in a >> separate > document, would an Appendix be more appropriate? >> >> Section 9 and 10 refer back to this section in a normative fashion. > Er, wouldn't that make this section no longer non-normative? (Not that > I could find the references you're talking about, so a clue bat is > welcome.) It's of the form, "if you wish to do X, then you MUST do Y" (but, X is not a MUST). section 9: In recognition of this, some mechanisms are presented in Section 7.2. The manufacturer MUST provide at least one of the one- touch mechanisms described that permit enrollment to be proceed without availability of any manufacturer server (such as the MASA). >> > I think this is maybe more of a "does not enforce"
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Benjamin Kaduk wrote: >> There does not otherwise seem to be any risk from this compromise to >> devices which are already deployed, or which are sitting locally in >> boxes waiting for deployment (local spares). The issue is that > (That is, if the boxes are already in local storage at the time of > first compromise) yes. If you have physical care of them, then nobody could have tried an attack while the MASA signing key was compromised. >> The authors are unable to come up with an attack scenario where a >> compromised voucher signature enables an attacker to introduce a >> compromised pledge into an existing operator's network. This is the >> case because the operator controls the communication between Registrar >> and MASA, and there is no opportunity to introduce the fake voucher >> through that conduit. > This seems predicated on the attacker having the MASA signing key but > not persistent control of the (formerly?) legitimate MASA service, > right? yes, that's right. Assume the key was generated in a deterministic way (the way the SSH keys were), or brute-forced, or something like that. >> A key operational recommendation is for manufacturers to sign >> nonceless, long-lived vouchers with a different key that they sign >> short-lived vouchers. That key needs significantly better protection. >> If both keys come from a common trust-anchor (the manufacturer's CA), >> then a compromise of the manufacturer's CA would be a bigger problem. > (probably some wordsmithing options for "be a bigger problem") how about: If both keys come from a common trust-anchor (the manufacturer's CA), then a compromise of the manufacturer's CA would compromise both keys. Such a compromise of the manufacturer's CA likely compromises all keys outlined in this section. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Thu, Aug 15, 2019 at 01:02:45PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > >> There does not otherwise seem to be any risk from this compromise to > >> devices which are already deployed, or which are sitting locally in > >> boxes waiting for deployment (local spares). The issue is that > > > (That is, if the boxes are already in local storage at the time of > > first compromise) > > yes. If you have physical care of them, then nobody could have tried an > attack while the MASA signing key was compromised. I guess that makes the "under physical control of the owner" the relevant property, so emphasizing that in the text might be good. > >> The authors are unable to come up with an attack scenario where a > >> compromised voucher signature enables an attacker to introduce a > >> compromised pledge into an existing operator's network. This is the > >> case because the operator controls the communication between Registrar > >> and MASA, and there is no opportunity to introduce the fake voucher > >> through that conduit. > > > This seems predicated on the attacker having the MASA signing key but > > not persistent control of the (formerly?) legitimate MASA service, > > right? > > yes, that's right. Assume the key was generated in a deterministic way > (the way the SSH keys were), or brute-forced, or something like that. I was initiall confused about this, so it might be worth adding some text. (But then again, sometimes I'm easily confused...) > >> A key operational recommendation is for manufacturers to sign > >> nonceless, long-lived vouchers with a different key that they sign > >> short-lived vouchers. That key needs significantly better protection. > >> If both keys come from a common trust-anchor (the manufacturer's CA), > >> then a compromise of the manufacturer's CA would be a bigger problem. > > > (probably some wordsmithing options for "be a bigger problem") > > how about: > If both keys come from a common trust-anchor > (the manufacturer's CA), then a compromise of the > manufacturer's CA would compromise both keys. Such a > compromise of the manufacturer's CA likely compromises > all keys outlined in this section. WFM. Thanks, Ben ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Wed, Aug 14, 2019 at 09:10:26PM -0400, Michael Richardson wrote: > > Benjamin Kaduk 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: > > 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. > 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 a
[Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-26.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Toerless Eckert Michael H. Behringer Kent Watsen Filename: draft-ietf-anima-bootstrapping-keyinfra-26.txt Pages : 110 Date: 2019-08-15 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Remote Secure Key Infrastructure (BRSKI) is created using manufacturer installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping to is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-26 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-26 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] {FINAL} Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Hi,
I have pushed -26 to the datatracker.
I believe that this addresses all IESG comments received, as well as the
comments from Christian's second review. In particular, I added a paragraph
to the intro as he suggested, as well as adding section 7.4.3, which is
now referenced by section 10.6 ("meddling").
As previously indicated, when I fixed the wrap issue in the examples between
-23 and -24, this resulted in a very unreadably wide diff. I posted -23 as
having only that fix, so compare -26 to -24 if you want to see everything
since your review.
Here is a link to help:
https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-23&url2=draft-ietf-anima-bootstrapping-keyinfra-26
The new text is pending proof-reading by myself and others, but as you may
know, it is impossible to catch small errors in this text.
Will Randy be happy? I hope so :-)
This is has been a very long effort for me and my co-authors, about 75 hours
of effort, occupying most of my brain for a month. If substantive are
still needed, they won't occur until mid-September.
There is still perhaps the somewhat "minor" issue of whether we should have a
registry created for the /.well-known/est. It feels like overkill to me.
I'm not sure if my instructions clearly say to add "see also " to the related
information. I reviewed some of the documents referenced under "related
information",
and I did not see any instructions in them.
--
] 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[
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Benjamin Kaduk wrote: >> 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. And which is never actually your car, nor has it any actual credentials that you control :-) It was onboarded at the factory. >> 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. Added after -26. -- ] 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[ signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
