Subject: [Rats] Call for Adoption: EAT draft

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 10 May 2019 11:06:46 -0400

Greetings!

At IETF 104, a poll was taken to determine interest in the RATS WG
adopting:

The Entity Attestation Token (EAT)
https://datatracker.ietf.org/doc/draft-mandyam-rats-eat/

This begins a 2 week period to determine interest in adopting this draft as
a working group item.  The poll will close on May 24th EOD PDT.

Minutes from IETF 104:
https://datatracker.ietf.org/doc/minutes-104-rats/
-- 

Best regards,
Kathleen

---

From: Giridhar Mandyam <[email-masked]>
Date: Fri, 17 May 2019 15:23:08 +0000

Endorse adoption.

-Giri Mandyam

From: RATS <[email-masked]> On Behalf Of Kathleen Moriarty
Sent: Friday, May 10, 2019 8:07 AM
To: [email-masked]
Subject: [Rats] Call for Adoption: EAT draft

CAUTION: This email originated from outside of the organization.
Greetings!

At IETF 104, a poll was taken to determine interest in the RATS WG adopting:

This begins a 2 week period to determine interest in adopting this draft as a working group item.  The poll will close on May 24th EOD PDT.

Minutes from IETF 104:

Best regards,
Kathleen

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 21 May 2019 15:17:27 +0000

Hi Kathleen, Hi all,

I should not come as a surprise that I am in favour of adopting the EAT draft as a working group item.

Ciao
Hannes

From: RATS <[email-masked]> On Behalf Of Kathleen Moriarty
Sent: Freitag, 10. Mai 2019 17:07
To: [email-masked]
Subject: [Rats] Call for Adoption: EAT draft

Greetings!

Minutes from IETF 104:

Best regards,
Kathleen
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: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 22 May 2019 17:53:05 +0000

I like the draft, but there is one thing I would like to hear from the authors before answering the poll.

This YANG model is exposed by software on a networking device like a router.  The router can examine information from local cryptoprocessors such as a TPM.

In looking at the proposed YANG model (draft-birkholz-rats-basic-yang-module), the tpms-attest-result structure from this YANG model can contain the raw result from a TPM.  This to me seems to be a binary blob which could also carry CBOR encoded EAT claims.  Do you agree with this assessment?

Eric

From: RATS <[email-masked]> On Behalf Of Kathleen Moriarty
Sent: Friday, May 10, 2019 11:07 AM
To: [email-masked]
Subject: [Rats] Call for Adoption: EAT draft

Greetings!

Minutes from IETF 104:

Best regards,
Kathleen

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 22 May 2019 18:12:33 +0000

One of the RATS architecture goals is to define an information model representation (e.g. CDDL) of ‘assertions’ that can easily be mapped to a data model representation (e.g. CBOR / CWT claims) and binding to an attestable identity (e.g. TPM, root-of-trust etc…). YANG models can contain various data model representations of things. YANG can also be used as an information modeling language AFAK. It seems helpful if the information model work could offer some ideas for how best to relate information model content that may be scattered across multiple drafts.
-Ned

On 5/22/19, 10:53 AM, "RATS on behalf of Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Eric

Greetings!

Minutes from IETF 104:

Best regards,
Kathleen

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 22 May 2019 21:24:36 +0200

> This begins a 2 week period to determine interest in adopting this draft as a working group item.  The poll will close on May 24th EOD PDT.

Hi Kathleen,

I am definitely interested in this work.  This is important, and I’d like to be able to convince myself we are doing it right.

I apologize for maybe being a bit slow on the uptake, but currently I don’t have enough data to make a decision that the present document is on the trajectory yet where I’d normally ask for WG adoption.  Maybe this adoption call simply is a few weeks (draft revisions) too early.

While we can fix a lot of details in the WG process, I’d like to understand some fundamentals before committing to the trajectory I don’t understand.

For instance, I’d like to understand whether an EAT is a token or a protocol message in some as yet undescribed protocol.  E.g., there is the 11, nonce.  Is this the same thing that would be 7, cti in RFC 8392?  Or is it really something that is about an attestation protocol?  If this is a nonce, what does the “nonce” mean?  A single-use token?  A nonce that isn’t quite a nonce but only can be reused in a limited context?  How does the nonce bind to that context?

More generally, I’d like to understand whether an EAT *Is* a CWT, or *Is like* a CWT.
Can I put in an “exp” claim?  If yes, why do we need a new CBOR tag for something that essentially is a CWT?  Wouldn’t it be useful to explain when a CWT is an EAT and when it is just a plain CWT?  Tagging outside the COSE sign/mac isn’t enough (an attacker can change the tag and make a confusion attack).  Is this spec really the place to define a “loc” claim and its subclaims?  Is subclaims a concept that is only for EATs or is it for CWTs in general?

I could go on explaining my lack of understanding here, but I think it should be clear that there are a lot of questions on *what* we are doing here (as opposed to *how* we are doing it, which is what the WG process is good for nailing down).  A couple of iterations on this document might allow us to make a much better case that this is indeed going to be one of the base documents for the WG.  Or maybe it really is a couple or three documents waiting to hatch from the eggshell.  We still have > 6 weeks before I-D deadline for Montreal to clean this up.

Grüße, Carsten

---

From: Ira McDonald <[email-masked]>
Date: Wed, 22 May 2019 15:58:37 -0400

Hi Kathleen,

I'm in favor of adoption.

But I also note Carsten's and others' queries about scope and details.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Fri, May 10, 2019 at 11:07 AM Kathleen Moriarty <
[email-masked]> wrote:

> This begins a 2 week period to determine interest in adopting this draft
> as a working group item.  The poll will close on May 24th EOD PDT.
>
> Minutes from IETF 104:
> _______________________________________________
> RATS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 23 May 2019 06:44:03 -0400

Hi Carsten,

Thanks for raising your questions to the list (and authors).  I'll respond
with my take on it and would like to hear from the authors as well.

First, once a document is adopted, it becomes the product of the WG.  If
the WG would like it to strictly to have the attestation data use a CWT,
then the WG can specify that.  We don't have to wait on additional
iterations of the document to request adoption though.  I read through the
document and think it is well developed enough for adoption.  If you'd like
the document to take on a different shape, the way to do that is through
adoption, not more iterations outside of the WG process.

On Wed, May 22, 2019 at 3:24 PM Carsten Bormann <[email-masked]> wrote:

> I am definitely interested in this work.  This is important, and I’d like
> to be able to convince myself we are doing it right.
>

Your participation in review cycles would be most appreciated, especially
once adopted.

>
> I apologize for maybe being a bit slow on the uptake, but currently I
> don’t have enough data to make a decision that the present document is on
> the trajectory yet where I’d normally ask for WG adoption.  Maybe this
> adoption call simply is a few weeks (draft revisions) too early.
>
> While we can fix a lot of details in the WG process, I’d like to
> understand some fundamentals before committing to the trajectory I don’t
> understand.
>
> For instance, I’d like to understand whether an EAT is a token or a
> protocol message in some as yet undescribed protocol.  E.g., there is the
> 11, nonce.  Is this the same thing that would be 7, cti in RFC 8392?  Or is
> it really something that is about an attestation protocol?  If this is a
> nonce, what does the “nonce” mean?  A single-use token?  A nonce that isn’t
> quite a nonce but only can be reused in a limited context?  How does the
> nonce bind to that context?
>

Right the text of the draft from the start in the introduction does say
it's the same as CWT for the attestation, but it doesn't say it uses CWT:

   Moreover, the
   attestation data is defined in the form of claims that is the same as
   CBOR Web Token (CWT, see [RFC8392]).

Section 1.2 goes on to say:
   As per Section 7 of [RFC8392], the
   verification method is in the CWT using the CBOR Object Signing and
   Encryption (COSE) methodology (see [RFC8152]).

The intent of using CWT and CBOR is more clear here.

> Can I put in an “exp” claim?  If yes, why do we need a new CBOR tag for
> something that essentially is a CWT?  Wouldn’t it be useful to explain when
> a CWT is an EAT and when it is just a plain CWT?  Tagging outside the COSE
> sign/mac isn’t enough (an attacker can change the tag and make a confusion
> attack).  Is this spec really the place to define a “loc” claim and its
> subclaims?  Is subclaims a concept that is only for EATs or is it for CWTs
> in general?
>

