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

From: Olaf Bergmann <[email-masked]>
Date: Tue, 08 Sep 2020 13:14:39 +0200

Hi Paul,

I hope you are doing well. On request from Jim Schaad who acts as the
document shepherd, we have submitted draft-ietf-ace-dtls-authorize-13
including the changes proposed below. Please feel free to contact us if
you do not agree with these proposals.

Grüße
Olaf

Olaf Bergmann <[email-masked]> writes:

> Thank you very much for your review and the very useful suggestions
> therein. Please find our comments inline. All issues that have not been
> resolved in the prior discussion threads with Ben and Jim have been
> addressed in the editor's copy of the draft.
>
> Paul Kyzivat <[email-masked]> writes:
>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> 1) MAJOR: Management of token storage in RS
>>
>> There seems to be an expectation that when the client uploads an
>> access token that the RS will retain it until the client attempts to
>> establish a DTLS association. This seems to require some sort of
>> management of token lifetime in the RS. The only discussion I can find
>> of this issue is the following in section 7:
>>
>>    ... A similar issue exists with the
>>    unprotected authorization information endpoint where the resource
>>    server needs to keep valid access tokens until their expiry.
>>    Adversaries can fill up the constrained resource server's internal
>>    storage for a very long time with interjected or otherwise retrieved
>>    valid access tokens.
>>
>> This seems to imply a normative requirement to keep tokens until their
>> expiry. But I find no supporting normative requirements about
>> this. And, this section only presents it as a DoS attack, rather than
>> a potential problem with valid usage.
>
> There is no normative requirement to keep tokens until their expiry. A
> resource server could dispose of a stored token at any time, forcing a
> client to retrieve another access token for subsequent requests directed
> to the respective resource server. The only requirement imposed on the
> resource server is that it must not send data to the client if there is
> no valid access token that authorizes this action (this is described in
> Section 3.4).
>
> Usually, a resource server implementation would keep the received access
> tokens as long as it deems useful for the intended interaction with the
> client, with the expiration time being an upper bound for the storage
> time (see Section 3.4).
>
>> ISTM that there is an implied requirement that the RS have the
>> capacity to store one access token for every PoP key of every
>> authorized client. If so, that ought to be stated. If not, then some
>> other way of bounding storage ought to be discussed.
>
> The ACE framework already states in Section 5.8.1 that the "RS
> MUST be prepared to store at least one access token for future use"
> and "RECOMMENDS that an RS stores only one token per
> proof-of-possession key". This is now re-iterated in this profile
> as suggested:
>
> NEW:
>
>   A resource server MUST have the capacity to store one access token
>   for every proof-of-possession key of every authorized client.
>
> Although a reasonable implementation
> of this profile would try to provide storage for every PoP key of
> every authorized client, this could easily get out of bounds with the
> separate upload mechanism to the authz-info resource as pointed out in
> the cited paragraph from the security considerations. This now has
> been elaborated as follows:
>
> OLD:
>
>   A similar issue exists with the unprotected authorization
>   information endpoint where the resource server needs to keep valid
>   access tokens until their expiry. Adversaries can fill up the
>   constrained resource server's internal storage for a very long time
>   with interjected or otherwise retrieved valid access tokens.
>
> NEW:
>
>   A similar issue exists with the unprotected authorization
>   information endpoint when the resource server needs to keep valid
>   access tokens for a long time. Adversaries could fill up the
>   constrained resource server's internal storage for a very long time
>   with interjected or otherwise retrieved valid access tokens.  To
>   mitigate against this, the resource server should set a time
>   boundary until an access token that has not been used until then
>   will be deleted.
>
>> 2) MAJOR: Missing normative language
>>
>> I found several places where the text seems to suggest required
>> behavior but fails to do so using normative language:
>>
>> * In section 3.3:
>>
>>    ... Instead of
>>    providing the keying material in the access token, the authorization
>>    server includes the key identifier in the "kid" parameter, see
>>    Figure 7.  This key identifier enables the resource server to
>>    calculate the symmetric key used for the communication with the
>>    client using the key derivation key and a KDF to be defined by the
>>    application, for example HKDF-SHA-256.  The key identifier picked by
>>    the authorization server needs to be unique for each access token
>>    where a unique symmetric key is required.
>>    ...
>>    Use of a unique (per resource server) "kid" and the use of a key
>>    derivation IKM that is unique per authorization server/resource
>>    server pair as specified above will ensure that the derived key is
>>    not shared across multiple clients.
>>
>> The uniqueness seems to be a requirement. Perhaps "needs to be unique"
>> should be "MUST be unique". (And something similar for the IKM.)
>
> We have changed "needs to be unique" to "MUST be unique" in the first
> paragraph as suggested, and "the use of a key derivation IKM that is
> unique" to "the use of a key derivation IKM that MUST be unique" in the
> second paragraph you have mentioned.
>
>> * 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.
>
>> * In section 3.3.1:
>>
>>    ... To
>>    be consistent with the recommendations in [RFC7252] a client is
>>    expected to offer at least the ciphersuite TLS_PSK_WITH_AES_128_CCM_8
>>    [RFC6655] to the resource server.
>>
>> I think "is expected" should be "MUST".
>
>>From [1] I take it that you have been ok with the current wording to
> indicate that this means a MUST implement while there may be cases where
> a client knows that it can offer something else.
>
>    [1] https://mailarchive.ietf.org/arch/msg/ace/V8WXg8dhE3UkDxbIbOK-D0VmD9U/
>
>> * Also in section 3.3.1:
>>
>>    ... This
>>    specification assumes that the access token is a PoP token as
>>    described in [I-D.ietf-ace-oauth-authz] unless specifically stated
>>    otherwise.
>>
>> I think "assumes ... unless" should be "MUST ... unless".
>
> We are happy to mandate PoP tokens. In the beginning when
> the protocol was intended to be similar to OAuth, people wanted to be
> have some loophole for other token types. The text now has been
> changed as proposed in [2] to
>
>   [2] https://mailarchive.ietf.org/arch/msg/ace/ddtl8a4fmvEdXhEWc3HQtv6RQgo/
>
> OLD: 
>
>   This specification assumes that the access token is a PoP token as
>   described in [I-D.ietf-ace-oauth-authz] unless specifically stated
>   otherwise.
>
> NEW:
>
>   This specification implements access tokens as proof-of-possession
>   tokens.
>  
>> * Also in section 3.3.1:
>>
>>    ... New access tokens issued by the
>>    authorization server are supposed to replace previously issued access
>>    tokens for the respective client.
>>
>> Is this normative? Should "are supposed to" be "MUST"?
>
> The ACE profiles would continue to work if there were multiple
> access tokens for a single resource server/client association in
> effect at a particular point in time. But neither OAuth nor ACE have
> defined algorithms for merging authorization rules, and therefore, the
> ACE WG has decided to keep things simple and assume that a newer
> access token always replaces the old one.
>
> As a consequence, the framework document and the profiles are written
> as if a newer access token always replaces older access tokens for a
> respective association between resource server and client.  To make
> this assumption more clear, we have removed the "are supposed to". The
> text now reads
>
> 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.
>
>> 3) MINOR: Insufficient specification
>>
>> (I'm waffling whether this is minor or major.)
>>
>> There are a couple of places where what seem to be requirements are
>> stated too vaguely to be implemented consistently:
>>
>> * In the previously mentioned paragraph in 3.3.1:
>>
>>    ... This
>>    specification assumes that the access token is a PoP token as
>>    described in [I-D.ietf-ace-oauth-authz] unless specifically stated
>>    otherwise.
>>
>> The "unless specifically stated otherwise" is too vague to be
>> normative. How would the alternative be indicated? Is this an escape
>> hatch for future extensions? If so, it needs more work to make that
>> clear and to open a path for that future work.
>
> See above. Basically, we now require PoP tokens. (An alternative type of
> access token would have been indicated with the token_type claim as
> defined in the framework document.)
>
>> * Also in section 3.3.1:
>>
>>    ... The resource server therefore must
>>    have a common understanding with the authorization server how access
>>    tokens are ordered.
>>
>> The last statement ("must have a common understanding") is
>> mysterious. IIUC section 4 is covering the same topic in a less
>> mysterious way.
>
> The reason for this seemingly mysterious statement is that it is
> very difficult to define a strict order on access tokens that works
> for all intended use cases the protocol has initially been designed
> for. This was discussed in [3].
>
>   [3] https://mailarchive.ietf.org/arch/msg/ace/x9JFbn0a6CRdsIwmQdKReGu5q1E/
>
> The only resolution the working group had agreed on by then was to treat
> use the last token that was received as the newest. There is some text
> in the framework that tells how the resource server might be able to
> order access tokens. The most general would be to use the cti claim,
> therefore the following text has been added to clarify this:
>
> NEW:
>
>   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.
>
>
>> 4) NIT: Subsection organization
>>
>> Both 3.2 and 3.3 share a common structure:
>>
>> * The section begins with discussion of the interaction between the
>> client and the AS.
>>
>> * it is followed by a subsection discussing the interaction between
>> the client and the RS.
>>
>> It is odd to have a section with a single subsection. And the
>> structure isn't easily discerned from the TOC.
>>
>> I suggest it would be clearer if each of these sections had *two*
>> subsections, one covering the AS interactions and the other the RS
>> interactions. IOW, put the material covering the AS interactions into
>> a new subsection.
>
> Good point, this is indeed very odd. The structure now has been changed
> to include a subsection "Access Token Retrieval from the Authorization
> Server" for each of the two modes where the interaction between client
> and authorization server is described.
>
> Grüße
> Olaf

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Sep 2020 16:49:01 -0400

