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

[Olaf Bergmann <[e-mail]>]

Paul,

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

> 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