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

[Olaf Bergmann <[e-mail]>]

Hi Ben,

Benjamin Kaduk <[e-mail]> writes:

> Please go ahead and upload a new version to the datatracker when you get a
> chance; I do have some further comments below.

Thanks again for the detailed response. I have just submitted version
-10 that includes changes to your previous comments as well as the
suggestions below:

> On Tue, Apr 14, 2020 at 06:20:38PM +0200, Olaf Bergmann wrote:
>> 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 <[e-mail]> 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.
>
> I think we need to give some guidance about what the semantics are if/when
> it happens.  My inclination would be to say that DTLS resumption can be
> used to amortize the cost of a handshake, but DTLS 1.2 resumption does not
> provide forward secrecy and also does not provide an opportunity for the
> client to prove possession of the PoP key, so servers will want to
> periodically force a full handshake according to their authentication
> requirements.  I'd also be inclined to forbid renegotiation entirely.

True, especially because RFC 7925 requires resumption to be
implemented. The security considerations now advise against session
resumptions and renegotiation as you have suggested. The Security
Considerations section now has been structured in sub-sections for
clarity.

>> > 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.
>
> I don't think we strictly need to, no.
>
>> > - 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.
>
> It looks like we now say the client "MUST include an access token that
> indicates the kid contained in the uploaded access token as psk_identity",
> which seems to be talking about two different access tokens.  Is one of
> them uploaded to authz-info and the other used to populate the
> "psk_identity" field?  The following sentences seem to imply that, but the
> quoted sentence is hard to parse.  Perhaps just "The client then needs to
> indicate during the DTLS handshake which previously uploaded access token
> it intends to use."  That proposed text drops the "MUST", so maybe we would
> want to put that back in the later sentence(s).

Agreed. The text now reads:

OLD:

  The client then MUST include an access token that indicates the
  `kid` contained in the uploaded access token as `psk_identity`.
  To do so, it creates…

NEW:

  The client then needs to indicate during the DTLS handshake which
  previously uploaded access token it intends to use.  To do so, it
  MUST create…

>> > - 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.
>
> It looks like this will be enough to meet the requirements from the
> framework (though I'm not looking at an actual diff so I'm not 100% sure).
>
>> > 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.
>
> Good catch, thanks!
>
>> > % 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}}.
>
> This looks good.
>
>> > 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.
>
> Okay.
>
>> >    [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}}
>
> Thanks!
>
>> > 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.
>
> Thanks!
>
>> >    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.
>
> That seems like it's going in the right direction, but I'm not sure it's
> the precise change we want.  Basically, we need to keep the requirement
> that the client prove possession of the key, and we want the recommended
> way to be to use it for DTLS with the AS, but we can't require that the
> client use DTLS to talk to the AS, because we "MUST NOT depend on the
> assumption that the profile is used for all the different types of
> interactions".  So perhaps
>
> NEWNEW:
>
> % previously made known to the authorization server. It is RECOMMENDED that
> % C use DTLS with the same keying material to secure the communication with
> % AS, proving possession of the key as part of the token request, but other
> % mechanisms for proving possession of the key may be defined in the
> % future.

Done.

>> 
>> >    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
>
> I think this sentence could probably be wordsmithed some more, though I
> don't have a concrete proposal at the moment.  It does seem like we might
> want to discuss this scenario more in terms of "identity misbinding" than
> "relay tokens", though.  (We had a SAAG talk at IETF 104 about misbinding
> attacks on device pairing, which is not quite the same, but shares some of
> the concepts.)

Okay. This is the only comment I did not yet address in the text. We
might want to keep this in mind for -11.

>>     therefore should at some point validate that the client can
>>     actually use the private key corresponding to the client's public
>>     key.
>
> Why is this only "should", vs. (e.g.) "needs to"?

I am perfectly happy with the stronger "needs to" and changed the text
accordingly.

>
>> 
>> > 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
>
> This sounds like "the information[...]" is part of the access token; maybe
> "along with"?

What is meant here is that the information is contained in the access
token. The misleading part is that the AT contains information about the
client's RPK that the resource server uses to recognize the client in
the subsequent communication.

