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

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Wed, 24 April 2019 18:30 UTC

MIME-Version: 1.0
References: <CAL02cgT1hY_wm8d0zpa3hpx926B3_of+=cnDEwikMHS90gVyjw@mail.gmail.com> <CAGL6ep+8MiQNj1e6HGTeVownaS1nfn-TUjCa3aafRPeZ02AdiQ@mail.gmail.com> <DM6PR11MB3385A866E463497B5C19EA0CDB230@DM6PR11MB3385.namprd11.prod.outlook.com>
In-Reply-To: <DM6PR11MB3385A866E463497B5C19EA0CDB230@DM6PR11MB3385.namprd11.prod.outlook.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Wed, 24 Apr 2019 14:30:34 -0400
Message-ID: <CAGL6epKd+ooPS5s2VT6yPBtaxJxk0KtLuRLQr_dbJEg4-VTaMg@mail.gmail.com>
To: "Owen Friel (ofriel)" <ofriel@cisco.com>
Cc: Richard Barnes <rlb@ipv.sx>, IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005c8cc805874ae64e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/nMbEe7_5d2Kg_yi_puT1Tz6F5qQ>
Subject: Re: [Acme] Use cases / trust model for device certs
Precedence: list

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) <ofriel@cisco.com>
wrote:

> Hi Rifaat,
>
> Inline.
>
>
>
> *From:* Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
> *Sent:* 17 April 2019 20:37
> *To:* Richard Barnes <rlb@ipv.sx>
> *Cc:* IETF ACME <acme@ietf.org>; Owen Friel (ofriel) <ofriel@cisco.com>
> *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 <rlb@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] Use cases / trust model for device certs Richard Barnes
Re: [Acme] [SUSPICIOUS] Use cases / trust model f… Eliot Lear
Re: [Acme] Use cases / trust model for device cer… Rifaat Shekh-Yusef
Re: [Acme] Use cases / trust model for device cer… Owen Friel (ofriel)
Re: [Acme] Use cases / trust model for device cer… Rifaat Shekh-Yusef