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

[Paul Kyzivat <[e-mail]>]

Hi Olaf,

On 9/17/20 4:09 AM, Olaf Bergmann wrote:
> 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.
> 
> [...]

Sorry to be so dense, but I'm still not getting it.

I take your point that this is only an example of a way to agree on a 
shared secret. But at the end of the day they indeed must somehow agree 
on a shared secret. *If* they use this technique then it will only work 
if they also agree on a consistent way to do the serialization and 
encoding that is otherwise not standardized. So they need a side 
agreement, which is not a good situation for a standardized protocol.

At the very least it seems like you should highlight that some sort of 
out of band communication is required between the authorization and 
resource servers to establish the shared secret or the algorithm to be 
used for deriving the shared secret.

>>>> 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.

That seems ok.

	Thanks,
	Paul