Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12

[Olaf Bergmann <[e-mail]>]

Hi Paul,

Responding to you remaining comments please see inline.

Paul Kyzivat <[e-mail]> writes:

>>>> * Also in section 3.3:
>>>>
>>>>     All CBOR data types are encoded in CBOR using preferred serialization
>>>>     and deterministic encoding as specified in Section 4 of
>>>>     [I-D.ietf-cbor-7049bis].  This implies in particular that the "type"
>>>>     and "L" components use the minimum length encoding.  The content of
>>>>     the "access_token" field is treated as opaque data for the purpose of
>>>>     key derivation.
>>>>
>>>> IIUC the type of serialization and encoding is a requirement. Will
>>>> need some rewording to make it so.
>>>
>>> I take it that you and Ben have agreed that the example description does
>>> not necessarily need normative language as the description of this key
>>> derivation procedure is meant as an example how the authorization server
>>> and the resource server can securely agree on a shared secret to be used
>>> between the client and the resource server.
>
> This still confuses me. IIUC preferred serialization and deterministic
> encoding are *optional* in CBOR. The text hear seems to require it,
> but doesn't use normative language to do so.
>
> If these are required for things to work then you make a normative
> statement about it. E.g., "The "type" and "L" components MUST use the
> minimum length encoding."
>
> Or do you intend that some other (non-minimum-length) MAY be used? (In
> which case both sides would need a side agreement on what encoding is
> used.)

The text here just gives an example how key derivation may be used by
the authorization server and the resource server to agree on a shared
secret (that is used to encrypt the traffic between the resource server
and the to-be-authorized client).

To that regard, the text is not really normative. The only normative
language we need here would be to avoid security issues. Commenting on
the data representation here is to be understood as a suggestion to use,
e.g., preferred CBOR serialization according to 7049bis.

[...]

>>> OLD:
>>>
>>>    New access tokens issued by the authorization server are supposed to
>>>    replace previously issued access tokens for the respective client.
>>>
>>> NEW:
>>>
>>>    New access tokens issued by the authorization server replace
>>>    previously issued access tokens for the respective client.
>
> The above is still non-normative. Perhaps:
>
>       New access tokens issued by the authorization server MUST replace
>       previously issued access tokens for the respective client.

Following Section 5.8.1 of the framework document, this should be a
SHOULD (the text there reads as: "This specification RECOMMENDS that an
RS stores only one token per proof-of-possession key, meaning that an
additional token linked to the same key will overwrite any existing
token at the RS."

The text then would read as follows (changes are the new SHOULD and
"needs a common understanding" instead of "must have":

OLD:

   According to
   Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one
   access token for each client.  New access tokens issued by the
   authorization server replace previously issued access tokens for the
   respective client.  The resource server therefore must have a common
   understanding with the authorization server how access tokens are
   ordered.  The authorization server may, e.g., specify a "cti" claim
   for the access token (see Section 5.8.3 of
   [I-D.ietf-ace-oauth-authz]) to employ a strict order.

NEW:

   According to
   Section 5.8.1 of [I-D.ietf-ace-oauth-authz], there should be only one
   access token for each client.  New access tokens issued by the
   authorization server SHOULD replace previously issued access tokens for the
   respective client.  The resource server therefore needs a common
   understanding with the authorization server how access tokens are
   ordered.  The authorization server may, e.g., specify a "cti" claim
   for the access token (see Section 5.8.3 of
   [I-D.ietf-ace-oauth-authz]) to employ a strict order.


Grüße
Olaf