[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 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
