Re: [Acme] Use cases / trust model for device certs

[Rifaat Shekh-Yusef]

Hi Richard,

I was not aware of the ANIMA work before the meeting in Prague, so I will
definitely look into that in details.

One use case that I have in mind is a way to make sure that a specific
device can only be used by a specific party.
If you rely on RP to request identities for the device, then any party that
has a valid ACME account can use any device.
For example, if party A purchased a device from the vendor, and party B
gets a hold of that device, then there
is nothing that prevents party B from getting a valid ACME certificate for
that device.

If instead you reply on a token from the Device Authority, then the CA will
only issue a certificate to a specific party and specific device.

Regards,
 Rifaat


On Wed, Apr 17, 2019 at 1:09 PM Richard Barnes  wrote:

> Hey Rifaat,
>
> Owen and I were chatting about ACME and device certs this morning, and it
> seemed like it might be useful to rekindle discussion on the topic here on
> the ACME list.
>
> I'd like to push a little more on the trust model here.  Just to establish
> some terminology:
>
> - Device: Uses certificates to authenticate identifiers
> - Vendor: Makes the device that will get the end certificate
> - Customer: Buys the device from the vendor and operates it
> - CA: Validates identifiers and issues certificates
> - Relying Party: Uses certificates to verify authentication for identifiers
> - Device Identity: MAC address or similar
>
> In the flows Owen and I have been discussing (more based on ANIMA/BRSKI),
> the model is basically broken in two, with the customer in the middle:
>
> 1. The customer validates devices' device identity as part of the ANIMA
> flow, based on the customer trusting the vendor, and assigns the device a
> domain name
> 2. The customer uses ACME to issue domain name certificates (the CA is
> unaware of the device identity)
>
> That all pretty much just works with BRSKI and ACME as they are today.
> But it presumes that the RP is authenticating the device by domain name, as
> is prevalent in most uses of TLS today.
>
> In contrast, it seems like your draft presumes that the RP needs to know
> the device identity; it's not satisfied by a domain name alone.  Can you
> elaborate a bit more on what scenarios you have in mind for this?  If all
> you care about is the customer tracking things, then the model above is
> sufficient; the customer can simply assign domain names that encode the
> device identity however it likes.
>
> Thanks,
> --Richard
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] [SUSPICIOUS] Use cases / trust model for device certs

[Eliot Lear]

Hi Richard,

Just to add, ACME is really an enrollment protocol.  For device onboarding, we 
have those.  I hadn’t really thought about ACME as one, but there are 
definitely some concepts that can and should be leverage.  PoP or Proof of 
ownership is one that requires exploration.  Also, this ties to supply chain 
management/SBoM, and the work of SUIT.  Specifically, how does the onboarded 
identity relate to the application?

There is a mailing list for this: iot-onboard...@ietf.org 
.

Eliot

> On 17 Apr 2019, at 10:09, Richard Barnes  wrote:
> 
> Hey Rifaat,
> 
> Owen and I were chatting about ACME and device certs this morning, and it 
> seemed like it might be useful to rekindle discussion on the topic here on 
> the ACME list.
> 
> I'd like to push a little more on the trust model here.  Just to establish 
> some terminology:
> 
> - Device: Uses certificates to authenticate identifiers
> - Vendor: Makes the device that will get the end certificate
> - Customer: Buys the device from the vendor and operates it
> - CA: Validates identifiers and issues certificates
> - Relying Party: Uses certificates to verify authentication for identifiers
> - Device Identity: MAC address or similar
> 
> In the flows Owen and I have been discussing (more based on ANIMA/BRSKI), the 
> model is basically broken in two, with the customer in the middle:
> 
> 1. The customer validates devices' device identity as part of the ANIMA flow, 
> based on the customer trusting the vendor, and assigns the device a domain 
> name
> 2. The customer uses ACME to issue domain name certificates (the CA is 
> unaware of the device identity)
> 
> That all pretty much just works with BRSKI and ACME as they are today.  But 
> it presumes that the RP is authenticating the device by domain name, as is 
> prevalent in most uses of TLS today.
> 
> In contrast, it seems like your draft presumes that the RP needs to know the 
> device identity; it's not satisfied by a domain name alone.  Can you 
> elaborate a bit more on what scenarios you have in mind for this?  If all you 
> care about is the customer tracking things, then the model above is 
> sufficient; the customer can simply assign domain names that encode the 
> device identity however it likes.
> 
> Thanks,
> --Richard
> ___
> Acme mailing list
> Acme@ietf.org
> https://secure-web.cisco.com/1tlmqIbvXi2GsjydUBbTmsMvgAIUs8PxjTEsHBBrQHvGqLC_eq6oyniVBQXUhbMRIWXPbic_j3yu99L40LmxOHOYbKI4aLWdBh6LaxJPSYilwp4z5jjYm7UPZa8EOAIGFrR9y1rF0w2Ls0JKD9OKvDPF-XGunL6DjYBbJFzon6FcSCWNBEXAMs4i5ieqiAGKlvM-Mbou1gqIVK13Mf-9mlIBvXhq0Kry2Koqd9p67M1NUtZyo8XBseYnMDprATd3AN0j20H5vApQe62q3I36Pyx6Mi69rw_H6vODTiraXAsFI58RFVCsqmTrVa9ZTNVwV/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Facme



signature.asc
Description: Message signed with OpenPGP
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Use cases / trust model for device certs

[Richard Barnes]

Hey Rifaat,

Owen and I were chatting about ACME and device certs this morning, and it
seemed like it might be useful to rekindle discussion on the topic here on
the ACME list.

I'd like to push a little more on the trust model here.  Just to establish
some terminology:

- Device: Uses certificates to authenticate identifiers
- Vendor: Makes the device that will get the end certificate
- Customer: Buys the device from the vendor and operates it
- CA: Validates identifiers and issues certificates
- Relying Party: Uses certificates to verify authentication for identifiers
- Device Identity: MAC address or similar

In the flows Owen and I have been discussing (more based on ANIMA/BRSKI),
the model is basically broken in two, with the customer in the middle:

1. The customer validates devices' device identity as part of the ANIMA
flow, based on the customer trusting the vendor, and assigns the device a
domain name
2. The customer uses ACME to issue domain name certificates (the CA is
unaware of the device identity)

That all pretty much just works with BRSKI and ACME as they are today.  But
it presumes that the RP is authenticating the device by domain name, as is
prevalent in most uses of TLS today.

In contrast, it seems like your draft presumes that the RP needs to know
the device identity; it's not satisfied by a domain name alone.  Can you
elaborate a bit more on what scenarios you have in mind for this?  If all
you care about is the customer tracking things, then the model above is
sufficient; the customer can simply assign domain names that encode the
device identity however it likes.

Thanks,
--Richard
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme