Subject: [Ace] WGLC for draft-ietf-ace-authz

From: Jim Schaad <[email-masked]>
Date: Mon, 8 Oct 2018 14:34:40 -0700

The chairs believe that the set of documents dealing with the OAuth
framework for constrained environments is nearing the point that we should
be able to advance it to the IESG for publication.   We therefore want to
have a full list of issues that need to be dealt with at the Bangkok
meeting.

This starts a 2 week WGLC for draft-ietf-ace-authz

We know that the following issues are outstanding:

draft-ietf-ace-authz
*  There are a couple of esoteric issues around listing AS servers
associated with resources in a Resource Directory

Jim & Roman

---

From: Jim Schaad <[email-masked]>
Date: Mon, 22 Oct 2018 12:09:19 -0700

* Section 3.1 - Refresh Token - I don't think that refresh tokens are going
to be strings because binary is more efficient.

* Section 3.2 - we need to reference TLS 1.3 even if DTLS 1.3 is not yet
available.

* Description for Figure 6 -  Should the example somehow indicate in the
message that it is going to be an application/ace+cbor content.   Also, I
don't know that this is a good example in some ways because this is not a
currently documented profile anywhere.

* Section 5.6.3 - Should the content type for an error response be
application/ace+cbor ?

* Section 5.7.1 - Is the content format for a request application/ace+cbor?
I assume it is but that is not documented in this section.

Section 5.8 - bytes arrays or byte strings?  I think CBOR uses the latter

* Section 5.8.1 - What is the purpose of creating an identifier for a token?
Is this supposed to be used rather than the one from the AS for something
like shared secret TLS?  Note that this is an unprotected value.

* Section 5.8.1 - Given the change in the OSCORE profile, you might want to
make this an application/ace+cbor structure as well.

* Section 5.8.1 - If the token is "not valid" is the RS required (i.e. MUST)
to try introspection before returning a response if the RS does
introspection?  The text currently says MAY.  If this is really MAY then the
text should say that the token is always successfully accepted by the RS.

* Section 5.8.2 - If the RS is going to do introspection, can it send some
type of "Server Busy - try again in xxx" while it does the introspection
rather than just doing an ack of the request and possibly waiting a long
time?

* Section 5.8.3 - third point - I think that the correct text would be "The
method does not provide timely expiration, but it makes sure that older
tokens will cease to be valid after newer issued tokens are registered with
the RS."  My problem is that just issuing tokens is not enough as they may
be going to a different RS for use.  This may also need to have some type of
rate limit to issued tokens or making the sequence number be on an
RS/audience basis.

* Section 6. - The recommendation not to use a shared secret for an audience
which is hosted by multiple servers is interesting.  This does require that
a multiple recipient COSE structure be used and it may be worth calling that
out.  Also the size of the CWT is going to grow for that.  You are also now
losing the low-level authentication and thus a signature wrapping is now
also needed.

* Section 6 - "Developers MUST" para - May want to add that this can also be
mitigated to some extent by making sure that keys roll over more frequently.

* Section 6 - I am not sure that I agree with the SHOULD NOT in the last
paragraph.  Think multicast.

* Section 6.4 - This also applies to sending back some type of identifier
from the RS->C when a token is registered.

* Section 8.6.1 - Is pop still this document or is it Mike's document?

* Section 8.9 - The description of reference is wrong.

* Section 8.12 - some of these should move to the OAuth parameters document?

* Section 8.13 - ditto

* Appendix A -  para "CBOR, COSE, CWT"  - Is it really a requirement to use
CBOR or is that a recommended?  I thought this was part of what Hannes was
looking at.

* Appendix A - para Client Credentials Grant  s/can the/can then/

* Registries -  I am wondering if we should think about re-writing a couple
of the registries.  As things stand it appears that the application/ace+cbor
content type is being used in 5 or 6 places.  It might make more sense to
have a registry for all of the CBOR abbreviations that are being used in a
single table and have multiple columns for each of the different places were
the content format is being used.  This would make it easier to keep
everything constant and can make re-use of integer values easier to see.  

* Comments on protection of CWT/Token:  I am wondering if there needs to be
any comments on how a CWT is going to be protected.  While it is ok to use
either a symmetric key or a direct key agreement operation for a single
recipient without forcing a signature operation to occur.  If the token is
going to be targeted a single audience hosted on multiple RSs then a
signature operation would be required for the purposes of authentication.  

* I am not sure where this issue should be raised so I am putting it here.
Both of the profiles have as their last security consideration a statement
that the use of multiple access tokens is a bad idea.  Both of them also
devote a large section of text to how to deal with multiple access tokens as
does this document.  More methods of having multiple access tokens seem to
be coming down the path from the OAuth group.  This appears to be a distinct
contradiction within the set of documents that should be resolved.  

Jim

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 23 Oct 2018 16:43:14 +0200

Hallo Jim,

thank you for the review! Comments inline.

/Ludwig

> to be strings because binary is more efficient.

This refers to the way it is defined in OAuth. I'll add a word to clarify.

> * Section 3.2 - we need to reference TLS 1.3 even if DTLS 1.3 is not yet
Agree.

> currently documented profile anywhere.
True. I'll change this to OSCORE.

> * Section 5.6.3 - Should the content type for an error response be
That makes sense. I'll add a sentence to that effect.

> I assume it is but that is not documented in this section.I'll add that.