I have changed this sentence to:

NEW:

  The response also contains an access token with information for the
  resource server about the client's public key.


>>    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.
>
> Thanks!
>
>> > 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.
>
> Thanks; I think that text strikes a good balance.
>
>> >    [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.
>
> I think that will work; thanks.
>
>> >    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.
>
> Okay, thanks.
>
>> >    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.
>
> Thank you!
>
>> > (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.
>
> Ah, looks good :)
>
>> >    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.
>
> The formatting/discussion looks good, but I'll need to cross-check the data
> structures once the new revision is uploaded.
>
>> > 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:
>
> I think I confused myself with the previous diff, but your description here
> and the text in the editor's copy seem to make sense, so I'm willing to say
> that I got confused earlier and move on.
>
>> 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.
>
> Nicely said!
>
>> >    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].
>
> I think this is good; it repeats the hints from the core framework that
> getting things right with multiple active tokens is hard, but doesn't
> strictly forbid it.
>
>> > 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:
>
> That's good.  I didn't think very hard about whether adding a brief note
> after the list along the lines of "additional checks may be applied
> according to local policy" would add value; it may well go without saying.
>
>> >    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.
>
> That seems likely :)
>
>> >    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.
>
> This looks like it will work; I can handle the lack of my preferred
> phrasing about the "proof has already been provided" :)
>
>>     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.
>
> This looks good (modulo the nit: comma after "e.g.").

Fixed, thanks!

>> >    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.
>
> Ah, thanks.
>
>> > 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.
>
> Okay.
>
>> > 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
>
> (Do we use the phrase "authorization manager" elsewhere?)
>
>>     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?
>
> I think it is specific to key generation through KDF, but let me try to
> walk through it.
>
> Up in Section 3.3 we talk about a case where the AS and RS are assumed to
> share a key derivation key that's used to derive symmetric keys for the RS
> to share with the client.  The KDF input is the IKM and the 'info' (since
> 'salt' is empty), and the IKM is just that same "key derivation key".  So
> the only input to HKDF that changes for different clients (and the same RS)
> is the 'info'.  The 'info', in turn contains a string constant 'type' plus
> the 'kid' and (presumably fixed) output length.  If I'm reading this
> correctly, the 'kid' is the only HKDF input that varies between clients, so
> if the 'kid' was reused for different clients, the AS and RS would derive
> the same symmetric key for those distinct client/RS pairs.  Furthermore,
> since the AS returns the actual symmetric key to the client in the token
> response, that means that the symmetric key is shared by *three* parties
> (vs. just client and RS, ignoring in the count the AS which knows
> everything).  I guess technically this is not the scenario forbidden by the
> core framework (which is to have the same symmetric key used at multiple
> RSes, but it still is bad hygeine and would let one client impersonate the
> other.
>
> In cases not using the KDF, the 'kid' is just a hint to finding the actual
> key, and the actual key is assumed to be constructed uniquely by the AS
> each time.

Thank you, this is absolutely true. I have now changed the input for the
key derivation mechanism in the sense of what originally has been
specified in draft-gerdes-ace-dcaf-authorize, i.e., including the access
token as input to the KDF. This enables the authorization server to
include a certain amount of unifying attributes in the info parameter,
esp. with a randomly generated kid and the iat claim. I would have loved
to have a claim type for carrying a nonce in the access token…

>> > 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
>
> Though I guess we're on v3 XML now (yay! very pretty!), which hopefully
> does not have the same artificial limitations.
>
>> >    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.
>
> I think the discussion is still valid and the only thing I'm not sure about
> is whether the last sentence is needed.

As there is no guidance so far on how permission sets in access tokens
are to be combined properly it seems to be wise at least to advise
against.

>> > 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.
>
> Okay, thanks.
>
>> > Section 10.2
>> >
>> > I think RFCs 7250, 7251, and 8422 need to be normative.
>> 
>> done

Actually, I had to revert this for the informational RFC 7251 as the
idnits tool did not allow the downref from normative.

Grüße
Olaf