I agree, having EAT use CWT is cleaner.  If something is lacking, the COSE
WG is open again...

>
> I could go on explaining my lack of understanding here, but I think it
> should be clear that there are a lot of questions on *what* we are doing
> here (as opposed to *how* we are doing it, which is what the WG process is
> good for nailing down).  A couple of iterations on this document might
> allow us to make a much better case that this is indeed going to be one of
> the base documents for the WG.  Or maybe it really is a couple or three
> documents waiting to hatch from the eggshell.  We still have > 6 weeks
> before I-D deadline for Montreal to clean this up.
>

I get your point, the references to both JOSE and COSE make it a bit
confusing.  However, in reading through the full draft, they plan to use
the CWT registry, so I think there's just some minor cleanup to do that
should not stop adoption.  My opinion is that we can straighten it up as a
WG document.

It would be helpful for the authors to chime in on intent around CWT in
case I missed anything.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 May 2019 11:53:59 +0000

Hi Carsten,

You have been around when CWT defined but let me provide a history for those who weren't.

The CWT was defined in ACE to correspond to a JWT. CWT uses CBOR together with COSE while the JWT uses JSON with JOSE.
The CWT spec aimed to provide an easy mapping of claims already defined for the JWT. The JWT, a standardized access token format, is widely used in OAuth deployments and because ACE-OAuth uses, as the name indicates, OAuth as a foundation it created a "more lightweight version" of the JWT in form of the CWT. Defining an alternative token format for use with OAuth was possible because in the OAuth architecture the format of the access token is opaque to the OAuth Client.

The CWT and the JWT have been defined for the OAuth authorization framework but they have later been used in other context too. Is this useful? It seems that the idea of having signed/encrypted/MACed claims is something people want to use even if different claims are used in different environments. Do they use different names then for these tokens (similarly what we do here with EAT)? Of course. People working in standardization like to come up with new names. That's why there are things like the "protection API access token (PAT)" or the "persisted claims token (PCT)".

Is a token, like the CWT or the JWT, now a protocol message, a "document" or what? If you don't send it around then it does not seem to be a message. Not sending a token anywhere wouldn't be too useful either. The question I have is: does it matter? From a practical usage point of view you will have to send it around and it will be part of some message. I personally don't call it message or protocol but that's just me. There are claims defined for CWTs and JWTs that provide some meta-data, such as allowing to restrict its validity (time-based and even to a one-time use), or information that indicate when it was created.

The main use case for attestation is a bit different than OAuth or ACE-OAuth because in OAuth/ACE-OAuth the access token gets created by the Authorization Server and is consumed by the Resource Server. While this is a possible use case also for RATS (when combined with an OAuth-based system, as folks in the OAuth group had suggested), the main use case (at least from my point of view) is that a device creates the token and then passes it on to the party that wants to verify it.

If the EAT document uses the same structure as a CWT but defines new claims should you therefore say that "it is" a CWT or should one rather say "it is like" a CWT. I think it a matter of taste. I do not care - pick something.

So, can you use claims defined already in an EAT token? Sure, you can. Will all the claims defined in the past be useful for an attestation context? Probably not. Will there be organizations defining profiles what claims they expect to see in an attestation token in a given deployment? Absolutely. GP, for example, is already working on it.

In a nutshell: EAT is a simple effort and that's a good thing. This is why we implemented it and it is waiting for you to use it.

Ciao
Hannes

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Carsten Bormann
Sent: Mittwoch, 22. Mai 2019 21:25
To: Kathleen Moriarty <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] Call for Adoption: EAT draft

Hi Kathleen,

Grüße, Carsten

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 23 May 2019 09:49:16 -0400

Chair hat off -

On Thu, May 23, 2019 at 7:54 AM Hannes Tschofenig <[email-masked]>
wrote:

> The CWT was defined in ACE to correspond to a JWT. CWT uses CBOR together
> with COSE while the JWT uses JSON with JOSE.
> The CWT spec aimed to provide an easy mapping of claims already defined
> for the JWT. The JWT, a standardized access token format, is widely used in
> OAuth deployments and because ACE-OAuth uses, as the name indicates, OAuth
> as a foundation it created a "more lightweight version" of the JWT in form
> of the CWT. Defining an alternative token format for use with OAuth was
> possible because in the OAuth architecture the format of the access token
> is opaque to the OAuth Client.
>
> The CWT and the JWT have been defined for the OAuth authorization
> framework but they have later been used in other context too. Is this
> useful? It seems that the idea of having signed/encrypted/MACed claims is
> something people want to use even if different claims are used in different
> environments. Do they use different names then for these tokens (similarly
> what we do here with EAT)? Of course. People working in standardization
> like to come up with new names. That's why there are things like the
> "protection API access token (PAT)" or the "persisted claims token (PCT)".
>
> Is a token, like the CWT or the JWT, now a protocol message, a "document"
> or what? If you don't send it around then it does not seem to be a message.
> Not sending a token anywhere wouldn't be too useful either. The question I
> have is: does it matter? From a practical usage point of view you will have
> to send it around and it will be part of some message. I personally don't
> call it message or protocol but that's just me. There are claims defined
> for CWTs and JWTs that provide some meta-data, such as allowing to restrict
> its validity (time-based and even to a one-time use), or information that
> indicate when it was created.
>

I'd say it is a CWT.  CWT was built so that you could add new claims and
the plan for EAT is to register these.  If editors agree, we are down to
editorial changes on a well developed specification.  I support adoption.

Best regards,
Kathleen

>
> The main use case for attestation is a bit different than OAuth or
> ACE-OAuth because in OAuth/ACE-OAuth the access token gets created by the
> Authorization Server and is consumed by the Resource Server. While this is
> a possible use case also for RATS (when combined with an OAuth-based
> system, as folks in the OAuth group had suggested), the main use case (at
> least from my point of view) is that a device creates the token and then
> passes it on to the party that wants to verify it.
>
> If the EAT document uses the same structure as a CWT but defines new
> claims should you therefore say that "it is" a CWT or should one rather say
> "it is like" a CWT. I think it a matter of taste. I do not care - pick
> something.
>
> So, can you use claims defined already in an EAT token? Sure, you can.
> Will all the claims defined in the past be useful for an attestation
> context? Probably not. Will there be organizations defining profiles what
> claims they expect to see in an attestation token in a given deployment?
> Absolutely. GP, for example, is already working on it.
>
> In a nutshell: EAT is a simple effort and that's a good thing. This is why
> we implemented it and it is waiting for you to use it.
>
> 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.
>

-- 

Best regards,
Kathleen

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 23 May 2019 15:54:14 +0200

Hi Hannes,
hi list,

TL;DR I'd strongly recommend to pick EAT *is* a CWT. The document itself 
really is not very consistent with respect to the corresponding 
question: *what* we are trying to do here?

Please find some comments in-line.

On 5/23/19 1:53 PM, Hannes Tschofenig wrote:
> The CWT and the JWT have been defined for the OAuth authorization framework but they have later been used in other context too. Is this useful? It seems that the idea of having signed/encrypted/MACed claims is something people want to use even if different claims are used in different environments. 

I totally agree with this statement. CWT is a super simple and obvious 
way to express assertions via claim sets.

The initial scope of CWT is inherited by JWT, analogously (as you 
highlighted), and is defined by the initial CWT claims set. The 
semantics of the resulting CBOR data item is even better defined via the 
corresponding CBOR tag for CWTs.

> Do they use different names then for these tokens (similarly what we do here with EAT)? Of course. People working in standardization like to come up with new names. That's why there are things like the "protection API access token (PAT)" or the "persisted claims token (PCT)".

Maybe I am mistaken, but I am under the impression that these names (or 
applications) you provide as examples were not created in the IETF 
though and, analogously, the creation was not under the corresponding 
control of the IETF. We have to make sure to understand the context here 
and the relationship to the existing IETF ecosystem, I think.

I am highlighting this, because wrt the IETF/RATS scope Carsten raised 
the quite relevant question if EAT "*Is* a CWT, or *Is like* a CWT"?

Naming a claim set for CWT is something different than creating a new 
type of token than CWT, I think.

First, your following reply focuses on the "protocol message" part of 

> Is a token, like the CWT or the JWT, now a protocol message, a "document" or what? If you don't send it around then it does not seem to be a message. Not sending a token anywhere wouldn't be too us…

