Subject: Re: [Ace] Comments on draft-ietf-ace-oauth-authz

From: Ludwig Seitz <[email-masked]>
Date: Mon, 24 Jul 2017 13:23:36 +0200

On 2017-06-24 02:00, Jim Schaad wrote:
> * Figure 7 makes no sense.  This appears to be mapping a string to a keyed
> object.  I think however, that the error here is used as a value not a key.

Indeed that figure needs clarification. The errors are values not keys.

> 
> * Is there a recommendation for behavior if a new item is posted to the
> authz-info endpoint which has the same key id as a previous one?  I can
> think of three answers, none of which I link
> --- Just accept it - this leans to a problem because for DTLS the key ids
> are single shot tries, that is one cannot try the first key and then the
> second key.
> --- Replace it - this means that the client associated with the current key
> will suddenly be unable to access resources but knows only that the key no
> longer works
> --- Reject it - this may be the best option as it leaks only that the key id
> is already in use, but if the key id is assigned by an AS then it may be
> hard to get a different one assigned by the AS.
> 

Currently there is no recommendation, I have implemented the 3rd variant 
(reject).

> * We communicate the profile to be used to the client, however it is not
> currently being communicated to the server.  If the server wants to keep the
> OSCOAP and DTLS keys separate, this needs to be done.  Does it makes sense
> to put this in the 'cnf' field?
> 

My perhaps naive assumption was that the profile should be obvious to 
the server, since the client will initiate the communication accordingly 
e.g. send an OSCOAP message if the OSCOAP profile is to be used, or 
start a DTLS handshake if the DTLS profile is to be used.

If we where to tackle this, how would we signal the profile to the 
server? Securely sending messages to the server already implies the use 
of a specific profile, so it seems like a hen-and-egg problem to me.

> * the dtls draft has the concept of a nonce in the AS information payload.
> How is this propagated through the request (to the AS) and token back to the
> RS?
> 
I wonder if this functionality should be in the framework, or if it 
would rather fit into another draft extending the framework. Is there a 
compelling reason to have it as a base functionality?

> * Per comments from other drafts.  How many of these points are supposed to
> be under the .well-known arch?
> 

Good point, we should investigate this.

> * In section 5.7.1 - why is there a requirement that a created rather than a
> changed response be returned.  I was not intending to create a new resource
> in response to this POST operation. 

I would argue that you are creating a new resource, namely the access 
token, thus "create" is the right response.

>  If the 2.01 (created) response is
> required.  Should the token be accessible using the location path in the
> response?  --- Same questions apply to the Client--AS interaction.

Indeed, that would mean that a client could access it's token with GET 
and delete it with DELETE. I haven't thought through the implications, 
I'll create an issue for this.

/Ludwig

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

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 24 Jul 2017 13:36:34 +0200

Hi Ludwig,

> the server, since the client will initiate the communication
> accordingly e.g. send an OSCOAP message if the OSCOAP profile is to be
> used, or start a DTLS handshake if the DTLS profile is to be used.
>
> server? Securely sending messages to the server already implies the
> use of a specific profile, so it seems like a hen-and-egg problem to
> me.

Related to another issue, we had briefly discussed the possibility that
the entity that contacts the AS is not the client that seeks to contact
the RS. Where this is the case, there is no reason to assume that the
security protocol used to retrieve the access token from the AS is the
same that is used for the communication between C and RS. A profile
might want to explicitly forbid this practice, though.

Grüße
Olaf

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 24 Jul 2017 13:47:36 +0200

> might want to explicitly forbid this practice, though.
I'm not sure I understand that comment. The communication between C and 
AS doesn't matter for this issue, neither does the security protocol 
used between C and AS. Perhaps my wording was unclear?

If you replace "server" with "RS" in my previous comment does it make 
more sense?

/Ludwig

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

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 24 Jul 2017 14:15:12 +0200

> If you replace "server" with "RS" in my previous comment does it make

Sorry, my fault! Forget my comment.

Grüße
Olaf