Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
I have posted -29, which includes all changes in the past two weeks, including the informal YANG Doctor review. Name: draft-ietf-anima-bootstrapping-keyinfra Revision: 29 Title: Bootstrapping Remote Secure Key Infrastructures (BRSKI) Document date: 2019-10-28 Group: anima Pages: 117 URL: https://www.ietf.org/internet-drafts/draft-ietf-anima-bootstrapping-keyinfra-29.txt Status: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ Htmlized: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-29 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-29 -- 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)
Benjamin Kaduk wrote: >> >> 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. > Please double-check; I think I saw one in the -28 (but didn't make a > note of where). I found a second instance of 1.1, and removed it. -- 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)
While recovering from today's telechat, I noticed that I seem to have never replied to this one! (Luckily, there's not much to say...) On Mon, Sep 16, 2019 at 05:46:37PM -0400, Michael Richardson wrote: > > 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 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. Maybe I've just been reading too many copies of different text in flux, but I'm not sure that the current text gives me a clear picture of who picks what will be pinned and how much choice they have in the matter. But, if it's the "root" (last certificate in the chain) presented by the registrar for the provisional TLS connection, I think things are pretty self-consistent about it. > 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>
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
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 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
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Whoops, this one apparently got skipped over amid some other deluge in my inbox; sorry. On Sun, Aug 18, 2019 at 04:09:50PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > > That specific construction would seem like an "optional feature" per > > > https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/ > > ... > > I re-read this, and this as to do with References, and so anything optional > referenced in section 7 would still need to be a Normative Reference. > > The stickler I see right now is [I-D.ietf-netconf-keystore]. > I don't want to hang on MISREF on that document; it's just one of many that > could be used, and I do not want to tell manufacturers that they have > to use this specific protocol to update trust anchors. > There are many other protocols that they presently support which they could > use, in particular, a CLI interface would be fine. > > I think that this 7.4.3 section that creates a factory default which isn't > the default from the factory should be worry people who care about remote > attestation of software. > > Adam has been particularly vocal about the need to specify something > normative that manufacturers have to provide in order to resale and operation > with the availability of the MASA. > > It seems that we might need another round of discussion on this topic. > I feel that we are being pushed to describe the entire security lifetime of > the device; that we need to solve the entire management problem of devices in > our document. (i.e. the 25 years of SNMPv3, plus YANG...) Maybe I just don't > understand what would be a reasonable answer, if what I've written is not > enough. > > Maybe a virtual interim discussion! If so, please let me know. I think I'm going to have to leave this one to Adam et al. > ANIMA/Iot-Onboarding has some time booked already: > > https://datatracker.ietf.org/meeting/interim-2019-anima-01/materials/agenda-interim-2019-anima-01-anima-01 > > ps: (s/IPv6 NAT44/IPv4 NAT44/ for section 7.4.2, btw) > > > >> 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). > > > ... but this is a somewhat different construction. In isolation, it > looks > > more like "MUST do at least one of X, Y, Z" without condition on "wish > to > > do W", and if X, Y, and Z are all in the same place, that place seems > > normative to me. (I will confess I've rather lost track of exactly why > > we're debating if this is normative or not; I guess it's just the > > disclaimer in Section 7 about "considered non-normative in the > generality > > of the protocol".) > > Yes, it's MUST do one of X,Y,Z. > So that implies: MAY do X, MAY do Y, MAY do Z, but not the case of all being > false. If "ignore all of Section 7.2" is not an option, then at least some part of it is normative. "You just get to choose which part" :) -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 Thu, Aug 15, 2019 at 12:58:45PM -0400, Michael Richardson wrote: > > 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. Fair enough. > >> > "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. Hmm, I guess I must have missed that or skimmed over it too quickly. > >> > 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). That
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
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
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)
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)
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
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: 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: >> 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. >> > 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
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
https://tinyurl.com/y2skc9xz Benjamin Kaduk wrote: >> We did not resort to a YANG data model for the auditlog responses, so I spent >> a few minutes mystified by your complaint... then: >> We referenced 7951 (YANG->JSON), but we should have just referenced RFC7159 (JSON)! > Oh! That would make a lot more sense... (but 7159 is obsoleted by 8259, > of course) got them all now. >> If so, the reason for normative language is because, we want to say, "if you >> do X, then you MUST do it this way". >> >> Second, we have referenced some pieces of section 7.2 from section 9. >> We think that there are significant security issues by accepting nonceless >> vouchers, which we discuss in 11.1. A variation of the protocol is when >> the manufacturer programs the pledge to ALWAYS accept nonceless vouchers. >> There could otherwise be some more complex (proprietary, or documented later >> on) evaluation of whether to accept a nonceless voucher. For instance, the >> MASA could sign them with a different key, perhaps one stored in an HSM. > Okay, so it is that the client (well, manufacturer?) chooses whether or not > to accept nonceless vouchers. So we could change the introduction to the > enumerated list to be saying that this is a list of exclusive candidate > behaviors that could be chosen independently of each other, and not a > collection of behaviors all of which are expected to be implemented. I have revised section 7.2. My use of normative language seems inconsistent at this point. I need to distinguish between "X is possible" from "when doing X you MUST Y" better. >> > (14) In Section 5.6: >> >> > The server MUST answer with a suitable 4xx >> > or 5xx HTTP [RFC2616] error code when a problem occurs. In this case, >> > the response data from the MASA MUST be a plaintext human- readable >> > (ASCII, English) error message containing explanatory information >> > describing why the request was rejected. >> >> > It seems hard to support this stance on internationalization in 2019. >> >> We don't believe that this response will go anywhere other than logs, >> for software suppliers to evaluate. Localizing these error message causes >> more problems in my experience than benefit. 90% of the information is in >> the 4xx/5xx code. > I should probably defer to my ART-area colleagues here. But you're saying > that mandating English is better than allowing UTF-8 and otherwise leaving > it as implementation defined? We have removed "ASCII, English), and left this as "UTF-8", with the expectation that the message may be localized. Emphasis is on human readable. >> > (15) In Section 5.9.4: >> >> >To indicate successful enrollment the client SHOULD re-negotiate the >> > EST TLS session using the newly obtained credentials. This occurs by >> > the client initiating a new TLS ClientHello message on the existing TLS >> > connection. The client MAY simply close the old TLS session and start >> > a new one. The server MUST support either model. >> >> > Is this supposed to be sending a new TLS ClientHello in the application >> > data channel or as a new handshake message (aka "renegotiation")? The >> > latter is not possible in TLS 1.3 and is generally disrecommended >> > anyways even in TLS 1.2. I would strongly suggest to remove the >> > "renegotiation" option and just leave "close the connection and start a >> > new connection/handshake". >> >> Okay, fixed to say: >> >> To indicate successful enrollment the client SHOULD re-negotiate >> the EST TLS session using the newly obtained credentials. This >> - occurs by the client initiating a new TLS ClientHello message on the >> - existing TLS connection. The client MAY simply close the old TLS >> - session and start a new one. The server MUST support either >> + occurs by the client closing the existing TLS connection, and >> + starting a new one. The server MUST support either >> model. > I'd prefer to s/re-negotiate/re-establish/ as well, but this is probably > good enough to clear the discuss. Changed. -- 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)
https://tinyurl.com/y2skc9xz
Michael Richardson wrote:
>> o The subject-alt field's encoding MAY include a non-critical
>> version of the RFC4108 defined HardwareModuleName. (from [IDevID]
>> section 7.2.9) If the IDevID is stored in a Trusted Platform
>> Module (TPM), then this field MAY contain the TPM identification
>> rather than the device's serial number. If both fields are
>> present, then the subject field takes precedence.
>> "if both fields are present", but the subject field MUST be present, so
>> this field can never take precedence.
> I'm willing to drop, because I never got proper clarification.
> We were told by implementors that if the IDevID is contained in a TPM that
> the resulting IDevID often has the serialNumber of the TPM,not the device
> itself.
> *** MAX ***
>> 1. [RFC4519] section 2.31 provides an example ("WI-3005") of the
>> Distinguished Name "serialNumber" attribute. [RFC4514] indicates
>> this is a printable string so no encoding is necessary.
>> I don't understand why these references were chosen. Why are LDAP specs
>> authoritative about what the encoding format for the serialNumber DN
>> attribute is? E.g., one could look at RFC 5280 to see that
>> X520SerialNumber is a PrintableString.
> *** MAX ***
We have simplified the text, removed the TPM and Hardware Module Name, etc.
and clarified why we are referencing the LDAP RFC.
We have left an out that says that the Registrar may need to dig elsewhere
on a per-manufacturer basis.
>> o In the language of [RFC6125] this provides for a SERIALNUM-ID
>> category of identifier that can be included in a certificate and
>> therefore that can also be used for matching purposes. The
>> SERIALNUM-ID whitelist is collated according to manufacturer trust
>> anchor since serial numbers are not globally unique.
>> RFC 6125 does not define a SERIALNUM-ID, so maybe we could reword to "in
>> the model of RFC 6125" or "provides a new SERIAL-ID category" or
>> similar.
> I have an open request to *** MAX *** to clarify this part.
We have resolved by this removing the reference to RFC6125.
--
] 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 , 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)
Apparently I only have one comment buried inline. We must be making progress :) On Tue, Aug 13, 2019 at 05:07:46PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > doc> The authentication of the BRSKI-MASA connection does not affect the > doc> voucher-request process, as voucher-requests are already signed by > doc> the registrar. Instead, this authentication provides access control > doc> to the audit log. > >> > >> > I don't understand what "access control to the audit log" means. Is > the > >> > idea that the TLS client identity in the BSRKI-MASA connection is > only > >> > used when processing requests to the requestauditlog endpoint and > that > >> > some clients might be denied access? > >> > >> The audit log reveals who owns what. Revealing it to strangers would > be a problem. > >> So in order to get access to the audit log for device FOO, one > presents a > >> voucher-request for FOO. Since the request contains a serial-number > and a > >> mapping to an owner, we use that as an access key to get the audit-log. > >> The identity that the MASA sees in the HTTPS request (ClientCertificate > >> preferred), says who is asking. > >> > >> What can I fix here? > > > Well, I think a lot of my confusion stemmed from the lack of advance > > definition of "MASA Audit Log" as a protocol element, which you already > > fixed. So what's left would seem to mostly be a question of whether > > something about "access control" vs. "authorization to access the > relevant > > subset of the audit log" is a more accurate description of what's going > on. > > That is, whether "access control" is something done by a server > (MASA)-side > > agent applying policy, or ... something else that I don't know how to > > describe well. > > I have added a forward reference in section 5.4 to section 5.8 around the > the access control question. > > doc> created-on: Registrars are RECOMMENDED to populate this field. This > doc> provides additional information to the MASA. > > >> > Earlier we said that this field would be propagated from the pledge > >> > voucher-request; we should probably say something like "populate this > >> > field; if it was present in the pledge voucher-request it is copied > >> > unchanged to the registrar voucher-request; otherwise the current > time > >> > is used". > >> > >> That create-on is the time on the Registrar, not on the pledge. It > currently > >> says: > >> > >> The registrar populates the voucher-request fields as follows: > >> > >> created-on: The Registrars SHOULD populate this field with the > >> current date and time when the Registrar formed this voucher > >> request. This field provides additional information to the MASA. > > > Hmm, I'm trying to look for why I claimed that "earlier we said that > this > > field would be propagated". Section 3.3 (of the -22)'s Example (2) says > > "[t]he nonce, created-on and assertion is carried forward", and Section > 5.2 > > wants pledges to populate it as well. So the idea is that the MASA is > only > > going to get the pledge's created-on via the > prior-signed-voucher-request > > (if present)? > > > I'm confused about what it means to "carry forward" the created-on if > the > > registrar is populating it anew, though. > > I have changed the text: > > -here it must be base64 encoded. The nonce, created-on and > -assertion is carried forward. The serial-number is extracted > -from > +here it must be base64 encoded. The nonce and > +assertion MAY be carried forward from the pledge request to > +the registrar request. > +The serial-number is extracted from > > It is a MAY, because in a case where the Registrar wants a nonceless voucher, > then it won't include a nonce. > > >> > There is no "idevid-issuer" field in the pledge certificate; I assume > >> > this is supposed to be the Issuer Name of the IDevID certificate. > >> > >> Changed to: > >> idevid-issuer: The Issuer value from the value from the pledge > > > nit: duplicated "value from the" > > fixed. > > >> IDevID certificate is included to ensure a uniqueness of the > >> serial-number. In the case of nonceless (offline) voucher- > >> request, then an appropriate value needs to be configured from the > >> same out-of-band source as the serial-number. > >> > >> > >> > prior-signed-voucher-request: The signed pledge voucher-request > >> > SHOULD be included in the registrar voucher-request. (NOTE: what > >> > is included is the complete pledge voucher-request, inclusive of > >> > the 'assertion', 'proximity-registrar-cert', etc wrapped by the > >> >
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Mon, Aug 12, 2019 at 04:23:54PM -0400, Michael Richardson wrote: > > Benjamin Kaduk via Datatracker wrote: > > Section 13.2 > > > I think CDDL needs to be a normative reference, as does RFC 7231. RFC > > 2473 is listed but not referenced in the text, as are RFC 2663, RFC > > 7217, and RFC 7575. > > CDDL->RFC8610, now normative. (Glad that got published) > RFC2473 removed, we no longer attempt to document a stateless IPIP proxy > mechanism. > > RFC2663 (NAT terminology) reference was for Join Proxy, and I've restored > a reference in section 4. > > RFC7217 was thought to be relevant to Pledge use of SLAAC, but actually it's > not, removed. > > You are right that we don't reference RFC7575, which is the architecture of > ANIMA. I have added a sentence to the Intro, referencing RFC7575's > goal of "secure by default" > > > Appendix B > > doc>Discovery of registrar MAY also be performed with DNS-based > service > doc> discovery by searching for the service "_brski- > doc> registrar._tcp.example.com". In this case the domain "example.com" > is > doc> discovered as described in [RFC6763] section 11 (Appendix A.2 > suggests > doc> the use of DHCP parameters). > > > I'd suggest using "" per 6763 rather than "example.com". > > okay. > > doc>If no local proxy or registrar service is located using the GRASP > doc> mechanisms or the above mentioned DNS-based Service Discovery methods > doc> the pledge MAY contact a well known manufacturer provided > bootstrapping > doc> server by performing a DNS lookup using a well known URI such as > doc> "brski-registrar.manufacturer.example.com". The details of the URI > are > doc> manufacturer specific. Manufacturers that leverage this method on > the > doc> pledge are responsible for providing the registrar service. Also see > doc> Section 2.7. > > > It seems like there are some security considerations for device owners > > that may wish to prevent such registrars from being used. Do we need > > to direct them to run a firewall or similar? > > If they are doing ANIMA ACP bootstrapping, then there would ideally be no > IPv4 available, and so this won't work anyway. > I'd rather not get into too much of this here. I'm not sure I see how v6-only prevents URI dereference or obviates the usecase for a firewall. Perhaps you mean that there would be no non-link-local available? > > Appendix C > > > I don't know how important file "ietf-mud-extens...@2018-02-14.yang" > > is, but it seems a tad generic. > > Renamed already. > > Ben, I'm posting the -25, and then moving on back to the responses to > my responses, including Adam's concerns. Okay, 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 Mon, Aug 12, 2019 at 03:30:13PM -0400, Michael Richardson wrote:
>
> WG: there is a chunk of Security Considerations text here that I hope
> many will read.
>
>
> Benjamin Kaduk via Datatracker wrote:
> > Section 11.4
>
> > It is not entirely clear to me whether device manufacturers are set up
> > with incentives to maintain a well-run secure CA with strong hardware
> > protections on the offline signing key for the root CA, cycling through
> > various levels of intermediates, etc., that CAs in the Web PKI do
> > today. If the manufacturer uses a less stringent process, that would
> > leave the manufacturer's key as a more tempting attack surface, and it
> > may be worth some discussion here about what damage could be done with
> > a compromised MASA signing key. E.g., would an attack require
> > restoring devices to factory defaults or otherwise waiting for natural
> > bootstrapping events to occur? Would the attacker need to be on-path?
> > Etc.
>
> I wanted to add that I think that there are some interesting economic
> discussions about these incentives. I wonder how to interest some people
> into doing some analysis of a monetary rather that technical manner.
>
> I have added:
> 11.4. Manufacturer Maintenance of trust anchors . . . . . . . 75
>11.4.1. Compromise of Manufacturer IDevID signing keys . . . 77
>11.4.2. Compromise of MASA signing keys . . . . . . . . . . 77
>11.4.3. Compromise of MASA web service . . . . . . . . . . . 79
>
> and this text is rough, and as yet unreviewed by anyone, and I
(not sure if there was supposed to be much more to that sentence).
It's rough, sure, but generally looks quite good in terms of content coverage.
> 11.4. Manufacturer Maintenance of trust anchors
>
>BRSKI depends upon the manufacturer building in trust anchors to the
>pledge device. The voucher artifact which is signed by the MASA will
>be validated by the pledge using that anchor. This implies that the
>manufacturer needs to maintain access to a signing key that the
>pledge can validate.
>
>The manufacturer will need to maintain the ability to make signatures
>that can be validated for the lifetime that the device could be
>onboarded. Whether this onboarding lifetime is less than the device
>
>lifetime depends upon how the device is used. An inventory of
>devices kept in a warehouse as spares might not be onboarded for many
>decades.
>
>There are good cryptographic hygiene reasons why a manufacturer would
>not want to maintain access to a private key for many decades. A
>manufacturer in that situation can leverage a long-term certificate
>authority anchor, built-in to the pledge, and then a certificate
>chain may be incorporated using the normal CMS certificate set. This
>may increase the size of the voucher artifacts, but that is not a
>significant issues in non-constrained environments.
>
>There are a few other operational variations that manufacturers could
>consider. For instance, there is no reason that every device need
>have the same set of trust anchors pre-installed. Devices built in
>different factories, or on different days, or any other consideration
>could have different trust anchors built in, and the record of which
>batch the device is in would be recorded in the asset database. The
>manufacturer would then know which anchor to sign an artifact
>against.
>
>Aside from the concern about long-term access to private keys, a
>major limiting factor for the shelf-life of many devices will be the
>age of the cryptographic algorithms included. A device produced in
>2019 will have hardware and software capable of validating algorithms
>common in 2019, and will have no defense against attacks (both
>quantum and von-neuman brute force attacks) which have not yet been
>invented. This concern is orthogonal to the concern about access to
>private keys, but this concern likely dominates and limits the
>lifespan of a device in a warehouse. If any update to firmware to
>support new cryptographic mechanism were possible (while the device
>was in a warehouse), updates to trust anchors would also be done at
>the same time.
>
>The set of standard operating proceedures for maintaining high value
>private keys is well documented. For instance, the WebPKI provides a
>number of options for audits at {{cabforumaudit}}, and the DNSSEC
>root operations are well documented at {{dnssecroot}}.
>
>It is not clear if Manufacturers will take this level of precaution,
>or how strong the economic incentives are to maintain an appropriate
>level of security.
>
>This next section examines the risk due to a compromised MASA key.
>This is followed by examination of the risk of a compromised
>manufacturer IDevID
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Wed, Aug 14, 2019 at 10:05:13AM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > >> domainID: The domain IDentity is a unique hash based upon a > >> Registrar's certificate. If the certificate includes the > >> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be > >> used as the domainID. If not, then the 160-bit SHA-1 hash as > >> described in that section is to be used. This value needs to be > >> calculated by both MASA (to populate the audit log), and by the > >> Registrar (to recognize itself). > >> > >> Does this work? We are only using SHA-1 (for identification, btw, not > >> for resistence to pre-image attacks) as a last resort. > > > Sorry, I'm still not seeing the justification for using SHA-1 as the > > fallback instead of (e.g.) SHA-256. If the SKI is present, then > > definitely use that. But if it's not present, we can define whatever > > we want, can't we? It's not like "The keyIdentifier is composed of the > > 256-bit SHA-256 > > hash of the value of the BIT STRING subjectPublicKey (excluding the tag, > > length, and number of unused bits)" is an unreasonable amount of text ot > > include in the document. Now, if there's some backwards compatibility > > need > > or implementation challenge, we can talk about that, but all I'm seeing > so > > far is blind adherence to an 11-year-old document for consistency's > sake, > > and in this case I don't think consistency outweighs cryptographic > > modernization. > > Hi, we have revised the text, making use of section 2.4 from rfc7469, which > has a similar need. > > We added a new section 5.8.2, calculation of domainID: > > 5.8.2. Calculation of domainID > >The domainID is a binary value (a BIT STRING) that uniquely >identifies a Registrar by the "pinned-domain-cert" > >If the "pinned-domain-cert" certificate includes the >SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be >used as the domainID. If not, then it is the SPKI Fingerprint as >described in [RFC7469] section 2.4 is to be used. This value needs >to be calculated by both MASA (to populate the audit-log), and by the >Registrar (to recognize itself). > >[RFC5280] section 4.2.1.2 does not mandate that the >SubjectKeyIdentifier extension be present in non-CA certificates. It >is RECOMMENDED that Registrar certificates (even if self-signed), >always include the SubjectKeyIdentifier to be used as a domainID. > >The domainID is determined from the certificate chain associated with >the pinned-domain-cert and is used to update the audit-log. > > and referenced this section in the terminology. This eliminates all > references to SHA-1. RFC7469 section 2.4 uses SHA-256. Thank you! > We also strengthened our statement that the SubjectKeyIdentifier SHOULD > exist. In the process, we recognized that we had some mismatch in > (MY) thinking about pinned-domain-cert, thinking it was always the > Registrar End-Entity Certificate, when in fact it is the Registrar's > CA certificate. As a CA certificate, it SHOULD always have the > SubjectKeyIdentifier. My recollection was that it was expected to be a certificate in the Registrar's chain, probably a CA certificate but possibly an intermediate one (i.e., not self-signed). (And I see in 5280 "this extension MUST appear in all conforming CA certificates".) > We are presenting discussing whether the EE Registrar cert should get > audited. Okay, sounds good. -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 Mon, Aug 12, 2019 at 03:05:44PM -0400, Michael Richardson wrote: > > https://tinyurl.com/yylruorn contains a diff against -24. > > Benjamin Kaduk via Datatracker wrote: > > Section 5.8.1 > > doc>A log data file is returned consisting of all log entries > associated > doc> with the the device selected by the IDevID presented in the request. > doc> The audit log may be truncated of old or repeated values as explained > doc> below. The returned data is in JSON format ([RFC7951]), and the > doc> Content-Type SHOULD be "application/json". For example: > > > If RFC 7951 is to be used, I'd suggest "is JSON-encoded YANG data". > > Typo, it should be 7159. (Well, 8529, but I think we covered that already.) > doc>This document specifies a simple log format as provided by the > MASA > doc> service to the registrar. This format could be improved by > distributed > doc> consensus technologies that integrate vouchers with technologies such > doc> as block-chain or hash trees or optimized logging approaches. Doing > so > doc> is out of the scope of this document but is an anticipated > improvement > doc> for future work. As such, the registrar client SHOULD anticipate new > doc> kinds of responses, and SHOULD provide operator controls to indicate > doc> how to process unknown responses. > > > This would be a great place to talk about the "version" field that's > > otherwise ignored. > > As in, what should occur if the "version" is not 1? Exactly so! > How about: > > > A registrar that sees a version value greater than 1 indicates > an audit log format that has been enhanced with additional > information. No information will be removed in future > versions; should an incompatible change be desired in the future, > then a new HTTP end point will be used. > > > > doc>anticipated improvement for future work. As such, the registrar > doc> client SHOULD anticipate new kinds of responses, and SHOULD provide > doc> operator controls to indicate how to process unknown responses. > > > Is "registrar client" intended to be both words or just one? > > Probably not, removed. > > doc>A registrar SHOULD use the log information to make an informed > doc> decision regarding the continued bootstrapping of the pledge. The > > > I may be confused, but I thought the registrar was asking for the log > > after the voucher had already been issued. Are these check supposed to > > keep the registrar from forwarding the voucher to the pledge, or just > > as a check for future renewal operations? > > The voucher can be returned to the Pledge immediately, as there is never > any issue about whether the Pledge should join. The MASA has already made > that decision. > > The Registrar could avoid passing the voucher on until after the audit log > checks are done, or could do that concurrently. What matters is that the > audit log checks are done prior to the Registrar accepting an enroll > request.This is down in (what is now) Figure 4. Thinking about it that way is very helpful; thank you. > The Registrar may do additional checks of the audit log at later times, > but I don't think we have any good advice on this yet. Okay. > doc>A relatively simple policy is to white list known (internal or > doc> external) domainIDs and to require all vouchers to have a nonce and/ > or > doc> require that all nonceless vouchers be from a subset (e.g. only > doc> internal) domainIDs. A simple action is to revoke any locally issued > > > nit: missing "of" > > I don't know where the "of" that is missing goes. "subset of" (though possibly split by the parenthetical) > While investigating, I broke the big sentence up, and discovered that the > 5209 reference was not coded as XML. Please clue me in what you mean... > > > 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) 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) is supported. > > > doc>credentials for the pledge in question
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Benjamin Kaduk wrote: >> domainID: The domain IDentity is a unique hash based upon a >> Registrar's certificate. If the certificate includes the >> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be >> used as the domainID. If not, then the 160-bit SHA-1 hash as >> described in that section is to be used. This value needs to be >> calculated by both MASA (to populate the audit log), and by the >> Registrar (to recognize itself). >> >> Does this work? We are only using SHA-1 (for identification, btw, not >> for resistence to pre-image attacks) as a last resort. > Sorry, I'm still not seeing the justification for using SHA-1 as the > fallback instead of (e.g.) SHA-256. If the SKI is present, then > definitely use that. But if it's not present, we can define whatever > we want, can't we? It's not like "The keyIdentifier is composed of the > 256-bit SHA-256 > hash of the value of the BIT STRING subjectPublicKey (excluding the tag, > length, and number of unused bits)" is an unreasonable amount of text ot > include in the document. Now, if there's some backwards compatibility > need > or implementation challenge, we can talk about that, but all I'm seeing so > far is blind adherence to an 11-year-old document for consistency's sake, > and in this case I don't think consistency outweighs cryptographic > modernization. Hi, we have revised the text, making use of section 2.4 from rfc7469, which has a similar need. We added a new section 5.8.2, calculation of domainID: 5.8.2. Calculation of domainID The domainID is a binary value (a BIT STRING) that uniquely identifies a Registrar by the "pinned-domain-cert" If the "pinned-domain-cert" certificate includes the SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be used as the domainID. If not, then it is the SPKI Fingerprint as described in [RFC7469] section 2.4 is to be used. This value needs to be calculated by both MASA (to populate the audit-log), and by the Registrar (to recognize itself). [RFC5280] section 4.2.1.2 does not mandate that the SubjectKeyIdentifier extension be present in non-CA certificates. It is RECOMMENDED that Registrar certificates (even if self-signed), always include the SubjectKeyIdentifier to be used as a domainID. The domainID is determined from the certificate chain associated with the pinned-domain-cert and is used to update the audit-log. and referenced this section in the terminology. This eliminates all references to SHA-1. RFC7469 section 2.4 uses SHA-256. We also strengthened our statement that the SubjectKeyIdentifier SHOULD exist. In the process, we recognized that we had some mismatch in (MY) thinking about pinned-domain-cert, thinking it was always the Registrar End-Entity Certificate, when in fact it is the Registrar's CA certificate. As a CA certificate, it SHOULD always have the SubjectKeyIdentifier. We are presenting discussing whether the EE Registrar cert should get audited. -- 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)
Benjamin Kaduk wrote: doc> The authentication of the BRSKI-MASA connection does not affect the doc> voucher-request process, as voucher-requests are already signed by doc> the registrar. Instead, this authentication provides access control doc> to the audit log. >> >> > I don't understand what "access control to the audit log" means. Is the >> > idea that the TLS client identity in the BSRKI-MASA connection is only >> > used when processing requests to the requestauditlog endpoint and that >> > some clients might be denied access? >> >> The audit log reveals who owns what. Revealing it to strangers would be a problem. >> So in order to get access to the audit log for device FOO, one presents a >> voucher-request for FOO. Since the request contains a serial-number and a >> mapping to an owner, we use that as an access key to get the audit-log. >> The identity that the MASA sees in the HTTPS request (ClientCertificate >> preferred), says who is asking. >> >> What can I fix here? > Well, I think a lot of my confusion stemmed from the lack of advance > definition of "MASA Audit Log" as a protocol element, which you already > fixed. So what's left would seem to mostly be a question of whether > something about "access control" vs. "authorization to access the relevant > subset of the audit log" is a more accurate description of what's going on. > That is, whether "access control" is something done by a server (MASA)-side > agent applying policy, or ... something else that I don't know how to > describe well. I have added a forward reference in section 5.4 to section 5.8 around the the access control question. doc> created-on: Registrars are RECOMMENDED to populate this field. This doc> provides additional information to the MASA. >> > Earlier we said that this field would be propagated from the pledge >> > voucher-request; we should probably say something like "populate this >> > field; if it was present in the pledge voucher-request it is copied >> > unchanged to the registrar voucher-request; otherwise the current time >> > is used". >> >> That create-on is the time on the Registrar, not on the pledge. It currently >> says: >> >> The registrar populates the voucher-request fields as follows: >> >> created-on: The Registrars SHOULD populate this field with the >> current date and time when the Registrar formed this voucher >> request. This field provides additional information to the MASA. > Hmm, I'm trying to look for why I claimed that "earlier we said that this > field would be propagated". Section 3.3 (of the -22)'s Example (2) says > "[t]he nonce, created-on and assertion is carried forward", and Section 5.2 > wants pledges to populate it as well. So the idea is that the MASA is only > going to get the pledge's created-on via the prior-signed-voucher-request > (if present)? > I'm confused about what it means to "carry forward" the created-on if the > registrar is populating it anew, though. I have changed the text: -here it must be base64 encoded. The nonce, created-on and -assertion is carried forward. The serial-number is extracted -from +here it must be base64 encoded. The nonce and +assertion MAY be carried forward from the pledge request to +the registrar request. +The serial-number is extracted from It is a MAY, because in a case where the Registrar wants a nonceless voucher, then it won't include a nonce. >> > There is no "idevid-issuer" field in the pledge certificate; I assume >> > this is supposed to be the Issuer Name of the IDevID certificate. >> >> Changed to: >> idevid-issuer: The Issuer value from the value from the pledge > nit: duplicated "value from the" fixed. >> IDevID certificate is included to ensure a uniqueness of the >> serial-number. In the case of nonceless (offline) voucher- >> request, then an appropriate value needs to be configured from the >> same out-of-band source as the serial-number. >> >> >> > prior-signed-voucher-request: The signed pledge voucher-request >> > SHOULD be included in the registrar voucher-request. (NOTE: what >> > is included is the complete pledge voucher-request, inclusive of >> > the 'assertion', 'proximity-registrar-cert', etc wrapped by the >> > pledge's original signature). If a signed voucher-request was not >> > recieved from the pledge then this leaf is omitted from the >> > registrar voucher request. >> >> > This is a good example of text that implies the signed voucher is >> > binary. (And as such would be a good place to talk about the base64 >> > encoding.) >> >> okay, done. >>
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On 8/13/19 10:37 AM, Michael Richardson wrote:
Adam Roach wrote:
>> Adam Roach:
https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA
>> ...
>> This is an rfcdiff from the already-wrapped JSON to the proposed -23
that
>> includes all the changes from the various DISCUSSes up to now:
>> https://tinyurl.com/y2qhjwh8
> As a quick note -- the diff above does not address the "discuss" part of
my
> second discuss point: the document remains ambiguous regarding *how* the
URL
> is to be returned. The lengthy parenthetical references added to the
> corresponding paragraph aren't sufficient to positively indicate that
the URL
> appears in a "Location" header: this needs to be stated explicitly rather
> than implied by a section reference.
I had previously updated to point to RFC7231 section 6.3.2, but upon careful
reading, I see that returning the URL in the Location: is not mandated by
6.3.2. I am a little bit surprised that 7231 is so vague on what I thought
was a pretty much written in stone process
Rather than returning the audit log as a response to the POST (with
a return code 200), the MASA MAY instead return a 201 ("Created")
- response ( sections 6.3.2 and 7.1)
containing
- a URL to the prepared (and idempotent, therefore cachable) audit
response.
+ response ( sections 6.3.2 and 7.1), with
+ the URL to the prepared (and idempotent, therefore cachable) audit
+ response in the Location: header.
Does this fix things for you?
Yes, thanks. One minor nit: "...Location: header field."
/a
___
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 Sun, Aug 11, 2019 at 12:06:07AM -0400, Michael Richardson wrote:
>
> https://tinyurl.com/yylruorn contains an updated diff against -24.
>
> Benjamin Kaduk via Datatracker wrote:
> > Section 5.2
>
> > application/voucher-cms+json The request is a "YANG-defined JSON
> > document that has been signed using a CMS structure" as described
> > in Section 3 using the JSON encoding described in [RFC7951]. This
>
> > Section 3 does not describe any "sign[ing] using a CMS structure"
> > operation.
>
> Yes, I see, the sentence structure is wrong. I have changed it:
>
>
> - application/voucher-cms+json The request is a "YANG-defined JSON
> - document that has been signed using a CMS structure" as described
> - in Section 3 using the JSON encoding described in [RFC7951]. This
> - voucher media type is defined in [RFC8366] and is also used for
> - the pledge voucher-request. The pledge SHOULD sign the request
> - using the Section 2.3 credential.
>
> + application/voucher-cms+json [RFC8366] defines a "YANG-defined JSON
> + document that has been signed using a CMS structure", and the
> + voucher-request described in Section 3 is created in the same way.
> + The media type is the same as defined in [RFC8366]. and is also
> + used for the pledge voucher-request. The pledge MUST sign the
> + request using the Section 2.3 credential.
>
>
> > To be clear, this is MUST sign, but SHOULD use IDevID (vs. some other
> > credential) to sign?
>
> It was SHOULD, because we supported unsigned voucher requests, but we removed
> that option. It is now MUST.
>
> > constrained voucher formats are expected in the future. Registrar's
> > and MASA's are expected to be flexible in what they accept.
>
> > nits: no apostrophes for plurals.
>
> done.
>
> > proximity-registrar-cert: In a pledge voucher-request this is the
> > first certificate in the TLS server 'certificate_list' sequence
> > (see [RFC5246]) presented by the registrar to the pledge. This
> > MUST be populated in a pledge voucher-request if the "proximity"
> > assertion is populated.
>
> > [same comment as above about "end-entity certificate"]
>
> done.
>
> > The registrar validates the client identity as described in EST
> > [RFC7030] section 3.3.2. The registrar confirms that the 'proximity'
> > assertion and associated 'proximity-registrar-cert' are correct.
>
> > what 'proximity' assertion?
> > Does verifying proximity-registrar-cert just mean checking that it's the
> > same leaf certificate that the registrar presented? What happens if the
> > validation fails?
>
> Yes, it means confirming that the pinned certificate is one's own.
> If it fails, then there is a MITM, and the connection should be closed.
> {I will use "MITM" until someone tells if me we are using a different term}
>
> I've split that paragraph up, as there are two thoughts, one is about the
> ClientCertificate, and the other is about the pinned certificate.
>
> The registrar validates the client identity as described in EST
> - [RFC7030] section 3.3.2. The registrar confirms that the 'proximity'
> - assertion and associated 'proximity-registrar-cert' are correct.
> + [RFC7030] section 3.3.2.
> +
> + The registrar confirms that the assertion is 'proximity' and that
> + pinned 'proximity-registrar-cert' is the Registrar's certificate. If
> + this validation fails, then there a On-Path Attacker (MITM), and the
> + connection MUST be closed after the returning an HTTP 401 error code.
>
> > Section 5.3
>
> doc> A Registrar accepts or declines a request to join the domain, based
> doc> on the authenticated identity presented. Automated acceptance
> doc> criteria include:
>
> > I suggest "for different networks, examples of automated acceptance
> > criteria may include".
>
> doc> If these validations fail the registrar SHOULD respond with an
> doc> appropriate HTTP error code.
>
> > Similarly, "If validation fails".
>
> done.
>
> > Section 5.4
>
> doc> The BRSKI-MASA TLS connection is a 'normal' TLS connection
> doc> appropriate for HTTPS REST interfaces. The registrar initiates the
> doc> connection and uses the MASA URL obtained as described in Section 2.8
> doc> for [RFC6125] authentication of the MASA.
>
> > I'd consider mentioning the implicit trust anchor database as well as
> > the MASA URL.
>
> edits for another review changed this to:
>The BRSKI-MASA TLS connection is a 'normal' TLS connection
>appropriate for HTTPS REST interfaces. The registrar initiates the
>connection and uses the MASA URL obtained as described in
>Section 2.8. The mechanisms in [RFC6125] SHOULD be used
>authentication of the MASA. Some vendors will establish explicit (or
>private) trust anchors for validating their MASA; this
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Adam Roach wrote:
>> Adam Roach:
https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA
>> ...
>> This is an rfcdiff from the already-wrapped JSON to the proposed -23 that
>> includes all the changes from the various DISCUSSes up to now:
>> https://tinyurl.com/y2qhjwh8
> As a quick note -- the diff above does not address the "discuss" part of
my
> second discuss point: the document remains ambiguous regarding *how* the
URL
> is to be returned. The lengthy parenthetical references added to the
> corresponding paragraph aren't sufficient to positively indicate that the
URL
> appears in a "Location" header: this needs to be stated explicitly rather
> than implied by a section reference.
I had previously updated to point to RFC7231 section 6.3.2, but upon careful
reading, I see that returning the URL in the Location: is not mandated by
6.3.2. I am a little bit surprised that 7231 is so vague on what I thought
was a pretty much written in stone process
Rather than returning the audit log as a response to the POST (with
a return code 200), the MASA MAY instead return a 201 ("Created")
- response ( sections 6.3.2 and 7.1)
containing
- a URL to the prepared (and idempotent, therefore cachable) audit
response.
+ response ( sections 6.3.2 and 7.1), with
+ the URL to the prepared (and idempotent, therefore cachable) audit
+ response in the Location: header.
Does this fix things for you?
--
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)
Benjamin Kaduk via Datatracker wrote: > Section 13.2 > I think CDDL needs to be a normative reference, as does RFC 7231. RFC > 2473 is listed but not referenced in the text, as are RFC 2663, RFC > 7217, and RFC 7575. CDDL->RFC8610, now normative. (Glad that got published) RFC2473 removed, we no longer attempt to document a stateless IPIP proxy mechanism. RFC2663 (NAT terminology) reference was for Join Proxy, and I've restored a reference in section 4. RFC7217 was thought to be relevant to Pledge use of SLAAC, but actually it's not, removed. You are right that we don't reference RFC7575, which is the architecture of ANIMA. I have added a sentence to the Intro, referencing RFC7575's goal of "secure by default" > Appendix B doc>Discovery of registrar MAY also be performed with DNS-based service doc> discovery by searching for the service "_brski- doc> registrar._tcp.example.com". In this case the domain "example.com" is doc> discovered as described in [RFC6763] section 11 (Appendix A.2 suggests doc> the use of DHCP parameters). > I'd suggest using "" per 6763 rather than "example.com". okay. doc>If no local proxy or registrar service is located using the GRASP doc> mechanisms or the above mentioned DNS-based Service Discovery methods doc> the pledge MAY contact a well known manufacturer provided bootstrapping doc> server by performing a DNS lookup using a well known URI such as doc> "brski-registrar.manufacturer.example.com". The details of the URI are doc> manufacturer specific. Manufacturers that leverage this method on the doc> pledge are responsible for providing the registrar service. Also see doc> Section 2.7. > It seems like there are some security considerations for device owners > that may wish to prevent such registrars from being used. Do we need > to direct them to run a firewall or similar? If they are doing ANIMA ACP bootstrapping, then there would ideally be no IPv4 available, and so this won't work anyway. I'd rather not get into too much of this here. > Appendix C > I don't know how important file "ietf-mud-extens...@2018-02-14.yang" > is, but it seems a tad generic. Renamed already. Ben, I'm posting the -25, and then moving on back to the responses to my responses, including Adam's concerns. -- ] 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)
WG: there is a chunk of Security Considerations text here that I hope
many will read.
Benjamin Kaduk via Datatracker wrote:
> Section 11.4
> It is not entirely clear to me whether device manufacturers are set up
> with incentives to maintain a well-run secure CA with strong hardware
> protections on the offline signing key for the root CA, cycling through
> various levels of intermediates, etc., that CAs in the Web PKI do
> today. If the manufacturer uses a less stringent process, that would
> leave the manufacturer's key as a more tempting attack surface, and it
> may be worth some discussion here about what damage could be done with
> a compromised MASA signing key. E.g., would an attack require
> restoring devices to factory defaults or otherwise waiting for natural
> bootstrapping events to occur? Would the attacker need to be on-path?
> Etc.
I wanted to add that I think that there are some interesting economic
discussions about these incentives. I wonder how to interest some people
into doing some analysis of a monetary rather that technical manner.
I have added:
11.4. Manufacturer Maintenance of trust anchors . . . . . . . 75
11.4.1. Compromise of Manufacturer IDevID signing keys . . . 77
11.4.2. Compromise of MASA signing keys . . . . . . . . . . 77
11.4.3. Compromise of MASA web service . . . . . . . . . . . 79
and this text is rough, and as yet unreviewed by anyone, and I
11.4. Manufacturer Maintenance of trust anchors
BRSKI depends upon the manufacturer building in trust anchors to the
pledge device. The voucher artifact which is signed by the MASA will
be validated by the pledge using that anchor. This implies that the
manufacturer needs to maintain access to a signing key that the
pledge can validate.
The manufacturer will need to maintain the ability to make signatures
that can be validated for the lifetime that the device could be
onboarded. Whether this onboarding lifetime is less than the device
lifetime depends upon how the device is used. An inventory of
devices kept in a warehouse as spares might not be onboarded for many
decades.
There are good cryptographic hygiene reasons why a manufacturer would
not want to maintain access to a private key for many decades. A
manufacturer in that situation can leverage a long-term certificate
authority anchor, built-in to the pledge, and then a certificate
chain may be incorporated using the normal CMS certificate set. This
may increase the size of the voucher artifacts, but that is not a
significant issues in non-constrained environments.
There are a few other operational variations that manufacturers could
consider. For instance, there is no reason that every device need
have the same set of trust anchors pre-installed. Devices built in
different factories, or on different days, or any other consideration
could have different trust anchors built in, and the record of which
batch the device is in would be recorded in the asset database. The
manufacturer would then know which anchor to sign an artifact
against.
Aside from the concern about long-term access to private keys, a
major limiting factor for the shelf-life of many devices will be the
age of the cryptographic algorithms included. A device produced in
2019 will have hardware and software capable of validating algorithms
common in 2019, and will have no defense against attacks (both
quantum and von-neuman brute force attacks) which have not yet been
invented. This concern is orthogonal to the concern about access to
private keys, but this concern likely dominates and limits the
lifespan of a device in a warehouse. If any update to firmware to
support new cryptographic mechanism were possible (while the device
was in a warehouse), updates to trust anchors would also be done at
the same time.
The set of standard operating proceedures for maintaining high value
private keys is well documented. For instance, the WebPKI provides a
number of options for audits at {{cabforumaudit}}, and the DNSSEC
root operations are well documented at {{dnssecroot}}.
It is not clear if Manufacturers will take this level of precaution,
or how strong the economic incentives are to maintain an appropriate
level of security.
This next section examines the risk due to a compromised MASA key.
This is followed by examination of the risk of a compromised
manufacturer IDevID signing key. The third section sections below
examines the situation where MASA web server itself is under attacker
control, but that the MASA signing key itself is safe in a not-
directly connected hardware module.
11.4.1. Compromise of Manufacturer IDevID signing keys
An attacker that has access to the key that the manufacturer uses to
sign IDevID certificates can create
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
https://tinyurl.com/yylruorn contains a diff against -24. Benjamin Kaduk via Datatracker wrote: > Section 5.8.1 doc>A log data file is returned consisting of all log entries associated doc> with the the device selected by the IDevID presented in the request. doc> The audit log may be truncated of old or repeated values as explained doc> below. The returned data is in JSON format ([RFC7951]), and the doc> Content-Type SHOULD be "application/json". For example: > If RFC 7951 is to be used, I'd suggest "is JSON-encoded YANG data". Typo, it should be 7159. doc>This document specifies a simple log format as provided by the MASA doc> service to the registrar. This format could be improved by distributed doc> consensus technologies that integrate vouchers with technologies such doc> as block-chain or hash trees or optimized logging approaches. Doing so doc> is out of the scope of this document but is an anticipated improvement doc> for future work. As such, the registrar client SHOULD anticipate new doc> kinds of responses, and SHOULD provide operator controls to indicate doc> how to process unknown responses. > This would be a great place to talk about the "version" field that's > otherwise ignored. As in, what should occur if the "version" is not 1? How about: A registrar that sees a version value greater than 1 indicates an audit log format that has been enhanced with additional information. No information will be removed in future versions; should an incompatible change be desired in the future, then a new HTTP end point will be used. doc>anticipated improvement for future work. As such, the registrar doc> client SHOULD anticipate new kinds of responses, and SHOULD provide doc> operator controls to indicate how to process unknown responses. > Is "registrar client" intended to be both words or just one? Probably not, removed. doc>A registrar SHOULD use the log information to make an informed doc> decision regarding the continued bootstrapping of the pledge. The > I may be confused, but I thought the registrar was asking for the log > after the voucher had already been issued. Are these check supposed to > keep the registrar from forwarding the voucher to the pledge, or just > as a check for future renewal operations? The voucher can be returned to the Pledge immediately, as there is never any issue about whether the Pledge should join. The MASA has already made that decision. The Registrar could avoid passing the voucher on until after the audit log checks are done, or could do that concurrently. What matters is that the audit log checks are done prior to the Registrar accepting an enroll request.This is down in (what is now) Figure 4. The Registrar may do additional checks of the audit log at later times, but I don't think we have any good advice on this yet. doc>A relatively simple policy is to white list known (internal or doc> external) domainIDs and to require all vouchers to have a nonce and/ or doc> require that all nonceless vouchers be from a subset (e.g. only doc> internal) domainIDs. A simple action is to revoke any locally issued > nit: missing "of" I don't know where the "of" that is missing goes. While investigating, I broke the big sentence up, and discovered that the 5209 reference was not coded as XML. Please clue me in what you mean... 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) 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) is supported. doc>credentials for the pledge in question or to refuse to forward the doc> voucher. A registrar MAY be configured to ignore the history of the > "simple action" in the case that the registrar doesn't like the audit > log results? See changes above for better clarity. >device but it is RECOMMENDED that this only be configured if > hardware assisted NEA [RFC5209] is supported. > Probably need to expand NEA. done, see above. > Section 5.9 doc>Although
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
https://tinyurl.com/yylruorn contains an updated diff against -24.
Benjamin Kaduk via Datatracker wrote:
> Section 5.2
> application/voucher-cms+json The request is a "YANG-defined JSON
> document that has been signed using a CMS structure" as described
> in Section 3 using the JSON encoding described in [RFC7951]. This
> Section 3 does not describe any "sign[ing] using a CMS structure"
> operation.
Yes, I see, the sentence structure is wrong. I have changed it:
- application/voucher-cms+json The request is a "YANG-defined JSON
- document that has been signed using a CMS structure" as described
- in Section 3 using the JSON encoding described in [RFC7951]. This
- voucher media type is defined in [RFC8366] and is also used for
- the pledge voucher-request. The pledge SHOULD sign the request
- using the Section 2.3 credential.
+ application/voucher-cms+json [RFC8366] defines a "YANG-defined JSON
+ document that has been signed using a CMS structure", and the
+ voucher-request described in Section 3 is created in the same way.
+ The media type is the same as defined in [RFC8366]. and is also
+ used for the pledge voucher-request. The pledge MUST sign the
+ request using the Section 2.3 credential.
> To be clear, this is MUST sign, but SHOULD use IDevID (vs. some other
> credential) to sign?
It was SHOULD, because we supported unsigned voucher requests, but we removed
that option. It is now MUST.
> constrained voucher formats are expected in the future. Registrar's
> and MASA's are expected to be flexible in what they accept.
> nits: no apostrophes for plurals.
done.
> proximity-registrar-cert: In a pledge voucher-request this is the
> first certificate in the TLS server 'certificate_list' sequence
> (see [RFC5246]) presented by the registrar to the pledge. This
> MUST be populated in a pledge voucher-request if the "proximity"
> assertion is populated.
> [same comment as above about "end-entity certificate"]
done.
> The registrar validates the client identity as described in EST
> [RFC7030] section 3.3.2. The registrar confirms that the 'proximity'
> assertion and associated 'proximity-registrar-cert' are correct.
> what 'proximity' assertion?
> Does verifying proximity-registrar-cert just mean checking that it's the
> same leaf certificate that the registrar presented? What happens if the
> validation fails?
Yes, it means confirming that the pinned certificate is one's own.
If it fails, then there is a MITM, and the connection should be closed.
{I will use "MITM" until someone tells if me we are using a different term}
I've split that paragraph up, as there are two thoughts, one is about the
ClientCertificate, and the other is about the pinned certificate.
The registrar validates the client identity as described in EST
- [RFC7030] section 3.3.2. The registrar confirms that the 'proximity'
- assertion and associated 'proximity-registrar-cert' are correct.
+ [RFC7030] section 3.3.2.
+
+ The registrar confirms that the assertion is 'proximity' and that
+ pinned 'proximity-registrar-cert' is the Registrar's certificate. If
+ this validation fails, then there a On-Path Attacker (MITM), and the
+ connection MUST be closed after the returning an HTTP 401 error code.
> Section 5.3
doc> A Registrar accepts or declines a request to join the domain, based
doc> on the authenticated identity presented. Automated acceptance
doc> criteria include:
> I suggest "for different networks, examples of automated acceptance
> criteria may include".
doc> If these validations fail the registrar SHOULD respond with an
doc> appropriate HTTP error code.
> Similarly, "If validation fails".
done.
> Section 5.4
doc> The BRSKI-MASA TLS connection is a 'normal' TLS connection
doc> appropriate for HTTPS REST interfaces. The registrar initiates the
doc> connection and uses the MASA URL obtained as described in Section 2.8
doc> for [RFC6125] authentication of the MASA.
> I'd consider mentioning the implicit trust anchor database as well as
> the MASA URL.
edits for another review changed this to:
The BRSKI-MASA TLS connection is a 'normal' TLS connection
appropriate for HTTPS REST interfaces. The registrar initiates the
connection and uses the MASA URL obtained as described in
Section 2.8. The mechanisms in [RFC6125] SHOULD be used
authentication of the MASA. Some vendors will establish explicit (or
private) trust anchors for validating their MASA; this will typically
done as part of a sales channel integration. Registars SHOULD permit
trust anchors to be pre-configured on a per-vendor basis.
doc> The MASA and the registrars SHOULD be prepared to support TLS client
doc> certificate authentication and/or HTTP Basic or Digest
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Fri, Aug 09, 2019 at 04:17:17PM -0400, Michael Richardson wrote:
>
> https://tinyurl.com/yylruorn contains a diff against -24.
>
> Benjamin Kaduk via Datatracker wrote:
> > [disclaimer: some of these comments get pretty blunt at the end; it's a
> > long document and I'm tired. Please try not to get too annoyed if I'm
> > failing to see something that's right in front of me.]
>
> > I concur with the directorate reviewers that expected a
> > high-level security analysis of what information flows where, and what
> > policy choices can be made that affect it. At a *very* high level
> > (skipping over a lot of things that I would expect to see), this would
> > be structured like:
>
> > On initial bootstrap, a new device uses local service autodiscovery to
> > locate a (proxy to a) local registrar. Having found a candidate
>
> I have included an edited version of this text. It was very well done, thank
> you!
>
> > Abstract
>
> > (side note?) Is there a quick explanation of why bootstrapping can
> > complete with just installation of the PKI (trust anchor?) and
> > provisioning a locally issued certificate is not mandatory?
>
> I don't think that we can fit a quick explanation into the Abstract.
> I did split up the last sentence.
This was a side note, so for my own edification more than the good of the
document...
> The hard thing that BRSKI provides is the trust of the network by the pledge.
> The trust of the device by the network is generally an "easy" problem solved
> by use of 802.1AR/IDevID. This is presently done in many existing EST and CMP
> users.
> So I'm not sure what further to do here.
and this helps; thank you!
> > Section 1
>
> > This document describes how pledges discover (or be discovered by) an
> > element of the network domain to which the pledge belongs to perform
> > the bootstrap. [...]
>
> > nit: s/be/are/, IIUC.
> > I think there's also something funky with the wording of "to perform the
> > bootstrap"; we may be looking for an element "that will perform the
> > bootstrap".
>
> yes, done.
>
> > 4. Pledge authorizing the registrar: "Should I join it?"
>
> > nit: what is "it"? Surely not the registrar, and presumably the
> > "network domain" in question?
>
> yes, it = "network"
>
> > This document details protocols and messages to answer the above
> > questions. It uses a TLS connection and an PKIX (X.509v3)
> > certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer
> > points 1 and 2. It uses a new artifact called a "voucher" that the
>
> > I'm kind of confused by "[IDevID] LDevID", since my understanding was
> > that the LDevID is issued only after all four steps are complete.
>
> Yes, that seems to be a typo.
>
> > Also, following the IDevID link lands me at a page that claims to be for
> > a standard of status "superseded".
>
> Yes, the IEEE apparently put out 802.1AR-2018 replacing -2009 last year.
> I don't have a copy, and the getieee program just goes in loops of logging
> in, or results in servlet errors.
> I even emailed support, and they were basically useless.
> {fetching coffee to avoid rant}
>
> > nit: one can use X.509v3 without being PKIX, and it's not entirely clear
> > that the IDevIDs will chain up to the Internet PKI.
>
> You didn't respond to my suggestion that PKIX!=Internet PKI.
> I do think that we want many things the IETF PKIX WG has produced
> since X.509v3, so I don't think that X.509v3 is an appropriate noun
> to describe things.
I think this discussion is continuing in the other thread, right?
> > Section 1.2
>
> > RFC 8174 has an updated version of the BCP 14 boilerplate.
>
> done already.
>
> > I'd suggest adding "MASA Audit Log" as a defined term to give advance
> > warning that this is an explicit protocol feature.
>
> added.
>
> > domainID: The domain IDentity is the 160-bit SHA-1 hash of the BIT
> > STRING of the subjectPublicKey of the pinned-domain-cert leaf,
> > i.e. the Registrars' certificate. This is consistent with the
> > subject key identifier (Section 4.2.1.2 [RFC5280]).
>
> > What would it take to move away from SHA-1 for this purpose? It's
> > unclear how long it will be before finding a second preimage of the SPKI
> > hash is feasible and thus using it as an identifier no longer serves to
> > uniquely identify something.
>
> 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.
> If so, we could just use that value in the MASA Audit Log.
> But, if we did, it would often still be the SHA-1 hash of the public key, but
>
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
https://tinyurl.com/yylruorn contains a diff against -24.
Benjamin Kaduk via Datatracker wrote:
> [disclaimer: some of these comments get pretty blunt at the end; it's a
> long document and I'm tired. Please try not to get too annoyed if I'm
> failing to see something that's right in front of me.]
> I concur with the directorate reviewers that expected a
> high-level security analysis of what information flows where, and what
> policy choices can be made that affect it. At a *very* high level
> (skipping over a lot of things that I would expect to see), this would
> be structured like:
> On initial bootstrap, a new device uses local service autodiscovery to
> locate a (proxy to a) local registrar. Having found a candidate
I have included an edited version of this text. It was very well done, thank
you!
> Abstract
> (side note?) Is there a quick explanation of why bootstrapping can
> complete with just installation of the PKI (trust anchor?) and
> provisioning a locally issued certificate is not mandatory?
I don't think that we can fit a quick explanation into the Abstract.
I did split up the last sentence.
The hard thing that BRSKI provides is the trust of the network by the pledge.
The trust of the device by the network is generally an "easy" problem solved
by use of 802.1AR/IDevID. This is presently done in many existing EST and CMP
users.
So I'm not sure what further to do here.
> Section 1
> This document describes how pledges discover (or be discovered by) an
> element of the network domain to which the pledge belongs to perform
> the bootstrap. [...]
> nit: s/be/are/, IIUC.
> I think there's also something funky with the wording of "to perform the
> bootstrap"; we may be looking for an element "that will perform the
> bootstrap".
yes, done.
> 4. Pledge authorizing the registrar: "Should I join it?"
> nit: what is "it"? Surely not the registrar, and presumably the
> "network domain" in question?
yes, it = "network"
> This document details protocols and messages to answer the above
> questions. It uses a TLS connection and an PKIX (X.509v3)
> certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer
> points 1 and 2. It uses a new artifact called a "voucher" that the
> I'm kind of confused by "[IDevID] LDevID", since my understanding was
> that the LDevID is issued only after all four steps are complete.
Yes, that seems to be a typo.
> Also, following the IDevID link lands me at a page that claims to be for
> a standard of status "superseded".
Yes, the IEEE apparently put out 802.1AR-2018 replacing -2009 last year.
I don't have a copy, and the getieee program just goes in loops of logging
in, or results in servlet errors.
I even emailed support, and they were basically useless.
{fetching coffee to avoid rant}
> nit: one can use X.509v3 without being PKIX, and it's not entirely clear
> that the IDevIDs will chain up to the Internet PKI.
You didn't respond to my suggestion that PKIX!=Internet PKI.
I do think that we want many things the IETF PKIX WG has produced
since X.509v3, so I don't think that X.509v3 is an appropriate noun
to describe things.
> Section 1.2
> RFC 8174 has an updated version of the BCP 14 boilerplate.
done already.
> I'd suggest adding "MASA Audit Log" as a defined term to give advance
> warning that this is an explicit protocol feature.
added.
> domainID: The domain IDentity is the 160-bit SHA-1 hash of the BIT
> STRING of the subjectPublicKey of the pinned-domain-cert leaf,
> i.e. the Registrars' certificate. This is consistent with the
> subject key identifier (Section 4.2.1.2 [RFC5280]).
> What would it take to move away from SHA-1 for this purpose? It's
> unclear how long it will be before finding a second preimage of the SPKI
> hash is feasible and thus using it as an identifier no longer serves to
> uniquely identify something.
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?
If so, we could just use that value in the MASA Audit Log.
But, if we did, it would often still be the SHA-1 hash of the public key, but
RFC5280 says:
"Other methods of generating unique numbers are also acceptable."
When https://tools.ietf.org/html/rfc5758 defined SHA-2 usage,
it didn't specify a way to identify keys with SHA-2, although the mechanism
is pretty clear.
> enrollment: The process where a device presents key material to a
> network and acquires a network specific identity. For example
> nit: hyphenate "network-specific".
ok.
> Section 1.4
> As a result of the protocol described herein, the bootstrapped
> devices
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On Tue, Jul 16, 2019 at 06:14:37PM -0400, Michael Richardson wrote: > > I have responded to DISCUSSes from: > Alissa Cooper: > https://mailarchive.ietf.org/arch/msg/anima/QZn8UnsNxtE3MCHm_gPVBl5uSrU > Roman Danyli: > https://mailarchive.ietf.org/arch/msg/anima/mff9ZyGBk4EflTqYS6fENWOFRpI > Alexey Melnikov > https://mailarchive.ietf.org/arch/msg/anima/Ul0yfnf4UlQhoI0UtlJVZ9otY7M > Adam Roach: > https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA > Eric Vyncke: > https://mailarchive.ietf.org/arch/msg/anima/O860UBbY4p3iNOZUdEYF_iNKMvs > > plus comments: > Mirja Kühlewind > https://mailarchive.ietf.org/arch/msg/anima/jFuz6ugS-_1bf0HG46vMjf3UNaw > Magnus Westlund: > https://mailarchive.ietf.org/arch/msg/anima/g1c17bHiBUMuhCmw4RDoHoN_1zE > and noted comments from Barry and Warren. > > and this is for Ben Kaduk's DISCUSS, which got buried, and I think is the > last. (You can always consult the datatracker page, too: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ballot/ I guess there's a couple No Objection with COMMENT that aren't mentioned above but maybe not that need replies.) > I'm going to use this email to deal with Ben's comments which I think we > already dealt with other edits, then I'll deal with low-hanging fruit, and > then decide how to deal with the desire for a high-level security analysis. > > Benjamin Kaduk via Datatracker wrote: > > (5) RFC7951 is cited for the audit log response, but I cannot find the > > underlying YANG module that is JSON-encoded using the RFC 7951 > > procedures. Furthermore, I don't think the "nonce" handling (with > > explicit "NULL" string where base64-encoded binary data might be > > expected) would be consistent with the 7951 rules. > > We did not resort to a YANG data model for the auditlog responses, so I spent > a few minutes mystified by your complaint... then: > We referenced 7951 (YANG->JSON), but we should have just referenced RFC7159 > (JSON)! Oh! That would make a lot more sense... (but 7159 is obsoleted by 8259, of course) > (Those numbers are annoyingly similar. And we actually made this mistake > before, I wonder if this was collatoral damage from a global search and > replace) > > > (6) In Section 7.2: > > >The pledge can choose to accept vouchers using less secure methods. > > These methods enable offline and emergency (touch based) deployment use > > cases: > > >1. The pledge MUST accept nonceless vouchers. This allows for a > > use > > > It's very unclear to me what this "MUST" means, especially so given > > that the entire section 7 is declared to be non-normative. Is it that > > the client "can choose" whether it "MUST accept nonceless vouchers"? > > That would seem to make the MUST basically ineffective. > > > > > > More broadly, if the entire Section 6 is non-normative, why is there > > any normative language in it? > > First, I think you mean section 7? I think you're right and that was a typo; sorry. > If so, the reason for normative language is because, we want to say, "if you > do X, then you MUST do it this way". > > Second, we have referenced some pieces of section 7.2 from section 9. > We think that there are significant security issues by accepting nonceless > vouchers, which we discuss in 11.1. A variation of the protocol is when > the manufacturer programs the pledge to ALWAYS accept nonceless vouchers. > There could otherwise be some more complex (proprietary, or documented later > on) evaluation of whether to accept a nonceless voucher. For instance, the > MASA could sign them with a different key, perhaps one stored in an HSM. Okay, so it is that the client (well, manufacturer?) chooses whether or not to accept nonceless vouchers. So we could change the introduction to the enumerated list to be saying that this is a list of exclusive candidate behaviors that could be chosen independently of each other, and not a collection of behaviors all of which are expected to be implemented. > A key point is that the Manufacturer/MASA knows exactly the rules that the > Pledge has been coded to, and we don't need to agree on all these rules to > get interoperability. Originally, we didn't even think we needed to > standardize the voucher, just the voucher-request; but it was the desire to > audit them on the Registrar that changed our mind. > > > (7) the new /enrollstatus and /voucher_status well-known EST endpoints > > are not registered in Section 8.1 > > Good catch, we have since been told by the .well-known designated expert that > either we create a new registry, or we just ask IANA to point the "est" > definition at RFC7030 and this document. Most .well-known entries do not > have registries. > > I haven't heard a clear opinion as to which we should do. I haven't, either, but if we do need an explicit list, we can remebmer to include these as well. > >
Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
On 7/16/19 5:14 PM, Michael Richardson wrote: Adam Roach: https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA ... This is an rfcdiff from the already-wrapped JSON to the proposed -23 that includes all the changes from the various DISCUSSes up to now: https://tinyurl.com/y2qhjwh8 As a quick note -- the diff above does not address the "discuss" part of my second discuss point: the document remains ambiguous regarding *how* the URL is to be returned. The lengthy parenthetical references added to the corresponding paragraph aren't sufficient to positively indicate that the URL appears in a "Location" header: this needs to be stated explicitly rather than implied by a section reference. /a ___ 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)
I have responded to DISCUSSes from: Alissa Cooper: https://mailarchive.ietf.org/arch/msg/anima/QZn8UnsNxtE3MCHm_gPVBl5uSrU Roman Danyli: https://mailarchive.ietf.org/arch/msg/anima/mff9ZyGBk4EflTqYS6fENWOFRpI Alexey Melnikov https://mailarchive.ietf.org/arch/msg/anima/Ul0yfnf4UlQhoI0UtlJVZ9otY7M Adam Roach: https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA Eric Vyncke: https://mailarchive.ietf.org/arch/msg/anima/O860UBbY4p3iNOZUdEYF_iNKMvs plus comments: Mirja Kühlewind https://mailarchive.ietf.org/arch/msg/anima/jFuz6ugS-_1bf0HG46vMjf3UNaw Magnus Westlund: https://mailarchive.ietf.org/arch/msg/anima/g1c17bHiBUMuhCmw4RDoHoN_1zE and noted comments from Barry and Warren. and this is for Ben Kaduk's DISCUSS, which got buried, and I think is the last. I'm going to use this email to deal with Ben's comments which I think we already dealt with other edits, then I'll deal with low-hanging fruit, and then decide how to deal with the desire for a high-level security analysis. Benjamin Kaduk via Datatracker wrote: > (5) RFC7951 is cited for the audit log response, but I cannot find the > underlying YANG module that is JSON-encoded using the RFC 7951 > procedures. Furthermore, I don't think the "nonce" handling (with > explicit "NULL" string where base64-encoded binary data might be > expected) would be consistent with the 7951 rules. We did not resort to a YANG data model for the auditlog responses, so I spent a few minutes mystified by your complaint... then: We referenced 7951 (YANG->JSON), but we should have just referenced RFC7159 (JSON)! (Those numbers are annoyingly similar. And we actually made this mistake before, I wonder if this was collatoral damage from a global search and replace) > (6) In Section 7.2: >The pledge can choose to accept vouchers using less secure methods. > These methods enable offline and emergency (touch based) deployment use > cases: >1. The pledge MUST accept nonceless vouchers. This allows for a > use > It's very unclear to me what this "MUST" means, especially so given > that the entire section 7 is declared to be non-normative. Is it that > the client "can choose" whether it "MUST accept nonceless vouchers"? > That would seem to make the MUST basically ineffective. > More broadly, if the entire Section 6 is non-normative, why is there > any normative language in it? First, I think you mean section 7? If so, the reason for normative language is because, we want to say, "if you do X, then you MUST do it this way". Second, we have referenced some pieces of section 7.2 from section 9. We think that there are significant security issues by accepting nonceless vouchers, which we discuss in 11.1. A variation of the protocol is when the manufacturer programs the pledge to ALWAYS accept nonceless vouchers. There could otherwise be some more complex (proprietary, or documented later on) evaluation of whether to accept a nonceless voucher. For instance, the MASA could sign them with a different key, perhaps one stored in an HSM. A key point is that the Manufacturer/MASA knows exactly the rules that the Pledge has been coded to, and we don't need to agree on all these rules to get interoperability. Originally, we didn't even think we needed to standardize the voucher, just the voucher-request; but it was the desire to audit them on the Registrar that changed our mind. > (7) the new /enrollstatus and /voucher_status well-known EST endpoints > are not registered in Section 8.1 Good catch, we have since been told by the .well-known designated expert that either we create a new registry, or we just ask IANA to point the "est" definition at RFC7030 and this document. Most .well-known entries do not have registries. I haven't heard a clear opinion as to which we should do. > (7.1) I think we also need to register the > "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa" XML namespace. added. > (8) The versioning mechanism for Pledge BRSKI Status Telemetry is > underspecified, including the interaction with new registered values. This was updated based upon comments from Adam. > (9) The versioning mechainsm for the MASA audit log response is > underspecified, including whether a registry of field names is > appropriate. This was updated based upon comments from Adam. > (10) The term PKIX seems to be incorrectly used a few times; it refers > to the Internet PKI, and so things like a private PKI internal to a > manufacturer would probably not be best described as such. Such > private PKIs can of course still reuse the protocols and mechanisms > developed for PKIX, and it's accurate to describe them as such. I would never call the Internet PKI "PKIX". I'd call it WebPKI, or CAB. PKIX is the set of IETF specifications that made X509v3 useful. (And why I try never to use "X509"...) I couldn't find a
[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-22: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ -- DISCUSS: -- (1) The text of the document suffers from lack of clarity throughout about whether the nonce-ful operation is mandatory or not, with several figures and discussions making declarative statements about nonce usage and others saying that nonce usage is optional. (See COMMENT.) (2) There also seems to be internal inconsistency about the proximity assertion process (and, any sort of assertion in a voucher-request at all, it seems). I've tried to note some locations in the Comment section. (3) There are other internal inconsistencies as well, including about section references for when various behaviors occur (see COMMENT). (4) In Section 5.6.1 The pledge MUST verify that the voucher nonce field is accurate and matches the nonce the pledge submitted to this registrar, or that the voucher is nonceless (see Section 7.2). Is the pledge supposed to accept a nonceless voucher in response to a nonce-ful voucher request? (5) RFC7951 is cited for the audit log response, but I cannot find the underlying YANG module that is JSON-encoded using the RFC 7951 procedures. Furthermore, I don't think the "nonce" handling (with explicit "NULL" string where base64-encoded binary data might be expected) would be consistent with the 7951 rules. (5) the new /enrollstatus EST endpoint seems under-specified. (6) In Section 7.2: The pledge can choose to accept vouchers using less secure methods. These methods enable offline and emergency (touch based) deployment use cases: 1. The pledge MUST accept nonceless vouchers. This allows for a use It's very unclear to me what this "MUST" means, especially so given that the entire section 7 is declared to be non-normative. Is it that the client "can choose" whether it "MUST accept nonceless vouchers"? That would seem to make the MUST basically ineffective. More broadly, if the entire Section 6 is non-normative, why is there any normative language in it? (7) the new /enrollstatus and /voucher_status well-known EST endpoints are not registered in Section 8.1 (7.1) I think we also need to register the "urn:ietf:params:xml:ns:yang:ietf-mud-brski-masa" XML namespace. (8) The versioning mechanism for Pledge BRSKI Status Telemetry is underspecified, including the interaction with new registered values. (9) The versioning mechainsm for the MASA audit log response is underspecified, including whether a registry of field names is appropriate. (10) The term PKIX seems to be incorrectly used a few times; it refers to the Internet PKI, and so things like a private PKI internal to a manufacturer would probably not be best described as such. Such private PKIs can of course still reuse the protocols and mechanisms developed for PKIX, and it's accurate to describe them as such. (11) In a few places we describe the voucher-request in terms of its YANG structure but do not say that it has to be wrapped in a signed CMS object as is done for the RFC 8366 voucher. (12) Maybe this is a "discuss discuss", but why do we need SHA-1 in the domainID calculation? (13) In Section 5.5.1: As described in [RFC8366] vouchers are normally short lived to avoid revocation issues. If the request is for a previous (expired) voucher using the same registrar then the request for a renewed voucher SHOULD be automatically authorized. The MASA has sufficient I don't understand what "for a previous (expired) voucher" means. Is it something like "containing the same content as a previous voucher request for which a voucher was issued", with the presumption that the voucher expired before the pledge could successfully imprint, so it needs to try again? Or does this extend to longer timescales, like a device that gets deployed for a couple years and is then reset to factory settings and has to rebootstrap but is still by the same registrar? (14) In Section 5.6: The server MUST answer with a suitable 4xx or 5xx HTTP [RFC2616] error code when a problem occurs. In this case, the response data from the MASA MUST be a plaintext human- readable (ASCII, English) error message containing explanatory information describing why the request was rejected. It seems hard to support this stance on internationalization in 2019. (15)