> Section 5.8 - bytes arrays or byte strings?  I think CBOR uses the latter
Right that slipped through. I'll replace it.

> like shared secret TLS?  Note that this is an unprotected value.
AFAIK cti is not a mandatory claim of an access token, thus a RS might 
want to create an identifier for tokens that do not have a cti.

> make this an application/ace+cbor structure as well.
Right

> text should say that the token is always successfully accepted by the RS.
I'm not sure I understand the issue. Introspection is optional in 
general, and may be required in specific use cases. If the RS determines 
that the token is not valid on its own, why would it want to do 
introspection on top of this?

> rather than just doing an ack of the request and possibly waiting a long

This is probably transport protocol specific, and we were asked not to 
link the framework to a specific protocol, thus I don't know if we can 
provide guidance here.

> rate limit to issued tokens or making the sequence number be on an

I think the sentence here: "The AS increments this number for each 
access token it issues" needs to be ammended to "... for each access 
token it issues for this RS".

> losing the low-level authentication and thus a signature wrapping is now
Right, I'll extend the paragraph to add this information.

> mitigated to some extent by making sure that keys roll over more frequently.
Ok

> paragraph.  Think multicast.
Any suggestions on how to mitigate the issue then? If I issue a token 
bound to a symmetric key for audience {R1, R2, R3}, as soon as R1 got 
this token it can impersonate the client and gain access to R2 and R3.

> from the RS->C when a token is registered.
That is correct, however the token identifier should be just as opaque 
to attackers as the token itself.

> * Section 8.6.1 - Is pop still this document or is it Mike's document?

The token type pop is currently not part of 
draft-ietf-ace-cwt-proof-of-possession. I wouldn't argue against putting 
it there.

> * Section 8.9 - The description of reference is wrong.

Can you explain how? I'm not seeing the issue (assuming you mean the 
reference to RFC8126).

> * Section 8.12 - some of these should move to the OAuth parameters document?
These are new claims. We could move them to the params draft, which 
would then become the params and claims draft. I have not strong opinion 
either way.

> CBOR or is that a recommended?  I thought this was part of what Hannes was
Yes that should be RECOMMENED as well.

> * Appendix A - para Client Credentials Grant  s/can the/can then/
Ok

> contradiction within the set of documents that should be resolved.
I will get back to those last 3 comments (running out of time).

Regards,

Ludwig

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

---

From: Jim Schaad <[email-masked]>
Date: Tue, 23 Oct 2018 11:44:39 -0700

> -----Original Message-----
> From: Ludwig Seitz <[email-masked]>
> Sent: Tuesday, October 23, 2018 7:43 AM
> To: Jim Schaad <[email-masked]>; draft-ietf-ace-oauth-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
> 
> Hallo Jim,
> 

> > Is this supposed to be used rather than the one from the AS for
> > something like shared secret TLS?  Note that this is an unprotected value.
> >
> AFAIK cti is not a mandatory claim of an access token, thus a RS might want
> to create an identifier for tokens that do not have a cti.

Ok - so the client has this cti - what could it use it for?

> introspection on top of this?

The RS has just received a token.  The RS wants to validate said token.  It can do it on its own or it can do it with introspection.  If it is going to do it with introspection can it defer this validation until first use or does it need to do it immediately so it is not going to store an invalid token?  It is possible that an RS is going to both support some tokens and require introspection on others.  In that case it would decide the token was not valid, but would not necessarily know if it was a legal introspection token.

> this token it can impersonate the client and gain access to R2 and R3.

I am not sure that I think this is an issue that needs to be mitigated.  It needs to be acknowledged, but the assumption would be that if you have three resource servers that are hosting the same audience they are going to be run by the same RO and already be coupled.  After all it should not matter which of them you do a GET from, you should get the same answer.  Similarly a PUT to one should propagate to the others so that it is available to all clients.

> draft-ietf-ace-cwt-proof-of-possession. I wouldn't argue against putting

I would only because it would delay that document.  I just could not remember where if it was there and was too lazy to look.

> Can you explain how? I'm not seeing the issue (assuming you mean the

Reference  This contains a pointer to the public specification of the
      grant type abbreviation, if one exists.

This is not about grant types.

> would then become the params and claims draft. I have not strong opinion

I have no opinion either way - was just asking.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 Oct 2018 20:44:51 -0500

Just one minor note -- this is a great discussion to see happening!

> link the framework to a specific protocol, thus I don't know if we can 

I think it would be okay to say something like "some transport protocols
may provide a way to indicate that the server is busy and the client should
retry after an interval; this type of status update would be appropriate
while the server is waiting for an introspection response".  Which does
provide guidance, but in a non-normative fashion that does not require or
prohibit any given transport protocol.

-Ben

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 24 Oct 2018 11:02:27 +0200

On 23/10/2018 20:44, Jim Schaad wrote:

> 
> 
>>> * Section 6 - I am not sure that I agree with the SHOULD NOT in
>>> the last paragraph.  Think multicast.
>> Any suggestions on how to mitigate the issue then? If I issue a
>> token bound to a symmetric key for audience {R1, R2, R3}, as soon
>> as R1 got this token it can impersonate the client and gain access
>> to R2 and R3.
> 
> I am not sure that I think this is an issue that needs to be
> mitigated.  It needs to be acknowledged, but the assumption would be
> that if you have three resource servers that are hosting the same
> audience they are going to be run by the same RO and already be
> coupled.  After all it should not matter which of them you do a GET
> from, you should get the same answer.  Similarly a PUT to one should
> propagate to the others so that it is available to all clients.
> 

