Subject: Re: [EAT] [OAUTH-WG] Standardizing Attestation Tokens

From: Eliot Lear <[email-masked]>
Date: Thu, 21 Jun 2018 21:17:07 +0200

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-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Jun 2018 20:04:33 +0000

That’s a good question, Eliot. Let me put something together for the IETF meeting

From: Eliot Lear [mailto:[email-masked]]
Sent: 21 June 2018 20:17
To: Hannes Tschofenig; [email-masked]
Cc: Laurence Lundblade; [email-masked]
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

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

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-masked]<mailto:[email-masked]>

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.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Jun 2018 08:02:04 +0200

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:
> *From:*Eliot Lear [mailto:[email-masked]]
> *Sent:* 21 June 2018 20:17
> *To:* Hannes Tschofenig; [email-masked]
> *Cc:* Laurence Lundblade; [email-masked]
> *Subject:* Re: [OAUTH-WG] Standardizing Attestation Tokens
>
>  
>
> Hi Hannes,
>
> 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
>
>  
>
>     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.
>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Jun 2018 06:06:42 +0000

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

Sent: 22 June 2018 07:02

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.

From: Eliot Lear [mailto:[email-masked]]
Sent: 21 June 2018 20:17
To: Hannes Tschofenig; [email-masked]<mailto:[email-masked]>
Cc: Laurence Lundblade; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Standardizing Attestation Tokens

Hi Hannes,

Eliot

Ciao
Hannes

OAuth mailing list

---

From: "Wheeler, David M" <[email-masked]>
Date: Fri, 22 Jun 2018 14:02:36 +0000

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-masked]] On Behalf Of Hannes Tschofenig
Sent: Thursday, June 21, 2018 11:07 PM
To: Eliot Lear <[email-masked]>; [email-masked]
Cc: [email-masked]; Laurence Lundblade <[email-masked]>
Subject: Re: [EAT] [OAUTH-WG] Standardizing Attestation Tokens

Ciao
Hannes

Hi Hannes,

Eliot

Ciao
Hannes

OAuth mailing list

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 22 Jun 2018 09:00:28 -0700

> On Jun 22, 2018, at 7:02 AM, Wheeler, David M <[email-masked]> wrote:
> 
> Laurence,

Yes, good to hear from you too!

> 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 instal…

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,…

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

>   <>
>  <>From: EAT [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
> From: Eliot Lear [mailto:[email-masked] <mailto:[email-masked]>] 
> Sent: 22 June 2018 07:02
> To: Hannes Tschofenig; [email-masked] <mailto:[email-masked]>
> Cc: Laurence Lundblade; [email-masked] <mailto:[email-masked]>
> From: Eliot Lear [mailto:[email-masked] <mailto:[email-masked]>] 
> Sent: 21 June 2018 20:17
> To: Hannes Tschofenig; [email-masked] <mailto:[email-masked]>
> Cc: Laurence Lundblade; [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/eat <https://www.ietf.org/mailman/listinfo/eat>
>  
> https://tools.ietf.org/html/draft-mandyam-eat-00 <https://tools.ietf.org/html/draft-mandyam-eat-00>
>  
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 22 Jun 2018 09:12:43 -0700

Android Key Attestation <https://developer.android.com/training/articles/security-key-attestation> does this today. It is part of the Android Keystore that is usually implemented in the TEE. This feature is on Android P (maybe O too, I can’t recall for sure). 

It implements some of the same functionality as EAT, but uses an X.509 certificate for syntax. All the claims are in the X.509 v3 extensions in ASN.1 format. It is very oriented around key attestation as David requested the addition of. See here <https://developer.android.com/training/articles/security-key-attestation#certificate_schema>.

LL

> On Jun 21, 2018, at 11:02 PM, Eliot Lear <[email-masked]> wrote:
>