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

[Carsten Bormann]

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

Grüße, Carsten

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

Re: [Ace] WGLC for draft-ietf-ace-oauth-params

[Mike Jones]

3.1, 3.2, and 4.1, parameter definitions: None of these parameter definitions 
specify the syntax of the parameters defined, making understanding these quite 
confusing.  Yes, this is talked about later in the doc but there are not even 
forward references to where the definitions are completed in most cases.  
Please fully specify the parameters when they are defined.



3.1 req_aud: 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.  If not, say how it is different and why the 
differences are necessary.



5 cnf in the introspection response: Which token is being referred to by the 
phrase "bound to the token".  The access token?  The refresh token?  Another 
kind of token?  Please make this more specific.



6 CBOR Mappings.  The table contains the magic numbers 8, 17, 18, and 19.  
>From what space are these numbers being allocated and what registry are they 
in?  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 claim number conflicts.



Missing Examples:  The best thing you could do to help developers understand 
what these values are and how they use them is to add examples, just as was 
done in RFC 7800.  Please add examples of each of the parameters using the JSON 
representations of them.  Optionally, also add CBOR examples if you believe 
that they will convey important information to developers that the JSON 
example's don't.



  Thank you,

  -- Mike



-Original Message-
From: Ace  On Behalf Of Jim Schaad
Sent: Monday, October 8, 2018 2:35 PM
To: ace@ietf.org
Subject: [Ace] WGLC for draft-ietf-ace-oauth-params



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



We know that the following issues are outstanding:



draft-ietf-ace-oauth-params:

*  No current known issues





Jim & Roman







___

Ace mailing list

Ace@ietf.org

https://www.ietf.org/mailman/listinfo/ace
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

On 24/10/2018 03:44, Benjamin Kaduk wrote:

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

On Tue, Oct 23, 2018 at 04:43:14PM +0200, Ludwig Seitz wrote:


On 22/10/2018 21:09, Jim Schaad wrote:

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


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.


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



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

/Ludwig

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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

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


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.





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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

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

[Ludwig Seitz]

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

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.




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.


Neither the abstract nor the intro says this.



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:


https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01



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:


    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.




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

___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace