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

2019-09-16 Thread Michael Richardson

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)

2019-09-03 Thread Benjamin Kaduk
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)

2019-08-18 Thread Michael Richardson

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

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

2019-08-16 Thread Benjamin Kaduk
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)

2019-08-16 Thread Benjamin Kaduk
On Thu, Aug 15, 2019 at 12:17:22PM -0400, Michael Richardson wrote:
> 
> 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.

Understood.  To be clear, this was only ever intended to be an editorial
question (to be more explicit about not using client authentication), so
 use your editorial discretion.

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

2019-08-15 Thread Michael Richardson

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)

2019-08-15 Thread Benjamin Kaduk
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)

2019-08-15 Thread Benjamin Kaduk
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)

2019-08-15 Thread Michael Richardson

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)

2019-08-15 Thread Michael Richardson

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)

2019-08-15 Thread Michael Richardson

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)

2019-08-15 Thread Michael Richardson

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)

2019-08-14 Thread Michael Richardson

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)

2019-08-14 Thread Michael Richardson

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)

2019-08-14 Thread Michael Richardson

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)

2019-08-14 Thread Benjamin Kaduk
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)

2019-08-14 Thread Benjamin Kaduk
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)

2019-08-14 Thread Benjamin Kaduk
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)

2019-08-14 Thread Benjamin Kaduk
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)

2019-08-14 Thread Benjamin Kaduk
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)

2019-08-14 Thread Michael Richardson

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)

2019-08-13 Thread Michael Richardson

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)

2019-08-13 Thread Adam Roach

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)

2019-08-13 Thread Benjamin Kaduk
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)

2019-08-13 Thread Michael Richardson

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)

2019-08-12 Thread Michael Richardson

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)

2019-08-12 Thread Michael Richardson

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)

2019-08-12 Thread Michael Richardson

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)

2019-08-11 Thread Michael Richardson

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)

2019-08-09 Thread Benjamin Kaduk
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)

2019-08-09 Thread Michael Richardson

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)

2019-07-20 Thread Benjamin Kaduk
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)

2019-07-16 Thread Adam Roach

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)

2019-07-16 Thread Michael Richardson

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