Subject: [Ace] Review of draft-ietf-ace-oauth-params-00

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 23 Oct 2018 19:09:48 +0000

Hi all,

I read through draft-ietf-ace-oauth-params-00 and have a few comments.

1) I believe the document should explain in more detail about how it fits into the rest of the OAuth PoP token work.
The story essentially is that we have the HTTP-based transport in the OAuth WG and we have the CoAP-based transport
in ACE. draft-ietf-ace-oauth-params-00 is about registering the necessary parameters for use with CoAP only.

Neither the abstract nor the intro says this.

2) 'req_aud' parameter

At the last IETF OAuth meeting in Montreal we agreed to adopt a new document, called resource indicators, and it can be found here:
https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01

I believe the parameter name and semantics defined in draft-ietf-oauth-resource-indicators-01 should match what is defined in draft-ietf-ace-oauth-params-00.

The name of the parameter in draft-ietf-oauth-resource-indicators-01 is 'resource' and it is defined as

   resource
      Indicates the location of the target service or resource where
      access is being requested.  Its value MUST be an absolute URI, as
      specified by Section 4.3 of [RFC3986], which MAY include a query
      component but MUST NOT include a fragment component.  Multiple
      "resource" parameters MAY be used to indicate that the requested
      token is intended to be used at multiple resources.

In a nutshell I believe you should do the following:
 a) rename the parameter to 'resource' to get it inline with draft-ietf-oauth-resource-indicators-01
b) use the same semantics as in draft-ietf-oauth-resource-indicators-01
c) find out what the encoding considerations are when using CoAP

3) 'req_cnf' parameter

Changing the name of the parameter name from the previous 'cnf' is good and that was also requested at the last IETF due to the potential confusion with the 'cnf' claim name. However, I believe the semantics is different to the semantics defined in draft-ietf-oauth-pop-key-distribution. Unless I misunderstand but the relevant text regarding the req_cnf parameter content is this:

   o  "req_cnf" in the token request C -> AS, OPTIONAL to indicate the
      client's raw public key, or the key-identifier of a previously
      established key between C and RS that the client wishes to use for
      proof-of-possession of the access token.

For example, in draft-ietf-oauth-pop-key-distribution there is no key identifier passed from the client to the server when making the request for a PoP token. Instead, the server just mints one (along with the symmetric key) and sends it to the client.

Ciao
Hannes

PS: Why was a standalone document written instead of leaving the parameters in the ACE-OAuth framework spec? I guess there are reasons (which I may have missed).

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.

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 24 Oct 2018 09:39:38 +0200

On 23/10/2018 21:09, Hannes Tschofenig wrote:
> 1) I believe the document should explain in more detail about how it 
> fits into the rest of the OAuth PoP token work.
> 

Ok I can update the introduction.

> The story essentially is that we have the HTTP-based transport in the 
> OAuth WG and we have the CoAP-based transport
> 
> in ACE. draft-ietf-ace-oauth-params-00 is about registering the 
> necessary parameters for use with CoAP only.
> 

Actually at the moment it is about registering necessary parameters for 
both HTTP and CoAP and whatever other transport you can want, since when 
I wrote it draft-ietf-oauth-pop-key-distribution was dormant.

> 2) 'req_aud' parameter
> 
> At the last IETF OAuth meeting in Montreal we agreed to adopt a new 
> document, called resource indicators, and it can be found here:
> 

I'll have a look at that draft. How close is it to WGLC?

> 
> 3) 'req_cnf' parameter
> 
> Changing the name of the parameter name from the previous 'cnf' is good 
> and that was also requested at the last IETF due to the potential 
> confusion with the 'cnf' claim name. However, I believe the semantics is 
> different to the semantics defined in 
> draft-ietf-oauth-pop-key-distribution. Unless I misunderstand but the 
> relevant text regarding the req_cnf parameter content is this:
> 
> For example, in draft-ietf-oauth-pop-key-distribution there is no key 
> identifier passed from the client to the server when making the request 
> for a PoP token. Instead, the server just mints one (along with the 
> symmetric key) and sends it to the client.
> 

Weird, because in the RFC7800 there is a cnf claim with just a key-id. I 
thought that you would want to be able to do something similar when 
requesting a specific, previously known key.

> PS: Why was a standalone document written instead of leaving the 
> parameters in the ACE-OAuth framework spec? I guess there are reasons 
> (which I may have missed).

The idea was that OAuth could obsolete that document when they sort the 
pop stuff out, without obsoleting the ACE framework. Thus a different 
standalone document.

/Ludwig

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

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 24 Oct 2018 10:00:29 +0200

On 23/10/2018 21:09, Hannes Tschofenig wrote:

> I believe the parameter name and semantics defined in 
> draft-ietf-oauth-resource-indicators-01 should match what is defined in 
> draft-ietf-ace-oauth-params-00.
> 

Looking closer at this draft:

The resource parameter seems to be much more limited than the audience 
claim, since a URI is required. As Steffi recently remarked in her 
review of draft-ietf-oauth-authz, URIs are not a good way to identify 
resources in constrained environments, since the address of a device can 
change.

Furthermore there seems also to be an overlap with the 'scope' 
parameter, since the 'resource' parameter can be used to indicate 
specific resources and not only the target RS.

What if we want to identify the audience by its public key instead of an 
URI?

What if a client wants to request a token for a group of RS identified 
by a specific audience value (e.g. "thermostats-building-1")?

/Ludwig

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

---

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

> -----Original Message-----
> From: Ace <[email-masked]> On Behalf Of Ludwig Seitz
> Sent: Wednesday, October 24, 2018 1:00 AM
> To: [email-masked]
> Subject: Re: [Ace] Review of draft-ietf-ace-oauth-params-00
> 
> > draft-ietf-oauth-resource-indicators-01 should match what is defined
> > in draft-ietf-ace-oauth-params-00.
> >
> claim, since a URI is required. As Steffi recently remarked in her review
of
> draft-ietf-oauth-authz, URIs are not a good way to identify resources in
> constrained environments, since the address of a device can change.

I rather have to agree that these do not seem to be doing the same thing.
The 'resource' parameter looks like it could actually be used in parallel
with the 'aud' parameter if you want to refer to a specific RS which is
hosting the audience in question.  But that would be some form of narrowing
of scope.

> parameter, since the 'resource' parameter can be used to indicate specific
> resources and not only the target RS.
> 
URI?

Ludwig, this is not actually a problem since there is a URI for doing that.

> 
> What if a client wants to request a token for a group of RS identified by
a
> specific audience value (e.g. "thermostats-building-1")?

One of the things that I kept hearing is that an audience may be hosted by
multiple resource servers as long as I have been going to ACE meetings.
This does not seem to be a problem with the OAuth in HTTP right now as a CDN
would hide that level of detail.  

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