Re: [Rats] Call for Adoption: EAT draft

[Henk Birkholz <[e-mail]>]

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:
> 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. 


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 
the question raised, I think:

> 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 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 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.

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 do not care - pick something.
> 


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 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.


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

> 
> 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 <[e-mail]> On Behalf Of Carsten Bormann
> Sent: Mittwoch, 22. Mai 2019 21:25
> To: Kathleen Moriarty <[e-mail]>
> Cc: [e-mail]
> 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>