I agree - a lot of the claims we find in CWT are similar to those of 
identity documents (e.g. time-based validity, creation-time) and 
therefore are used in authentication architectures/protocols, naturally.

I think the "protocol message" (which is semantically not very similar 
to a token that can be part of a protocol message) question might have 
come up due to the "nonce" claim? If so:

Typically, nonces are used as a basis to proof recentness via protocol 
messages in challenge/response based interaction models (also to provide 
some protection for replay, alas not for relay attacks).

I.e., I am not convinced that tokens are the best choice to express a 
complete protocol message (but are intended to be used by other 
protocols in their messages, e.g. TLS via tokbind). They could be 
tinkered that way, but I am not sure if that is the intended scope of a 
token, especially {J,C}WT.

> The main use case for attestation is a bit different than OAuth or ACE-OAuth because in OAuth/ACE-OAuth the access token gets created by the Authorization Server and is consumed by the Resource Ser…

I totally agree with this statement, too. And that's why I think the 
claims defined in the EAT draft provide significant value (and why I 
hope that they will be one of the sources for the RATS assertions 
information model, like Ned already highlighted).

> If the EAT document uses the same structure as a CWT but defines new claims should you therefore say that "it is" a CWT or should one rather say "it is like" a CWT. I think it a matter of taste. I…

The draft document itself seems to be torn with respect to this question:

Why EAT could be seen as *it is" a CWT:

1.) Section 5.1, Claim
> https://tools.ietf.org/html/draft-mandyam-rats-eat-00#section-5.1

The CWT Claim Registry is used to register EAT claims.

2.) Section 2, Terminology
> https://tools.ietf.org/html/draft-mandyam-rats-eat-00#section-2

The EAT draft includes the definition of "CWT Claims Set" and seems to 
allow for the use of CWT claims in EAT. Although, it is not spelled out 
explicitly. You also seem to believe that to be true further below in 
your reply, I think.

Why EAT could be seen as *it is like* a CWT:

1.) Section 2, Terminology
> https://tools.ietf.org/html/draft-mandyam-rats-eat-00#section-2

Like CWT, the definition of NumericDate is copied one-2-one into the EAT 
draft. Which was quite confusing when reading it for the first time (I 
think the wording should be rephrased and should only refer to the 
definition in CWT).

Like CWT, EAT does not incorporate the definition of Claim itself:
> Claim: A piece of information asserted about a subject.

2.) Section 5.2., EAT CBOR Tag Registration
> https://tools.ietf.org/html/draft-mandyam-rats-eat-00#section-5.2

Like CWT, EAT intends to register its own tag.

Also, I think this quote speaks a little bit for itself (admittedly, it 
seems to be just an oversight):
> Semantics: Entity Attestation Token (CWT), as defined in *this_doc*

I would be strongly in favor of designing EAT in a way that *it is* a 
CWT - and pick that one, personally.

> So, can you use claims defined already in an EAT token? Sure, you can. Will all the claims defined in the past be useful for an attestation context? Probably not. Will there be organizations defini…

And some of us are working with GP to do that :) But that is not what 
Carsten is trying to say, I think. To re-quote:
> it should be clear that there are a lot of questions on *what* we are doing here (as opposed to *how* we are doing it, which is what the WG process is good for nailing down)

Viele Grüße,

Henk

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 May 2019 14:07:59 +0000

*   I'd say it is a CWT.  CWT was built so that you could add new claims and the plan for EAT is to register these.  If editors agree, we are down to editorial changes on a well developed specification.  I support adoption.

Works for me.

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 23 May 2019 17:21:16 +0200

Hello Kathleen,

I just posted a list of recommendations wrt the EAT I-D. Not all of 
these are editorial, I think.

Viele Grüße,

Henk

On 5/23/19 3:49 PM, Kathleen Moriarty wrote:
> Chair hat off -
> 
> On Thu, May 23, 2019 at 7:54 AM Hannes Tschofenig 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Carsten,
> 
>     The CWT was defined in ACE to correspond to a JWT. CWT uses CBOR
>     together with COSE while the JWT uses JSON with JOSE.
>     The CWT spec aimed to provide an easy mapping of claims already
>     defined for the JWT. The JWT, a standardized access token format, is
>     widely used in OAuth deployments and because ACE-OAuth uses, as the
>     name indicates, OAuth as a foundation it created a "more lightweight
>     version" of the JWT in form of the CWT. Defining an alternative
>     token format for use with OAuth was possible because in the OAuth
>     architecture the format of the access token is opaque to the OAuth
>     Client.
> 
>     framework but they have later been used in other context too. Is
>     this useful? It seems that the idea of having signed/encrypted/MACed
>     claims is something people want to use even if different claims are
>     used in different environments. Do they use different names then for
>     these tokens (similarly what we do here with EAT)? Of course. People
>     working in standardization like to come up with new names. That's
>     why there are things like the "protection API access token (PAT)" or
>     the "persisted claims token (PCT)".
> 
>     Is a token, like the CWT or the JWT, now a protocol message, a
>     "document" or what? If you don't send it around then it does not
>     seem to be a message. Not sending a token anywhere wouldn't be too
>     useful either. The question I have is: does it matter? From a
>     practical usage point of view you will have to send it around and it
>     will be part of some message. I personally don't call it message or
>     protocol but that's just me. There are claims defined for CWTs and
>     JWTs that provide some meta-data, such as allowing to restrict its
>     validity (time-based and even to a one-time use), or information
>     that indicate when it was created.
> 
> 
>     ACE-OAuth because in OAuth/ACE-OAuth the access token gets created
>     by the Authorization Server and is consumed by the Resource Server.
>     While this is a possible use case also for RATS (when combined with
>     an OAuth-based system, as folks in the OAuth group had suggested),
>     the main use case (at least from my point of view) is that a device
>     creates the token and then passes it on to the party that wants to
>     verify it.
> 
>     claims should you therefore say that "it is" a CWT or should one
>     rather say "it is like" a CWT. I think it a matter of taste. I do
>     not care - pick something.
> 
>     So, can you use claims defined already in an EAT token? Sure, you
>     can. Will all the claims defined in the past be useful for an
>     attestation context? Probably not. Will there be organizations
>     defining profiles what claims they expect to see in an attestation
>     token in a given deployment? Absolutely. GP, for example, is already
>     working on it.
> 
>     In a nutshell: EAT is a simple effort and that's a good thing. This
>     is why we implemented it and it is waiting for you to use it.
> 
>     Ciao
>     Hannes
> 
>     From: RATS <[email-masked] <mailto:[email-masked]>> On
>     Behalf Of Carsten Bormann
>     To: Kathleen Moriarty <[email-masked]
>     <mailto:[email-masked]>>
>     Cc: [email-masked] <mailto:[email-masked]>
>      > This begins a 2 week period to determine interest in adopting
>     this draft as a working group item.  The poll will close on May 24th
>     EOD PDT.
> 
>     Hi Kathleen,
> 
>     I am definitely interested in this work.  This is important, and I’d
>     like to be able to convince myself we are doing it right.
> 
>     I apologize for maybe being a bit slow on the uptake, but currently
>     I don’t have enough data to make a decision that the present
>     document is on the trajectory yet where I’d normally ask for WG
>     adoption.  Maybe this adoption call simply is a few weeks (draft
>     revisions) too early.
> 
>     understand some fundamentals before committing to the trajectory I
>     don’t understand.
> 
>     protocol message in some as yet undescribed protocol.  E.g., there
>     is the 11, nonce.  Is this the same thing that would be 7, cti in
>     RFC 8392?  Or is it really something that is about an attestation
>     protocol?  If this is a nonce, what does the “nonce” mean?  A
>     single-use token?  A nonce that isn’t quite a nonce but only can be
>     reused in a limited context?  How does the nonce bind to that context?
> 
>     Can I put in an “exp” claim?  If yes, why do we need a new CBOR tag
>     for something that essentially is a CWT?  Wouldn’t it be useful to
>     explain when a CWT is an EAT and when it is just a plain CWT? 
>     Tagging outside the COSE sign/mac isn’t enough (an attacker can
>     change the tag and make a confusion attack).  Is this spec really
>     the place to define a “loc” claim and its subclaims?  Is subclaims a
>     concept that is only for EATs or is it for CWTs in general?
> 
>     I could go on explaining my lack of understanding here, but I think
>     it should be clear that there are a lot of questions on *what* we
>     are doing here (as opposed to *how* we are doing it, which is what
>     the WG process is good for nailing down).  A couple of iterations on
>     this document might allow us to make a much better case that this is
>     indeed going to be one of the base documents for the WG.  Or maybe
>     it really is a couple or three documents waiting to hatch from the
>     eggshell.  We still have > 6 weeks before I-D deadline for Montreal
>     to clean this up.
> 
>     Grüße, Carsten
> 
>     [email-masked] <mailto:[email-masked]>
>     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.
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 23 May 2019 11:36:35 -0400

