Subject: [Ace] Review of draft-ietf-ace-oauth-authz -12

From: Jim Schaad <[email-masked]>
Date: Tue, 19 Jun 2018 11:05:17 -0700

Based on where I currently am, here is another review of the document.

1.  In section 4 for Figure one:  Is the term "RS Information" your term or
an OAuth term.  When I see this I think of it as information for not about
the RS which I do not believe is the intent.

2.  In section 5.1 - I am unclear what the second paragraph is supposed to
be doing here.  I think that you want state this different.  Rather than
talking about the "desired resource" you may want to talk about the AS.
That would better match the title of the section.

3.  In section 5.1 - There is a note in this section that does not seem to
be extremely useful.  Where is this discussion go on?  Is it still going on?
I am not even sure if the statement about a common understanding of time is
correct?  It seems that one can either add or not add the nonce as an RS
depending on if you think you understand a common time.

4.  In section 5.3 - There is a reference to I-D.erdtman-ace-rpcc.  Given
the use of POP tokens, what is the reason for this draft and the text about
client credential types?  (Put it this way.  I did not need to implement
this for anything yet.  Why is it here?)

Given 15 different introspection tokens, how do I decide which is the one to
present to the AS - enumerate them?

'authorization code' vs 'decode code' grants

---

From: Samuel Erdtman <[email-masked]>
Date: Thu, 21 Jun 2018 17:15:21 +0200

Thanks for reviewing, some answers inline

> the RS which I do not believe is the intent.

No, the intent is information about the RS for the client. It is described
in "2. Terminology".
Not sure if "client information" would be preferable.

> That would better match the title of the section.

The focus could maybe be different but the text is about how to find the AS
but the method for that is quite RS focused.

> depending on if you think you understand a common time.

I have not heard anything on the time discussion for a while.

> this for anything yet.  Why is it here?)

Not sure what profile you have implemented.
I-D.erdtman-ace-rpcc defines how the client can use Raw Public Key or Pre
Shared Key with (D)TLS to authenticate it self to the AS. It is not a
strange operation so you might have implemented it without thinking about
it (Ludwig kind of did). I-D.erdtman-ace-rpcc is similar to
draft-ietf-oauth-mtls that defines what was already done in the wild when
it comes to x509 certificates and client authentication.
Or you might have used default client credentials (client_id/username and
client_secret/password).

I think writing about client credentials is needed since the ACE use cases
so far has been client centric, i.e. the client is often described to
authenticate as it self to get a token and not as is common i OAuth the
user is authenticated and authorizes the client to get a token.
With that said the reference to I-D.erdtman-ace-rpcc should maybe be
removed since interest in I-D.erdtman-ace-rpcc has been very limited.

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

---

From: Jim Schaad <[email-masked]>
Date: Thu, 21 Jun 2018 08:58:29 -0700

I sent this review early by accident (I thought I was sending a different mail).

However a couple things below.

From: Samuel Erdtman <[email-masked]> 
Sent: Thursday, June 21, 2018 8:15 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; ace <[email-masked]>
Subject: Re: [Ace] Review of draft-ietf-ace-oauth-authz -12

On Tue, Jun 19, 2018 at 8:05 PM, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

No, the intent is information about the RS for the client. It is described in "2. Terminology".

[JLS] Yeah I agree that ‘client information’ is not really any better.  I wonder if ‘Access Information’ might be a better term?

The focus could maybe be different but the text is about how to find the AS but the method for that is quite RS focused.

[JLS] This is not clear to me from what is stated.  Does this mean that there is going to be AS pointers that are contained on the RD entry for the resource that one is interested in?  If that is the case then a pointer to where those fields are (going) to be defined would be useful.  I read this as searching the RD for an AS directly.

I-D.erdtman-ace-rpcc defines how the client can use Raw Public Key or Pre Shared Key with (D)TLS to authenticate it self to the AS. It is not a strange operation so you might have implemented it without thinking about it (Ludwig kind of did). I-D.erdtman-ace-rpcc is similar to draft-ietf-oauth-mtls that defines what was already done in the wild when it comes to x509 certificates and client authentication.