Say the client is a cleaning service and the audience is the locks of 
the different apartments it is allowed to open.

If the token uses symmetric keys, as soon as the cleaning service sends 
the token to one apartment, this apartment can open the other 
apartments. This is the situation I want to avoid.

/Ludwig

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

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 24 Oct 2018 11:02:59 +0200

> prohibit any given transport protocol.

Thank you for the suggestion. I will integrate that text.

/Ludwig

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

---

From: Jim Schaad <[email-masked]>
Date: Wed, 24 Oct 2018 11:20:01 -0700

> Sent: Wednesday, October 24, 2018 2:02 AM
> >>> * Section 6 - I am not sure that I agree with the SHOULD NOT in the
> >>> last paragraph.  Think multicast.
> Say the client is a cleaning service and the audience is the locks of the
> different apartments it is allowed to open.
> 
> If the token uses symmetric keys, as soon as the cleaning service sends the
> token to one apartment, this apartment can open the other apartments. This
> is the situation I want to avoid.

I would not expect that the locks would all be a single audience.  You might have all of the locks in a single apartment be one audience but you would want to separate the apartments into different security groups.  The cleaning service should be required to obtain a token specific to an apartment and not generally for all apartments.

If you have a situation where a single audience encompasses multiple security objects that are to be controlled differently then you run across the problem that Stefanie was raising where you cannot know which RS to make the token for because you are now needing to map audience, scope and actions all to a different RS which seems to be defeating the purpose of having an audience. 

Jim

---

From: Mike Jones <[email-masked]>
Date: Thu, 25 Oct 2018 00:58:10 +0000

IT CAN'T BE A COINCIDENCE:  There's clearly a relationship between many of the CBOR numeric values used in this this specification and corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the relationship is currently unspecified and the goals behind it are undefined.  The spec should be augmented to make the nature and goals of this relationship explicit.  I infer that there's such a relationship because the Mapping Parameters to CBOR in Section 5.6.5 apparently carefully do not overlap with the values registered in the IANA CWT Claims registry at https://www.iana.org/assignments/cwt/cwt.xhtml.  The Introspection mappings in Section 5.7.4 apparently carefully use the same values as CWT for the same things, but then adds additional values.  And some of these values are the same as values proposed for the CWT Claims registry in 8.13.  This has to be more than a coincidence but the spec doesn't currently say why.

Per my earlier reviews of the ace-authz spec, I believe that the ACE OAuth parameters should all be registered in the CWT Claims registry because of the possibility of them being used in signed requests in a manner analogous to https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17.  The parameters need to be registered to avoid future claim number conflicts.  While conflicts have clearly been carefully avoided to date, they will inevitably occur in the future unless the values are actually registered.  Please do so.

DON'T SQUAT ON NUMERIC REGISTRY VALUES:  Please change all instances of numbers to be assigned by designated experts in existing registries from specific values to "TBD".  For instance, all the values for the CWT Claims Registry in Section 8.13 (currently 12, 16, and 17) should be changed to TBD.  Our chair, Jim Schaad has been a vigorous advocate of not squatting in my past interactions with him as a Designated Expert and I believe would support this request.  Likewise, the "19" in the CoAP Content-Format Registration in Section 8.15 should become TBD.

req_aud: Several examples use the "req_aud" parameter without defining it.  Doesn't this duplicate the "resource" parameter defined by https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01?  If so, please delete this parameter and use "resource".  If not, say how it is different and why the differences are necessary.

rs_cnf:  There isn't a clear normative definition of this parameter.  It's mentioned obliquely but its purpose, syntax, and semantics should be plainly stated (as with each other newly defined parameter).

The proposed numbers in Figures 12 and 16 contain mismatches.  For instance, token_type is "14" in Figure 12 in Section 5.6.5 and "13" in Figure 16 in Section 5.7.4.  There's too much alignment for it to be a coincidence but if you intend alignment, please say so explicitly and fix the alignment.  The proposed ongoing alignment should also be described in the registration instructions for the Designated Experts.

				-- Mike

P.S.  Per my earlier reviews of this specification, in my view as a Designated Expert for the CWT Claims registry, I believe that it's not appropriate to use up rare single-byte identifiers for most of the OAuth parameter encodings specified in 5.6.5.  I could be persuaded that "scope" merits one of these rare numbers, but "profile", "error", "grant_type", "access_token", and "token_type" probably do not, as they are application-specific and not of general applicability.  I also believe that some of the other Designated Experts for this registry agree with me.

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Jim Schaad
Sent: Monday, October 8, 2018 2:35 PM
To: [email-masked]
Subject: [Ace] WGLC for draft-ietf-ace-authz

The chairs believe that the set of documents dealing with the OAuth framework for constrained environments is nearing the point that we should
be able to advance it to the IESG for publication.   We therefore want to
have a full list of issues that need to be dealt with at the Bangkok meeting.

draft-ietf-ace-authz
*  There are a couple of esoteric issues around listing AS servers associated with resources in a Resource Directory

Jim & Roman

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Oct 2018 07:33:38 +0200

+1 for making all the CWT-like structures into real CWTs.

Grüße, Carsten

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 25 Oct 2018 10:45:52 +0200

> +1 for making all the CWT-like structures into real CWTs.

Not every key/value-pair encoded as CBOR is automatically a CWT. What
happens here is that we are trying to force every protocol element that
is required to solve an application-specific problem to fit into
existing registered OAuth elements. As already pointed out by Mike, this
does not work well because ACE is different from vanilla OAuth.

The best solution I can imagine to conserve precious number space is to
use the media type (Content-Format in CoAP) as differientiator and use
CWT-numbers only for things that are CWTs

Grüße
Olaf

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Oct 2018 15:31:52 +0200

Well, I was a bit terse, was I.

I really meant to address the CWT-like structures, not everything that is ever encoded in CBOR.
If it doesn’t feel like a claim set, then of course there is no point in mimicking CWT.

Grüße, Carsten

> On Oct 25, 2018, at 10:45, Olaf Bergmann <[email-masked]> wrote:
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 25 Oct 2018 13:41:31 -0400

> does not work well because ACE is different from vanilla OAuth.

We tried at first to fit RFC8366 (vouchers) into JWTs (and thus CWTs for
constrained vouchers), but we found the OAuth claim statements too confusing
for what we were doing.  We could have made it work, but it just felt wrong.

    > CWT-numbers only for things that are CWTs

I would agree.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Oct 2018 20:30:38 +0200

On Oct 25, 2018, at 19:41, Michael Richardson <[email-masked]> wrote:
> 
> OAuth claim statements too confusing

Indeed, there is a problem there (as with many things inherited from OAuth).
We might want to fix those issues for the purposes ACE, even if it wasn’t in the domain for the ANIMA work.

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Thu, 25 Oct 2018 14:15:21 -0700

Looking back to the message I sent on 10/3 I don't believe that the OAuth requests are the same thing as CWTs and I proposed a solution there about how to fix thing in the future so that they don't become them.

> From: Carsten Bormann <[email-masked]>
> Sent: Wednesday, October 24, 2018 10:34 PM
> To: Mike Jones <Michael.Jones=[email-masked]>
> Cc: Jim Schaad <[email-masked]>; [email-masked]

---

From: Jim Schaad <[email-masked]>
Date: Thu, 25 Oct 2018 14:43:22 -0700

> From: Mike Jones <[email-masked]>
> Sent: Wednesday, October 24, 2018 5:58 PM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Subject: RE: [Ace] WGLC for draft-ietf-ace-authz
> 
> IT CAN'T BE A COINCIDENCE:  There's clearly a relationship between many of
> the CBOR numeric values used in this this specification and corresponding
> CBOR Web Token (CWT) claim identifiers, but oddly, the relationship is
> currently unspecified and the goals behind it are undefined.  The spec
should
> be augmented to make the nature and goals of this relationship explicit.
I
> infer that there's such a relationship because the Mapping Parameters to
> CBOR in Section 5.6.5 apparently carefully do not overlap with the values
> registered in the IANA CWT Claims registry at
> https://www.iana.org/assignments/cwt/cwt.xhtml.  The Introspection
> mappings in Section 5.7.4 apparently carefully use the same values as CWT
> for the same things, but then adds additional values.  And some of these
> values are the same as values proposed for the CWT Claims registry in
8.13.
> This has to be more than a coincidence but the spec doesn't currently say
> why.

You are right it is not a coincidence.  You have been asking that they match
up for quite a while and at one time the authors tried to do this.  This
does not mean that it should be that way.

> 
> Per my earlier reviews of the ace-authz spec, I believe that the ACE OAuth
> parameters should all be registered in the CWT Claims registry because of
> the possibility of them being used in signed requests in a manner
analogous
> to https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17.  The parameters
> need to be registered to avoid future claim number conflicts.  While
conflicts
> have clearly been carefully avoided to date, they will inevitably occur in
the
> future unless the values are actually registered.  Please do so.

This is something that I think is incorrect - see my mail on 10/3.

> 
> DON'T SQUAT ON NUMERIC REGISTRY VALUES:  Please change all instances
> of numbers to be assigned by designated experts in existing registries
from
> specific values to "TBD".  For instance, all the values for the CWT Claims
> Registry in Section 8.13 (currently 12, 16, and 17) should be changed to
TBD.
> Our chair, Jim Schaad has been a vigorous advocate of not squatting in my
> past interactions with him as a Designated Expert and I believe would
> support this request.  Likewise, the "19" in the CoAP Content-Format
> Registration in Section 8.15 should become TBD.

If they are creating a new registry - which means not going in the CWT claim
registry then it makes sense for them to assign numbers.  I agree on the
content format registration unless they have gotten an early registry done.

> 
> req_aud: Several examples use the "req_aud" parameter without defining it.
> Doesn't this duplicate the "resource" parameter defined by
> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01?  If
so,
> please delete this parameter and use "resource".  If not, say how it is
> different and why the differences are necessary.
> 
> rs_cnf:  There isn't a clear normative definition of this parameter.  It's
> mentioned obliquely but its purpose, syntax, and semantics should be
plainly
> stated (as with each other newly defined parameter).
> 
> The proposed numbers in Figures 12 and 16 contain mismatches.  For
> instance, token_type is "14" in Figure 12 in Section 5.6.5 and "13" in
Figure 16
> in Section 5.7.4.  There's too much alignment for it to be a coincidence
but if
> you intend alignment, please say so explicitly and fix the alignment.  The
> proposed ongoing alignment should also be described in the registration
> instructions for the Designated Experts.
> 
> 				-- Mike
> 
> P.S.  Per my earlier reviews of this specification, in my view as a
Designated
> Expert for the CWT Claims registry, I believe that it's not appropriate to
use
> up rare single-byte identifiers for most of the OAuth parameter encodings
> specified in 5.6.5.  I could be persuaded that "scope" merits one of these
rare
> numbers, but "profile", "error", "grant_type", "access_token", and
> "token_type" probably do not, as they are application-specific and not of
> general applicability.  I also believe that some of the other Designated
> Experts for this registry agree with me.