Hi Henk,

> these are editorial, I think.

Great.  We can make technical and editorial edits in adopted drafts, that's
not an issue, it's expected.

Best,
Kathleen

-- 

Best regards,
Kathleen

---

From: Simon Frost <[email-masked]>
Date: Thu, 23 May 2019 16:24:10 +0000

I support adoption of this draft.

Regards
Simon Frost

From: Kathleen Moriarty <[email-masked]>
Sent: 10 May 2019 16:07
To: [email-masked]
Subject: [Rats] Call for Adoption: EAT draft

Greetings!

Minutes from IETF 104:

Best regards,
Kathleen

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 23 May 2019 18:53:23 +0200

> You have been around when CWT defined but let me provide a history for those who weren't.

Couldn't an iteration of
https://tools.ietf.org/html/draft-ietf-teep-opentrustprotocol-03
could build on EAT/CWT?

Anders

---

From: Jeremy O'Donoghue <[email-masked]>
Date: Thu, 23 May 2019 16:57:17 +0000

You could probably rewrite the messaging to use CWT, but...

  1.  There are a lot of protocol aspects in OTrP that don't really map well into EAT. You would still need a protocol definition.
  2.  An awful lot of what is in OTrP would be difficult to classify as "claims" (some of the auditing information meets the definition, but something like "Install TA" is not really a claim.
  3.  There are deployments of OTrP out there already, and other specifications that build on it. I don't believe such radical change would be a good idea (or at least should no longer be called OTrP)

Best regards
Jeremy

On 23 May 2019, at 17:53, Anders Rundgren <[email-masked]<mailto:[email-masked]>> wrote:

-------------------------------------------------------------------------
CAUTION: This email originated from outside of the organization.
-------------------------------------------------------------------------

Couldn't an iteration of

Anders

-----Original Message-----
From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Carsten Bormann
Sent: Mittwoch, 22. Mai 2019 21:25
To: Kathleen Moriarty <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Call for Adoption: EAT draft

[email-masked]<mailto:[email-masked]>

_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 23 May 2019 16:57:22 +0000

Yes, that's what some folks have been suggesting.
So far I haven't heard anyone saying that this would be a bad idea.

-----Original Message-----
From: Anders Rundgren <[email-masked]>
Sent: Donnerstag, 23. Mai 2019 18:53
To: Hannes Tschofenig <[email-masked]>; Carsten Bormann <[email-masked]>; Kathleen Moriarty <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] Call for Adoption: EAT draft

Couldn't an iteration of

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 23 May 2019 19:36:16 +0200

>  3. There are deployments of OTrP out there already, and other specifications that build on it. I don't believe such radical change would be a good idea (or at least should no longer be called OTrP)

I have suggested an even more radical change
https://github.com/ietf-teep/architecture/issues/52#issuecomment-493652265
where EAT/CWT would be a good fit.

But if OTrP is already deployed (and that means it must not change), I guess my point is moot.

Best regards,
Anders

> 
> 
> Best regards
> Jeremy
> 
>> On 23 May 2019, at 17:53, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>> From: RATS <[email-masked] <mailto:[email-masked]>> On Behalf Of Carsten Bormann
>>> To: Kathleen Moriarty <[email-masked] <mailto:[email-masked]>>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 24 May 2019 15:56:16 +0000

Hi Henk,

Thanks for your detailed response. I have inserted a few remarks below. In a nutshell, we are on the same page.

Hi Hannes,
hi list,

TL;DR I'd strongly recommend to pick EAT *is* a CWT.

[Hannes] Works for me.

The document itself really is not very consistent with respect to the corresponding
question: *what* we are trying to do here?

[Hannes] It is not unusual that a document proposed as a starting point for further work requires further work.

Maybe I am mistaken, but I am under the impression that these names (or
applications) you provide as examples were not created in the IETF though and, analogously, the creation was not under the corresponding control of the IETF. We have to make sure to understand the context here and the relationship to the existing IETF ecosystem, I think.

I am highlighting this, because wrt the IETF/RATS scope Carsten raised the quite relevant question if EAT "*Is* a CWT, or *Is like* a CWT"?

Naming a claim set for CWT is something different than creating a new type of token than CWT, I think.

[Hannes] Then, I should pick a different example. Take draft-ietf-oauth-jwsreq, for example. It uses the JWT structure and calls it  "JWT Secured Authorization Request" (JAR), or "Request Object". RFC 7521 uses the term "assertion" for JWTs and also for SAML assertions. RFC 7591 uses the term "software statements" for JWTs that assert metadata values about the software running on the client.

So, I still think it is good to use some new terminology for these use cases (as it is done with "EAT") but also saying that those are JWTs or CWTs, as it is the case there, is good.

> Is a token, like the CWT or the JWT, now a protocol message, a "document" or what? If you don't send it around then it does not seem to be a message. Not sending a token anywhere wouldn't be too us…

I agree - a lot of the claims we find in CWT are similar to those of identity documents (e.g. time-based validity, creation-time) and therefore are used in authentication architectures/protocols, naturally.

I think the "protocol message" (which is semantically not very similar to a token that can be part of a protocol message) question might have come up due to the "nonce" claim? If so:

Typically, nonces are used as a basis to proof recentness via protocol messages in challenge/response based interaction models (also to provide some protection for replay, alas not for relay attacks).

I.e., I am not convinced that tokens are the best choice to express a complete protocol message (but are intended to be used by other protocols in their messages, e.g. TLS via tokbind). They could be tinkered that way, but I am not sure if that is the intended scope of a token, especially {J,C}WT.

[Hannes] If you want to demonstrate freshness of the token then there are two common ways, namely nonces and timestamps. I believe both work fine and should be supported. So far, we haven't called CWTs with nonces used in ACE-OAuth protocol messages either. I think "token" is a nice term.

Regarding the token binding: To be honest I don't fully understand how replay protection of attestation information works there.

> The main use case for attestation is a bit different than OAuth or ACE-OAuth because in OAuth/ACE-OAuth the access token gets created by the Authorization Server and is consumed by the Resource Ser…

I totally agree with this statement, too. And that's why I think the claims defined in the EAT draft provide significant value (and why I hope that they will be one of the sources for the RATS assertions information model, like Ned already highlighted).

[Hannes] I like all except for one claim in the EAT document, namely the location claim. Luckily I don't have to use the location claim and so it is fine for me if someone else uses it. The main reason why I don't like the location claim is that it is difficult for the secure world to verify it. If you cannot verify it then what does attesting it really mean. I also raises the question why other sensor data is not registered either.

1.) Section 5.1, Claim

[Hannes] I agree with you. There is some room for improvement in the draft, as you pointed out.

> it should be clear that there are a lot of questions on *what* we are doing here (as opposed to *how* we are doing it, which is what the WG process is good for nailing down)

[Hannes] I said that because the question about whether separate registries should be created is something that also came up in prior discussions regarding JWTs and CWTs. My take on that is that it is fine to re-use registries.

Ciao
Hannes

Viele Grüße,

Henk

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 24 May 2019 16:01:15 +0000

Hi Jeremy,

This is probably a discussion for the TEEP working group but I was indeed wondering whether it makes sense to refer to the ongoing TEEP work as a “OTrPv2”.

Ciao
Hannes

From: Jeremy O'Donoghue <[email-masked]>
Sent: Donnerstag, 23. Mai 2019 18:57
To: Anders Rundgren <[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Carsten Bormann <[email-masked]>; Kathleen Moriarty <[email-masked]>; [email-masked]
Subject: Re: [Rats] Call for Adoption: EAT draft

Best regards
Jeremy

Hi Carsten,

Couldn't an iteration of

Anders

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 28 May 2019 14:09:18 +0000

Resending a question to the authors...   (It looks like it got skipped during the blizzard of emails on JWT/CWT)

Eric

From: RATS <[email-masked]> On Behalf Of Eric Voit (evoit)
Sent: Wednesday, May 22, 2019 1:53 PM

Eric

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Kathleen Moriarty
Sent: Friday, May 10, 2019 11:07 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Rats] Call for Adoption: EAT draft

