Re: [EAT] [saag] "EAT" proposal for device attestation

[Laurence Lundblade <[e-mail]>]

Yes, I think the work should be separate. There’s lots of EAT stuff that has little to do with BRSKI and vice versa.

I do think it is useful to understand the primordial device key material in both and see how they relate.  From my experience this key material is to get set up well so the more info we have on real world practice and results, the better. 

LL



> On Jun 28, 2018, at 11:47 PM, Hannes Tschofenig <[e-mail]> wrote:
> 
> Hi Michael, Hi Laurence,
> 
> I prefer to keep the work on BRSIKI and EAT separate. I would also prefer not to reference IEEE 802.1AR.
> I think it would be a distraction.
> 
> Ciao
> Hannes
> 
> -----Original Message-----
> From: EAT [mailto:[e-mail]] On Behalf Of Michael Richardson
> Sent: 28 June 2018 21:04
> To: Laurence Lundblade
> Cc: [e-mail]
> Subject: Re: [EAT] [saag] "EAT" proposal for device attestation
> 
> 
> Laurence Lundblade <[e-mail]> wrote:
>> But, I don’t care that much what it is called. I’m interested in how BRSKI
>> and EAT relate because I think the ADs and lots of other folks will ask that
>> question.
> 
>> It still seems to me that both EAT and BRSKI make use of a secret/private key
>> that is stored securely on the device by the device manufacturer. That key is
>> used to prove to a server / service that the device is not a fake or
>> emulator.
> 
>> From there BRSKI goes on to define a protocol for bootstrapping a device
>> configuration and binding to a cloud service.
> 
> Yes, but in BRSKI, after connecting, BRSKI replaces the manufacturer's key with a domain-specific key bound to the owner of the device.
> 
> Once the device is under the owner's control, the manufacturer is no longer
> involved.   I don't think the LDevID is generally useful for attestation, but
> I could be wrong in some specific situations.
> 
>> EAT goes in a different direction to define a general means of representing
>> and signing lots claims about the device for lots of different use cases.
> 
>> BRSKI prefers IEEE IDevID.
> 
> I would say it differently, but yes, that's true.
> 
> BRSKI says to manufacturers, "thou shall provision a key pair signed by manufacturer".
> We don't really care that much about what it is... and actually 802.1AR's IDevID is woefully underspecified in my opinion!
> The major reason to refer to 802.1AR so that nobody thinks we are asking something ridiculous, and to make it clear that a TPM could be used to store it.
> 
> BRSKI could carry an EAT artifact in it somewhere.
> There are quite a number of choices actually.
> 
>> EAT can use IEEE IDevID, but accommodate other signing schemes like EPID /
>> ECDAA to deal with privacy, other non-X.509 public key schemes and even
>> symmetric keys if necessary.
> 
>> Does that make sense to everyone as a start on how these relate?
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works  -= IPv6 IoT consulting =-
> 
> 
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.