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

[Hannes Tschofenig <[e-mail]>]

[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