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 +46(0)70-349 92 51
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