> you do not agree with these proposals.

Thanks for addressing my comments. For the most part the changes address 
my concerns. My lack of any deep understanding of the subject material 
limits the extent that I can comprehend if my concerns have been 
sufficiently addressed. Further comments inline.

>> client, with the expiration time being an upper bound for the storage

I think I understand. Discarding tokens while they are still in use 
would result in sub-optimal behavior (including potential thrashing). 
But this can be viewed as an optimization or quality of implementation 
issue.

>>    for every proof-of-possession key of every authorized client.

Sounds good.

>>    boundary until an access token that has not been used until then

Sounds good.

>> second paragraph you have mentioned.

Sounds good.

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

>>     [1] https://mailarchive.ietf.org/arch/msg/ace/V8WXg8dhE3UkDxbIbOK-D0VmD9U/

Yes.

>>    This specification implements access tokens as proof-of-possession

Sounds good.

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

>> defined in the framework document.)

Sounds good.

>>    access token (see Section 5.8.3 of [I-D.ietf-ace-oauth-authz] to

Its all getting hazy here for me. I trust you.

>> and authorization server is described.

I think it seems better now.

	Thanks,
	Paul

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 17 Sep 2020 10:09:13 +0200

Hi Paul,

Responding to you remaining comments please see inline.

Paul Kyzivat <[email-masked]> writes:

> encoding are *optional* in CBOR. The text hear seems to require it,
> but doesn't use normative language to do so.
>

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.

[...]

>       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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Sep 2020 11:25:55 -0400

Hi Olaf,

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

>     [I-D.ietf-ace-oauth-authz]) to employ a strict order.

