Re: [Rats] Call for Adoption: EAT draft

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 <jodonogh@qti.qualcomm.com>
Sent: Donnerstag, 23. Mai 2019 18:57
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Carsten Bormann <cabo@tzi.org>; Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>; rats@ietf.org
Subject: Re: [Rats] Call for Adoption: EAT draft

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 <anders.rundgren.net@gmail.com<mailto:anders.rundgren.net@gmail.com>> wrote:

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

On 2019-05-23 13:53, Hannes Tschofenig wrote:

Hi Carsten,
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

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 <rats-bounces@ietf.org<mailto:rats-bounces@ietf.org>> On Behalf Of Carsten Bormann
Sent: Mittwoch, 22. Mai 2019 21:25
To: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com<mailto:Kathleen.Moriarty.ietf@gmail.com>>
Cc: rats@ietf.org<mailto:rats@ietf.org>
Subject: Re: [Rats] Call for Adoption: EAT draft

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.
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
_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats
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.
_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats

_______________________________________________
RATS mailing list
RATS@ietf.org<mailto:RATS@ietf.org>
https://www.ietf.org/mailman/listinfo/rats

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.