Re: [Acme] Use cases / trust model for device certs
Thanks Owen, I honestly did not have a chance to look BRSKI yet. Just to make sure that I understand you correctly, are you saying that BRSKI has a solution for my use case with ACME? If so, can you please point me to the right document? Regards, Rifaat On Tue, Apr 23, 2019 at 6:41 PM Owen Friel (ofriel) wrote: > Hi Rifaat, > > Inline. > > > > *From:* Rifaat Shekh-Yusef > *Sent:* 17 April 2019 20:37 > *To:* Richard Barnes > *Cc:* IETF ACME ; Owen Friel (ofriel) > *Subject:* Re: Use cases / trust model for device certs > > > > 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. > > [ofriel] This is one of the use cases that BRSKI enables. Read the > sections relating to Ownership Tracker. > > > > 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. > > [ofriel] With strict ownership tracking, BRSKI is flexible enough to > prevent devices from bootstrapping against a network without proof of > ownership. > > > > 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. > > [ofriel] The Device Authority appears to perform a similar function to the > MASA audit log function. The Client (i.e. customer.com) can claim devices > from the DA (via some sales channel/integration API), the DA issues JWTs > indicating that the device is claimed by a specific Client, and ACME checks > that the requesting Client matches that in the JWT which the DA has logged. > The BRSKI MASA service audit logs every single domain that a device has > registered against, and does not preclude Registrars claiming > devices/proving ownership via some sales channel integration/API. It > appears that this proposal is trying to address similar issues as BRSKI. > > > > 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] Use cases / trust model for device certs
Hi Rifaat, Inline. From: Rifaat Shekh-Yusef Sent: 17 April 2019 20:37 To: Richard Barnes Cc: IETF ACME ; Owen Friel (ofriel) Subject: Re: Use cases / trust model for device certs 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. [ofriel] This is one of the use cases that BRSKI enables. Read the sections relating to Ownership Tracker. 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. [ofriel] With strict ownership tracking, BRSKI is flexible enough to prevent devices from bootstrapping against a network without proof of ownership. 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. [ofriel] The Device Authority appears to perform a similar function to the MASA audit log function. The Client (i.e. customer.com) can claim devices from the DA (via some sales channel/integration API), the DA issues JWTs indicating that the device is claimed by a specific Client, and ACME checks that the requesting Client matches that in the JWT which the DA has logged. The BRSKI MASA service audit logs every single domain that a device has registered against, and does not preclude Registrars claiming devices/proving ownership via some sales channel integration/API. It appears that this proposal is trying to address similar issues as BRSKI. Regards, Rifaat On Wed, Apr 17, 2019 at 1:09 PM Richard Barnes mailto:r...@ipv.sx>> 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] Use cases / trust model for device certs
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
[Acme] Use cases / trust model for device certs
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
