Laurence, It is good to hear your name again! I look forward to seeing you in Montreal.
I have skimmed through the proposal, but I still need to read it more deeply and carefully – please excuse me if I missed something in the reading. What seems to be missing from the proposed structure is the ability to attach new key material into the EAT structure, with an attestation claim. The attestation claim can be that it was generated on the device, or generated inside the TEE and bound/sealed to the TEE. And perhaps even a purpose for the key material. A new attestation key, for example; or a special signing/authorization key for a particular application. Many times, IMHO, it is useful to generate a new key that is attested in some way, and then future operations use that key. In fact, OTrP/TEEP has this implication, with the AIK keys for new installed Apps, but (IMO) it is not really that clearly spelled out, although I think the intention is clear. Other attestation claims are also useful – the identity and cryptographic hash of the code of a particular TEE application; a DH public key to establish an encrypted channel; the set of root CA’s this TEE will trust; … One additional thing that I would like to see is perhaps a more generic way to extend or add a claim into the attestation structure. After all, the attestation is just a container, that is signed, which carries some claims. But for these claims to be true, the claims must be constructed in a way that would be trusted by a verifier. Additional data for the verifier to understand how the claims are constructed (which may be inferred by the origination information), but may need more data, as some claims (for secure boot) may come from the TPM, and others from a TEE. I do like this proposal, I hope we can discuss some extensions to make it more extensible. Thanks, Dave Wheeler From: EAT [mailto:[email protected]] On Behalf Of Hannes Tschofenig Sent: Thursday, June 21, 2018 11:07 PM To: Eliot Lear <[email protected]>; [email protected] Cc: [email protected]; Laurence Lundblade <[email protected]> Subject: Re: [EAT] [OAUTH-WG] Standardizing Attestation Tokens I guess this is a piece of info we should have mentioned somewhere. Yes, the idea is to use a TEE for that purpose. At least for Arm, TrustZone for v8-M even brings TEE capabilities to the low-end IoT devices and the first products are already on the market. Ciao Hannes From: Eliot Lear [mailto:[email protected]] Sent: 22 June 2018 07:02 To: Hannes Tschofenig; [email protected]<mailto:[email protected]> Cc: Laurence Lundblade; [email protected]<mailto:[email protected]> Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens By the way, a lot *has* changed. If we can use the TEE to get signed information out... if *it* is the attester, that's a pretty big benefit. That just leaves the protocol gorp. But one needs to know that there is a TEE. On 21.06.18 22:04, Hannes Tschofenig wrote: That’s a good question, Eliot. Let me put something together for the IETF meeting From: Eliot Lear [mailto:[email protected]] Sent: 21 June 2018 20:17 To: Hannes Tschofenig; [email protected]<mailto:[email protected]> Cc: Laurence Lundblade; [email protected]<mailto:[email protected]> Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens Hi Hannes, The draft is interesting, but it looks a bit like NEA. How would this vary, apart from the CoAP part and a different registry? Seems to me the real magic is how the device is interrogated such that the consumer of this information has confidence as to its validity. The protocol bits are the easy part. If people have some understanding of that magic and are willing to share, then this work becomes considerably more interesting. Eliot On 21.06.18 17:11, Hannes Tschofenig wrote: Hi all, I would like to make you aware of work that will be discussed on attestation on the EAT mailing list. Here is the link to the list: https://www.ietf.org/mailman/listinfo/eat Here is a document describing the idea: https://tools.ietf.org/html/draft-mandyam-eat-00 The work is relevant for IoT and non-IoT devices. Laurence and I are planning to organize a Bar BOF at the Montreal IETF meeting to entertain the idea. Ciao Hannes 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. _______________________________________________ OAuth mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/oauth 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. 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.
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
