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

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 1 Oct 2017 11:35:11 +0200

[chair hat off]

Hi all,

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.

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

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

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

- 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?
(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.

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

Ciao
Hannes

---

From: Ludwig Seitz <[email-masked]>
Date: Mon, 2 Oct 2017 12:39:36 +0200

> Hi all,

Hello Hannes,

thank you for your comments. Replies inline.

/Ludwig

> 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
Will fix.

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

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

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

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

> and the key embedded in the access token is used directly within TLS as

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

> 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 +46(0)70-349 92 51

---

From: Olaf Bergmann <[email-masked]>
Date: Wed, 04 Oct 2017 16:47:33 +0200

Hello Hannes,

Thank you very much for your comments. I am replying to the comment that
Ludwig did not yet address:

>> and the key embedded in the access token is used directly within TLS as

Yes, you could embed the session key in the access token. But then, you
would always have to encrypt the access token and ensure that is never
decrypted by unauthorized parties. Key derivation allows you to transfer
the access token unencrypted (as long as the privacy objectives are met,
of course). This could even save some bytes in the token as the
encrypted session key does not have to be transferred.

This mechanism has previously been discussed in section 6 of [1] but now
has been adjusted from the simple ad-hoc syntax in DCAF to the more
flexible COSE method.

[1] https://tools.ietf.org/html/draft-gerdes-ace-dcaf-authorize-04#section-6

Grüße
Olaf