Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

Olaf Bergmann <bergmann@tzi.org> Tue, 14 April 2020 16:20 UTC

Return-Path: <bergmann@tzi.org>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D853E3A0B56; Tue, 14 Apr 2020 09:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQAR3rkFw340; Tue, 14 Apr 2020 09:20:45 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3F13A0B62; Tue, 14 Apr 2020 09:20:41 -0700 (PDT)
Received: from wangari.tzi.org (client-0110.vpn.uni-bremen.de [134.102.107.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 491rLv0nQwzyYs; Tue, 14 Apr 2020 18:20:39 +0200 (CEST)
From: Olaf Bergmann <bergmann@tzi.org>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org
References: <20200102234020.GI35479@kduck.mit.edu>
Date: Tue, 14 Apr 2020 18:20:38 +0200
In-Reply-To: <20200102234020.GI35479@kduck.mit.edu> (Benjamin Kaduk's message of "Thu, 2 Jan 2020 15:40:20 -0800")
Message-ID: <87pnca9gyx.fsf@wangari>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/pFYED9lMtepExgTvKPB-UUqAwuw>
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2020 16:20:57 -0000

Ben,

Thanks again for the thorough review of the ACE DTLS profile and my
sincere apologies for the long time it took to process. Please find our
comments inline. As this comprises a lot of changes, the proposed text
already has been included in the Editor's copy [1].  Our proposals for
new text are in the section-by-section comments.

[1] https://ace-wg.github.io/ace-dtls-profile/

Benjamin Kaduk <kaduk@mit.edu> writes:

> Hi all,
>
> Some high-level remarks before delving into the section-by-section
> comments:
>
> This document is pretty clearly DTLS 1.2-specific -- it talks about
> particular protocol messages, message fields, and cipher suites that
> simply do not apply to DTLS 1.3.  In order to use this profile with DTLS
> 1.3, we'd need to specify the analogous behavior/requirements to these
> (including standalone signature schemes and key-exchange groups, which
> are now both separately negotiated from the cipher suite).
> Given that DTLS 1.3 is past WGLC and only a few documents behind this
> one in my review queue, it seems fairly prudent to spend some time and
> cover how DTLS 1.3 would work here, since otherwise this document will
> become stale shortly after (or even before!) its publication as an RFC.
>
> There's probably some additional discussion to include about the usage of
> key identifiers in this document versus the potential uses described in
> the core framework.  Specifically, the framework reminds us that "no
> assumptions should be made that it is unique in the domains of either
> the client or the RS" yet this document is using the kid as input to a
> KDF that produces keys that must be unique across all clients, and
> allowing live/instant authorization updates based on matching "kid".
> How shall we resolve this apparent conflict?
>
> We also are potentially in violation of the framework's requirements
> with respect to the independent selection of profiles for client/AS and
> client/RS interactions -- at present, when DTLS+RPK is used for
> client/RS, we require that DTLS+RPK is also used for client/AS, in order
> to prove possession of the key.  We could perhaps weasel our way out by
> saying that the framework's requirement applies at the profile
> granularity, and with symmetric PSK we can be fully independent, but we
> still need to say something about this property and the interaction with
> the framework's requirements.
>
> This profile is mostly applicable to the client/RS communications and
> feels like it only provides some of the picture for use with client/AS
> interactions.  (It doesn't really say much of anything about RS/AS
> interactions.) The introductory discussion does not do a great job of
> painting that picture, and I'd like to see it more clearly introduced
> that the bulk of our coverage is for the client/RS interaction.  We also
> lean heavily on the existing out-of-band configuration and key material
> shared between client and AS to secure the client/AS communications; we
> could probably tighten up the discussion about exactly what parameters
> of client/AS communication are specified by this profile.

The introduction has been revised according to your suggested text, see
below. We also have included some text on the out-of-band configuration
in a new subsection in the security considerations. The important thing
here really are the client/RS and client/AS interactions. Regarding
client/AS, much of this is out of scope as there are certain
OAuth-related assumptions on how these entities get in touch with each
other; neither the framework nor the profile can do much about it
without creating a new enrollment protocol. Regarding the RS/AS
interaction, there is normative language that describes what each of
these entities needs to do in each protocol step covered by the
document. The necessary out-of-band configuration again is described in
the new subsection in the security considerations as well as some
clarifications in the text, see below.

> We do not say anything about DTLS session resumption (or renegotiation,
> though not talking about that one is perfectly fine); that's a fairly
> core DTLS concept that we should give some guidance on.

Not sure if we really need to but if you think this is necessary, we can
comment on this, of course.

> Looking through Appendix C ("Requirements on Profiles") of the
> framework, do we want to say anything about:
>
> - using the client credentials grant with this profile, as that's IIRC
>   the only example we show

Do you think we need to say anything here? The actual grant used to
make the client known to the AS is out of scope for the profile as
long as the requirements given here are met.

> - require that DTLS be used in a mode that provides replay protection

Added as a requirement in Section 2.

> - when the client uses the authz-info endpoint instead of the
>   "psk_identity" field to convey the token to the RS, how does the RS
>   know which client is connecting (and thus what PSK to use), and what
>   does the client actually *put* in the "psk_identity" field?  (The
>   other aspects of "how to select a proof-of-possession protocol" seem
>   to fall out naturally from the DTLS usage.)

We have included more explanatory text in section 3.3.1 on how this is
supposed to work.

> - whether/how introspection is used?

We have added text stating that token introspection may be used but is
out of scope for the profile spec.

> - give more details of what this profile mandates when used for
>   client/AS interactions (as mentioned above)

This should be covered now, see detailed responses below.

> - explicitly state that the authz-info endpoint is unprotected (or that
>   it might be protected if, e.g., the RS has a trustable certificate
>   that would be used instead of RPK or PSK, or by supplying the
>   token as the "psk_identity" when symmetric PoP is used, or by only
>   doing server-authentication with RPK as known by the client by the
>   rs_cnf access information

I am not sure which security gain we would yield by trustable
certificates: The client does not need to authenticate the resource
server for the authz-info upload. The important aspect here is that the
access token must be integrity-protected by the AS and encrypted if it
contains information to be kept confidential (esp. a shared secret but
possibly other data as well). We have added some text on this to the
security considerations.

> And now, on to the section-by-section comments.
>
> Section 1
>
>    a DTLS session.  The communication between client and authorization
>    server may also be secured with DTLS.  This specification supports
>    DTLS with Raw Public Keys (RPK) [RFC7250] and with Pre-Shared Keys
>    (PSK) [RFC4279].
>
> [DTLS 1.3 will inherit TLS 1.3's built-in support for (so-called
> "external") PSKs.]

(See general discussion on wether DTLS 1.3 needs to be addressed at this
time.)

>    The DTLS handshake requires the client and server to prove that they
>    can use certain keying material.  In the RPK mode, the client proves
>    with the DTLS handshake that it can use the RPK bound to the token
>    and the server shows that it can use a certain RPK.  The access token
>    must be presented to the resource server.  For the RPK mode, the
>    access token needs to be uploaded to the resource server before the
>    handshake is initiated, as described in Section 5.8.1 of the ACE
>    framework [I-D.ietf-ace-oauth-authz].
>
> This seems to be making some implicit assumptions about the message flow
> that have not yet been covered by this document and are only somewhat
> covered by the core framework spec.  I'd propose:
>
> %  The ACE framework requires that client and server mutually
> %  authenticate each other before any other protocol exchanges take
> %  place.

Actually, this is not true: The client can upload data to the
resource server's authorization endpoint without authentication.  I
suggest to rephrase this as "The ACE framework requires that client
and server mutually authenticate each other before any application
data is exchanged.", see below.

> % In order for DTLS to provide mutual authentication, both
> %  client and server must prove their ability to use certain keying
> %  material (tied to the authenticated identity) as part of the DTLS
> %  handshake.  The AS assists in this process by incorporating key
> %  material (or information about key material) into the access token,
> %  which is considered a "proof of possession" token.  In the RPK mode,
> %  the client proves that it can use the RPK bound to the token and the
> %  server shows that it can use a certain RPK (as indicated by the AS to
> %  the client).  The resource server needs access to the token in order
> %  to complete this exchange.  For the RPK mode, the access token needs
> %  to be uploaded to the resource server before the handshake is
> %  initiated, as described in Section 5.8.1 of the ACE framework
> %  [I-D.ietf-ace-oauth-authz].
>
> though I recognize that my text tends to be a bit more verbose than is
> strictly needed, so please feel free to edit it down.

We propose the following change:

OLD:

  The DTLS handshake requires the client and server to prove that they
  can use certain keying material. In the RPK mode, the client proves
  with the DTLS handshake that it can use the RPK bound to the token
  and the server shows that it can use a certain RPK. The access token
  must be presented to the resource server.  For the RPK mode, the
  access token needs to be uploaded to the resource server before the
  handshake is initiated, as described in Section 5.8.1 of the ACE
  framework {{I-D.ietf-ace-oauth-authz}}.

NEW:

  The ACE framework requires that client and server mutually
  authenticate each other before any application data is exchanged.
  DTLS enables mutual authentication if both client and server prove
  their ability to use certain keying material in the DTLS handshake.
  The authorization server assists in this process on the server side
  by incorporating keying material (or information about keying
  material) into the access token, which is considered a "proof of
  possession" token.

  In the RPK mode, the client proves that it can use the RPK bound to
  the token and the server shows that it can use a certain RPK (as
  indicated by the authorization server to the client).

  The resource server needs access to the token in order to complete
  this exchange.  For the RPK mode, the client must upload the access
  token to the resource server before initiating the handshake, as
  described in Section 5.8.1 of the ACE framework
  {{I-D.ietf-ace-oauth-authz}}.

> Section 2
>
>    The CoAP-DTLS profile for ACE specifies the transfer of
>    authentication information and, if necessary, authorization
>    information between the client (C) and the resource server (RS)
>    during setup of a DTLS session for CoAP messaging.  It also specifies
>    how C can use CoAP over DTLS to retrieve an access token from the
>    authorization server (AS) for a protected resource hosted on the
>    resource server.
>
> I suggest reiterating that "As specified in Section 6.7 of
> [I-D.ietf-ace-oauth-authz], use of DTLS for one or both of these
> interactions is completely independent".

done

>    To determine the AS in charge of a resource hosted at the RS, C MAY
>    send an initial Unauthorized Resource Request message to the RS.  The
>
> This is part of the core framework, so the "MAY" may be overkill.
> (Lowercase "can" would do just fine.)

done

>    Once the client knows the authorization server's address, it can send
>    an access token request to the token endpoint at the AS as specified
>
> Hmm.  There's some level of "the client needs to have already been
> configured that that AS is a valid AS" verification that's done here,
> but I'm not sure if that's too much detail to include at this stage
> (since we're really just summarizing the framework here).

Yes, there has been a discussion on this. The issue with this three
corner model is that the client needs a pretty tight relationship with
the AS, meaning that it must be able to recognize an AS depicted in the
AS Request Creation Hints as trustworthy.

>    in [I-D.ietf-ace-oauth-authz].  As the access token request as well
>    as the response may contain confidential data, the communication
>    between the client and the authorization server MUST be
>
> (This "MUST" is already a requirement from the core framework, so we
> don't necessarily need to repeat it as normative language.)

Okay, changed to lower case.

>    confidentiality-protected and ensure authenticity.  C may have been
>    registered at the AS via the OAuth 2.0 client registration mechanism
>    as outlined in Section 5.3 of [I-D.ietf-ace-oauth-authz].
>
> Section 5.3 of oauth-authz says that registration is "out of scope"; is
> this still the right reference?

It is the correct reference but unfortunately, Section 5.3 of the
framework document just says that "Authentication of the client is
mandatory". The issue here is that the framework as well as OAuth
requires a prior registration of the client. Otherwise, the AS would not
be able to authorize the client in the three corner model. Not including
the reference would mean to repeat the requirement of client
registration here.

>    [I-D.ietf-ace-oauth-authz].  In case the client uses a symmetric
>    proof-of-possession key in the DTLS handshake, the procedure as above
>    MAY be used, or alternatively, the access token MAY instead be
>    transferred in the DTLS ClientKeyExchange message (see
>    Section 3.3.1).
>
> (This is not DTLS 1.3-compatible.)

Agreed. This would need a change if we decided to add-in support for
DTLS 1.3.

> Section 3
>
>    secured.  Depending on the used CoAP security mode (see also
>    Section 9 of [RFC7252], the Client-to-AS request, AS-to-Client
>    response and DTLS session establishment carry slightly different
>    information.  [...]
>
> At this point in the document it's pretty unclear what "Client-to-AS
> request", "AS-to-Client response", and "DTLS session establishment" are
> and how they relate to each other.

The "Client-to-AS request" and "AS-to-Client response" are introduced by
the ACE framework document. Maybe an explicit reference helps to avoid
confusion.

OLD:

  Depending on the used CoAP security mode (see also Section 9 of
  {{RFC7252}}, the Client-to-AS request, AS-to-Client response and DTLS
  session establishment carry slightly different
  information. {{rpk-mode}} addresses the use of raw public keys while
  {{psk-mode}} defines how pre-shared keys are used in this profile.

NEW:

  Depending on the used CoAP security mode (see also Section 9 of
  {{RFC7252}}, the Client-to-AS request, AS-to-Client response (see
  Section 5.6 of {{I-D.ietf-ace-oauth-authz}}) and DTLS session
  establishment carry slightly different information. {{rpk-mode}}

> Also, it seems like the behavior in Section 3.2 and 3.3 are relating to
> the mode used for the client/RS interactions, which relates to the
> client/AS interactions only in the form of how PoP information is bound
> to/with the token.

I am not sure if there is anything else to say about the client/AS
interactions that is not covered by the framework.

> Section 3.1
>
>    establish a secure communication channel.  C MUST securely have
>    obtained keying material to communicate with AS.  Furthermore, C MUST
>    verify that AS is authorized to provide access tokens (including
>    authorization information) about RS to C.  Also, AS MUST securely
>    have obtained keying material for C, and obtained authorization rules
>    approved by the resource owner (RO) concerning C and RS that relate
>    to this keying material.  [...]
>
> The way this is written right now, we're going to get lots of questions
> from reviewers about "how does this happen?" and for more details about
> it.  We are effectively assuming that this stuff is all provisioned
> already as part of the device configuration or during enrollment, we
> should say something about these being requirements on device
> provisioning, not on the operation of the ACE protocol.

The following new text has been added for clarification:

NEW:

   This profile assumes that the keying material to secure this
   communication channel has securely been obtained either by manual
   configuration or in an automated provisioning process.

>    between C and AS is bootstrapped is not part of this document.  C and
>    AS MUST ensure the confidentiality, integrity and authenticity of all
>    exchanged messages.
>
> I think this is also restating requirements from the core framework, and
> may not need normative language in this manner.

done

> Section 3.2
>
> I know that the section heading says "RawPublicKey Mode" already, but
> I'd recommend adding a sentence in the preface that repeats that "When
> the client and RS use RawPublicKey authentication, the procedure is as
> follows"; we might get complaints otherwise that we are saying that the
> client MUST do things that are not universal requirements.
> (Section 3.3 does already have something like this for the symmetric-key
> case.)

done

>    previously made known to the authorization server.  To prove that the
>    client is in possession of this key, C MUST use the same keying
>    material that it uses to secure the communication with AS, e.g., the
>    DTLS session.
>
> This seems in conflict with the core framework's requirement that the
> client/AS profile and client/RS profile are severable.

This profile explicitly specifies the communication flow between C and
AS on one side and between C and RS on the other. As both legs are part
of this profile, there is no combination of profiles involved. In that
regard, there is no such assumption as indicated in Section 6.7 of the
framework.

  *) https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-6.7

We could weaken the security here by removing the "To prove"-statement.
However, it is advisable not to do this because by using the keying
material in the C/AS communication, C shows that it is actually in
possession of the respective private key. This would raise the bar for
the client to retrieve access tokens in the name of other clients.

The preferred alternative would be replace MUST with SHOULD:

OLD:

   previously made known to the authorization server.  To prove that the
   client is in possession of this key, C MUST use the same keying
   material that it uses to secure the communication with AS, e.g., the
   DTLS session.

NEW:

   previously made known to the authorization server. To prove that the
   client is in possession of this key, C SHOULD use the same keying
   material that it uses to secure the communication with AS, e.g., the
   DTLS session.


>    AS MUST check if the client that it communicates with is associated
>    with the RPK in the cnf object before issuing an access token to it.
>
> Earlier in the section we noted a requirement to prove possession of the
> key by using it in DTLS; why is there a separate "association"
> requirement?

This is the same rationale as above. The AS needs some way to decide
which authorization rules apply to the requesting client. There was a
discussion on the mailing list that the client may use a different RPK
in the communication with AS than it uses in the communication with the
resource server. AS then must ensure two things: First, that the
authorization decision coded into the access token applies to the RPK
provided by C. Second, that the access token is transferred to the same
C.

The following text has been added to the Security Considerations to
explain the problems that arise from using different RPKs for the C/AS
and C/RS communication:

NEW:

    The authorization server must ascertain that the keying material
    for the client that it provides to the resource server actually is
    associated with this client.  Malicious clients may hand over
    access tokens containing their own access permissions to other
    entities. This problem cannot be completely
    eliminated. Nevertheless, in RPK mode it should not be possible
    for clients to request access tokens for arbitrary public keys,
    since that would allow the client to relay tokens without the need
    to share its own credentials with others. The authorization server
    therefore should at some point validate that the client can
    actually use the private key corresponding to the client's public
    key.


> also, nit: "The AS".

done

>    which case it does not have to be sent.  The response also contains
>    an access token and an "rs_cnf" parameter containing information
>    about the public key that is used by the resource server.  AS MUST
>
> nit(?): is the "rs_cnf" parameter always mandatory?  (Or only when
> DTLS-RPK is used for client-RS interactions?)

Done as follows:

OLD:

   The response also contains an access token and an "rs_cnf"
   parameter containing information about the public key that is used
   by the resource server.  AS MUST ascertain that the RPK specified
   in "rs_cnf" belongs to the resource server that C wants to
   communicate with.

NEW:

   The response also contains an access token with information about
   the public key that is used by the resource server. The
   authorization server MUST return in its response the parameter
   "rs_cnf" unless it is certain that the client already knows the
   public key of the resource server. The authorization server MUST
   ascertain that the RPK specified in "rs_cnf" belongs to the resource
   server that the client wants to communicate with.

> nit: "The AS" again (and throughought, to a large extent).

[Okay, we will change these for I-D submission.]

>    server that C wants to communicate with.  AS MUST protect the
>    integrity of the token.  If the access token contains confidential
>    data, AS MUST also protect the confidentiality of the access token.
>
> This requirement ("protect the integrity of the token") feels a little
> underspecified, as it doesn't say protection over what workflow or who
> will verify the integrity (the RS).

done, by adding

NEW:

   to ensure that the resource server can detect unauthorized changes.

>    C MUST ascertain that the access token response belongs to a certain
>    previously sent access token request, as the request may specify the
>    resource server with which C wants to communicate.
>
> nit: I recomment rewording "belongs to", perhaps as "corresponds to".
> DTLS can provide this guarantee when configured to do so, though it is
> not a guaranteed property from DTLS.

Changed to:

OLD:

    C MUST ascertain that the access token response corresponds to a
    certain previously sent access token request,...

NEW:

    the client MUST check if the access token response is bound to a
    certain previously sent access token request,

> We'll probably get some grief about the "access_token" contents in the
> example not being valid CBOR, due to the parenthetical comment.  We
> could probably put a note in the preface that the value is truncated for
> readability.  Also, nit: "the client's" with article and apostrophe.

Okay. For now, I have put in a disclaimer into the description of the
two examples where this occurs.

> Section 3.2.1
>
>    Before the client initiates the DTLS handshake with the resource
>    server, C MUST send a "POST" request containing the new access token
>    to the authz-info resource hosted by the resource server.  After the
>    client
>
> nit: we don't require single-use tokens, so "new" is probably overkill;
> just "its access token" should suffice.
> nit: formatting issue with spurious line break here.

done

>    server.  To use the RawPublicKey mode, the client MUST specify the
>    public key that AS defined in the "cnf" field of the access token
>    response in the SubjectPublicKeyInfo structure in the DTLS handshake
>    as specified in [RFC7250].
>
> IIRC the access token response does not have to include a "cnf" field
> (e.g., if the AS accepts the req_cnf from the request), so "defined in
> the field of the response" doesn't seem like quite the right wording.

Done:

OLD:

   To use the RawPublicKey mode, the client MUST specify the public
   key that AS defined in the `cnf` field of the access token response
   in the SubjectPublicKeyInfo structure in the DTLS handshake as
   specified in {{RFC7250}}.

NEW:

   The client MUST use its correct public key in the DTLS
   handshake. If the authorization server has specified a `cnf` field
   in the access token response, the client MUST use this
   key. Otherwise, the client MUST use the public key that it
   specified in the `req_cnf` of the access token request. The client
   MUST specify this public key in the SubjectPublicKeyInfo structure
   of the DTLS handshake as described in [RFC7250].

>    An implementation that supports the RPK mode of this profile MUST at
>    least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
>
> I understand that making the full-width-tag ciphersuite MTI would
> exclude some devices, though it feels like some recommendation to use
> the full-length tag when possible would be appropriate.  That said, I do
> see that RFC 7252 makes no such remark, and thus consistency would have
> us not say anything either.

We have now included more text on the tag length in the Security
Considerations, see below.

>    [RFC7251] with the ed25519 curve (cf.  [RFC8032], [RFC8422]).
>
> Just to be clear: ed25519 is an ECDSA algorithm; the corresponding ECDHE
> operation is called x25519, and both algorithms make use of the
> elliptical curve known as curve25519.  Since we are using both ECDHE and
> ECDSA, it's probably simplest to just refer to "curve25519", though
> mentioning both ed25519 and x25519 would also work.

This has been a WG decision at some point but the authors agree that
curve25519 is the best to go for and propose the following change which
also gets rid of the ugly note in favor of more coherent text:

OLD:

   An implementation that supports the RPK mode of this profile MUST
   at least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
   [RFC7251] with the ed25519 curve (cf.  [RFC8032], [RFC8422]).

NEW:

  To be consistent with {{RFC7252}} which allows for shortened MAC
  tags in constrained environments, an implementation that supports
  the RPK mode of this profile MUST at least support the ciphersuite
  TLS\_ECDHE\_ECDSA\_WITH\_AES\_128\_CCM\_8 {{RFC7251}}.  As discussed
  in {{RFC7748}}, new ECC curves have been defined recently that are
  considered superior to the so-called NIST curves. This specification
  therefore mandates implementation support for curve25519
  (cf. {{RFC8032}}, {{RFC8422}}) as this curve said to be efficient
  and less dangerous regarding implementation errors than the
  secp256r1 curve mandated in {{RFC7252}}.

>    RS MUST check if the access token is still valid, if RS is the
>    intended destination, i.e., the audience, of the token, and if the
>    token was issued by an authorized AS.  The access token is
>
> nit: "i.e., the audience" is in effect a parenthetical, so using commas
> to offset it inside a comma-separated list is potentially confusing; I'd
> suggest using actual parentheses instead of commas around it.

done

>    reference to this key.  If the authorization server has no certain
>    knowledge that the Client's key is already known to the resource
>    server, the Client's public key MUST be included in the access
>    token's "cnf" parameter.  If CBOR web tokens [RFC8392] are used as
>    recommended in [I-D.ietf-ace-oauth-authz], keys MUST be encoded as
>    specified in [I-D.ietf-ace-cwt-proof-of-possession].  RS MUST use the
>
> Is talking about """the access token's "cnf" parameter" consistent with
> allowing the use of non-CWT (non-JWT) token formats?

This has been addressed by adding the following paragraph to the
introduction:

NEW:

    As recommended in Section 5.8 of [I-D.ietf-ace-oauth-authz], this
    specification uses CBOR web tokens to convey claims within an
    access token issued by the server. While other formats could be
    used as well, those are out of scope for this document.

>    keying material in the handshake that AS specified in the rs_cnf
>    parameter in the access token.  Thus, the handshake only finishes if
>    C and RS are able to use their respective keying material.
>
> I suggest being explicit about "the DTLS handshake with the client",
> perhaps as "MUST use in the DLTS handshake with the client the keying
> material that the AS specified in the rs_cnf parameter in the access
> token".

Done, see next comment.

> The same caveat about "parameter in the access token"
> applies here, though I guess there is an additional complication for
> "rs_cnf" in that it's an token response parameter but I don't remember
> that we say a huge amount about it also being included in the token
> itself -- the token response is directed to the client but the token is
> directed to the RS.

As we have found, the mailing list discussion concluded that the access
token does not contain an rs_cnf claim at all. This occurrence most
likely was an artefact. This now has been changed as follows:

OLD:

   RS MUST use the keying material in the handshake that AS specified
   in the rs_cnf parameter in the access token.  Thus, the handshake
   only finishes if C and RS are able to use their respective keying
   material.

NEW:

   The resource server MUST use its own raw public key in the DTLS
   handshake with the client. If the resource server has several raw
   public keys, it must already know which key it is supposed to use
   with this client. How this is achieved is not part of this profile.

> Section 3.3
>
>    token.  AS MUST check if the identifier refers to a symmetric key
>    that was previously generated by AS as a shared secret for the
>    communication between this client and the resource server.
>
> "What does the AS do if this check fails?"

The following text has been added to avoid additional roundtrips for the
client:

NEW:

   If no such symmetric key was found, the AS MUST generate a new
   symmetric key that is returned in its response to the client.

>    The authorization server MUST determine the authorization rules for
>    the C it communicates with as defined by RO and generate the access
>
> nit: it's surprising to see "authorization server" spelled out in the
> same sentence as "C" and "RO" (which, incidentally, we don't seem to use
> in abbreviation form anywhere other than where we define it).

There has been some discussion about the short forms. We will
harmonize this before submitting the next I-D version.

>    wants to communicate with.  Also, AS MUST protect the integrity of
>    the access token.  If the token contains confidential data such as
>    the symmetric key, the confidentiality of the token MUST also be
>    protected.  Depending on the requested token type and algorithm in
>
> (same comment about "protect the integrity" or "protect" as for the RPK
> case.)

Done, by adding:

NEW:

   to ensure that the resource server can detect unauthorized changes.

>    that is to be used between C and the resource server.  The access
>    token MUST be bound to the same symmetric key by means of the cnf
>    claim.
>
> Now we call it a "claim" rather than a "token parameter", but this again
> seems to be implicitly assuming CWT/JWT for tokens.

We distinguish between the (semantic) information conveyed by an access
token of the syntactic description of data objects. To make this more
explicit, we now have added some text in the Terminology section that
refers to the same usage of the term 'claim' as in the framework
document.

> (Also, this "MUST" seems like something that the framework should
> guarantee and not a new requirement that the DTLS profile imposes.)

As this as been a bit misleading as well, it has been rephrased as
follows:

OLD:

   The access token MUST be bound to the same symmetric key by means
   of the cnf claim.

NEW:

    To convey the same secret to the resource server, the
    authorization server either includes it directly in the access
    token by means of the `cnf` claim or it provides sufficient
    information to enable the resource server to derive the key from
    the access token using key derivation.

>          Figure 5: Example Access Token Request, symmetric PoP-key
>
> Maybe we could include "(implicit)" in the caption, since symmetric PoP
> key is the default.

done

>    An example access token response is illustrated in Figure 6.  In this
>
> Is it accurate to say "A corresponding example access token response"?
> It's nice to the reader if we can tie the examples together like that.

done

> Is the "Max-Age" usage in Figure 6 typical?  (Also, similar comment
> about having the parenthetical comment in the example body vs. preface.)

New text was added as follows to clarify that inconsistencies with
cached responses should be avoided. For a more realistic example, the
value of Max-Age in the examples has been decreased to be sufficiently
below expires_in:

NEW:

  Caching proxies process the Max-Age option in the CoAP response
  which has a default value of 60 seconds (Section 5.6.1 of
  [RFC7252]).  The authorization server SHOULD adjust the Max-Age
  option such that it does not exceed the `expires_in` parameter to
  avoid stale responses.

>          token_type : pop,
>
> Didn't we switch this to being capitalized as "PoP"?

done

>    "COSE_Encrypt0" structure.  The AS MUST use the keying material
>    shared with the RS to encrypt the token.
>
> nit: I suggest s/shared with/it shares with/

done

> We should probably say something about why the kid in Figure 7 is
> different from the one in Figure 6.

As it seems more clear if both examples use the same kid, this now has
been harmonized.

>        4.00 Bad Request
>        Content-Format: application/ace+cbor
>        Payload:
>        {
>          error : invalid_request
>        }
>
>             Figure 8: Example Access Token Response With Reject
>
> RFC 6749's description of "invalid_request" seems to imply that it's
> mostly about malformed requests, as opposed to the AS deciding that the
> client is not authorized for any access to the requested resource (which
> is maybe what's implied by the previous paragraph).  This is not
> necessarily a problem, but perhaps we could make the text and example
> more consistent.

This example is actually about malformed requests (4.00). We now have
added text to clarify this.

>    The method for how the resource server determines the symmetric key
>    from an access token containing only a key identifier is application
>    specific, the remainder of this section provides one example.
>
> nit: hyphenate "application-specific", and this is a comma splice.

done

>    resource server.  This key needs to be securely stored and processed
>    in the same way as the key used to protect the communication between
>    AS and RS.
>
> nit: is this better as "processed" or "protected"?

"processed" because this part is about the handling not the
characteristics of the data.

>    The fields in the context information "COSE_KDF_Context"
>    (Section 11.2 of [RFC8152]) have the following values:
>
>    o  AlgorithmID = "ACE-CoAP-DTLS-key-derivation"
>
> RFC 8152 says that these AlgorithmID values come from the COSE
> Algorithms registry, which this does not (unless we register it there,
> which we don't currently).  Also, since the output is used directly for
> DTLS PSK, I don't think the "key-derivation" portion is needed.
>
>    o  PartyUInfo = PartyVInfo = ( null, null, null )
>
> (8152 seems to prefer "nil" over "null".)
>
>    o  keyDataLength needs to be defined by the application
>
>    o  protected MUST be a zero length bstr
>
>    o  other is a zero length bstr
>
> (These three are all members of the "SuppPubInfo" field, which is not
> very clear from how we include them in the same list as top-level
> fields.)

The example now has updated and rephrased according to HKDF usage.

> Section 3.3.1
>
>    When a client receives an access token response from an authorization
>    server, C MUST ascertain that the access token response belongs to a
>    certain previously sent access token request, as the request may
>    specify the resource server with which C wants to communicate.
>
> (Same bit about "belongs to".)

done

>    If a resource server receives a ClientKeyExchange message that
>    contains a "psk_identity" with a length greater zero, it uses the
>    contents as index for its key store (i.e., treat the contents as key
>
> (This is not DTLS 1.3-compatible.)

See side discussion on DTLS versions.

> nits: "greater than", "as an index", "as a key identifier"

done

>    identifier).  The resource server MUST check if it has one or more
>    access tokens that are associated with the specified key.
>
> I don't understand this sentence -- isn't the access token the precise
> contents of the "psk_identity" field, so that there would be a key
> associated with the access token, not the other way around?

Now clarified that the psk_identity must contain the opaque access
token:

OLD:

   Alternatively, the client MAY provide the most recent access
   token in the `psk_identity` field of the ClientKeyExchange
   message. To do so, the client MUST treat the contents of the
   `access_token` field from the AS-to-Client response as opaque data
   and not perform any re-coding.

   Note:
     As stated in Section 4.2 of [RFC7925], the PSK identity should be
     treated as binary data in the Internet of Things space and not
     assumed to have a human-readable form of any sort.

NEW:

   As an alternative to the access token upload, the client can
   provide the most recent access token in the `psk_identity` field of
   the ClientKeyExchange message. To do so, the client MUST treat the
   contents of the `access_token` field from the AS-to-Client response
   as opaque data as specified in Section 4.2 of [RFC7925] and not
   perform any re-coding. This allows the resource server to retrieve
   the shared secret directly from the `cnf` claim of the access
   token.

>    If no key with a matching identifier is found, the resource server
>    MAY process the contents of the "psk_identity" field as access token
>
> Similarly here, the causality feels reversed.

Hopefully, this has been sufficiently clarified by the previous
comment. Moreover, the following change is proposed to emphasize the
aforementioned behavior of RS. The access token now must always be
parsed but may contain a kid for an already known key:

OLD:

   If a resource server receives a ClientKeyExchange message that
   contains a `psk_identity` with a length greater than zero, it uses
   the contents as an index for its key store[...]

   [...] session setup is terminated with an `illegal_parameter` DTLS
   alert message.
   
NEW: 

   If a resource server receives a ClientKeyExchange message that
   contains a `psk_identity` with a length greater than zero, it MUST
   process the contents of the `psk_identity` field as access token
   that is stored with the authorization information endpoint, before
   continuing the DTLS handshake. If the contents of the
   `psk_identity` do not yield a valid access token for the requesting
   client, the resource server aborts the DTLS handshake with an
   `illegal_parameter` alert.

>    continuing the DTLS handshake.  If the contents of the "psk_identity"
>    do not yield a valid access token for the requesting client, the DTLS
>    session setup is terminated with an "illegal_parameter" DTLS alert
>    message.
>
> I think "the RS aborts the DTLS handshake with an 'illegal_parameter' alert"
> would be more conventional phrasing.

done

>    Note2:  According to [RFC7252], CoAP implementations MUST support the
>       ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655].  A client is
>       therefore expected to offer at least this ciphersuite to the
>       resource server.
>
> Do we want to say anything about the (EC)DHE variants?  Short-lived access
> tokens with the AS generating new symmetric keys can provide similar
> forward-secrecy properties to using DHE, but there is in general a trend
> in the IETF towards defaulting to providing forward secrecy in key
> exchanges.

Yes, this makes a lot of sense. We have added the following text to
the Security Considerations to give advice:

NEW:

   The PSK mode of this profile offers a distribution mechanism to
   convey authorization tokens together with a shared secret to a
   client and a server. As this specification aims at constrained
   devices and uses CoAP [RFC7252] as transfer protocol, at least the
   ciphersuite TLS\_PSK\_WITH\_AES\_128\_CCM\_8 {{RFC6655}} should be
   supported. The access tokens and the corresponding shared secrets
   generated by the authorization server are expected to be
   sufficiently short-lived to provide similar forward-secrecy
   properties to using ephemeral Diffie-Hellman (DHE) key exchange
   mechanisms. For longer-lived access tokens, DHE ciphersuites should
   be used.

>    When RS receives an access token, RS MUST check if the access token
>    is still valid, if RS is the intended destination, i.e., the audience
>    of the token, and if the token was issued by an authorized AS.  This
>
> As above, "i.e., the audience of the token" would probably be better
> when offset in parentheses than by commas.

done

>    While the client can retrieve the shared secret from the contents of
>    the "cnf" parameter in the AS-to-Client response, the resource server
>    uses the information contained in the "cnf" claim of the access token
>    to determine the actual secret when no explicit "kid" was provided in
>    the "psk_identity" field.  If key derivation is used, the RS uses the
>    "COSE_KDF_Context" information as described above.
>
> "psk_identity" is a field in ClientKeyExchange, and we say that its
> contents are the raw access token for our usage.  It does not have a
> direct COSE structure for this talk of "kid" to make much sense without
> further explanation.

Yes, this is misleading. We propose the following to clarify the
processing of access tokens (independent whether this has been uploaded
or carried in the psk_identity) on the RS:

OLD:

    While the client can retrieve the shared secret from the contents
    of the `cnf` parameter in the AS-to-Client response, the resource
    server uses the information contained in the `cnf` claim of the
    access token to determine the actual secret when no explicit `kid`
    was provided in the `psk_identity` field. If key derivation is
    used, the RS uses the `COSE_KDF_Context` information as described
    above.

NEW:

    While the client can retrieve the shared secret from the contents
    of the `cnf` parameter in the AS-to-Client response, the resource
    server uses the information contained in the `cnf` claim of the
    access token to determine the actual secret. To retrieve the `cnf`
    claim and determine the shared secret for the session between the
    client and the resource server, the resource server first has to
    decrypt the access token if it is enclosed in a `COSE_Encrypt0`
    structure and then parse the access token.  The parsed access
    token then is associated with the `kid` for the contained shared
    secret, if any.  If key derivation is used, the resource server
    calculates the shared secret from the `COSE_KDF_Context`
    information as described above.

> Section 3.4
>
> We may get some requests for a more explicit definition of what the
> "authorization information" tied to a client is.
>
>    Once a DTLS channel has been established as described in Section 3.2
>    and Section 3.3, respectively, the client is authorized to access
>
> nit: I think "or" is more appropriate to join the sections listed, as
> only one is applicable to a given connection.

done

>    With the successful establishment of the DTLS channel, C and RS have
>    proven that they can use their respective keying material.  An access
>    token that is bound to the client's keying material is associated
>    with the channel.  Any request that the resource server receives on
>    this channel MUST be checked against these authorization rules.  RS
>
> nit: I'd s/these/the following/

done

>    MUST check for every request if the access token is still valid.
>    Incoming CoAP requests that are not authorized with respect to any
>    access token that is associated with the client MUST be rejected by
>    the resource server with 4.01 response as described in Section 5.1.1
>    of [I-D.ietf-ace-oauth-authz].
>
> "any access token" implies there might be more than one, though I seem
> to recall discussion of updated tokens overwriting any previous one, so
> that only one token per client is active at any given time.  What did we
> end up settling on?

done

OLD:

   Any request that the resource server receives on this channel MUST
   be checked against these authorization rules.  RS MUST check for
   every request if the access token is still valid.  Incoming CoAP
   requests that are not authorized with respect to any access token
   that is associated with the client MUST be rejected by the resource
   server with 4.01 response as described in Section 5.1.1 of
   [I-D.ietf-ace-oauth-authz].

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 are supposed to 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.

    Any request that the resource server receives on a DTLS channel
    that is tied to an access token via its keying material MUST be
    checked against the authorization rules that can be determined
    with the access token. The resource server MUST check for every
    request if the access token is still valid. Incoming CoAP requests
    that are not authorized with respect to any access token that is
    associated with the client MUST be rejected by the resource server
    with 4.01 response. The response MAY include AS Request Creation
    Hints as described in Section 5.1.1 of [I-D.ietf-ace-oauth-authz].
 
> Also, the referenced framework Section 5.1.1 does not actually mandate
> the 4.01 response code.

Fixed in the proposed text for the previous comment: We now require the
4.01 and do not imply that this is required by section 5.1.1 of the
framework document which is silent on the proper response codes.

>    The resource server SHOULD treat an incoming CoAP request as
>    authorized if the following holds:
>
> We could say more about this "SHOULD" (or change the way we discuss it)
> -- is it the minimum baseline of checks and additional checks may be
> applied, or do some of them not apply in some cases, or ...?

These are the minimum checks that the RS needs to do. The following
proposal should make this clearer:

OLD:

   The resource server SHOULD treat an incoming CoAP request as
   authorized if the following holds:

NEW:

   The resource server MUST only accept an incoming CoAP request as
   authorized if the following holds:

>    Incoming CoAP requests received on a secure DTLS channel that are not
>    thus authorized MUST be rejected according to Section 5.8.2 of
>    [I-D.ietf-ace-oauth-authz]
>
> We may also get some questions asking about what the difference is
> between the "not authorized with respect to any access token" in the
> previous quoted snippet" and "not thus authorized" in this quoted
> snippet.

We hope that the previous change should have fixed this as well.

>    The client cannot always know a priori if an Authorized Resource
>    Request will succeed.  It MUST check the validity of its keying
>    material before sending a request or processing a response.  If the
>
> What does "check the validity of its keying material" mean?

The following change should make this more clear as the only thing that
the client can do is to check if the keying material is still valid:

OLD:

   The client cannot always know a priori if an Authorized Resource
   Request will succeed.  It MUST check the validity of its keying
   material before sending a request or processing a response.

NEW:

   The client MUST ascertain that its keying material is still valid
   before sending a request or processing a response.


>    client repeatedly gets error responses containing AS Creation Hints
>    (cf.  Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response to its
>    requests, it SHOULD request a new access token from the authorization
>    server in order to continue communication with the resource server.
>
> Why should this only be done in the case of *repeatedly* getting such
> error responses; I thought the idea of the AS Request Creation Hints was
> to take immediate effect.

Correct. The intention was to deal with the race condition for the
upload mechanism. But as this affects different communication channels,
it is safe to just remove the word "repeatedly":

OLD:

   client repeatedly gets error responses containing AS Creation Hints

NEW:

   client gets an error response containing AS Request Creation Hints

> (Also, nit: s/AS Creation Hints/AS Request Creation Hints/.)

done

> Section 4
>
>    The client can update the authorization information stored at the
>    resource server at any time without changing an established DTLS
>    session.  To do so, the Client requests a new access token from the
>    authorization server for the intended action on the respective
>    resource and uploads this access token to the authz-info resource on
>    the resource server.
>
> I suggest adding another sentence similar to "Because ACE tokens are
> proof-of-possession tokens, the updated authorization information only
> takes immediate effect if such proof has already been provided, e.g., if
> the PoP key associated with the new token is the same as the one
> currently in use."  This is further detailed in the following
> paragraphs, but not stated concretely as a key principle.

The term "ACE tokens" may be a bit misleading. In this profile, we
always use PoP tokens. Our proposal is to move the note from the end
upwards:

OLD:

    The client can update...

NEW:

    Resource servers must only use a new access token to update the
    authorization information for a DTLS session if the keying
    material that is bound to the token is the same that was used in
    the DTLS handshake. By associating the access tokens with the
    identifier of an existing DTLS session, the authorization
    information can be updated without changing the cryptographic keys
    for the DTLS communication between the client and the resource
    server, i.e. an existing session can be used with updated
    permissions.

    The client can therefore update...

> Section 5
>
>    DTLS sessions that have been established in accordance with this
>    profile are always tied to a specific access token.  As this token
>
> Doesn't the dynamic authorization update mechanism allow that token to
> be swapped out during the lifetime of the connection?
> Also, as a terminology point, I think "DTLS association" is more
> appropriate than "DTLS session" for what we describe, since the token is
> is tied to the client and consulted at the start of the handshake, as
> opposed to being a property of the DTLS session and carried across
> resumptions.

We propose the following text as a clarification. This also takes
into account the "session" vs. "association" part which looks a bit
weird. If we come to the conclusion that this is a better term, we
would have to revise the rest of the document accordingly:

OLD:

    DTLS sessions that have been established in accordance with this
    profile are always tied to a specific access token. As this token
    may become invalid at any time (e.g. because it has expired), the
    session may become useless at some point. A resource server
    therefore MUST terminate existing DTLS sessions after the access
    token for this session has been deleted.

NEW:

    The resource server MUST delete access tokens that are no longer
    valid.  DTLS associations that have been setup in accordance with
    this profile are always tied to specific tokens (which may be
    exchanged with a dynamic update as described in Section 4). As
    tokens may become invalid at any time (e.g. because they have
    expired), the association may become useless at some point.  A
    resource server therefore MUST terminate existing DTLS association
    after the last access token associated with this association has
    expired.

>    may become invalid at any time (e.g. because it has expired), the
>    session may become useless at some point.  A resource server
>    therefore MUST terminate existing DTLS sessions after the access
>    token for this session has been deleted.
>
> I assume that using "been deleted" vs. "has expired" is a deliberate
> choice?  If we don't say anything else about when to delete tokens, it
> doesn't post much of a requirement, though.

Good point. This is missing in Section 3.4. We now have added an
explicit requirement to remove expired (or otherwise invalid) access
tokens:

OLD:

    The resource server MUST check for every request if the access
    token is still valid.

NEW:

    The resource server MUST check for every request if the access
    token is still valid.  If the token has expired, the resource
    server MUST remove it.

> Section 6
>
>    endpoint.  The use of CoAP and DTLS for this communication is
>    RECOMMENDED in this profile, other protocols (such as HTTP and TLS or
>    CoAP and OSCORE) MAY be used instead.
>
> nit: comma splice

done

> Also, we could potentially refer to the OSCORE profile document here
> (informatively).

done

>    If other means of securing the communication with the AS are used,
>    the security protocol MUST fulfill the communication security
>    requirements in Section 6.2 of [I-D.ietf-ace-oauth-authz].
>
> I suggest phrasing more like "the communication security requirements
> from Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable", since
> there's no need to add another MUST to the ones already in the framework
> document.

Done, although "remain applicable" seems a bit weak.

> Section 7
>
> I have a few suggestions for potential additions to this section as well
> as comments on the existing contents.
>
> We might consider adding a brief note about the use of 8-byte
> authentication tags in DTLS ciphers and how that affects the risk
> profile.

Done. New text has been added as follows.

NEW:

  As this specification targets at constrained environments, message
  payloads exchanged between the client and the resource server are
  expected to be small and rare.  CoAP {{RFC7252}} mandates the
  implementation of cipher suites with abbreviated, 8-byte tags for
  message integrity protection. For consistency, this profile requires
  implementation of the same cipher suites. For application scenarios
  where the cost of full-width authentication tags is low compared to
  the overall amount of data being transmitted, the use of cipher
  suites with 16-byte integrity protection tags is preferred.

> The use of "live" authorization upgrades on an existing DTLS connection
> by posting a new token to the authz-info endpoint does not provide much
> guarantee about the order in which operations occur (and thus which
> authorization info is used to process a given client request),
> especially in the face of an attacker that can delay and reorder
> packets.  This does not necessarily mean that we should not bother to
> define that mechanism, but we should point out that there is only a weak
> ordering property provided, note that other mechanisms should be used
> when strict serialization is important, and caution that when the
> later-issued token contains a reduction in authorization from the
> initial token, it is impossible to guarantee that the reduction in
> authorization will take effect prior to the expiration of the original
> token.

Exactly! To address this, the following text has been added to the
Security Considerations:

NEW:

    Even when a single access token per client is used, an attacker
    could compromise the dynamic update mechanism for existing DTLS
    connections by delaying or reordering packets destined for the
    authz-info endpoint. Thus, the order in which operations occur at
    the resource server (and thus which authorization info is used to
    process a given client request) cannot be guaranteed.  Especially
    in the presence of later-issued access tokens that reduce the
    client's permissions from the initial access token, it is
    impossible to guarantee that the reduction in authorization will
    take effect prior to the expiration of the original token.

> We rely heavily on the AS to accurately provide binding of raw key
> material to authorization information and endpoint identinty; I think
> this is a stronger reliance than just that implied by the core
> architecture, and so might merit a mention here.  (This relates to all
> the checks about "MUST check that [client/...] is associated with
> [RPK/PSK]" that appear throughout the document.)

We are not sure if this is specific to this profile. For any profile
within the ACE framework, the AS must know C and RS and must know their
keys. In this profile, we just describe what the AS needs to do to
address these requirements.

> I'd also suggest reiterating all the places where we rely on out-of-band
> configuration, as there's always a risk of such configuration becoming
> stale (or getting attacked directly).

Most parts of the document already now do this. We have added an
additional remark in Section 3.1 to ensure that the client checks that
the authorization information about the AS is still valid.
We have also added a new subsection to the Security Considerations that
describes the configuration and authorization information that must
be provided to the authorization server, the resource server, and the
client outside of the ACE DTLS profile.

NEW:

    7.1 Out-of-Band Configuration

    To communicate securely, the authorization server, the client and
    the resource server require certain information that must be
    exchanged outside the protocol flow described in this
    document. The authorization server must have obtained
    authorization information concerning the client and the resource
    server that is approved by the resource owner as well as
    corresponding keying material. The resource server must have
    received authorization information approved by the resource owner
    concerning its authorization managers and the respective keying
    material. The client must have obtained authorization information
    concerning the authorization server approved by its owner as well
    as the corresponding keying material. Also, the client's owner
    must have approved of the client's communication with the resource
    server. The client and the authorization server must have obtained
    a common understanding how this resource server is identified to
    ensure that the client obtains access token and keying material
    for the correct resource server. If the client is provided with a
    raw public key for the resource server, it must be ascertained to
    which resource server (which identifier and authorization
    information) the key is associated.  All authorization information
    and keying material must be kept up to date.

> I'd consider reiterating that when the KDF scheme is in use between RS
> and AS, that kid uniqueness is paramount, as using the same kid for
> multiple clients and the same RS would have potentially disasterous
> consequences in that case.

Not sure if this is specific to the key generation through KDF, as the
kid is typically used to find the access token that was uploaded to the
auth-info endpoint?

> Similarly (though this is inherent to symmetric PoP and may not actually
> need reiterating), when we use symmetric PSKs for PoP, they lose almost
> all value if any given PSK is known to more than one client or RS.  (The
> secdir review on the framework has us putting in MUST-level requirements
> to not share further than that, so it seems pretty reasonable to not
> duplicate that warning here.)

Okay. This was one of things that we deemed obvious…

>    This document specifies a profile for the Authentication and
>    Authorization for Constrained Environments (ACE) framework
>    [I-D.ietf-ace-oauth-authz].  As it follows this framework's general
>    approach, the general security considerations from section 6 also
>    apply to this profile.
>
> (The HTMLized link will only do the right thing if you use the redundant
> "section 6 of [I-D.ietf-ace-oauth-authz]".)

done

>    The use of multiple access tokens for a single client increases the
>    strain on the resource server as it must consider every access token
>    and calculate the actual permissions of the client.  Also, tokens may
>    contradict each other which may lead the server to enforce wrong
>    permissions.  If one of the access tokens expires earlier than
>    others, the resulting permissions may offer insufficient protection.
>    Developers SHOULD avoid using multiple access tokens for a client.
>
> I think I touched on this above; did we want to make a stronger
> statement about "only one active token per client"?

At the time this was written, the framework document was pretty unclear
about this. Now, it would be possible to have multiple access tokens for
a client if you knew how to merge the authorization rules.  We have
changed the update mechanism to clearly state that a new token replaces
the old one. The question is if we still need this paragraph.

> Section 8
>
>    information as possible in an unencrypted response.  When a DTLS
>    session between the client and the resource server already exists,
>    more detailed information MAY be included with an error response to
>    provide the client with sufficient information to react on that
>    particular error.
>
> I'd suggest adding a caveat like "an authenticated client" or
> "a known client", since DTLS itself does not guarantee that the client
> is not an attacker.

done

> Section 9
>
>    Profile ID: 1
>
> I think this has to be merely a "suggested value", as IANA will control
> the actual allocations, in the absence of a reservation of this value in
> the framework document.

done

> Section 10.1
>
> We don't currently reference RFC 7925 in any way that would require it
> to be a normative reference.  We probably should, though -- somehow pull
> in that we require/recommend conformance with that profile of DTLS.

We are not sure if there is anything special about RFC 7925 that we
explicitly want to point out. However, as we have the requirement of
treating the access token in the psk_identity as opaque binary data, we
have moved the reference RFC 7925 into the normative section.

> Section 10.2
>
> I think RFCs 7250, 7251, and 8422 need to be normative.

done


Grüße
Olaf