Re: [Rats] Call for Adoption: EAT draft

[Hannes Tschofenig <[e-mail]>]

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.

Please find some comments in-line.

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

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


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.

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

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

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

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

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


[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

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

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