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

[Paul Kyzivat <[e-mail]>]

On 9/8/20 7:14 AM, Olaf Bergmann wrote:
> 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.

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.

> Grüße
> Olaf
> 
> Olaf Bergmann <[e-mail]> 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 <[e-mail]> 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).

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.

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

Sounds good.

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

Sounds good.

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

Sounds good.

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

>>> * 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/

Yes.

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

Sounds good.

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

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.

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

Sounds good.

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

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

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

I think it seems better now.

	Thanks,
	Paul