Re: [Ace] Francesca Palombini's Yes on draft-ietf-ace-dtls-authorize-16: (with COMMENT)

[Stefanie Gerdes <[e-mail]>]

Hi Francesca,

Thank you for your detailed comments, and sorry for the late reply. We
addressed most of your comments in the latest version. Please find my
comments inline.

On 3/24/21 4:49 PM, Francesca Palombini via Datatracker wrote:
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for this document. Some minor comments below.
> 
> Francesca
> 
> 1. -----
> 
>    The response MAY contain a "profile" parameter with the value
> 
>    authorizes the client, it returns an AS-to-Client response.  If the
>    profile parameter is present, it is set to "coap_dtls".  The
> 
>          profile    : coap_dtls,
> 
> FP: s/profile/ace_profile

Fixed.

> 
> 2. -----
> 
>    [RFC8747].  A resource server MUST have the capacity to store one
>    access token for every proof-of-possession key of every authorized
>    client.
> 
> FP: I am not sure this BCP 14 MUST is correct here.

The normative language was used here to address a comment from Paul
Kyzivat's GEN-ART review who explicitly has asked for a normative
requirement to keep tokens until their expiry.

> 
> 3. ------
> 
>    raw public keys, it needs to determine which key to use.  The
>    authorization server can help with this decision by including a "cnf"
>    parameter in the access token that is associated with this
>    communication.  In this case, the resource server MUST use the
> 
> FP: The example in Figure 4 show how the whole RPK of the client can be
> included in the access_token, so maybe this paragraph should cover that case,
> or the example changed.

I am not quite sure if I understand your comment. In Figure 4, the
contents of the access token is omitted for brevity. The response
contains access information for the client with the server's RPK in
the rs_cnf parameter. This is required by the client to authenticate
its peer during the DTLS handshake. We changed the example paragraph
so that it now explains the use of the rs_cnf parameter. Does that
make it more clear?

> 
> 4. -----
> 
>    token carries a symmetric key, the access token MUST be encrypted
>    using a "COSE_Encrypt0" structure.  The authorization server MUST use
> 
> FP: Since only CWT is allowed in this profile, it might be good to reference
> section 7.1 of RFC 8392.

Fixed as suggested.

> 
> 5. -----
> 
>    the "psk_identity" field.  If key derivation is used, the resource
>    server uses the "COSE_KDF_Context" information as described above.
> 
> FP: "COSE_KDF_Context" appears here for the first time, so this might need to
> be rephrased.

Okay, done.

> 
> 6. -----
> 
>    As recommended in Section 5.8 of [I-D.ietf-ace-oauth-authz], this
>    specification uses CBOR web tokens to convey claims within an access
>    token issued by the server.  While other formats could be used as
> 
> FP: I think this warrants for RFC 8392 to be moved to normative reference (but
> can be convinced of the contrary).

Yes, changed to normative.

Thank you for your time,
Steffi