Or you might have used default client credentials (client_id/username and client_secret/password).

I think writing about client credentials is needed since the ACE use cases so far has been client centric, i.e. the client is often described to authenticate as it self to get a token and not as is common i OAuth the user is authenticated and authorizes the client to get a token.

With that said the reference to I-D.erdtman-ace-rpcc should maybe be removed since interest in I-D.erdtman-ace-rpcc has been very limited.

[JLS] I am implementing all of my credentials as being something that is either a) cooked in to the device or b) as a COSE Key which is part of a database which is read up by the program.  As such I do not believe I am using anything from this draft.  Part of what I am trying to figure out here is what the status of this document is and what dependencies the Authz document has one it.  Is it really informational?  What does it do for the Authz document to have it referenced?  Should this document be pushed up to a WG document because it is really needed?   My understanding from RFC6749 is that these are client credentials that are being used in the HTTP authentication rather then the TLS client auth layer below HTTP.   On the other hand this is not completely clear.

[JLS] These are not finished questions – not surprised you did not respond.

Jim

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

---

From: Samuel Erdtman <[email-masked]>
Date: Sat, 23 Jun 2018 22:23:29 +0200

see inline

On Thu, Jun 21, 2018 at 5:58 PM, Jim Schaad <[email-masked]> wrote:

> *From:* Samuel Erdtman <[email-masked]>
> *Sent:* Thursday, June 21, 2018 8:15 AM
> *To:* Jim Schaad <[email-masked]>
> *Cc:* [email-masked]; ace <[email-masked]>
> *Subject:* Re: [Ace] Review of draft-ietf-ace-oauth-authz -12
>
>
>
> [JLS] Yeah I agree that ‘client information’ is not really any better.  I
> wonder if ‘Access Information’ might be a better term?
>

I have create an issue so that it is not forgotten at least.

> The focus could maybe be different but the text is about how to find the
> AS but the method for that is quite RS focused.
>
>
>
> [JLS] This is not clear to me from what is stated.  Does this mean that
> there is going to be AS pointers that are contained on the RD entry for the
> resource that one is interested in?  If that is the case then a pointer to
> where those fields are (going) to be defined would be useful.  I read this
> as searching the RD for an AS directly.
>

I did some more reading and I agree the text implies that there is a AS
pointer in the RD. I could not find such registration in this document.
I have created a github issue to either add this information or remove the
text that implies so.

> [JLS] I am implementing all of my credentials as being something that is
> either a) cooked in to the device or b) as a COSE Key which is part of a
> database which is read up by the program.  As such I do not believe I am
> using anything from this draft.  Part of what I am trying to figure out
> here is what the status of this document is and what dependencies the Authz
> document has one it.  Is it really informational?  What does it do for the
> Authz document to have it referenced?  Should this document be pushed up to
> a WG document because it is really needed?   My understanding from RFC6749
> is that these are client credentials that are being used in the HTTP
> authentication rather then the TLS client auth layer below HTTP.   On the
> other hand this is not completely clear.
>

The draft (erdtman-ace-rpcc) is not concerned about how the key is stored.
Id describes how to use the key as a client credential with (D)TLS
Raw-Public-Key or Pre-Shared-Key. (depending on the key type).
The reference is informational as far as I can tell, it is used to
exemplify how the OAuth client authentication can be extended.
RFC6749 (The OAuth 2.0 Authorization Framework) describes one type of
client credentials and that is (client_id/username and
client_secret/password). In my opinion that is not a great fit for the IoT
use case with limited user interactions and interfaces. Therefore I created
the draft (erdtman-ace-rpcc) to describe how to use Raw-Public-Key or
Pre-Shared-Key to authenticate the client, i.e. I think there is value in
the document.
With that said there is no absolute need for it from
draft-ietf-ace-oauth-authz point of view.

> :-)

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 25 Jun 2018 10:25:48 +0200

>         depending on if you think you understand a common time.

I agree, this seems like a leftover from when we discussed the issue of 
common understanding of time. I suggest we remove that paragraph.

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