Greetings!

Minutes from IETF 104:

Best regards,
Kathleen

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 28 May 2019 14:23:50 +0000

Sorry for the failure to respond.

Yes, your assessment is correct.  A custom claim can be created to carry the entire TPM attestation as a payload, similar to what is done in FIDO/Webauthn where the TPM relevant fields are included in a CBOR structure – see https://w3c.github.io/webauthn/#sctn-tpm-attestation.

Note that we would like to include claims into EAT that would cover measured boot.  There is no reason that entries in a PCR map couldn’t be represented as individual COSE structures (assuming the COSE algm. registry is consistent with the TPM specifications).  If so, then each measurement can nested within an EAT.

-Giri Mandyam

From: Eric Voit (evoit) <[email-masked]>
Sent: Tuesday, May 28, 2019 7:09 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Rats] Call for Adoption: EAT draft

Eric

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Eric Voit (evoit)
Sent: Wednesday, May 22, 2019 1:53 PM
I like the draft, but there is one thing I would like to hear from the authors before answering the poll.

Eric

Greetings!

Minutes from IETF 104:

Best regards,
Kathleen

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 28 May 2019 18:19:39 +0000

Hi Giridhar,

I expect we will want to expand the claims over time.  Based on that, what are the limits to what can plausibly be populated as an EAT claim?

This is an important question at adoption time.  One of the things I like about Section 3 (everything but section 3.4) is that all the proposed claims are very specific/well defined.   And also importantly, each of these claims feel to be something which could plausibly be supported and signed within a hardware chip.  This is goodness.

However Section 3.4 defines "unrestricted" security environments which provide "no meaningful security assurances".    I can see why this might feel interesting: it provides flexibility for future use/applicability of EAT anywhere.  But a downside is that this could be read to mean that a general purpose CPU could add their own Claim types and then sign them.

Initially that seems like this flexibility would be ok.  But there are lots of protocols in the Internet.  And  I expect each of those protocols would want to maintain an explicit the list of attributes which might be passed on top.    So if those protocols are to someday carry EAT information, it would be good to define the universe of what might conceivably be carried within.  Without this, there could be unnecessary fights on who owns the purview of various nested protocol objects.

Eric

From: Giridhar Mandyam, May 28, 2019 10:24 AM

-Giri Mandyam

From: Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 28, 2019 7:09 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [Rats] Call for Adoption: EAT draft

Eric

Eric

Greetings!

Minutes from IETF 104:

Best regards,
Kathleen

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 28 May 2019 12:53:35 -0700

Hi Eric,

CWT says it in the start of section 3 of RFC 8932: “…all claims that are not understood by implementations MUST be ignored.” So anyone can add any claims. There is a CWT claims registry, so if you want to be sure no one collides with your, register them. (Looks like EAT didn’t say this explicitly, but that is the intent. Anyone can add any claim. All claims are optional. This is just like CWT).

It quite the intention that a token can be generated on a general purpose CPU. However the idea is to mark it as such so the receiver knows. Of course, if a token in generated on a special security-oriented CPU, it will be signed there and the general purpose CPU will just be a middle man that can’t change it.

I foresee the work we do here as a general frame up for EAT including the definition of a lot of common and useful claims.  Then individual applications and use case and such will define profiles that say what claims are allowed or disallowed. The ARM PSA document is more-of-less an example of that. FIDO is interested in workin on a profile. I expect Global Platform to define a TEE-oriented profile.

LL

> On May 28, 2019, at 11:19 AM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> Hi Giridhar,
>  
> Yes, your assessment is correct.  A custom claim can be created to carry the entire TPM attestation as a payload, similar to what is done in FIDO/Webauthn where the TPM relevant fields are included in a CBOR structure – see https://w3c.github.io/webauthn/#sctn-tpm-attestation <https://w3c.github.io/webauthn/#sctn-tpm-attestation>.
>  
> From: Eric Voit (evoit) <[email-masked] <mailto:[email-masked]>> 
> To: [email-masked] <mailto:[email-masked]>
> From: RATS <[email-masked] <mailto:[email-masked]>> On Behalf Of Eric Voit (evoit)
> From: RATS <[email-masked] <mailto:[email-masked]>> On Behalf Of Kathleen Moriarty
> To: [email-masked] <mailto:[email-masked]>
> https://datatracker.ietf.org/doc/draft-mandyam-rats-eat/ <https://datatracker.ietf.org/doc/draft-mandyam-rats-eat/> 
>  
> https://datatracker.ietf.org/doc/minutes-104-rats/ <https://datatracker.ietf.org/doc/minutes-104-rats/>
> -- 
>  
> Best regards,
> Kathleen
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 28 May 2019 20:36:49 +0000

> There is a CWT claims registry, so if you want to be sure no one collides with your, register them. (Looks like EAT didn’t say this explicitly, but that is the intent. Anyone can add any claim. All claims are optional. This is just like CWT).

Clarification:  The EAT draft didn’t need to state the above, as EAT is making use of the existing CWT registry.  Each claim submitted to the CWT registry will undergo expert review – see https://tools.ietf.org/html/rfc8392#section-9.1.  The designated experts should verify that not only claim ID’s in a submitted registration are not overlapping with existing entries, but they should also determine “whether the proposed registration duplicates existing functionality”.

-Giri

From: Laurence Lundblade <[email-masked]>
Sent: Tuesday, May 28, 2019 12:54 PM
To: Eric Voit (evoit) <[email-masked]>
Cc: Giridhar Mandyam <[email-masked]>; [email-masked]
Subject: Re: [Rats] Call for Adoption: EAT draft

LL

On May 28, 2019, at 11:19 AM, Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Giridhar,

Eric

-Giri Mandyam

Eric

Eric

Greetings!

Minutes from IETF 104:

Best regards,
Kathleen

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 28 May 2019 21:27:28 +0000

Taking a look at the CWT Claims from:
https://www.iana.org/assignments/cwt/cwt.xhtml
there are less than 10 claim defined currently.  And some of these appear as if they are not specified to allow interoperation. E.g., from RFC7519 #4.1.3, the audience claim passes "values is generally application specific".

If the number of claims stays in the 10's, I think your proposal will work fine.   But what if the scale is more?

When I look at what is going on with YANG right now, I see many thousands of objects.  The administrative effort involved with understanding the semantic bindings between these objects consumes multiple Working Groups' time.

So with the current open-ended scoping of the domain of possible claims, would it be possible for any of these thousands of YANG objects to  being asserted by a device as a claim?  And would we have a way of explicitly defining the relationship/mapping between that claim and a corresponding YANG object?

I do like EAT.  I think it is useful.  I just want to avoid the creation/assignment of new, parallel universe of managed object definitions.  And I especially want to avoid undefined mappings between the two.  It would be great for the draft to explore how to minimize such complexities.

Eric

From: Giridhar Mandyam, May 28, 2019 4:37 PM

-Giri

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, May 28, 2019 12:54 PM
To: Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>
Cc: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Call for Adoption: EAT draft

LL

Hi Giridhar,

Eric

-Giri Mandyam

Eric

Eric

Greetings!

Minutes from IETF 104:

Best regards,
Kathleen

---

From: Giridhar Mandyam <[email-masked]>
Date: Tue, 28 May 2019 22:57:46 +0000

> If the number of claims stays in the 10's, I think your proposal will work fine.   But what if the scale is more?
…
> So with the current open-ended scoping of the domain of possible claims, would it be possible for any of these thousands of YANG objects to  being asserted by a device as a claim?  And would we hav…

Is your assumption that there could be thousands of registered YANG claims that extend the CWT registry?  For a claim being proposed for the registry, expert review is supposed to take into account the corresponding claim specification (which should document the relationship/mapping between a claim and a YANG object).  Writing a specification that would pass expert review should (in theory) be a high enough barrier to prevent mass registration of lightly-used or unused claims.

For unregistered claims - we cannot really stop implementations in the wild from using them.  I am not sure we would want to stop use of unregistered claims anyways as it could allow for pre-registration validation of any proposed claims.

Granted – I am putting a lot of faith in expert review for the CWT claims registry.  But I know that some of the designated CWT claims registry expert reviewers are reading this list and are quite diligent in carrying out their responsibilities.

-Giri

From: Eric Voit (evoit) <[email-masked]>
Sent: Tuesday, May 28, 2019 2:27 PM
To: Giridhar Mandyam <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Subject: RE: [Rats] Call for Adoption: EAT draft

Eric

-Giri

LL

Hi Giridhar,

Eric

-Giri Mandyam

Eric

Eric

Greetings!

Minutes from IETF 104:

Best regards,
Kathleen

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 28 May 2019 23:25:36 +0000

Hi Giri,

I like where this is going.  Are you willing to add text into this draft defining:
(a) some principles/guidance to CWT claims registry people on avoiding the mass registration of lightly-used or unused claims
(b) a requirement to map claims to existing YANG objects, if these YANG objects exist

Eric

From: Giridhar Mandyam, May 28, 2019 6:58 PM

…

-Giri

To: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>; Laurence Lundblade <[email-masked]<mailto:[email-masked]>>

Eric

-Giri

LL

Hi Giridhar,

Eric

-Giri Mandyam

Eric

Eric

Greetings!

Minutes from IETF 104:

Best regards,
Kathleen

---

From: Giridhar Mandyam <[email-masked]>
Date: Thu, 30 May 2019 16:54:20 +0000

Hi Eric,
Sorry for the delay in response.  I wanted to do some research first.

> Are you willing to add text into this draft defining:

I have added an issue to track - https://github.com/eat-ietf-wg/eat/issues/9.  It makes sense to provide suggested guidance to the CWT expert reviewers as to how they would evaluate additional claims with respect to EAT.

>(b) a requirement to map claims to existing YANG objects, if these YANG objects exist

I have added an issue as well – see https://github.com/eat-ietf-wg/eat/issues/10.  I would prefer to leverage RFC 7951 and https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ as much as possible in providing guidance within the EAT spec as to how such claims eventually map to CWT’s and JWT’s.  If you know of other guidelines in reflecting YANG objects into auth tokens that would be more relevant, please let me know.

-Giri

From: RATS <[email-masked]> On Behalf Of Eric Voit (evoit)
Sent: Tuesday, May 28, 2019 4:26 PM
To: Giridhar Mandyam <[email-masked]>; [email-masked]
Subject: Re: [Rats] Call for Adoption: EAT draft

Eric

…

-Giri

Eric

-Giri

LL

Hi Giridhar,

Eric

-Giri Mandyam

Eric

Eric

Greetings!

Minutes from IETF 104:

Best regards,
Kathleen

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 30 May 2019 17:17:54 +0000

Hi Giri, Hi Eric,

>(a) some principles/guidance to CWT claims registry people on avoiding the mass registration of lightly-used or unused claims

Why is this a requirement? When a claim is registered then it is most likely done with the anticipation that it will be used. I have not seen other IETF registries that have raised the bar to a similar level, at least the JWT claims registry does not work that way. Furthermore, what is the harm in registering claims that later turn out to be less frequently used?

>(b) a requirement to map claims to existing YANG objects, if these YANG objects exist

I also don’t understand this requirement. Is there some design rational why this would be needed/useful?

Cia
Hannes

---

From: Giridhar Mandyam <[email-masked]>
Date: Thu, 30 May 2019 17:49:07 +0000

Thanks for chiming in, Hannes.  I assume you can speak on behalf of the CWT claims registry expert reviewers.

>Why is this a requirement? When a claim is registered then it is most likely done with the anticipation that it will be used. I have not seen other IETF registries that have raised the bar to a simi…

OK – maybe guidance on lightly-used/unused claims is not desirable.

From a broader perspective - I am wondering whether claims intended for use in EAT should be designated as such when registering them in the CWT claims registry.  If so, should the CWT claims expert reviewers take into account different criteria when considering whether a proposed claim should be added to the registry?  If arbitrary claims are added to EAT via the registry that do not serve the purpose of remote attestation, it seems that the value of EAT would lessen.

>I also don’t understand this requirement. Is there some design rational why this would be needed/useful?

I was envisioning guidance along the lines of  - “If a claim represents a YANG object, then the corresponding CWT claim should follow the guidelines provided in https://datatracker.ietf.org/doc/draft-ietf-core-yang-cbor/ and the JWT claim should follow the guidelines of https://tools.ietf.org/html/rfc6020.”  This would hopefully prevent the case where a claim proposal uses an arbitrary methodology to map an attestation-related YANG object to CWT or JWT.  I don’t see a need to provide more guidance than this.

-Giri

From: Hannes Tschofenig <[email-masked]>
Sent: Thursday, May 30, 2019 10:18 AM
To: Giridhar Mandyam <[email-masked]>; [email-masked]; Eric Voit (evoit) <[email-masked]>
Subject: RE: [Rats] Call for Adoption: EAT draft

Cia
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 30 May 2019 18:39:51 +0000

Hi Giri,

We are currently in the phase of working document adoption and the question whether you would be willing to add this or that guidance to your individual draft isn’t actually relevant.
If your document becomes a working group item then we should have these details discussions about what claims should be registered and what the policy for adding new claims should be. Then, it is a decision of the working group and you will have to add it irrespectively of whether you like it or not. (At least that’s the idea.)

In a nutshell, we should have these discussions but now is actually not the time for it.

I will nevertheless give you feedback regarding your question below whether claims intended for use in EAT should be designated somehow: Of course this can be done by adding an extra attribute to the existing registry. Is it necessary is something I am wondering. There are, however, examples where adding an extra attribute to an already existing registry made sense. For example, when DTLS was developed the registry of algorithms for TLS was already established and there was a stream cipher (RC4) that couldn’t be used with DTLS. (Later we found out that stream ciphers are not even safe for TLS and hence this extra attribute does not make much sense anymore.)

Ciao
Hannes

From: RATS <[email-masked]> On Behalf Of Giridhar Mandyam
Sent: Donnerstag, 30. Mai 2019 19:49
To: [email-masked]
Subject: Re: [Rats] Call for Adoption: EAT draft

-Giri

From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, May 30, 2019 10:18 AM
To: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Eric Voit (evoit) <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Rats] Call for Adoption: EAT draft

Cia
Hannes

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 30 May 2019 19:19:39 +0000

Hi Hannes,

I do like EAT.  I am hoping that it gets adopted.  

At the same time, I am trying to avoid unnecessary mapping of claims from a chipmakers domain into system integrator /network operator domains.  I believe much pain can be avoided with a little planning up front.  That is what I am trying to facilitate with this discussion.  

Specific details/examples in-line...

> From: Hannes Tschofenig, May 30, 2019 1:18 PM
>
> Hi Giri, Hi Eric,   
> 

Let me provide a *best* case example.  In the NETMOD WG, there is a draft-ietf-netmod-geo-location.  Both that draft and this have definitions of latitude, longitude, altitude, accuracy, etc.   The *good* news is that both drafts are based on WGS84.  So at least our experts have lucked in to using a consistent resource.  But are these the same objects?  How does a reader know?   In one of the documents the latitude/longitude attributes are "FloatOrNumber", in the other they are "decimal64 {fraction-digits 16}".

It of course gets harder for other objects.   The velocity objects in draft-mandyam-rats-eat are "heading" and "speed".  And draft-ietf-netmod-geo-location has this information "v-north", " v-east", and " v-up".  Here we have different formats, the first of which cannot be easily upgraded to serve three dimensions.

And then we get into other harder objects where we will have timestamping, explicit domains of allowed entries, etc.  And is there is no boundaries on what might be claimed as an EAT, in theory we could create a parallel domain of objects without description on how to map between the two, placing the heavy lifting onto the implementer.

Now I am not trying to solve world hunger in this thread.  I am just trying to have the draft consider minimizing inter-ecosystem friction where we can see it coming.  I believe with a little foresight we can ensure a consistent population and data typing for a subset of claims.   Without foresight, I see that people will create new CWT to avoid some later mapping.  And more/redundant CWT tags will harm interoperability.
 
> I also don’t understand this requirement. Is there some design rational why this would be needed/useful?

