Subject: [Ace] Resume of discussion at IETF 103 meeting on draft-ietf-ace-oauth-authz

From: Ludwig Seitz <[email-masked]>
Date: Mon, 12 Nov 2018 16:21:55 +0100

Hello ACE,

I wanted to post a resume of the in room discussions from the IETF 103 
meeting, related to draft-ietf-ace-oauth-authz, for those who missed 
them and those who want to further comment (sorry for the verbose 
summary below):

During my presentation I put up a 7 issues for discussion as follows:

1. Use of one-byte CBOR abbreviations for parameters and CWT claims.

So far there is a consensus between me and Mike Jones on what we think 
is reasonable.

This would be summarized here: 
https://www.ietf.org/mail-archive/web/ace/current/msg03053.html

I was wondering if anyone else wants to weight in on what they consider 
important parameters & claims for constrained applications that need 
compact (one-byte) abbreviations in CBOR?

2. Unified registry for CWT claims and token/introspection parameter 
abbreviations

Currently the draft(s) have aligned the CBOR abbreviations for both CWT 
claims and token/introspection parameters under one singe number space.

There were arguments for splitting this up so that we can re-use the 
same compact one-byte abbreviations in those different "namespaces" i.e. 
there would be a number range just for CWT claims, and a separate one 
for introspection and token endpoint parameters.

Even here I'm interested in additional input.

3. CWT as format for signed protocol messages

As OAuth is currently working on a number of drafts specifying JWT as a 
format for encoding request (and response?) parameters wrt. the token 
and the introspection endpoint, the question was raised whether this 
should also be done for ACE and CWT.

My stance here (and I got the impression that the room agreed or at 
least had no strong opinion against) is that this is absolutely 
possible, but would best be done in an additional draft in order to not 
increase the already significant delay of draft-ietf-ace-oauth-authz.

4. Alignment between "req_aud" and "resource" parameters

draft-ietf-oauth-resource-indicators proposes a new parameter for the 
token request called "resource" which specifies the location of the 
resource or service for which the token is requested. This is supposed 
to map to the audience claim in the token.

draft-ietf-ace-oauth-params has in parallel defined the "req_aud" 
parameter (for "requested audience") which has a somewhat broader 
definition, roughly speaking "a value that the RS identifies with". This 
could be a public key, a group identifier or something else, so the key 
difference is that it is not specifically bound to the location of the RS.

I would argue to keep the "req_aud" as it is currently (since it covers 
a broader set of use cases than "resource"), but I would be curious to 
hear additional arguments for or against.

5. Handling of multiple tokens for one pair of client-RS

The question was whether an additional token issued for the same 
client-RS pair would

a.) Amend the permissions (i.e. scope) of the older token(s)

b.) Replace all older tokens for that client-RS pair

My implementation and my current understanding of the draft was a.) but 
apparently OAuth mostly does b.).
I would be strongly in favor of doing b.) (and clarifying the specs to 
this end) since it greatly simplifies the code on the RS side. Unless 
someone has a strong argument for approach a. I will implement that 
change in the next document update.

6. Do we need the expiration mechanism based on sequence numbers?

Section 5.8.3 of the draft currently proposes a sequence-number-based 
mechanism for expiration of access tokens on devices that do not have an 
internal clock. Since this mechanisms has pretty severe limitations and 
thus very weak security properties, and since we haven't yet seen a use 
case involving devices without at least an internal "wall-clock time" I 
propose to remove that mechanism from the draft, which seemed to be the 
in-room consensus as well.

7. Symmetric proof-of-possession keys and multi RS audiences

Currently the draft does NOT RECOMMEND this, since it allows one RS to 
impersonate the client towards other RSs that are part of the audience.
The in-room consensus seemed to be that this should be a MUST NOT 
instead and I agree.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51

---

From: Michael Richardson <[email-masked]>
Date: Mon, 12 Nov 2018 12:47:30 -0500

> https://www.ietf.org/mail-archive/web/ace/current/msg03053.html

This message seems to be about which ones get abbreviated.

I was thinking more that we need to have some process by which new
claim parameters get introduced, and how we observe they become popular, and
then then give them an abbreviation.

Unless I'm mistaken, a three character claim ("iss", "sub", etc.) will take
four bytes to encode.   That's not that expensive, but there are naturally a
limited number of interesting three letter codes.

Since we verify the signature and then interpret, (rather than interpret, try
to put it back into canonical order and verify), it seems that we can easily
replace longer codes with shorter ones as long as we can be sure our audience
knows the new shorter codes.

This last part seems the hardest part.

    > same compact one-byte abbreviations in those different "namespaces"
    > i.e. there would be a number range just for CWT claims, and a separate
    > one for introspection and token endpoint parameters.

    > Even here I'm interested in additional input.