That seems ok.

	Thanks,
	Paul

---

From: Göran Selander <[email-masked]>
Date: Fri, 25 Sep 2020 15:07:47 +0000

Hi Paul,

On 2020-09-17, 17:26, "Paul Kyzivat" <[email-masked]> wrote:

    Hi Olaf,

[GS]
I'm not sure I understand the issue correctly. 

Section 4.1 of ietf-cbor-7049bis states:
'The preferred serialization always uses the shortest form of representing the argument'

This seems to me to be in coherence with:
"All CBOR data types are encoded in CBOR using preferred serialization and deterministic encoding"
and
'This implies in particular that the "type" and "L" components use the minimum length encoding. '

If I understand right you would like to replace the latter sentence with:
'The "type" and "L" components MUST use the minimum length encoding.'

But there are multiple statements in this example which could be replaced with normative language, e.g.,:

'In this example, HKDF consists of the composition of the HKDF-Extract and HKDF-Expand steps [RFC5869].'

'The symmetric key is derived from the key identifier, the key derivation key and other data:'

'type is set to the constant text string "ACE-CoAP-DTLS-key-derivation" '

Would you be happy with only the specific normative statement you proposed (which BTW is fine to me) or would you like to see all statements like this to be replaced with normative text (or can we make a normative formulation at the beginning of the example indicating that "compliance to this example REQUIRES the following:")?

Thanks,
Göran