> On Jun 22, 2018, at 7:02 AM, Wheeler, David M <david.m.whee...@intel.com> > wrote: > > Laurence, > It is good to hear your name again! I look forward to seeing you in Montreal.
Yes, good to hear from you too! > 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. You are completely right and I completely agree. Was / is just a matter of doing the writing. Some have proposed inserting a CSR. That seems OK, but should be able to carry a bare public key too as CSRs are ASN.1 and we’d like to avoid that. The bare key should use the COSE formats for representing RSA, EC and other key types. > > Other attestation claims are also useful – the identity and cryptographic > hash of the code of a particular TEE application; Agree on this too. I have some text for a “measurement” claim that is not in the current draft. > a DH public key to establish an encrypted channel; the set of root CA’s this > TEE will trust; … Sure. > > 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. Anyone can add any claim they want. The only real rule is that non-standard claims must use a label in the proprietary range. The association of data with the security level is one the biggest design issue I’ve struggled with. The submods claim is the current thinking. See example A.2. LL > > I do like this proposal, I hope we can discuss some extensions to make it > more extensible. > > Thanks, > Dave Wheeler > <> > <>From: EAT [mailto:eat-boun...@ietf.org] On Behalf Of Hannes Tschofenig > Sent: Thursday, June 21, 2018 11:07 PM > To: Eliot Lear <l...@cisco.com>; oauth@ietf.org > Cc: e...@ietf.org; Laurence Lundblade <l...@island-resort.com> > 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:l...@cisco.com <mailto:l...@cisco.com>] > Sent: 22 June 2018 07:02 > To: Hannes Tschofenig; oauth@ietf.org <mailto:oauth@ietf.org> > Cc: Laurence Lundblade; e...@ietf.org <mailto:e...@ietf.org> > 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:l...@cisco.com <mailto:l...@cisco.com>] > Sent: 21 June 2018 20:17 > To: Hannes Tschofenig; oauth@ietf.org <mailto:oauth@ietf.org> > Cc: Laurence Lundblade; e...@ietf.org <mailto:e...@ietf.org> > 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 > <https://www.ietf.org/mailman/listinfo/eat> > > Here is a document describing the idea: > https://tools.ietf.org/html/draft-mandyam-eat-00 > <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 > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
