-----Original Message-----
From: Benjamin Kaduk <[email protected]>
Sent: Thursday, January 2, 2020 3:40 PM
To: [email protected]
Cc: [email protected]
Subject: AD review of draft-ietf-ace-dtls-authorize-09
Hi all,
Some high-level remarks before delving into the section-by-section
comments:
This document is pretty clearly DTLS 1.2-specific -- it talks about particular
protocol messages, message fields, and cipher suites that simply do not apply
to DTLS 1.3. In order to use this profile with DTLS 1.3, we'd need to specify
the analogous behavior/requirements to these (including standalone signature
schemes and key-exchange groups, which are now both separately negotiated from
the cipher suite).
Given that DTLS 1.3 is past WGLC and only a few documents behind this one in my
review queue, it seems fairly prudent to spend some time and cover how DTLS 1.3
would work here, since otherwise this document will become stale shortly after
(or even before!) its publication as an RFC.
[JLS] Yes we need to look at this, but we also know who's fault this is 😉 Part
of me wants to punt this off to the CoRE working group because the way they are
currently using DTLS 1.2 is quite restrictive and they really need to do a DTLS
1.3 document.
There's probably some additional discussion to include about the usage of key
identifiers in this document versus the potential uses described in the core
framework. Specifically, the framework reminds us that "no assumptions should
be made that it is unique in the domains of either the client or the RS" yet
this document is using the kid as input to a KDF that produces keys that must
be unique across all clients, and allowing live/instant authorization updates
based on matching "kid".
How shall we resolve this apparent conflict?
[JLS] I am having a problem seeing what the conflict is here. The "kid" is a
publicly known value so that fact that it is included in the KDF is not what is
going to produce unique keys for all clients no matter what. It is the secret
that is going to make things unique. There is a potential problem with the
fact that the RS may get two different entities that register a token which has
the same kid value, but that is a known issue for (D)TLS. This is one of the
reasons that the token itself can be used as the "kid" for DTLS.
We also are potentially in violation of the framework's requirements with
respect to the independent selection of profiles for client/AS and client/RS
interactions -- at present, when DTLS+RPK is used for client/RS, we require
that DTLS+RPK is also used for client/AS, in order to prove possession of the
key. We could perhaps weasel our way out by saying that the framework's
requirement applies at the profile granularity, and with symmetric PSK we can
be fully independent, but we still need to say something about this property
and the interaction with the framework's requirements.
[JLS] I am missing where it is saying this. Can you give a pointer? I don't
believe that the POP of the RPK is required at the time that the token is
obtained.
This profile is mostly applicable to the client/RS communications and feels
like it only provides some of the picture for use with client/AS interactions.
(It doesn't really say much of anything about RS/AS
interactions.) The introductory discussion does not do a great job of painting
that picture, and I'd like to see it more clearly introduced that the bulk of
our coverage is for the client/RS interaction. We also lean heavily on the
existing out-of-band configuration and key material shared between client and
AS to secure the client/AS communications; we could probably tighten up the
discussion about exactly what parameters of client/AS communication are
specified by this profile.
[JLS] I think this makes sense.
We do not say anything about DTLS session resumption (or renegotiation, though
not talking about that one is perfectly fine); that's a fairly core DTLS
concept that we should give some guidance on.
[JLS] I don't see any reason to talk about renegotiation, either it is done or
it isn't and a new connection would need to be created. I am not sure what to
say about session resumption. This is something that really needs to be dealt
with in the CoRE working group before anything can be said here. Session
resumption would only resume the TLS session, but any CoRE state above it is
not going to be restored because it is defined as going away in RFC 7252. This
is currently also true for doing a renegotiation.
Looking through Appendix C ("Requirements on Profiles") of the framework, do we
want to say anything about:
- using the client credentials grant with this profile, as that's IIRC
the only example we show
- require that DTLS be used in a mode that provides replay protection
- when the client uses the authz-info endpoint instead of the
"psk_identity" field to convey the token to the RS, how does the RS
know which client is connecting (and thus what PSK to use), and what
does the client actually *put* in the "psk_identity" field? (The
other aspects of "how to select a proof-of-possession protocol" seem
to fall out naturally from the DTLS usage.)
- whether/how introspection is used?
- give more details of what this profile mandates when used for
client/AS interactions (as mentioned above)
- explicitly state that the authz-info endpoint is unprotected (or that
it might be protected if, e.g., the RS has a trustable certificate
that would be used instead of RPK or PSK, or by supplying the
token as the "psk_identity" when symmetric PoP is used, or by only
doing server-authentication with RPK as known by the client by the
rs_cnf access information
And now, on to the section-by-section comments.
Section 1
a DTLS session. The communication between client and authorization
server may also be secured with DTLS. This specification supports
DTLS with Raw Public Keys (RPK) [RFC7250] and with Pre-Shared Keys
(PSK) [RFC4279].
[DTLS 1.3 will inherit TLS 1.3's built-in support for (so-called
"external") PSKs.]
The DTLS handshake requires the client and server to prove that they
can use certain keying material. In the RPK mode, the client proves
with the DTLS handshake that it can use the RPK bound to the token
and the server shows that it can use a certain RPK. The access token
must be presented to the resource server. For the RPK mode, the
access token needs to be uploaded to the resource server before the
handshake is initiated, as described in Section 5.8.1 of the ACE
framework [I-D.ietf-ace-oauth-authz].
This seems to be making some implicit assumptions about the message flow that
have not yet been covered by this document and are only somewhat covered by the
core framework spec. I'd propose:
% The ACE framework requires that client and server mutually % authenticate
each other before any other protocol exchanges take % place. In order for
DTLS to provide mutual authentication, both % client and server must prove
their ability to use certain keying % material (tied to the authenticated
identity) as part of the DTLS % handshake. The AS assists in this process by
incorporating key % material (or information about key material) into the
access token, % which is considered a "proof of possession" token. In the RPK
mode, % the client proves that it can use the RPK bound to the token and the %
server shows that it can use a certain RPK (as indicated by the AS to % the
client). The resource server needs access to the token in order % to complete
this exchange. For the RPK mode, the access token needs % to be uploaded to
the resource server before the handshake is % initiated, as described in
Section 5.8.1 of the ACE framework % [I-D.ietf-ace-oauth-authz].
though I recognize that my text tends to be a bit more verbose than is strictly
needed, so please feel free to edit it down.
Section 2
The CoAP-DTLS profile for ACE specifies the transfer of
authentication information and, if necessary, authorization
information between the client (C) and the resource server (RS)
during setup of a DTLS session for CoAP messaging. It also specifies
how C can use CoAP over DTLS to retrieve an access token from the
authorization server (AS) for a protected resource hosted on the
resource server.
I suggest reiterating that "As specified in Section 6.7 of
[I-D.ietf-ace-oauth-authz], use of DTLS for one or both of these interactions
is completely independent".
To determine the AS in charge of a resource hosted at the RS, C MAY
send an initial Unauthorized Resource Request message to the RS. The
This is part of the core framework, so the "MAY" may be overkill.
(Lowercase "can" would do just fine.)
Once the client knows the authorization server's address, it can send
an access token request to the token endpoint at the AS as specified
Hmm. There's some level of "the client needs to have already been configured
that that AS is a valid AS" verification that's done here, but I'm not sure if
that's too much detail to include at this stage (since we're really just
summarizing the framework here).
in [I-D.ietf-ace-oauth-authz]. As the access token request as well
as the response may contain confidential data, the communication
between the client and the authorization server MUST be
(This "MUST" is already a requirement from the core framework, so we don't
necessarily need to repeat it as normative language.)
confidentiality-protected and ensure authenticity. C may have been
registered at the AS via the OAuth 2.0 client registration mechanism
as outlined in Section 5.3 of [I-D.ietf-ace-oauth-authz].
Section 5.3 of oauth-authz says that registration is "out of scope"; is this
still the right reference?
[I-D.ietf-ace-oauth-authz]. In case the client uses a symmetric
proof-of-possession key in the DTLS handshake, the procedure as above
MAY be used, or alternatively, the access token MAY instead be
transferred in the DTLS ClientKeyExchange message (see
Section 3.3.1).
(This is not DTLS 1.3-compatible.)
Section 3
secured. Depending on the used CoAP security mode (see also
Section 9 of [RFC7252], the Client-to-AS request, AS-to-Client
response and DTLS session establishment carry slightly different
information. [...]
At this point in the document it's pretty unclear what "Client-to-AS request",
"AS-to-Client response", and "DTLS session establishment" are and how they
relate to each other.
Also, it seems like the behavior in Section 3.2 and 3.3 are relating to the
mode used for the client/RS interactions, which relates to the client/AS
interactions only in the form of how PoP information is bound to/with the token.
Section 3.1
establish a secure communication channel. C MUST securely have
obtained keying material to communicate with AS. Furthermore, C MUST
verify that AS is authorized to provide access tokens (including
authorization information) about RS to C. Also, AS MUST securely
have obtained keying material for C, and obtained authorization rules
approved by the resource owner (RO) concerning C and RS that relate
to this keying material. [...]
The way this is written right now, we're going to get lots of questions from
reviewers about "how does this happen?" and for more details about it. We are
effectively assuming that this stuff is all provisioned already as part of the
device configuration or during enrollment, we should say something about these
being requirements on device provisioning, not on the operation of the ACE
protocol.
between C and AS is bootstrapped is not part of this document. C and
AS MUST ensure the confidentiality, integrity and authenticity of all
exchanged messages.
I think this is also restating requirements from the core framework, and may
not need normative language in this manner.
Section 3.2
I know that the section heading says "RawPublicKey Mode" already, but I'd
recommend adding a sentence in the preface that repeats that "When the client
and RS use RawPublicKey authentication, the procedure is as follows"; we might
get complaints otherwise that we are saying that the client MUST do things that
are not universal requirements.
(Section 3.3 does already have something like this for the symmetric-key
case.)
previously made known to the authorization server. To prove that the
client is in possession of this key, C MUST use the same keying
material that it uses to secure the communication with AS, e.g., the
DTLS session.
This seems in conflict with the core framework's requirement that the client/AS
profile and client/RS profile are severable.
AS MUST check if the client that it communicates with is associated
with the RPK in the cnf object before issuing an access token to it.
Earlier in the section we noted a requirement to prove possession of the key by
using it in DTLS; why is there a separate "association"
requirement?
also, nit: "The AS".
which case it does not have to be sent. The response also contains
an access token and an "rs_cnf" parameter containing information
about the public key that is used by the resource server. AS MUST
nit(?): is the "rs_cnf" parameter always mandatory? (Or only when DTLS-RPK is
used for client-RS interactions?)
nit: "The AS" again (and throughought, to a large extent).
server that C wants to communicate with. AS MUST protect the
integrity of the token. If the access token contains confidential
data, AS MUST also protect the confidentiality of the access token.
This requirement ("protect the integrity of the token") feels a little
underspecified, as it doesn't say protection over what workflow or who will
verify the integrity (the RS).
C MUST ascertain that the access token response belongs to a certain
previously sent access token request, as the request may specify the
resource server with which C wants to communicate.
nit: I recomment rewording "belongs to", perhaps as "corresponds to".
DTLS can provide this guarantee when configured to do so, though it is not a
guaranteed property from DTLS.
We'll probably get some grief about the "access_token" contents in the example
not being valid CBOR, due to the parenthetical comment. We could probably put
a note in the preface that the value is truncated for readability. Also, nit:
"the client's" with article and apostrophe.
Section 3.2.1
Before the client initiates the DTLS handshake with the resource
server, C MUST send a "POST" request containing the new access token
to the authz-info resource hosted by the resource server. After the
client
nit: we don't require single-use tokens, so "new" is probably overkill; just
"its access token" should suffice.
nit: formatting issue with spurious line break here.
server. To use the RawPublicKey mode, the client MUST specify the
public key that AS defined in the "cnf" field of the access token
response in the SubjectPublicKeyInfo structure in the DTLS handshake
as specified in [RFC7250].
IIRC the access token response does not have to include a "cnf" field (e.g., if
the AS accepts the req_cnf from the request), so "defined in the field of the
response" doesn't seem like quite the right wording.
An implementation that supports the RPK mode of this profile MUST at
least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
I understand that making the full-width-tag ciphersuite MTI would exclude some
devices, though it feels like some recommendation to use the full-length tag
when possible would be appropriate. That said, I do see that RFC 7252 makes no
such remark, and thus consistency would have us not say anything either.
[RFC7251] with the ed25519 curve (cf. [RFC8032], [RFC8422]).
Just to be clear: ed25519 is an ECDSA algorithm; the corresponding ECDHE
operation is called x25519, and both algorithms make use of the elliptical
curve known as curve25519. Since we are using both ECDHE and ECDSA, it's
probably simplest to just refer to "curve25519", though mentioning both ed25519
and x25519 would also work.
RS MUST check if the access token is still valid, if RS is the
intended destination, i.e., the audience, of the token, and if the
token was issued by an authorized AS. The access token is
nit: "i.e., the audience" is in effect a parenthetical, so using commas to
offset it inside a comma-separated list is potentially confusing; I'd suggest
using actual parentheses instead of commas around it.
reference to this key. If the authorization server has no certain
knowledge that the Client's key is already known to the resource
server, the Client's public key MUST be included in the access
token's "cnf" parameter. If CBOR web tokens [RFC8392] are used as
recommended in [I-D.ietf-ace-oauth-authz], keys MUST be encoded as
specified in [I-D.ietf-ace-cwt-proof-of-possession]. RS MUST use the
Is talking about """the access token's "cnf" parameter" consistent with
allowing the use of non-CWT (non-JWT) token formats?
keying material in the handshake that AS specified in the rs_cnf
parameter in the access token. Thus, the handshake only finishes if
C and RS are able to use their respective keying material.
I suggest being explicit about "the DTLS handshake with the client", perhaps as
"MUST use in the DLTS handshake with the client the keying material that the AS
specified in the rs_cnf parameter in the access token". The same caveat about
"parameter in the access token"
applies here, though I guess there is an additional complication for "rs_cnf"
in that it's an token response parameter but I don't remember that we say a
huge amount about it also being included in the token itself -- the token
response is directed to the client but the token is directed to the RS.
Section 3.3
token. AS MUST check if the identifier refers to a symmetric key
that was previously generated by AS as a shared secret for the
communication between this client and the resource server.
"What does the AS do if this check fails?"
The authorization server MUST determine the authorization rules for
the C it communicates with as defined by RO and generate the access
nit: it's surprising to see "authorization server" spelled out in the same
sentence as "C" and "RO" (which, incidentally, we don't seem to use in
abbreviation form anywhere other than where we define it).
wants to communicate with. Also, AS MUST protect the integrity of
the access token. If the token contains confidential data such as
the symmetric key, the confidentiality of the token MUST also be
protected. Depending on the requested token type and algorithm in
(same comment about "protect the integrity" or "protect" as for the RPK
case.)
that is to be used between C and the resource server. The access
token MUST be bound to the same symmetric key by means of the cnf
claim.
Now we call it a "claim" rather than a "token parameter", but this again seems
to be implicitly assuming CWT/JWT for tokens.
(Also, this "MUST" seems like something that the framework should guarantee and
not a new requirement that the DTLS profile imposes.)
Figure 5: Example Access Token Request, symmetric PoP-key
Maybe we could include "(implicit)" in the caption, since symmetric PoP key is
the default.
An example access token response is illustrated in Figure 6. In this
Is it accurate to say "A corresponding example access token response"?
It's nice to the reader if we can tie the examples together like that.
Is the "Max-Age" usage in Figure 6 typical? (Also, similar comment about
having the parenthetical comment in the example body vs. preface.)
token_type : pop,
Didn't we switch this to being capitalized as "PoP"?
"COSE_Encrypt0" structure. The AS MUST use the keying material
shared with the RS to encrypt the token.
nit: I suggest s/shared with/it shares with/
We should probably say something about why the kid in Figure 7 is different
from the one in Figure 6.
4.00 Bad Request
Content-Format: application/ace+cbor
Payload:
{
error : invalid_request
}
Figure 8: Example Access Token Response With Reject
RFC 6749's description of "invalid_request" seems to imply that it's mostly
about malformed requests, as opposed to the AS deciding that the client is not
authorized for any access to the requested resource (which is maybe what's
implied by the previous paragraph). This is not necessarily a problem, but
perhaps we could make the text and example more consistent.
The method for how the resource server determines the symmetric key
from an access token containing only a key identifier is application
specific, the remainder of this section provides one example.
nit: hyphenate "application-specific", and this is a comma splice.
resource server. This key needs to be securely stored and processed
in the same way as the key used to protect the communication between
AS and RS.
nit: is this better as "processed" or "protected"?
The fields in the context information "COSE_KDF_Context"
(Section 11.2 of [RFC8152]) have the following values:
o AlgorithmID = "ACE-CoAP-DTLS-key-derivation"
RFC 8152 says that these AlgorithmID values come from the COSE Algorithms
registry, which this does not (unless we register it there, which we don't
currently). Also, since the output is used directly for DTLS PSK, I don't
think the "key-derivation" portion is needed.
o PartyUInfo = PartyVInfo = ( null, null, null )
(8152 seems to prefer "nil" over "null".)
o keyDataLength needs to be defined by the application
o protected MUST be a zero length bstr
o other is a zero length bstr
(These three are all members of the "SuppPubInfo" field, which is not very
clear from how we include them in the same list as top-level
fields.)
Section 3.3.1
When a client receives an access token response from an authorization
server, C MUST ascertain that the access token response belongs to a
certain previously sent access token request, as the request may
specify the resource server with which C wants to communicate.
(Same bit about "belongs to".)
If a resource server receives a ClientKeyExchange message that
contains a "psk_identity" with a length greater zero, it uses the
contents as index for its key store (i.e., treat the contents as key
(This is not DTLS 1.3-compatible.)
nits: "greater than", "as an index", "as a key identifier"
identifier). The resource server MUST check if it has one or more
access tokens that are associated with the specified key.
I don't understand this sentence -- isn't the access token the precise contents
of the "psk_identity" field, so that there would be a key associated with the
access token, not the other way around?
If no key with a matching identifier is found, the resource server
MAY process the contents of the "psk_identity" field as access token
Similarly here, the causality feels reversed.
continuing the DTLS handshake. If the contents of the "psk_identity"
do not yield a valid access token for the requesting client, the DTLS
session setup is terminated with an "illegal_parameter" DTLS alert
message.
I think "the RS aborts the DTLS handshake with an 'illegal_parameter' alert"
would be more conventional phrasing.
Note2: According to [RFC7252], CoAP implementations MUST support the
ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]. A client is
therefore expected to offer at least this ciphersuite to the
resource server.
Do we want to say anything about the (EC)DHE variants? Short-lived access
tokens with the AS generating new symmetric keys can provide similar
forward-secrecy properties to using DHE, but there is in general a trend in the
IETF towards defaulting to providing forward secrecy in key exchanges.
When RS receives an access token, RS MUST check if the access token
is still valid, if RS is the intended destination, i.e., the audience
of the token, and if the token was issued by an authorized AS. This
As above, "i.e., the audience of the token" would probably be better when
offset in parentheses than by commas.
While the client can retrieve the shared secret from the contents of
the "cnf" parameter in the AS-to-Client response, the resource server
uses the information contained in the "cnf" claim of the access token
to determine the actual secret when no explicit "kid" was provided in
the "psk_identity" field. If key derivation is used, the RS uses the
"COSE_KDF_Context" information as described above.
"psk_identity" is a field in ClientKeyExchange, and we say that its contents
are the raw access token for our usage. It does not have a direct COSE
structure for this talk of "kid" to make much sense without further explanation.
Section 3.4
We may get some requests for a more explicit definition of what the
"authorization information" tied to a client is.
Once a DTLS channel has been established as described in Section 3.2
and Section 3.3, respectively, the client is authorized to access
nit: I think "or" is more appropriate to join the sections listed, as only one
is applicable to a given connection.
With the successful establishment of the DTLS channel, C and RS have
proven that they can use their respective keying material. An access
token that is bound to the client's keying material is associated
with the channel. Any request that the resource server receives on
this channel MUST be checked against these authorization rules. RS
nit: I'd s/these/the following/
MUST check for every request if the access token is still valid.
Incoming CoAP requests that are not authorized with respect to any
access token that is associated with the client MUST be rejected by
the resource server with 4.01 response as described in Section 5.1.1
of [I-D.ietf-ace-oauth-authz].
"any access token" implies there might be more than one, though I seem to
recall discussion of updated tokens overwriting any previous one, so that only
one token per client is active at any given time. What did we end up settling
on?
Also, the referenced framework Section 5.1.1 does not actually mandate the 4.01
response code.
The resource server SHOULD treat an incoming CoAP request as
authorized if the following holds:
We could say more about this "SHOULD" (or change the way we discuss it)
-- is it the minimum baseline of checks and additional checks may be applied,
or do some of them not apply in some cases, or ...?
Incoming CoAP requests received on a secure DTLS channel that are not
thus authorized MUST be rejected according to Section 5.8.2 of
[I-D.ietf-ace-oauth-authz]
We may also get some questions asking about what the difference is between the
"not authorized with respect to any access token" in the previous quoted
snippet" and "not thus authorized" in this quoted snippet.
The client cannot always know a priori if an Authorized Resource
Request will succeed. It MUST check the validity of its keying
material before sending a request or processing a response. If the
What does "check the validity of its keying material" mean?
client repeatedly gets error responses containing AS Creation Hints
(cf. Section 5.1.2 of [I-D.ietf-ace-oauth-authz] as response to its
requests, it SHOULD request a new access token from the authorization
server in order to continue communication with the resource server.
Why should this only be done in the case of *repeatedly* getting such error
responses; I thought the idea of the AS Request Creation Hints was to take
immediate effect.
(Also, nit: s/AS Creation Hints/AS Request Creation Hints/.)
Section 4
The client can update the authorization information stored at the
resource server at any time without changing an established DTLS
session. To do so, the Client requests a new access token from the
authorization server for the intended action on the respective
resource and uploads this access token to the authz-info resource on
the resource server.
I suggest adding another sentence similar to "Because ACE tokens are
proof-of-possession tokens, the updated authorization information only takes
immediate effect if such proof has already been provided, e.g., if the PoP key
associated with the new token is the same as the one currently in use." This
is further detailed in the following paragraphs, but not stated concretely as a
key principle.
Section 5
DTLS sessions that have been established in accordance with this
profile are always tied to a specific access token. As this token
Doesn't the dynamic authorization update mechanism allow that token to be
swapped out during the lifetime of the connection?
Also, as a terminology point, I think "DTLS association" is more appropriate
than "DTLS session" for what we describe, since the token is is tied to the
client and consulted at the start of the handshake, as opposed to being a
property of the DTLS session and carried across resumptions.
may become invalid at any time (e.g. because it has expired), the
session may become useless at some point. A resource server
therefore MUST terminate existing DTLS sessions after the access
token for this session has been deleted.
I assume that using "been deleted" vs. "has expired" is a deliberate choice?
If we don't say anything else about when to delete tokens, it doesn't post much
of a requirement, though.
Section 6
endpoint. The use of CoAP and DTLS for this communication is
RECOMMENDED in this profile, other protocols (such as HTTP and TLS or
CoAP and OSCORE) MAY be used instead.
nit: comma splice
Also, we could potentially refer to the OSCORE profile document here
(informatively).
If other means of securing the communication with the AS are used,
the security protocol MUST fulfill the communication security
requirements in Section 6.2 of [I-D.ietf-ace-oauth-authz].
I suggest phrasing more like "the communication security requirements from
Section 6.2 of [I-D.ietf-ace-oauth-authz] remain applicable", since there's no
need to add another MUST to the ones already in the framework document.
Section 7
I have a few suggestions for potential additions to this section as well as
comments on the existing contents.
We might consider adding a brief note about the use of 8-byte authentication
tags in DTLS ciphers and how that affects the risk profile.
The use of "live" authorization upgrades on an existing DTLS connection by
posting a new token to the authz-info endpoint does not provide much guarantee
about the order in which operations occur (and thus which authorization info is
used to process a given client request), especially in the face of an attacker
that can delay and reorder packets. This does not necessarily mean that we
should not bother to define that mechanism, but we should point out that there
is only a weak ordering property provided, note that other mechanisms should be
used when strict serialization is important, and caution that when the
later-issued token contains a reduction in authorization from the initial
token, it is impossible to guarantee that the reduction in authorization will
take effect prior to the expiration of the original token.
We rely heavily on the AS to accurately provide binding of raw key material to
authorization information and endpoint identinty; I think this is a stronger
reliance than just that implied by the core architecture, and so might merit a
mention here. (This relates to all the checks about "MUST check that
[client/...] is associated with [RPK/PSK]" that appear throughout the document.)
I'd also suggest reiterating all the places where we rely on out-of-band
configuration, as there's always a risk of such configuration becoming stale
(or getting attacked directly).
I'd consider reiterating that when the KDF scheme is in use between RS and AS,
that kid uniqueness is paramount, as using the same kid for multiple clients
and the same RS would have potentially disasterous consequences in that case.
Similarly (though this is inherent to symmetric PoP and may not actually need
reiterating), when we use symmetric PSKs for PoP, they lose almost all value if
any given PSK is known to more than one client or RS. (The secdir review on
the framework has us putting in MUST-level requirements to not share further
than that, so it seems pretty reasonable to not duplicate that warning here.)
This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework
[I-D.ietf-ace-oauth-authz]. As it follows this framework's general
approach, the general security considerations from section 6 also
apply to this profile.
(The HTMLized link will only do the right thing if you use the redundant
"section 6 of [I-D.ietf-ace-oauth-authz]".)
The use of multiple access tokens for a single client increases the
strain on the resource server as it must consider every access token
and calculate the actual permissions of the client. Also, tokens may
contradict each other which may lead the server to enforce wrong
permissions. If one of the access tokens expires earlier than
others, the resulting permissions may offer insufficient protection.
Developers SHOULD avoid using multiple access tokens for a client.
I think I touched on this above; did we want to make a stronger statement about
"only one active token per client"?
Section 8
information as possible in an unencrypted response. When a DTLS
session between the client and the resource server already exists,
more detailed information MAY be included with an error response to
provide the client with sufficient information to react on that
particular error.
I'd suggest adding a caveat like "an authenticated client" or "a known client",
since DTLS itself does not guarantee that the client is not an attacker.
Section 9
Profile ID: 1
I think this has to be merely a "suggested value", as IANA will control the
actual allocations, in the absence of a reservation of this value in the
framework document.
Section 10.1
We don't currently reference RFC 7925 in any way that would require it to be a
normative reference. We probably should, though -- somehow pull in that we
require/recommend conformance with that profile of DTLS.
Section 10.2
I think RFCs 7250, 7251, and 8422 need to be normative.
Thanks,
Ben
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