I see both points of view, and I just don't know.
Clearly we need to decide *NOW* if want them to be seperate namespaces so
that programs build different tables.  If we later merge them, then that's
an easy transition.
Do they already have different IANA registries?  (I should know, but I don't)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 12 Nov 2018 22:07:13 -0600

[with no hats]

> Even here I'm interested in additional input.

I have no real data (or argument) here, but my gut feeling is that
eventually there would be desire for them to diverge, which would indicate
cleanly separating them from the start.

> increase the already significant delay of draft-ietf-ace-oauth-authz.

I agree.

> in-room consensus as well.

Some idea of wall-clock time is common, yes, but it is frequently easy for
an attacker to cause it to be wrong.  See, e.g.,
https://www.ietf.org/mail-archive/web/ietf/current/msg110144.html and the
document reviewed therein.

> The in-room consensus seemed to be that this should be a MUST NOT 

No objection here :)

-Ben

---

From: Jim Schaad <[email-masked]>
Date: Tue, 13 Nov 2018 13:47:10 +0900

Most of this is a restatement of previous positions.

> -----Original Message-----
> From: Ace <[email-masked]> On Behalf Of Ludwig Seitz
> Sent: Tuesday, November 13, 2018 12:22 AM
> To: [email-masked]
> Subject: [Ace] Resume of discussion at IETF 103 meeting on draft-ietf-ace-
> oauth-authz
> 
> Hello ACE,
> 
> meeting, related to draft-ietf-ace-oauth-authz, for those who missed them
> and those who want to further comment (sorry for the verbose summary
> below):
> 
> 
> So far there is a consensus between me and Mike Jones on what we think is
> reasonable.
> 

I have already weighted in where I care.

> There were arguments for splitting this up so that we can re-use the same
> compact one-byte abbreviations in those different "namespaces" i.e.
> there would be a number range just for CWT claims, and a separate one for
> introspection and token endpoint parameters.
> 

Especially after having gone to the RATS BOF, I really want to get these
separated and set an example for how things are done in the future.  Having
a CWT claim which identifies a namespace allows for a maximum number of
groups to define a new claim and then control the assignment within that
namespace in order to minimize size of those values.  Trying to go through
this process for the CWT claim experts does not make any sense.

> format for encoding request (and response?) parameters wrt. the token and
> the introspection endpoint, the question was raised whether this should
also
> be done for ACE and CWT.
> 
> My stance here (and I got the impression that the room agreed or at least
> had no strong opinion against) is that this is absolutely possible, but
would
> best be done in an additional draft in order to not increase the already
> significant delay of draft-ietf-ace-oauth-authz.

This is trivial to do and should definitely be in a different document, but
I would like to know that people are going to really implement it before
publishing a document.  One thing is that we already have this ability w/
the OSCORE wrappers so the set of use cases may be very different.

> token request called "resource" which specifies the location of the
resource
> or service for which the token is requested. This is supposed to map to
the
> audience claim in the token.
> 
could
> be a public key, a group identifier or something else, so the key
difference is
> that it is not specifically bound to the location of the RS.
> 
> I would argue to keep the "req_aud" as it is currently (since it covers a
> broader set of use cases than "resource"), but I would be curious to hear
> additional arguments for or against.

I agree with this.  We still need to get Hannes to clear his head and figure
out if he agrees with this after the discussions in Bangkok.

> The question was whether an additional token issued for the same client-RS
> pair would
> 
this end)
> since it greatly simplifies the code on the RS side. Unless someone has a
> strong argument for approach a. I will implement that change in the next
> document update.

I am not a big fan of this as I think that it may lead to more tokens being
issued.  Have a long term token for doing reads and a very short term token
for doing writes without having to have different authentication seems to be
a problem that I am not sure how it would be solved.

> internal clock. Since this mechanisms has pretty severe limitations and
thus
> very weak security properties, and since we haven't yet seen a use case
> involving devices without at least an internal "wall-clock time" I propose
to
> remove that mechanism from the draft, which seemed to be the in-room
> consensus as well.

Not having something like an internal I have been running for clock is just
not something that I would worry about.  This does not mean that a wall
clock exists so you would need to look at how the exp in a CWT is specified.
You many need some type of good for n time rather than a wall time.

> The in-room consensus seemed to be that this should be a MUST NOT

I think this should remain at NOT RECOMMENDED because in the future I think
it might be desired.

Jim

> 
> /Ludwig
> 
> 
> 
> --
> Ludwig Seitz, PhD
> Security Lab, RISE
> Phone +46(0)70-349 92 51
> 
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace