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

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 2 Jan 2020 15:40:20 -0800

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.

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.

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

---

From: Jim Schaad <[email-masked]>
Date: Fri, 3 Jan 2020 20:36:54 -0800

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

Hi all,

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:

Section 1

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

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

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

(This "MUST" is already a requirement from the core framework, so we don't necessarily need to repeat it as normative language.)

Section 5.3 of oauth-authz says that registration is "out of scope"; is this still the right reference?

Section 3

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

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.

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

This seems in conflict with the core framework's requirement that the client/AS profile and client/RS profile are severable.

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

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

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

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

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.

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.

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.

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.

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.

Is talking about """the access token's "cnf" parameter" consistent with allowing the use of non-CWT (non-JWT) token formats?

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

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

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

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

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,

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

       4.00 Bad Request

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.

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.

(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

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?

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.

As above, "i.e., the audience of the token" would probably be better when offset in parentheses than by commas.

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

nit: I think "or" is more appropriate to join the sections listed, as only one is applicable to a given connection.

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

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

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.

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

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

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.

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

nit: comma splice
Also, we could potentially refer to the OSCORE profile document here (informatively).

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

(The HTMLized link will only do the right thing if you use the redundant "section 6 of [I-D.ietf-ace-oauth-authz]".)

I think I touched on this above; did we want to make a stronger statement about "only one active token per client"?

Section 8

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

Thanks,

Ben

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 06 Jan 2020 11:02:55 +0100

Jim,

Jim Schaad <[email-masked]> writes:

[Ben's review]
> [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.

The problem is that AS must bind the Access Token to the RPK that the
Client has presented, and the Client must use the very same RPK to
establish the DTLS channel with RS. Otherwise, RS cannot be sure that AS
has issued the Token to the same entity that is currently communicating
with RS.

Grüße
Olaf

---

From: Jim Schaad <[email-masked]>
Date: Mon, 6 Jan 2020 10:12:05 -0800

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Olaf Bergmann
Sent: Monday, January 6, 2020 2:03 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; 'Benjamin Kaduk' <[email-masked]>; [email-masked]
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

Jim,

[Ben's review]
> [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.

The problem is that AS must bind the Access Token to the RPK that the Client has presented, and the Client must use the very same RPK to establish the DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued the Token to the same entity that is currently communicating with RS.

[JLS]  What if I do the following sequence of events:
1.  The AS is configured with RPK1 for the client and the client is configured with RPK2 for the AS.
2.  The client and the AS run some type of POP algorithm, not currently specified, to configure RPK3 into the AS for a second RPK to work with some set of audiences (AUD1).
3.  The client then uses RPK1 to authenticate to the AS and asks for a new token for AUD1 and provides (explicitly or implicitly RPK3).  The AS knows that it is tied to the client due to what happened in step 2.  The AS then creates a new token for AUD1 which contains RPK3 for the client (and RPK4 for the RS) and returns it.

The AS does a current POP for RPK1 when the token is being asked for.
The AS did a POP for RPK3 when it was placed into the system.
The AS has not done a POP for RPK4 - that was simply configured without that step ever being done.  The ACE framework has no ability for the AS to do the POP on RPK4 and ensure that it current.  The client would do a POP when the TLS session is created but has to rely on the AS that it is for the correct RS.

Note that the client can never generate a brand new RPK9 and send it to the AS in the token request because the AS will never have seen this before and would need to run the POP algorithm of step 2 in order to assure that it is bound to the correct client and not pulled out of thin air.  RPK9 could not be used to authenticate the token request because the AS has no idea what client it is tied to.

Jim

Jim

Grüße
Olaf

_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Olaf Bergmann <[email-masked]>
Date: Thu, 09 Jan 2020 12:32:40 +0100

Hi Jim,

Jim Schaad <[email-masked]> writes:

> Cc: [email-masked]; 'Benjamin Kaduk' <[email-masked]>;
> [email-masked]

okay, I see you have a valid point here. I will try to come up with some
text that says that the AS must ensure that (in your scenario) RPK1 and
RPK3 are bound to the same entity.

Grüße
Olaf

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 9 Jan 2020 12:17:00 -0800

> RPK3 are bound to the same entity.

Jim's proposal seems broadly reasonable (though I think in general there
needs to be some AS contributory nature in order to get proof of current
possession of RPK3 at the time of (2).  I think I would phrase it as "in
possession of the same entity" rather than "bound to the same entity",
though.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 9 Jan 2020 12:27:10 -0800

> [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 res…

I hadn't realized that the CoRE usage of DTLS was so restrictive; in that
case we may have to wait for them, yes.

> [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 cl…

I think I'm just thinking about what you note as the "potential problem"
where an RS receives two tokens with the same kid value but that are for
different clients.  For asymmetric PoP we require POST to authz-info, and
since "POST a new token with the same kid" is the way we update permissions
without changing DTLS keys, the RS needs to know to scope its
lookup/storage based on (client,kid) (or more?) and not just 'kid'.  Maybe
this is obvious, but I wasn't sure.

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

[Olaf got this; thanks Olaf!]

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

We could just have a single-sentence note that "DTLS session resumption is
an option to amortize RPK asymmetric crypto handshake costs, but CoRE state
will be reinitialized in such case (Section X of [RFC 7252])".  Or am I
misunderstanding?

-Ben

---

From: Jim Schaad <[email-masked]>
Date: Thu, 9 Jan 2020 12:52:56 -0800

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Thursday, January 9, 2020 12:17 PM
To: Olaf Bergmann <[email-masked]>
Cc: Jim Schaad <[email-masked]>; [email-masked];

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.
> > The problem is that AS must bind the Access Token to the RPK that the
Client has presented, and the Client must use the very same RPK to establish
the DTLS channel with RS. Otherwise, RS cannot be sure that AS has issued
the Token to the same entity that is currently communicating with RS.
> > 2.  The client and the AS run some type of POP algorithm, not currently
specified, to configure RPK3 into the AS for a second RPK to work with some
set of audiences (AUD1).
> > 3.  The client then uses RPK1 to authenticate to the AS and asks for a
new token for AUD1 and provides (explicitly or implicitly RPK3).  The AS
knows that it is tied to the client due to what happened in step 2.  The AS
then creates a new token for AUD1 which contains RPK3 for the client (and
RPK4 for the RS) and returns it.
> > The AS has not done a POP for RPK4 - that was simply configured without
that step ever being done.  The ACE framework has no ability for the AS to
do the POP on RPK4 and ensure that it current.  The client would do a POP
when the TLS session is created but has to rely on the AS that it is for the
correct RS.
> >
> > Note that the client can never generate a brand new RPK9 and send it to
the AS in the token request because the AS will never have seen this before
and would need to run the POP algorithm of step 2 in order to assure that it
is bound to the correct client and not pulled out of thin air.  RPK9 could
not be used to authenticate the token request because the AS has no idea
what client it is tied to.
> 
> okay, I see you have a valid point here. I will try to come up with 
> some text that says that the AS must ensure that (in your scenario) 
> RPK1 and

[JLS] If I was to write this out as a real protocol, it would end up
something along the lines of  Sign(RPK1, Sign(RPK3,  RPK1 || RPK3 || AS
Nonce || Client Nonce ))  so that we know that both keys are in the
possession of a single entity (or a cabal collaborating) and it is current
to the run of the POP protocol.

Jim

-Ben

---

From: Jim Schaad <[email-masked]>
Date: Thu, 9 Jan 2020 13:18:55 -0800

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Thursday, January 9, 2020 12:27 PM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: AD review of draft-ietf-ace-dtls-authorize-09

> [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 res…

I hadn't realized that the CoRE usage of DTLS was so restrictive; in that case we may have to wait for them, yes.

[JLS] Yeah, I really ought to start writing this document.   The first time I read the DTLS section and realized that when a re-key operation occurred that all of the current state on the server is to be cleared as if a new session had just been negotiated I just about went crazy.  They were worried about the security implications on the key roll over which made no sense to me, but then I am much more versed in TLS than they were.

I think I'm just thinking about what you note as the "potential problem"
where an RS receives two tokens with the same kid value but that are for different clients.  For asymmetric PoP we require POST to authz-info, and since "POST a new token with the same kid" is the way we update permissions without changing DTLS keys, the RS needs to know to scope its lookup/storage based on (client,kid) (or more?) and not just 'kid'.  Maybe this is obvious, but I wasn't sure.

[JLS] No, "POST a new token with the same KEY" is the way that we update permissions without changing the DTLS keys.  For RPK this is easy.  For symmetric keys this is a harder sell and you really need to add some additional checks to make it something along the lines of same <Key, AS>.  There may not be a key id if one is using the token as the user identifier when doing the DTLS protocol so matching on kid would seem to be difficult there.  What I was referring to as the potential problem is that if client 1 posts a token with a symmetric key and KID1 and uses KID1 as the user name things are fine.  Now if client 2 posts a token with a different symmetric key and KID1.  Client 2 can use KID1 as the user name to connect to the server but if client 1 attempts to connect with KID1 as the user name it will fail doing the connection.  This is a (D)TLS issue as you cannot do  a "retry" easily in TLS 1.2.  (Ding, ding, ding, ding.   Jim just realizes that TLS 1.3 might have solved this problem with the PSK binder and should do research to find out if this is true.)

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

We could just have a single-sentence note that "DTLS session resumption is an option to amortize RPK asymmetric crypto handshake costs, but CoRE state will be reinitialized in such case (Section X of [RFC 7252])".  Or am I misunderstanding?

[JLS] I think that this should be in the CoRE document.  If they change their minds about this then the sentence would become out of date.
jim

-Ben

> 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.)
> 
> (The HTMLized link will only do the right thing if you use the 
> redundant "section 6 of [I-D.ietf-ace-oauth-authz]".)
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 9 Jan 2020 13:21:43 -0800

> to the run of the POP protocol.

With a fixed protocol/context string to indicate the intent of what's being
signed, of course :)

I am too distracted to do a proper analysis right now but seem to recall
that usually an indication of "both parties/keys agree to <X>" involves
three signatures, so that each party certifies the signature of the other
over the operation (in addition to the operation itself).

-Ben

---

From: Jim Schaad <[email-masked]>
Date: Thu, 9 Jan 2020 13:43:11 -0800

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Thursday, January 9, 2020 1:22 PM
To: Jim Schaad <[email-masked]>
Cc: 'Olaf Bergmann' <[email-masked]>;
[email-masked]; [email-masked]
Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09

On Thu, Jan 09, 2020 at 12:52:56PM -0800, Jim Schaad wrote:
> 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.
> > >>
> I don't believe that the POP of the RPK is required at the time that 
> the token is obtained.
> > >
> establish the DTLS channel with RS. Otherwise, RS cannot be sure that 
> AS has issued the Token to the same entity that is currently communicating
with RS.
> > > 1.  The AS is configured with RPK1 for the client and the client 
> > > is
> configured with RPK2 for the AS.
> specified, to configure RPK3 into the AS for a second RPK to work with 
> some set of audiences (AUD1).
> new token for AUD1 and provides (explicitly or implicitly RPK3).  The 
> AS knows that it is tied to the client due to what happened in step 2.  
> The AS then creates a new token for AUD1 which contains RPK3 for the 
> client (and
> that step ever being done.  The ACE framework has no ability for the 
> AS to do the POP on RPK4 and ensure that it current.  The client would 
> do a POP when the TLS session is created but has to rely on the AS 
> that it is for the correct RS.
> > >
> the AS in the token request because the AS will never have seen this 
> before and would need to run the POP algorithm of step 2 in order to 
> assure that it is bound to the correct client and not pulled out of 
> thin air.  RPK9 could not be used to authenticate the token request 
> because the AS has no idea what client it is tied to.
> > 
> Jim's proposal seems broadly reasonable (though I think in general 
> there needs to be some AS contributory nature in order to get proof of 
> current possession of RPK3 at the time of (2).  I think I would phrase 
> it as "in possession of the same entity" rather than "bound to the 
> same entity", though.
> 
> something along the lines of  Sign(RPK1, Sign(RPK3,  RPK1 || RPK3 || 
> AS Nonce || Client Nonce ))  so that we know that both keys are in the 
> possession of a single entity (or a cabal collaborating) and it is 
> current to the run of the POP protocol.

[JLS] Yea I think you are right - I would need to go read CMC and make sure
that I got everything right as I spent about 2 years doing the analysis
there

-Ben