Yet another reason why we should not be combining these registries into a
single one in my opinion.

Jim

meeting.
> *  There are a couple of esoteric issues around listing AS servers
associated
> with resources in a Resource Directory
> 
> 
> Jim & Roman
> 
> 
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Oct 2018 14:09:48 -0400

> wasn’t in the domain for the ANIMA work.

I should clarify, I think.

It wasn't that OAUTH was confusing, but rather that mapping the standardized
claim tags to what we needed did not seem to leverage very much.

--
]               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: Ludwig Seitz <[email-masked]>
Date: Tue, 30 Oct 2018 11:19:44 +0100

> everything constant and can make re-use of integer values easier to see.

Yes in the light of the ensuing discussion with Mike, Carsten and Olaf 
it is clear that the whole registry process needs a second (third, n-th) 
go-over.

I'd very much like to have all abbreviations in a single table, however 
some of them are in the new draft-ietf-ace-oauth-params, so I'm not sure 
on where to do the table, since I'd like to have the parameters from 
there in it.

> signature operation would be required for the purposes of authentication.

In the light of your and Steffi's comments, this seems to merit a 
section in the security considerations.

> contradiction within the set of documents that should be resolved.

I'd like to have the view of our OAuth experts here: How is OAuth 
typically used, when a client needs to get more permissions than 
initially granted?
Is the old token invalidated and a new token issued, or is there 
something like "add-on" scopes in additional tokens?

Given the amount of trouble the handling of multiple tokens for one 
client-RS pair can raise, I'm not disinclined to forbid them or at least 
recommend against their use. However with audiences possibly addressing 
overlapping sets of RSs this might be more difficult than it looks.

/Ludwig

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

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 30 Oct 2018 13:13:28 +0100

On 25/10/2018 02:58, Mike Jones wrote:
> IT CAN'T BE A COINCIDENCE:  There's clearly a relationship between
> many of the CBOR numeric values used in this this specification and
> corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the
> relationship is currently unspecified and the goals behind it are
> undefined.  The spec should be augmented to make the nature and goals
> of this relationship explicit.  I infer that there's such a
> relationship because the Mapping Parameters to CBOR in Section 5.6.5
> apparently carefully do not overlap with the values registered in the
> IANA CWT Claims registry at
> mappings in Section 5.7.4 apparently carefully use the same values as
> CWT for the same things, but then adds additional values.  And some
> of these values are the same as values proposed for the CWT Claims
> registry in 8.13.  This has to be more than a coincidence but the
> spec doesn't currently say why.

For example in "5.6.5 Mapping Parameters to CBOR" there is this:

"Note that we have aligned these abbreviations with the claim
    abbreviations defined in [RFC8392]."

I can add some text to explain that this makes it easier to manage the 
abbreviations in code (no need to handle complex namespace issues, when 
you just use one abbreviation space). Would that address the "to make 
the nature and goals of this relationship explicit." part of your comment?

> 
> Per my earlier reviews of the ace-authz spec, I believe that the ACE
> OAuth parameters should all be registered in the CWT Claims registry
> because of the possibility of them being used in signed requests in a
> manner analogous to
> https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17.  The
> parameters need to be registered to avoid future claim number
> conflicts.  While conflicts have clearly been carefully avoided to
> date, they will inevitably occur in the future unless the values are
> actually registered.  Please do so.
> 

