Re: [Ace] draft-ietf-ace-dtls-authorize-01

[Ludwig Seitz <[e-mail]>]

On 2017-10-01 11:35, Hannes Tschofenig wrote:
> [chair hat off]
> 
> Hi all,

Hello Hannes,

thank you for your comments. Replies inline.

/Ludwig

> 
> I took a look at the draft and noticed a few minor things:
> 
> - The document should talk about "profiles" rather than "profile" since
> it specifies at least two profiles, namely the RPK and the PSK profiles
> with DTLS. I suspect an implementation is only expected to implement one
> of them rather than both.

I would have said that PSK vs RPK are just options within the DTLS 
profile, but I have no strong opinion about this.

You have a point that constrained implementations are likely to only 
support one option.

> 
> - Editorial comment: most of the articles are missing, which makes the
> document harder to read.
> 
Will fix.

> - AS discovery: Wouldn't the client need to know the AS upfront when
> using RPK and PSK (since it has to share a PSK with the AS or, in case
> of the RPK, has to have the RPK with the server exchanged out of band)?

There are two scenarios how this could work:

1.) The client doesn't know the AS upfront, but after getting the 
discovery message it can register at the AS through some out-of-scope 
method in order to establish the PSK or RPK needed for communication 
with the token endpoint.

2.) The discovery hint just helps the client to select an AS from a set 
of previously known ASs.


> - There are two options provided for conveying the access token to the
> RS, either either a dedicated endpoint or inband within the DTLS
> exchange. There are pros and cons regarding the usage of both; is the
> idea to settle with one approach in the end or do you envision both
> options to be available in the final version of the specification.

Note that the inband version only works for PSK, so the authz-info 
endpoint is at least needed for RPK. I would guess that constrained 
implementations would settle for just one option. Maybe we should 
specify some signaling for that.

> 
> - Regarding the dynamic update of authorization information. Since the
> access token is a PoP token I believe you will have to demonstrate the
> possession of the key every time you change the access token. (Section
> 2.4 gives me a different impression.)
> 

Not necessarily. Since you still have the session open, you only need to 
have the AS to link the new token to the same pop key (for which you 
already proved possession). The framework (in conjunction with the cnf 
draft) have mechanisms for this).

> - When the access token is conveyed inband in DTLS as part of the
> PSK_identity then the text on page 12 is applicable. The description in
> CDDL format confuses me. Normally, it should be quite simple: either you
> transmit a psk_identity field or you convey the access token. The server
> would figure it out. Is this just a complicated way to express this
> semantic or do you have something else in mind?

The actual functionality that is specified is this:

psk_identity = {kid : <kid>} | {access_token : <access token>}

does that make more sense to you?

I'm not entirely happy with that solution, since we now have the weird 
situation where a client oblivious of the profile might use the 
psk_identity as intended, thus we actually have:

psk_identity = {kid : <kid>} | {access_token : <access token>} | kid

and my code needs to handle all 3 cases. I agree this needs to be discussed.


> (Btw, my understanding is that the server does not need to send a
> illegal_parameter alert when it the psk_identity does not lead to a
> successful authentication. Is this your suggestion or is this taken from
> TLS PSK?)
> 
> - What is the reasoning behind this statement:
> 
>     "This specification mandates that at least the key derivation
>     algorithm "HKDF SHA-256" as defined in [I-D.ietf-cose-msg] MUST be
>     supported."
> 
> I would have assumed at the session key provided by the AS to the client
> and the key embedded in the access token is used directly within TLS as
> a PSK.
> 

I'm not sure about this, Olaf, Steffi?


> - Could you explain this statement:
> "
>     If the security association with RS still exists and RS has indicated
>     support for session renegotiation according to [RFC5746], the new
>     Access Token MAY be used to renegotiate the existing DTLS session.
>     In this case, the Access Token is used as "psk_identity" as defined
>     in Section 4.1.  The Client MAY also perform a new DTLS handshake
>     according to Section 4.1 that replaces the existing DTLS session.
> "
> 
> What are you trying to accomplish? Do you expect authorization
> information to change frequently? What security association are you
> talking about in the paragraph above?
> 

The idea is to be able to handle changing authorization information, 
without having to redo the full DTLS handshake. The scenario would be 
that a client gains access to a resource, starts performing a series of 
operations, and at some point gets a "permission denied". The client 
would then go back to the token endpoint at the AS and request a new 
access token with a wider scope, that it would submit to the RS.

The security association would be the DTLS session.


-- 
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone [phone]