Per above, EAT claim instances need to be integrated with other work/ecosystems in the IETF after the information comes off of a hardware chip.  A claim registry shouldn't create redundant info/formats to other work/ecosystems when it can be avoided, at least without broad discussion and consensus.   (I.e., lets avoid unconscious object definition and object domain overlaps wherever possible.)

Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 30 May 2019 20:14:38 +0000

Based on the inclusion of these issues, I am in favor of draft adoption.

Hopefully my other recent response to this thread shows why these issues are fairly fundamental to integrating EAT claims into Network Elements and their ecosystems.

Eric

From: RATS <[email-masked]> On Behalf Of Giridhar Mandyam
Sent: Thursday, May 30, 2019 12:54 PM
To: [email-masked]
Subject: Re: [Rats] Call for Adoption: EAT draft

Hi Eric,

-Giri

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Eric Voit (evoit)
Sent: Tuesday, May 28, 2019 4:26 PM
To: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Call for Adoption: EAT draft

Eric

…

-Giri

Eric

-Giri

LL

Hi Giridhar,

Eric

-Giri Mandyam

Eric

Eric

Greetings!

Minutes from IETF 104:

Best regards,
Kathleen

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 30 May 2019 16:09:11 -0700

So if an EAT is a CWT, then the proposal is to change the IANA registry rules for CWT in the EAT draft. Is that allowed? This is really a change to CWT and even JWT. Seems like it is saying that if a YANG-defined claim exists for a possible CWT or JWT claim, the YANG-based claim MUST be used. 

I think Eric’s thought about harmonizing is a good one. Learn from past efforts. Improve interop.

However, IANA registry rules revising aside, making it a MUST seems too much. I think the YANG-defined claims should be very much seriously considered, just like any other previous data structure definition, but that there be no blanket requirement.

To go a little further and to be clear. When a YANG-defined claim is used the CBOR encoding of it will be used with CWT and the JSON encoding of it will be used with JWT. This hinges on draft-ietf-core-yang-cbor-10 producing satisfying, compact and sensible CBOR encodings (binary data is really CBOR binary, claim keys are small integers…).

LL

> On May 30, 2019, at 12:19 PM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> Hi Hannes,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 31 May 2019 07:54:45 +0000

Hi Laurence, Hi Eric,

> So if an EAT is a CWT, then the proposal is to change the IANA registry rules for CWT in the EAT draft. Is that allowed? This is really a change to CWT and even JWT. Seems like it is saying that if…

IMHO everything can be changed.

> I think Eric’s thought about harmonizing is a good one. Learn from past efforts. Improve interop.

Learning from past efforts sounds always good. Let me pick on the example from below about draft-ietf-netmod-geo-location-01. It appears to me that the netmod group has either not looked at the work from the IETF GEOPRIV working group or ignored it. (I have not been involved in the netmod group and so I cannot say.) GEOPRIV published a number of RFCs that provide details about how to encode different geodetic location shapes (based on a mapping from GML), civic location, relative location, talks about uncertainty and confidence, how to encode moving objects, etc. While there is no need to use the info 1:1 there is a lot that can be learned from the work in that group. Of course, the content for the location encoding in draft-mandyam-eat-01 isn't much better.

For me the biggest question is whether location is actually a good source of information conveyed in an EAT token.

Eric, I understand that you do not want to duplicate information. I don’t want to do that either. I have been wondering about this aspect myself (particularly when I read the location claim). For example, in the LwM2M context we have a (pretty naive) location object as part of the data model as well. The data model we use with LwM2M is different to how data is modelled in the EAT token. Is this unavoidable? In some sense the situation is similar to the Yang-defined data model. The source of information comes from a different part of the system and is conveyed differently. Maybe you could call it a different layering where a device with Yang objects has to treat the EAT token as opaque (particularly since it is digitally signed and potentially encrypted). I am currently leaning towards seeing it that way from a LwM2M perspective.

Ciao
Hannes

~ snip ~

LL

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 31 May 2019 14:10:26 +0000

Hi Eric, Hi Laurence,

I thought about this a bit more.

If I understand it correctly then your main concern is that we duplicate information in the CWT claims registry that is already available in other registries. Is my understanding correct?
I also hear a second concern, which is more about whether the existing CWT / JWT registry contains claims that are not suitable for use in an EAT token.

Underlying both concerns is the question about what makes for a good claim for use within an EAT token. Do we know the answer?

Ciao
Hannes

-----Original Message-----
From: Hannes Tschofenig
Sent: Freitag, 31. Mai 2019 09:55
To: 'Laurence Lundblade' <[email-masked]>; Eric Voit (evoit) <[email-masked]>
Cc: [email-masked]; Giridhar Mandyam <[email-masked]>
Subject: RE: [Rats] Call for Adoption: EAT draft

Hi Laurence, Hi Eric,

Ciao
Hannes

~ snip ~

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 31 May 2019 14:41:53 +0000

Hi Hannes,
Hi Laurence,

> From: Hannes Tschofenig, May 31, 2019 10:10 AM
> 
> Hi Eric, Hi Laurence,
> 
> If I understand it correctly then your main concern is that we duplicate
> information in the CWT claims registry that is already available in other
> registries. Is my understanding correct?

Yes, this is the main concern.   I am not against duplication for good reasons.  I am against unconscious duplication which places the reconciliation role fully downstream.

> I also hear a second concern, which is more about whether the existing CWT /
> JWT registry contains claims that are not suitable for use in an EAT token.

I only brought up the location example when pressed.  I am less worried about location than future 'TBD object' claims.  Earlier assertions is this thread hinted that any object might be suitable to become a claim in the registry.
 
> Underlying both concerns is the question about what makes for a good claim for
> use within an EAT token. Do we know the answer?

I don't know the answer.
 
> > So if an EAT is a CWT, then the proposal is to change the IANA registry rules
> for CWT in the EAT draft. Is that allowed? This is really a change to CWT and
> even JWT. Seems like it is saying that if a YANG-defined claim exists for a
> possible CWT or JWT claim, the YANG-based claim MUST be used.
> 

I also believe things can be changed.  This is one of the reasons at the beginning of my comments I asked what the domain of possible claims might be.   Our IETF management processes must reflect the volume and provenance of claim types. 

As for me saying that claims MUST be YANG based, I certainly didn't mean to imply that.    What I wanted to say is that if downstream claim users have existing objects defined analogous to these claims, we should adopt these where possible.   These object might or might not be based on YANG.   But for Routers/Switches, YANG is where most of the recent object definition work has been happening.  

If there are no such analogous objects, we should feel free to define whatever we want.  However I suspect such 'green-space' objects will be rare.

> Learning from past efforts sounds always good. Let me pick on the example
> from below about draft-ietf-netmod-geo-location-01. It appears to me that the
> netmod group has either not looked at the work from the IETF GEOPRIV working
> group or ignored it. (I have not been involved in the netmod group and so I
> cannot say.) GEOPRIV published a number of RFCs that provide details about
> how to encode different geodetic location shapes (based on a mapping from
> GML), civic location, relative location, talks about uncertainty and confidence,
> how to encode moving objects, etc. While there is no need to use the info 1:1
> there is a lot that can be learned from the work in that group. Of course, the
> content for the location encoding in draft-mandyam-eat-01 isn't much better.
> 

I don't have a strong opinion on that.  But I can at least imagine a hardened GPS chip which signs its received location.
 
> Eric, I understand that you do not want to duplicate information. I don’t want to
> do that either. I have been wondering about this aspect myself (particularly
> when I read the location claim). For example, in the LwM2M context we have a
> (pretty naive) location object as part of the data model as well. The data model
> we use with LwM2M is different to how data is modelled in the EAT token. Is this
> unavoidable? In some sense the situation is similar to the Yang-defined data
> model. The source of information comes from a different part of the system and
> is conveyed differently. Maybe you could call it a different layering where a
> device with Yang objects has to treat the EAT token as opaque (particularly since
> it is digitally signed and potentially encrypted). I am currently leaning towards
> seeing it that way from a LwM2M perspective.

I really don't have a strong opinion on this.  But I like that we are having the discussion.

Eric

> Ciao
> Hannes
> 
> ~ snip ~
> 
> However, IANA registry rules revising aside, making it a MUST seems too much. I
> think the YANG-defined claims should be very much seriously considered, just
> like any other previous data structure definition, but that there be no blanket
> requirement.
> 
> To go a little further and to be clear. When a YANG-defined claim is used the
> CBOR encoding of it will be used with CWT and the JSON encoding of it will be
> used with JWT. This hinges on draft-ietf-core-yang-cbor-10 producing satisfying,
> compact and sensible CBOR encodings (binary data is really CBOR binary, claim
> keys are small integers…).
> 
> LL
> 
> 
> > At the same time, I am trying to avoid unnecessary mapping of claims from a
> chipmakers domain into system integrator /network operator domains.  I
> believe much pain can be avoided with a little planning up front.  That is what I
> am trying to facilitate with this discussion.
> >
> >> (a) some principles/guidance to CWT claims registry people on avoiding the
> mass registration of lightly-used or unused claims
> >>
> >> Why is this a requirement? When a claim is registered then it is most likely
> done with the anticipation that it will be used. I have not seen other IETF
> registries that have raised the bar to a similar level, at least the JWT claims
> registry does not work that way. Furthermore, what is the harm in registering
> claims that later turn out to be less frequently used?
> >
> > Let me provide a *best* case example.  In the NETMOD WG, there is a draft-
> ietf-netmod-geo-location.  Both that draft and this have definitions of latitude,
> longitude, altitude, accuracy, etc.   The *good* news is that both drafts are
> based on WGS84.  So at least our experts have lucked in to using a consistent
> resource.  But are these the same objects?  How does a reader know?   In one of
> the documents the latitude/longitude attributes are "FloatOrNumber", in the
> other they are "decimal64 {fraction-digits 16}".
> >
> > It of course gets harder for other objects.   The velocity objects in draft-
> mandyam-rats-eat are "heading" and "speed".  And draft-ietf-netmod-geo-
> location has this information "v-north", " v-east", and " v-up".  Here we have
> different formats, the first of which cannot be easily upgraded to serve three
> dimensions.
> >
> > And then we get into other harder objects where we will have timestamping,
> explicit domains of allowed entries, etc.  And is there is no boundaries on what
> might be claimed as an EAT, in theory we could create a parallel domain of
> objects without description on how to map between the two, placing the heavy
> lifting onto the implementer.
> >
> > Now I am not trying to solve world hunger in this thread.  I am just trying to
> have the draft consider minimizing inter-ecosystem friction where we can see it
> coming.  I believe with a little foresight we can ensure a consistent population
> and data typing for a subset of claims.   Without foresight, I see that people will
> create new CWT to avoid some later mapping.  And more/redundant CWT tags
> will harm interoperability.
> >
> > Per above, EAT claim instances need to be integrated with other
> work/ecosystems in the IETF after the information comes off of a hardware
> chip.  A claim registry shouldn't create redundant info/formats to other
> work/ecosystems when it can be avoided, at least without broad discussion and
> consensus.   (I.e., lets avoid unconscious object definition and object domain
> overlaps wherever possible.)
> >
> > Eric
> >
> >> Cia
> >> Hannes
> 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: Hannes Tschofenig <[email-masked]>
Date: Fri, 31 May 2019 14:56:37 +0000

>> Underlying both concerns is the question about what makes for a good
>> claim for use within an EAT token. Do we know the answer?

> I don't know the answer.

I unfortunately don't have an answer either.

I think the group will need to write some guidance (to be then used by the expert reviewers). I am sure there are folks in the group who could shed light on this aspect.
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: Simon Frost <[email-masked]>
Date: Fri, 31 May 2019 15:05:44 +0000

I've no experience of the process, but within this thread has been a discussion of requiring expert review before a new claim is accepted into the registry. Should the WG be able to provide guidelines for whoever is conducting such a review as to what considerations should be made before admitting a new claim?
For example:
+ ensuring the new claim is not already covered by one of the standard EAT claims. Note that I am assuming that the existing set will be tweaked / enhanced during the WG process.
+ comparing any related set of claims to information models covered in standards (the 'location' discussion)
+ ensuring that the implied data model for the claim is consistent
+ potentially expanding to a more public or (prior) WG member consultation in the event that a submission is seen as controversial.

...and Yes, I'm aware that the above may be potentially more expensive or time consuming, I'm trying to understand whether it’s appropriate to influence process as part of the standards process.

Thanks
Simon

-----Original Message-----
From: Hannes Tschofenig <[email-masked]>
Sent: 31 May 2019 15:10
To: Laurence Lundblade <[email-masked]>; Eric Voit (evoit) <[email-masked]>
Cc: [email-masked]; Giridhar Mandyam <[email-masked]>
Subject: Re: [Rats] Call for Adoption: EAT draft

Hi Eric, Hi Laurence,

Ciao
Hannes

-----Original Message-----
From: Hannes Tschofenig
Sent: Freitag, 31. Mai 2019 09:55
To: 'Laurence Lundblade' <[email-masked]>; Eric Voit (evoit) <[email-masked]>
Cc: [email-masked]; Giridhar Mandyam <[email-masked]>
Subject: RE: [Rats] Call for Adoption: EAT draft

Hi Laurence, Hi Eric,

Ciao
Hannes

~ snip ~

LL

---

From: Henk Birkholz <[email-masked]>
Date: Sat, 1 Jun 2019 00:51:43 +0200

Hi Hannes,

just thoughts from the top of my head:

1.) Expert review of course is helpful (feasibility, no overlap in claim 
semantics, etc.) and a quite straight forward procedure, but the 
qualifying criteria for CWT claims for EAT review might be defined in 
the EAT draft?

2.) in order to not make this a shopping list, I like the SUIT approach 
Hannes proposed, I think (not sure, if it is entirely applicable). In a 
nutshell, going from user story, to requirement, to claims.

But maybe that is on the information model level and should not burden 
the EAT I-D which is at a nice scope right now?

3.) Additionally, the semantics of a new CWT claim for EAT should be 
checked against existing YANG statement semantics. If there is semantic 
equivalence (or superset) defined in YANG already, the claim must 
reference that one.

I though this can be done via

> https://yangcatalog.org/yang-search/

But it seem not work for me right now...

That said, this would probably mitigate the issue, I assume. I might be 
missing something important here, of course.

Viele Grüße,

Henk

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 1 Jun 2019 06:45:23 +0000

Hi Henk,

A quick response below.

-----Original Message-----
From: Henk Birkholz <[email-masked]>
Sent: Samstag, 1. Juni 2019 00:52
To: Hannes Tschofenig <[email-masked]>; Laurence Lundblade <[email-masked]>; Eric Voit (evoit) <[email-masked]>
Cc: [email-masked]; Giridhar Mandyam <[email-masked]>
Subject: Re: [Rats] Call for Adoption: EAT draft

Hi Hannes,

1.) Expert review of course is helpful (feasibility, no overlap in claim semantics, etc.) and a quite straight forward procedure, but the qualifying criteria for CWT claims for EAT review might be defined in the EAT draft?

[Hannes] Yes, we have been talking about what those qualifying criteria for CWT claims in the EAT draft could look like. As mentioned, I don't have an answer for it. Still thinking...

2.) in order to not make this a shopping list, I like the SUIT approach Hannes proposed, I think (not sure, if it is entirely applicable). In a nutshell, going from user story, to requirement, to claims.

[Hannes] I don't think I suggested a specific approach here. The downside of the SUIT approach was/is that it takes very long and it is sometimes hard to decide what content goes where because everything is somewhat interrelated.

But maybe that is on the information model level and should not burden the EAT I-D which is at a nice scope right now?

3.) Additionally, the semantics of a new CWT claim for EAT should be checked against existing YANG statement semantics. If there is semantic equivalence (or superset) defined in YANG already, the claim must reference that one.

[Hannes] If I understand you correctly, then you are given the Yang registry a high priority in the process of defining EAT claims. Is that what you mean? How would this work for someone like Arm interested in the IoT space with the work we have been doing for Arm Trusted Firmware-M?

That said, this would probably mitigate the issue, I assume. I might be missing something important here, of course.

[Hannes] No, I don't think so. I think we are just a bit head of the discussion while doing a call for adoption.

Ciao
Hannes

Viele Grüße,

Henk

On 5/31/19 4:10 PM, Hannes Tschofenig wrote:
>>> (a) some principles/guidance to CWT claims registry people on
>>> avoiding the mass registration of lightly-used or unused claims
>>>