I have avoided doing this so far, since there was no precedent from 
OAuth on doing so (registering OAuth req/resp parameters as JWT claims) 
and I was trying to align with OAuth in that respect.
For example draft-ietf-oauth-jwsreq-17 doesn't seem to register any of 
the classical OAuth req/resp parameters as JWT claims ("This 
specification requests no actions by IANA.")

How is the position of the OAuth WG on this?

> of numbers to be assigned by designated experts in existing
> registries from specific values to "TBD".  For instance, all the
> values for the CWT Claims Registry in Section 8.13 (currently 12, 16,
> and 17) should be changed to TBD.  Our chair, Jim Schaad has been a
> vigorous advocate of not squatting in my past interactions with him
> as a Designated Expert and I believe would support this request.
> Likewise, the "19" in the CoAP Content-Format Registration in Section
> 8.15 should become TBD.
> 
I get your point.

Any hints on how one usually do that while still providing provisory 
numbers for interop tests?

> req_aud: Several examples use the "req_aud" parameter without
> defining it.  Doesn't this duplicate the "resource" parameter defined
> by
> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01?
> If so, please delete this parameter and use "resource".  If not, say
> how it is different and why the differences are necessary.
> 
> rs_cnf:  There isn't a clear normative definition of this parameter.
> It's mentioned obliquely but its purpose, syntax, and semantics
> should be plainly stated (as with each other newly defined
> parameter).
> 

This is probably heritage from the document split.
Note however that the framework (draft-ietf-ace-oauth-authz) defines 
some of these a CWT claims, while the params draft 
(draft-ietf-ace-oauth-params) only defines request/response parameters 
(which happen to have the same name, abbreviation and semantics).

I'll go over those sections and see if there are artifacts left that 
need to be adjusted.

> instance, token_type is "14" in Figure 12 in Section 5.6.5 and "13"
> in Figure 16 in Section 5.7.4. 
> 
Sorry for that. Errors when trying to make the alignment.

 > There's too much alignment for it to
 > be a coincidence but if you intend alignment, please say so
 > explicitly and fix the alignment.  The proposed ongoing alignment
 > should also be described in the registration instructions for the
 > Designated Experts.

"5.7.4.  Mapping Introspection parameters to CBOR
[...]
    Note that we have aligned these abbreviations with the claim
    abbreviations defined in [RFC8392].
"

(so yes, we do already say so explicitly)

I will add the requested instructions for Designated Experts (good catch!)

> Designated Expert for the CWT Claims registry, I believe that it's
> not appropriate to use up rare single-byte identifiers for most of
> the OAuth parameter encodings specified in 5.6.5.  I could be
> persuaded that "scope" merits one of these rare numbers, but
> "profile", "error", "grant_type", "access_token", and "token_type"
> probably do not, as they are application-specific and not of general
> applicability.  I also believe that some of the other Designated

I would argue that the rare single-byte identifiers should be used for 
the parameters typically used in constrained applications.

Since "error", "grant_type", "access_token", and "token_type" are all 
mandatory to use, they are bound to appear in constrained cases.

If we made "grant_type" and "token_type" non-mandatory in ACE (as 
opposed to how it is in OAuth) and define defaults I'd agree to move 
those into the two-byte space.

"profile" is arguably going to be used in less constrained scenarios 
where more than one profile could be supported, so I'd agree to move 
that to the two-byte space as well.

"error" and "access_token" are used in every OAuth/ACE interaction, so I 
would need some really good arguments why they shouldn't have a one-byte 
abbreviation.

Can we reach some compromise based on these observations Mike?

/Ludwig

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

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 30 Oct 2018 13:20:35 +0100

On 23/10/2018 20:44, Jim Schaad wrote:
> 
> 
>> -----Original Message----- From: Ludwig Seitz <[email-masked]> 
>> Sent: Tuesday, October 23, 2018 7:43 AM To: Jim Schaad
>> <[email-masked]>; draft-ietf-ace-oauth- [email-masked] Cc:
>> [email-masked] Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
>> 
>> Hallo Jim,
>> 
>>> * Section 5.8.1 - What is the purpose of creating an identifier
>>> for a token? Is this supposed to be used rather than the one from
>>> the AS for something like shared secret TLS?  Note that this is
>>> an unprotected value.
>>> 
>> AFAIK cti is not a mandatory claim of an access token, thus a RS
>> might want to create an identifier for tokens that do not have a
>> cti.
> 

You might want to treat the token as a RESTful resource under 
/authz-info that the client can GET or DELETE using the cti as part of 
the URI.

I admit this is never explicitly stated and would need to be worked out
quite a bit (as Steffi remarked, there would need to be access control
on the tokens), so I wouldn't argue against removing the comment from
the draft altogether.

>>> * Section 5.8.1 - If the token is "not valid" is the RS required
>>> (i.e. MUST) to try introspection before returning a response if
>>> the RS does introspection?  The text currently says MAY.  If this
>>> is really MAY then the text should say that the token is always
>>> successfully accepted by the RS.
>>> 
>> general, and may be required in specific use cases. If the RS
>> determines that the token is not valid on its own, why would it
>> want to do introspection on top of this?
> 
> The RS has just received a token.  The RS wants to validate said
> token.  It can do it on its own or it can do it with introspection.
> If it is going to do it with introspection can it defer this
> validation until first use or does it need to do it immediately so it
> is not going to store an invalid token?  It is possible that an RS is
> going to both support some tokens and require introspection on
> others.  In that case it would decide the token was not valid, but
> would not necessarily know if it was a legal introspection token.
> 

I'm not convinced we need to REQUIRE a certain behavior here. I would 
however agree to put some text in the draft outlining these options and 
analyzing the resulting security implications.

Would that address your comment sufficiently?

/Ludwig

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

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 30 Oct 2018 13:27:35 +0100

> +1 for making all the CWT-like structures into real CWTs.

A discussion of what we consider to be CWT-like structures and what not 
would be helpful as a follow-up here.

If draft-ietf-oauth-jwsreq is any indication the OAuth WG seems to 
consider that all requests to the AS can be passed as JWTs.

I'm unsure what their position on the AS responses is.

FYI my current reasoning and use of terms:

If a key/value pair is part of a CWT I call it a "claim".

If it is part of a request/response to the AS or RS I call it a "parameter".

I've been registering (or at least trying to) claims separately from 
parameters, leading to several double-registrations, when certain 
key/value definitions are used both as claims and parameters (such as 
scope, cnf etc).

/Ludwig

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

---

From: Mike Jones <[email-masked]>
Date: Tue, 30 Oct 2018 18:52:21 +0000

Thanks for your responses, Ludwig.

Responding to your point about "Note that we have aligned these abbreviations with the claim abbreviations defined in [RFC8392]."  The point of the alignment was to enable signed requests to be expressed as CWTs - just as OAuth signed requests are expressed as JWTs.  But given the high likelihood of numeric CWT claim collisions with unregistered OAuth request number values assigned by the spec, this won't actually work in the long term unless the request parameters are registered as CWT claims.  Collision-free alignment without IANA registration is a fleeting situation.  Please make the alignment permanent by registering the needed claims.

I get Jim's point that there are other ways to do signed requests.  If this working group wants to define a different signed request syntax for ACE OAuth requests than CWTs, that's fine, but if so, please do so before this draft finishes.  If a different signed request format is used, I'll note that there's no need for claim alignment with CWT [RFC8392] - in which case the draft should probably abandon it up front.  I'll note that abandoning the current alignment is more work and would be more confusing to implementers than simply using CWTs but multiple choices are possible.  The most important thing is to pick one now.  Industries such as banking are REQUIRING signed requests.

Since you asked about signed responses, those are also in the works for OAuth, for the same reasons - including requirements from the banking industry.  See https://openid.net/specs/openid-financial-api-jarm.html.  (Just as the OpenID Foundation standardized signed requests in 2014 in https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests in 2014 and then an IETF version was created, signed responses are currently on a similar trajectory.)

Per your question about values in IANA registries to be assigned by designated experts being TBD, the normal way of providing short-term values for interop purposes is to say "TBD (maybe <some number>).  For instance, you'll see that usage at https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-03#section-7.1.1.

I could live with "access_token" having a single-byte representation, since as you point out, it is needed for every ACE OAuth interaction.  An "error" value is only needed when something goes wrong, so that doesn't seem like a case that needs to be optimized for space.  A two-byte "error" representation will only be used when errors have occurred, so shouldn't be a problem.

				-- Mike

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Ludwig Seitz
Sent: Tuesday, October 30, 2018 5:13 AM
To: [email-masked]
Subject: Re: [Ace] WGLC for draft-ietf-ace-authz

On 25/10/2018 02:58, Mike Jones wrote:
> CWT for the same things, but then adds additional values.  And some of 
> these values are the same as values proposed for the CWT Claims 
> registry in 8.13.  This has to be more than a coincidence but the spec 
> doesn't currently say why.

I can add some text to explain that this makes it easier to manage the abbreviations in code (no need to handle complex namespace issues, when you just use one abbreviation space). Would that address the "to make the nature and goals of this relationship explicit." part of your comment?

I get your point.

/Ludwig

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

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 31 Oct 2018 10:08:28 +0100

> Thanks for your responses, Ludwig.
...
>
>  I could live with "access_token" having a single-byte
> representation, since as you point out, it is needed for every ACE
> OAuth interaction.  An "error" value is only needed when something
> goes wrong, so that doesn't seem like a case that needs to be
> optimized for space.  A two-byte "error" representation will only be
> used when errors have occurred, so shouldn't be a problem.
> 
> -- Mike
> 
> -----Original Message----- From: Ace <[email-masked]> On Behalf

Thank you for the quick and comprehensive answer Mike!

I conclude the following:

We are in agreement about giving "profile", "error", "token_type" and 
"grant_type" two-byte abbreviations in CBOR.

"scope" and "access_token" will get a one-byte abbreviation aligned with 
the unused numbers from CWT claims.

At IETF 103 I will propose the solution of registering all parameter 
abbreviations in the CWT claim registry in order to align abbreviations 
and avoid duplicate assignments.

If a signed request (and response) format is needed I am all for using 
CWT in the context of ACE access token requests, responses and 
introspection requests and responses. I will take up that discussion at 
IETF 103.

I will propose to make "token_type" and "grant_type" OPTIONAL, deviating 
from the OAuth 2.0 specs and defining the default token type to be "PoP" 
and the default grant_type to be "client_credentials".
This will avoid having to send grant_type with every access token 
request and token_type with every successful access token response.

Regards,

Ludwig

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

---

From: Jim Schaad <[email-masked]>
Date: Wed, 31 Oct 2018 04:05:57 -0700

Mike,

Writing a document to do this is easy.  I am not clear that there is anybody
that is going to implement this.   Are industries such as banking going to
abandon JWT for CWT?

Jim

> From: Ace <[email-masked]> On Behalf Of Mike Jones
> Sent: Tuesday, October 30, 2018 11:52 AM
> To: Ludwig Seitz <[email-masked]>; [email-masked]
> Responding to your point about "Note that we have aligned these
> abbreviations with the claim abbreviations defined in [RFC8392]."  The
point
> of the alignment was to enable signed requests to be expressed as CWTs -
> just as OAuth signed requests are expressed as JWTs.  But given the high
> likelihood of numeric CWT claim collisions with unregistered OAuth request
> number values assigned by the spec, this won't actually work in the long
term
> unless the request parameters are registered as CWT claims.
Collision-free
> alignment without IANA registration is a fleeting situation.  Please make
the
> alignment permanent by registering the needed claims.
> 
> I get Jim's point that there are other ways to do signed requests.  If
this
> working group wants to define a different signed request syntax for ACE
> OAuth requests than CWTs, that's fine, but if so, please do so before this
> draft finishes.  If a different signed request format is used, I'll note
that
> there's no need for claim alignment with CWT [RFC8392] - in which case the
> draft should probably abandon it up front.  I'll note that abandoning the
> current alignment is more work and would be more confusing to
> implementers than simply using CWTs but multiple choices are possible.
The
> most important thing is to pick one now.  Industries such as banking are
> REQUIRING signed requests.
> 
> Since you asked about signed responses, those are also in the works for
> OAuth, for the same reasons - including requirements from the banking
> industry.  See https://openid.net/specs/openid-financial-api-jarm.html.
(Just
> as the OpenID Foundation standardized signed requests in 2014 in
> https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests in
> 2014 and then an IETF version was created, signed responses are currently
> on a similar trajectory.)
> 
> Per your question about values in IANA registries to be assigned by
> designated experts being TBD, the normal way of providing short-term
> values for interop purposes is to say "TBD (maybe <some number>).  For
> instance, you'll see that usage at
https://tools.ietf.org/html/draft-ietf-ace-
> cwt-proof-of-possession-03#section-7.1.1.
> 
> I could live with "access_token" having a single-byte representation,
since as
> you point out, it is needed for every ACE OAuth interaction.  An "error"
value
> is only needed when something goes wrong, so that doesn't seem like a case
> that needs to be optimized for space.  A two-byte "error" representation
will
> only be used when errors have occurred, so shouldn't be a problem.
> 
> 				-- Mike
> 
> you just use one abbreviation space). Would that address the "to make the
> nature and goals of this relationship explicit." part of your comment?
> 
> >
> I have avoided doing this so far, since there was no precedent from OAuth
on
> doing so (registering OAuth req/resp parameters as JWT claims) and I was
> trying to align with OAuth in that respect.
> For example draft-ietf-oauth-jwsreq-17 doesn't seem to register any of the
> classical OAuth req/resp parameters as JWT claims ("This specification
> requests no actions by IANA.")
> 
> > from specific values to "TBD".  For instance, all the values for the
> > CWT Claims Registry in Section 8.13 (currently 12, 16, and 17) should
> > be changed to TBD.  Our chair, Jim Schaad has been a vigorous advocate
> > of not squatting in my past interactions with him as a Designated
> > Expert and I believe would support this request.
numbers
> for interop tests?
> 
> > req_aud: Several examples use the "req_aud" parameter without defining
> > it.  Doesn't this duplicate the "resource" parameter defined by
> > It's mentioned obliquely but its purpose, syntax, and semantics should
> > be plainly stated (as with each other newly defined parameter).
> >
>

---

From: Jim Schaad <[email-masked]>
Date: Wed, 31 Oct 2018 04:05:57 -0700

> nature and goals of this relationship explicit." part of your comment?

I think that this should be lost as a requirement in the document.  I don't
think it makes it any easier to deal with things by having the abbreviations
from two different things line up to be the same.  They need to be dealt
with on their own in code anyway.

> numbers for interop tests?

Generally this is done by assigning temp numbers from a private number space
that are then changed at the time of registration.  Additionally one can ask
for early registrations to occur.  This is done at the discretion of the
chairs.

---

From: Jim Schaad <[email-masked]>
Date: Wed, 31 Oct 2018 04:05:57 -0700

> Sent: Tuesday, October 30, 2018 3:20 AM
> > * Registries -  I am wondering if we should think about re-writing a
> > couple of the registries.  As things stand it appears that the
> > application/ace+cbor content type is being used in 5 or 6 places.  It
> > might make more sense to have a registry for all of the CBOR
> > abbreviations that are being used in a single table and have multiple
> > columns for each of the different places were the content format is
> > being used.  This would make it easier to keep everything constant and can
> make re-use of integer values easier to see.
> >
> 
> Yes in the light of the ensuing discussion with Mike, Carsten and Olaf it is
> clear that the whole registry process needs a second (third, n-th) go-over.
> 
> I'd very much like to have all abbreviations in a single table, however some of
> them are in the new draft-ietf-ace-oauth-params, so I'm not sure on where
> to do the table, since I'd like to have the parameters from there in it.

While it has some "goodness" to have all of the abbreviations in a single table, in the end that single table is going to be a registry that is maintained by IANA.  This allows multiple documents to create the abbreviations and not have any overlap.  I would just leave the items in oauth-params there and let them be registered on their own.

Jim

\>

---

From: Mike Jones <[email-masked]>
Date: Wed, 31 Oct 2018 16:07:51 +0000

This sounds like a good solution, Ludwig.  Thanks for the productive conversation.

				-- Mike

-----Original Message-----
From: Ludwig Seitz <[email-masked]> 
Sent: Wednesday, October 31, 2018 2:08 AM
To: Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [Ace] WGLC for draft-ietf-ace-authz

...
> since as you point out, it is needed for every ACE OAuth interaction.  
> An "error" value is only needed when something goes wrong, so that 
> doesn't seem like a case that needs to be optimized for space.  A 
> two-byte "error" representation will only be used when errors have 
> occurred, so shouldn't be a problem.
> 
> -- Mike
> 

We are in agreement about giving "profile", "error", "token_type" and "grant_type" two-byte abbreviations in CBOR.

"scope" and "access_token" will get a one-byte abbreviation aligned with the unused numbers from CWT claims.

At IETF 103 I will propose the solution of registering all parameter abbreviations in the CWT claim registry in order to align abbreviations and avoid duplicate assignments.

If a signed request (and response) format is needed I am all for using CWT in the context of ACE access token requests, responses and introspection requests and responses. I will take up that discussion at IETF 103.

I will propose to make "token_type" and "grant_type" OPTIONAL, deviating from the OAuth 2.0 specs and defining the default token type to be "PoP" 
and the default grant_type to be "client_credentials".
This will avoid having to send grant_type with every access token request and token_type with every successful access token response.

Regards,

Ludwig

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