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

[Olaf Bergmann]

Ludwig Seitz  writes:

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

Sorry, my fault! Forget my comment.

Grüße
Olaf

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

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

[Ludwig Seitz]

On 2017-07-24 13:36, Olaf Bergmann wrote:

Hi Ludwig,

Ludwig Seitz  writes:


On 2017-06-24 02:00, Jim Schaad wrote:



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


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.

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

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

[Ace] Comments on draft-ietf-ace-oauth-authz

[Jim Schaad]

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

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

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

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

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

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

Jim


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