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

[Jim Schaad <[e-mail]>]

-----Original Message-----
From: Benjamin Kaduk <[e-mail]> 
Sent: Thursday, January 2, 2020 3:40 PM
To: [e-mail]
Cc: [e-mail]
Subject: AD review of draft-ietf-ace-dtls-authorize-09

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.

[JLS] Yes we need to look at this, but we also know who's fault this is 😉  Part of me wants to punt this off to the CoRE working group because the way they are currently using DTLS 1.2 is quite restrictive and they really need to do a DTLS 1.3 document.

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?

[JLS] I am having a problem seeing what the conflict is here.  The "kid" is a publicly known value so that fact that it is included in the KDF is not what is going to produce unique keys for all clients no matter what.  It is the secret that is going to make things unique.  There is a potential problem with the fact that the RS may get two different entities that register a token which has the same kid value, but that is a known issue for (D)TLS.  This is one of the reasons that the token itself can be used as the "kid" for DTLS.

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.

[JLS] I am missing where it is saying this.   Can you give a pointer?  I don't believe that the POP of the RPK is required at the time that the token is obtained.

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.

[JLS] I think this makes sense.

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.

[JLS] I don't see any reason to talk about renegotiation, either it is done or it isn't and a new connection would need to be created.  I am not sure what to say about session resumption.   This is something that really needs to be dealt with in the CoRE working group before anything can be said here.  Session resumption would only resume the TLS session, but any CoRE state above it is not going to be restored because it is defined as going away in RFC 7252.  This is currently also true for doing a renegotiation.

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
- require that DTLS be used in a mode that provides replay protection
- 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.)
- whether/how introspection is used?
- give more details of what this profile mandates when used for
  client/AS interactions (as mentioned above)
- 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

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

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

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

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

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

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

   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?

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

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.

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.

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.

   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.

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

   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.

   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?
also, nit: "The AS".

   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?)
nit: "The AS" again (and throughought, to a large extent).

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

   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.

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.

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.

   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.

   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.

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

   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.

   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?

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

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

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

   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.
(Also, this "MUST" seems like something that the framework should guarantee and not a new requirement that the DTLS profile imposes.)

         Figure 5: Example Access Token Request, symmetric PoP-key

Maybe we could include "(implicit)" in the caption, since symmetric PoP key is the default.

   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.

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

         token_type : pop,

Didn't we switch this to being capitalized as "PoP"?

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

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

       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.

   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.

   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"?

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

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

   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.)
nits: "greater than", "as an index", "as a key identifier"

   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?

   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.

   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.

   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.

   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.

   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.

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.

   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/

   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?

Also, the referenced framework Section 5.1.1 does not actually mandate the 4.01 response code.

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

   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.

   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?

   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.
(Also, nit: s/AS Creation Hints/AS Request Creation Hints/.)

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.

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.

   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.

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
Also, we could potentially refer to the OSCORE profile document here (informatively).

   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.

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.

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.

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

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

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.

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

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

   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"?

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.

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.

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.

Section 10.2

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

Thanks,

Ben