On 07/01/2020, 17:40, "Ace on behalf of Benjamin Kaduk" wrote:
Hi all,
Some high-level points before the section-by-section commentary:
1. I'm a little confused by the registry we are creating in Section 9.2.
While it's clear that we need something to specify the CBOR map key
labels to encode the structure for transit, it's not clear that we need
easy extensibility vs. a fixed table. A registry implies expectations
of future additions, but draft-ietf-core-object-security did not feel a
need to make a registry for future extensions; what has changed in the
past few months that makes extensibility needed now? Why is this
document the right place to create the registry as opposed to that one?
FP: Why extensibility now: an example is the Group OSCORE profile, which extends this registry with fields that the OSCORE profile does not need, related to countersignatures (see https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04#page-22 ). The difference between OSCORE (RFC8613) and this doc is that in OSCORE the security context is never sent on the wire, it is assumed to be pre-established, while here we needed to define a structure to send. Yes, we could avoid defining the registry and define all the fields (we can think of right now), including those for ace-key-groupcomm-oscore as a fixed table, but we thought this would be better, also considering that the OSCORE security context could get extended in a future version of OSCORE.
I would suggest that we have some discussion about how "stock OSCORE"
treats the security context as a logical entity local to each endpoint, but
since we need to serialize it, the registry is required for extensibility.
We will probably still get questions from other IESG members about the
relationship between this registry and the core OSCORE spec, but we can
explain as needed.
2. We are in some sense defining a new substructure within "kid" values (a
CBOR-encoded array of one or two elements) for usage by things using
this profile. That's probably not problematic, as the "kid" can be an
arbitrary bstr and its interpretation is up to the recipient -- any
recipient that implements this profile will know to handle the
substructure, but it does feel a little unusual and perhaps worth an
early note. (IIUC, we also need to be careful about actually providing
the bstr framing in our examples.)
FP: Ok, I will add an early note and also make sure the array is wrapped in a bstr. Do you have any opinion on where best to add this note? Kid appears first in 3.1, should we have it in the introductory section 3.? Or were you thinking even before?
I think we may have to put something in Section 2, noting that OSCORE needs
to have identifiers for both parties, but these identifiers are only unique
within the scope of a given ID context, and that in order to have a
protocol element to convey both the client ID and the ID context, this
profiles uses a substructure within the "kid" bstr.
3. I'm concerned about the usage of "cnonce" to carry both N1 and N2,
neither of which correspond to the "cnonce" behavior in the core
framework; I think we should pick a different parameter name for the
differeng semantic usage. Specifically, the core-framework "cnonce" is
a tool to give RSes some modicum of replay protection -- it verifies
that the client's authorization in the token is "fresh", since the token
includes the random nonce generated by the RS and conveyd to the AS via
the client. This document uses a parameter named "cnonce" in two ways:
(1) to convey the client-generated nonce N1 to the RS in the authz-info
request; this is giving the client contributory behavior to the
ephemeral randomness input to the Security Context computation but does
not provide any sort of replay-protection in and of itself
(2) to convey the RS-generated nonce N2 back to the client in the
authz-info response; this does serve as replay protection in some sense,
but in that it serves to cause repeated posting of the same token (as
might occur in a replay attack) to generate a different OSCORE context
(due to the RSes contributory nature) so that the resulting key material
will be unique for a given association, as opposed to detecting and
blocking replay outright. I think all three uses should have distinct
parameter names, based on my current understanding.
FP: Yes, your understanding is right. I don't see any problem at all with defining new parameters names for the nonces, the reason we used "cnonce" is that this exact point was brought up in the wg and everybody seemed to agree on no need to define a new one, despite the semantics of "cnonce". The authors did not have a strong opinion.
It's true that, at the moment, there's no ambiguity of interpretation once
the context in which the message is received is known. But it feels
awkward and constrains future extensions to alias the semantics in this
way, and it's not obvious that codepoints are so scarce that we need to
have such a confusing interpretation of the field across messages.
4. We mention several times about getting protection from AEAD nonce/key
reuse, but to some extent leave it to the reader to figure out how that
works. Specifically, the only guidance we give on nonce selection is
for our N1 and N2 that go into the Master Salt; we don't say how varying
the Master Salt like that will cause the generated keys and (common) IVs
to differ across runs, thus by construction preventing the collision of
(key, nonce) pairs. (Implementation carelessness that just reuses
key+nonce for a given Security Context is still possible, of course.)
FP: Would it be sufficient to add a sentence in Section 2 saying that by construction if Master Salt is different that will generate different keys and common IVs (+ reference to OSCORE)? For example in this paragraph:
In fact, by using random nonces as part
of the Master Salt, the request to the authz-info endpoint posting
the same token results in a different Security Context, since Master
Secret, Sender ID and Recipient ID are the same but Master Salt is
different.
That sounds like a good plan, yes.
5. In a related vein, we do not get into full detail about the
cryptographic role played by N1 and N2, so as to make the reader
confident that our 64-bit recommendation does provide full
Internet-grade security (as opposed to a weakened "IoT" variant). I'm
not specifically concerned, but we may get some reviewers asking for
more detail.
FP: would it be sufficient to add text along the lines of what you describe in point 3 above?
Hmm, I'm not entirely sure how related they are. What I had in mind here
is more along the lines of the analysis that I asked about in response to
Jim (downthread).
6. I am, however, concerned about the exposure to an RFC 3552-style
attacker for unprotected authz-info responses. There are two main
aspects I'm concerned about: identifier selection and nonce selection.
Letting the server override the client's idea of its own identity (even
when the AS has given the client an identifier!) seems to increase the
risk of a client being tricked into impersonating a different client,
and the stated justification (letting the RS preserve uniqueness)
doesn't seem to hold up in our one-AS-per-RS stated scope, where the AS
can equally well do so. Based on what I know right now, it doesn't feel
like we're at the right point on the cost/benefit curve. For the nonce
selection, this comes into play due to the lack of injectivity for the
mapping of initial AS-generated salt, N1, and N2 into the Master Salt.
Specifically, if a client chooses an N1 that's a prefix of some other N1
that was used, then the attacker can send an "N2" that contains the tail
end of that other N1 plus the actual N2 picked by the server in that
other exchange, causing a full nonce collision and having the
AS-generated portion be the only difference in Master Salt between
security contexts. Using a length prefix for the fields being
concatenated provides injectivity and thwarts this type of attack.
FP: Concerning identifier selection: after a number of points raised (here and in following points), I do believe that the mechanism of letting the RS pick the identifier of the client is not worth the additional complexity. So I propose we revert that, and go back to AS MUST pick the clientId, the clientId MUST be included in the token. This will only add some considerations about the scenario has several-AS-per-RS, in which case these AS need to be synchronized on clientIds they give out.
Okay. I think ASes need to be synchronized in other ways already (right?),
so that's not a substantial additional burden.
About nonce selection: we will define N1 and N2 as CBOR bstr, so that the length prefix will be included.
Nice and elegant :)
7. There are a few places where I'm not entirely sure how the protocol flow
works for the case where the RS is (re)assigning the clientId; I've
tried to note them in the section-by-section comments.
FP: Yes, I agree, we missed some of those. As mentioned, I think it could be solved, but the additional complexity is probably not worth it.
On to the section-by-section notes:
Section 1
8. I'd suggest noting that this is a symmetric-crypto-based scheme in some
manner (e.g., that the AS is assigning a shared symmetric key used as the
OSCORE master secret), and/or that asymmetric PoP semantics are not possible
with this mechanism (or OSCORE in general).
FP: OK Done
9. I'd also suggest noting that proof of possession is not done by a dedicated
protocol element, but rather occurs implicitly based on knowledge of the
OSCORE Security Context. (This is essentially analogous to Kerberos, but a
reference is not strictly needed.) We do have a good treatment in
toplevel Section 4, but it might be worth saying earlier.
FP: OK Done
Section 2
10. [I-D.ietf-ace-oauth-authz]. The access token request and response
MUST be confidentiality-protected and ensure authenticity. This
profile RECOMMENDS the use of OSCORE between client and AS, but TLS
or DTLS MAY be used additionally or instead.
Since the client/AS and client/RS profile are supposed to be completely
severable, I don't think we should use "MAY" here; perhaps "but other
protocols (such as TLS or DTLS) can be used as well".
FP: OK Done
11. Once the client has retrieved the access token, it generates a nonce
N1 and posts both the token and N1 to the RS using the authz-info
endpoint and mechanisms specified in section 5.8 of
[I-D.ietf-ace-oauth-authz] and Content-Format = application/ace+cbor.
Do we want to say explicitly that there is no cryptographic protection
applied for this POST to authz-info?
FP: OK (will add a note) Done
12. which contains a nonce N2 in a CBOR map. Moreover, the server
concatenates N1 with N2 and appends the result to the Master Salt in
the Security Context (see section 3 of
[I-D.ietf-core-object-security]). The RS then derives the complete
Security Context associated with the received token from it plus the
parameters received in the AS, following section 3.2 of
[I-D.ietf-core-object-security].
This passage feels strange to me, probably because it seems to use "Master
Salt" to both the portion with and without N1+N2, and also because it does
not introduce "the Master Salt" as a term or some other object that deserves
the definite article. Would it be equivalent to say "Moreover, the server
concatenates the input salt, N1, and N2 to obtain the Master Salt of the
OSCORE Security Context (see section 3 of [I-D.ietf-core-object-security]"
instead? (Though the details may yet change based on later comments...)
Is "from it" the resulting Master Salt?
There seems to be a word or two missing in "the parameters received in
the AS". (Presumably these parameters are contained in the token?)
FP: OK. Yes,that would be equivalent. Yes, "From it" referred to the Master Salt (the input salt concatenated with N1 and N2). Yes, it's missing "received in the access token from the AS". Done
13. After receiving the nonce N2, the client concatenates it with N1 and
appends the result to the Master Salt in its Security Context (see
section 3 of [I-D.ietf-core-object-security]). The client then
derives the complete Security Context from the nonces plus the
parameters received from the AS.
Similarly, IIUC we should be able to word this so that the "Master Salt" is
unique (and includes the nonces), as opposed to having it apparently refer to
both the pre- and post-nonce-includion strings.
Are these "parameters" received from the AS in the token response?
FP: OK. Yes, they are. Done
14. Finally, the client sends a request protected with OSCORE to the RS.
If the request verifies, then this Security Context is stored in the
server, and used in the response, and in further communications with
the client, until token expiration. This Security Context is
discarded if the same token is re-used to successfully derive a new
Security Context.
The conditional on storing the Security Context only if the request
verifies reads oddly to me, as the RS seems to have needed to store some
amount of security context information for the period betweeen receiving
the token and receiving the authenticated request, as a prerequisite to
being able to verify the request.
Also, is this security context discarded if a new token from the same
client is successfully used?
FP: "Storing" is probably not clear enough, the point is that only after the request passes verification the server marks this security context as "valid" for this client. I'd love suggestions on how to make this clearer. Yes, the security context is discarded if a new token (or a valid old one) is successfully used. Is anything missing here?
W.r.t. the wording, would it work to do something like s/then this Security
Context is stored in the server/the server stores the complete Security
Context state that is ready for use in protecting messages/?
On the discarding old security contexts point, I don't think it's
necessarily required to mention the new-token case here (as it's
semantically different), but as an editorial matter if it flows more
smoothly to talk about "context is discarded when a token (whether the same
or different) is used to derive a new Security Context for that client"
then we get coverage of both cases "for free".
15. The use of random nonces during the exchange prevents the reuse of
AEAD nonces and keys with different messages, in case of re-
derivation of the Security Context both for Clients and Resource
Servers from an old non-expired access token, e.g. in case of re-boot
of either the client or RS. In fact, by using random nonces as part
This sentence is pretty long and a little hard to parse. I'd suggest
something more like:
% The use of random nonces during the exchange prevents the reuse of
% an AEAD nonces/key pair for two different messages. This situation
% might occur when client and RS derive a new Security Context from an
% existing (non-expired) access token, as might occur when either party
% has just rebooted. [...]
FP: OK Done
I'd also consider s/In fact/Instead/ since we are contrasting the
previously described hypothetical (bad) scenario with what actually
happens.
FP: OK Done
16. of the Master Salt, the request to the authz-info endpoint posting
the same token results in a different Security Context, since Master
Secret, Sender ID and Recipient ID are the same but Master Salt is
different. Therefore, the main requirement for the nonces is that
nit: [more usage of "Master Salt" for pre- and post-nonce forms]
I'd also suggest to s/since/since even though the/ (and the s/but/the/
needed to fix up the end of the sentence).
FP: OK (reformulation already fixed in PR) I think this is fixed.
I also want to check my understanding: this "different Security Context" is
still going to use the same identifiers for the endpoints, and will just have
different keys/IVs/etc? This would tie in to the (later) recommendation to
have such a new Security Context completely replace the old one, since
otherwise we'd have to resort to trial decryption to determine which
Security Context to use for processing a given message.
FP: Yes, it would use the same identifiers. Typically, the old security context would get discarded when the new one is validated. Applications could still decide to keep more than one context, and in that case yes, they'd have to rely on trial decryption, but that is not the goal of this document.
Okay, thanks for confirming.
17. they have a good amount of randomness. If random nonces were not
used, a node re-using a non-expired old token would be susceptible to
on-path attackers provoking the creation of OSCORE messages using old
AEAD keys and nonces.
I guess the focus on "good amount of randomness" is trying to emphasize
that we merely need to avoid a single node accidentally producing the
same value, as opposed to a stricter property of unguessability by an
on-path attacker? Or is unguessability also needed when the attacker
can delay traffic?
FP: Yes, that is correct (about the single node). We do not think unguessability is needed. Do you think it should?
I don't know of a reason why unguessability would be needed.
Section 3
18. Section 3.2 of [I-D.ietf-core-object-security] defines how to derive
a Security Context based on a shared master secret and a set of other
parameters, established between client and server, which the client
receives from the AS in this exchange. The proof-of-possession key
We say that the client gets the OSCORE parameters from the AS in the
token response; where do we say how the RS gets the OSCORE parameters
from the AS?
FP: Do you mean this sentence from section 4.
The
client generates a nonce N1 and posts it together with the token that
includes the materials provisioned by the AS to the RS.
And if not, what are we missing?
This may just have been a matter of "I didn't get to that part of the
document when I wrote the question". That said, it probably doesn't hurt
to say "the materials (e.g., OSCORE parameters) provisioned by the AS to
the RS" in the Section-4 passage.
FP: OK Done
Section 3.1
19. The client MUST send this POST request to the token endpoint over a
secure channel that guarantees authentication, message integrity and
confidentiality (see Section 5).
(The framework already requires this, so we may not need the "MUST"
keyword again, though I'm not proposing to remove all mention of the
need for these properties.)
FP: OK, will remove normative MUST etc for the requirements coming from the framework.
Thanks. This is an aspect where opinions differ, but I generally fall into
the camp that says the risk of introducing conflicting requirements is
stronger than the desire to reinforce the requirement with normative
language multiple times.
20. An example of such a request, in CBOR diagnostic notation without the
tag and value abbreviations is reported in Figure 2
nit: only the payload is using CBOR diagnostic notation; the headers are
using CoAP notation.
FP: Done in PR.
21. If the client wants to update its access rights without changing an
existing OSCORE Security Context, it MUST include in its POST request
to the token endpoint a req_cnf object. The req_cnf MUST include a
kid field carrying a CBOR array object containing the client's
identifier (assigned in section Section 3.2) and optionally the
context identifier (if assigned in section Section 3.2). The CBOR
I'm not sure the best way to write a clear description that includes the
"bstr" framing for "kid".
FP: OK, it is missing here that the CBOR array is wrapped in a bstr. I did miss that the kid is a CBOR bstr and not a byte string.
Also, nit: the "assigned" language in the parentheticals feels weird to
me, here.
FP: Why? the use of "assigned" was to highlight that that's the value the AS has set and communicated to the Client. How can we make it clearer?
I think it's because "assigned in Section 3.2" sounds like this spec is
making the assignment, but all that's actually in Section 3.2 is the
procedure/potential for making that assignment. So "assigned as discussed
in" would read more naturally to me.
What's the workflow when the RS has overridden the AS's idea of the
clientId? Does the client have to remember the original AS-assigned
clientId and use it here instead of the RS-assigned one?
FP: Good point, which we did not expand on. Yes, to make this mechanism work (RS can pick an identifier for the client + AS has already assigned one) the client would have to remember the original AS-assigned clientID and use that. Or we should define a mechanism for the client to communicate the RS-assigned clientId to the AS. This would be necessary also in case the AS did not assign the clientId at all. After thinking this through I think this complication makes this RS overwriting the clientId mechanism not worth having.
No argument from here :)
22. These identifiers can be used by the AS to determine the shared
secret to construct the proof-of-possession token and therefore MUST
identify a symmetric key that was previously generated by the AS as a
shared secret for the communication between the client and the RS.
nit: I suggest s/shared secret to construct/shared secret bound to/
FP: Done in PR.
Also, I think the AS will need to use some of the other token request
parameters (e.g., req_aud) in order to determine the client and RS for
which it needs to retrieve the shared PoP key. We might want to mention
that as well.
FP: I am not sure that would be needed, in principle. If the client sends them, then yes, they could be used (and I can add text clarifying that), but if it doesn't, those identifiers should be enough.
I think I had in mind a case where the AS assigns the same client ID and
context ID to more than one (client, server) pairs (but of course with
different servers). The AS can choose to not do so, but I don't remember
anything that prevents it; in such cases the AS would need to know at least
which client (and maybe which server, if the client is duplicated in the
(client, server) pairs) is making the reuqest. This could be done by the
key used to authenticate to the AS, the requested audience (server), etc.,
but I think there are scenarios allowed by the spec where just "req_cnf" is
not enough.
23. The AS MUST verify that the received value identifies a proof-of-
possession key and token that have previously been issued to the
requesting client. If that is not the case, the Client-to-AS request
nit: It's not clear that we need it to identify a specific token, just a
key. (And in fact for multiple successive access-rights updates, there
will be more than one previous token.)
FP: Done in PR. Unrelated, but why would the AS keep more than one previous token?
It would be weird for the AS to keep more than one (but is, IIRC, allowed).
From a rhetorical sense, though, I think even tokens already deleted by the
RS would still qualify as "previous token"s absent further clarifying
language.
The "kid" "req_cnf" member in Figure 4's example does not include the
bstr wrapper that draft-ietf-ace-cwt-proof-of-possession suggests is
required.
FP: correct, kid is missing the bstr wrapper, but req_cnf should be correct, as it should be a map (https://tools.ietf.org/html/draft-ietf-ace-oauth-params-11#section-3.1 defines it having the same structure of "cnf" from draft-ietf-ace-cwt-proof-of-possession, which in section 3.4 defines it as a CBOR map).
Right; I was just identifying that "kid" is a member of the "req_cnf" map.
Sorry for the confusion.
Section 3.2
24. Moreover, the AS MUST provision the following data:
It's frequently the case in IETF documents that "provision" is a
euphimism for "out-of-band configuration", so if we mean "include in the
token response" it's probably better to say that directly.
FP: OK, Done in PR.
25. Additionally, the AS MAY provision the following data, in the same
response.
When the AS does not do so, how are these parameters determined?
FP: Context ID can be omitted and not used in OSCORE. AEAD alg, HKDF alg, salt and replay window can be omitted and then the default value would be used in OSCORE. That should be clear from section 4.3, specifically the sentence:
" In
case these parameters are omitted, the default values are used as
described in section 3.2 of [I-D.ietf-core-object-security]. "
Anything else we need to add?
No, this looks fine (and thanks for explaining).
26. The OSCORE_Security_Context is a CBOR map object, defined in
Section 3.2.1. The master secret MUST be communicated as the 'ms'
field in the OSCORE_Security_Context in the 'cnf' parameter of the
access token response as defined in Section 3.2 of
[I-D.ietf-ace-oauth-params]. The AEAD algorithm MAY be included as
nit: s/in the OSCORE_Security_Context/in the OSCORE_Security_Context
field/, I think?
FP: Done in PR. Yes it is.
27. the 'alg' parameter in the OSCORE_Security_Context; the HKDF
algorithm MAY be included as the 'hkdf' parameter of the
OSCORE_Security_Context, a salt MAY be included as the 'salt'
parameter of the OSCORE_Security_Context, and the replay window type
and size MAY be included as the 'rpl' of the OSCORE_Security_Context,
as defined in Section 3.2.1.
I think we want to reword all of these, as I understand what we're doing
to be defining the parameters in which these values are conveyed, if
they are conveyed at all. Just saying "<X MAY be conveyed in <Y" has
the connotation that <X might alternatively be conveyed in some other
<Z that is not mentioned. The relevant MAY for our purposes is the one
above the list -- "the AS MAY provision the following data".
FP: OK. I will remove all the normative MAY and replace them with may. Would that be sufficient?
Now that you reminded me about the defaults and Section 4.3, yes :)
28. The same parameters MUST be included as metadata of the access token.
This profile RECOMMENDS the use of CBOR web token (CWT) as specified
in [RFC8392]. If the token is a CWT, the same
OSCORE_Security_Context structure defined above MUST be placed in the
'cnf' claim of this token.
nit: "metadata of the access token" sounds like it's trying to be a term
of art, but it is not presently used as such. s/metadata/attributes/
would, IIUC, be more in keeping with OAuth 2.0 tradition.
FP: rephrased into "part of the access token" in PR, is that ok?
Yes, that works.
not-nit: the second sentence seems redundant with the second sentence of
the previous paragraph.
FP: I do agree there is some redundancy. The previous sentence’s MUST referred to the master secret and how it MUST be transported (‘ms’ field of ‘OSCORE_Security_Context’ in ‘cnf’), this sentence is about OSCORE_Security_Context in ‘cnf’. I suggest removing the first MUST, as that will be compliant with point 27, removing the normative MAYs.
I think that's okay, assuming I understand correctly ("master secret must
be communicated as the 'ms' field").
29. The AS MUST also assign an identifier to the RS (serverId), MAY
assign an identifier to the client (clientId), and MAY assign an
identifier to the context (contextId). These identifiers are then
used as Sender ID, Recipient ID and ID Context in the OSCORE context
as described in section 3.1 of [I-D.ietf-core-object-security]. The
couple (client identifier, context identifier) MUST be unique in the
set of all clients on a single RS. Moreover, when assigned,
serverId, clientId and contextId MUST be included in the
OSCORE_Security_Context, as defined in Section 3.2.1.
[Any time we're assigning identities we have to say something about the
privacy properties thereof, or a bunch of reviewers will complain.]
FP: OK. What about adding privacy considerations pointing to the privacy considerations in OSCORE? I feel that should cover it.
Yes, that looks like it will do just fine.
Is the Recipient ID expected to be stable/persistent for a given RS as seen
by all clients?
FP: Not necessarily.
nit: "all clients on a single RS" reads oddly to me; maybe s/on/of/?
FP: Done in PR. s/on/for
nit: I'd suggest to replace "couple" with "tuple" or "pair".
FP: Done in PR: "pair".
nit: serverId is always assigned by the AS, so the "when assigned"
doesn't quite bind properly, grammar-wise. While the clientId is
"always assigned" by the time of the Master Secret derivation, this is
just discussing the AS token response, so we can't necessarily assume
it's assigned here, at least with the current protocol spec.
FP: Done in PR. I believe this is a formulation problem. Yes the serverId is always assigned, so it would always be included in the OSCORE_Security_Context. The point of this sentence was: whenever the AS assigns a value for the identifier, it also sets the corresponding field to that value in the OSCORE_Security_Context. I reformulated: The pair (client identifier, context identifier) MUST be unique in the set of all clients for a single RS. Moreover, clientId, serverId and (when assigned) contextId MUST be included in the OSCORE_Security_Context, as defined in ... This would be consistent with removing the option of clientId not being included in the OSCORE_Security_Context.
Yes, thanks!
OSCORE requires a Sender ID and Recipient ID, but we only have it as
optional for the AS to assign the clientId -- what does OSCORE use as
the Sender/Recipient ID when the AS does not assign a clientId?
FP: That was the case where the RS MUST assign a clientId, see section 4.2:
“Moreover, if the OSCORE_Security_Context in the token did not
contain a 'clientId' parameter, the RS MUST generate an identifier,
unique in the set of all its existing client identifiers, and send it
in a 'clientId' parameter in the CBOR map as a CBOR bstr.“
But if we agree on removing this mechanism, this becomes outdated.
When certain fields are optional, we typically have to ask whether it's
possible for the two parties to disagree about whether the field is
present. IIUC, the OSCORE context derivation procedure includes enough
information to prevent that possibility, but it would be good if someone
would confirm that.
FP: That is correct, a number of fields have default values when non present. Hkdf, alg, salt, contextId, rpl. On the other hand, ms, clientId and serverId need to be set.
Hmm, so there is not a great mechanism to distinguish "absent" from
"present with default value", but the practical consequences of such an
attack seem quite limited.
30. We assume in this document that a resource is associated to one
single AS, which makes it possible to assume unique identifiers for
each client requesting a particular resource to a RS. If this is not
I feel like this might be more clear if we can frame it in terms of the
AS enforcing the uniqueness of client identifiers (or, if you will, that
we delegate the enforcement thereof to the AS...)
FP: OK
31. the case, collisions of identifiers may appear in the RS, in which
case the RS needs to have a mechanism in place to disambiguate
identifiers or mitigate their effect.
nit: s/appear in/occur at/
FP: Done in PR.
nit: s/mitigate their effect/mitigate the effect of the collisions/
FP: Done in PR.
32. Note that in Section 4.3 C sets the Sender ID of its Security Context
to the clientId value received and the Recipient ID to the serverId
value, and RS does the opposite.
(The way this is written implicitly assumes that both clientId and
serverId are received from the AS.)
FP: That's right. I would keep as is if we agree on removing the RS-assigns-identifier mechanism.
33. Figure 5 shows an example of such an AS response, in CBOR diagnostic
notation without the tag and value abbreviations.
I'd suggest s/such an AS response/an AS token response/
FP: OK
34. "access_token" : h'a5037674656d7053656e73 ...'
(remainder of access token omitted for brevity)',
In addition to the invalid-CBOR-diagnostic-notation-syntax comment, we
also have unbalanced quotes.
FP: Right, but this is not valid CBOR diagnostic notation syntax anyway, do you have a better idea? I do not think it would be useful to have the full token here. Will remove the unbalanced quote.
This is probably manageable, though we do often see people put a disclaimer
before the example that <certain fields are truncated for readability;
some other ADs may have other suggestions, too.
Any reason to prefer b64'qA' over h'a8' which is shorter?
FP: No, this is a leftover of some previous example. Will remove b64 encodings.
36. If the client has requested an update to its access rights using the
same OSCORE Security Context, which is valid and authorized, the AS
MUST omit the 'cnf' parameter in the response, and MUST carry the
client identifier and optionally the context identifier in the 'kid'
field in the 'cnf' parameter of the token, with the same structure
I think we should be careful about referring to this as "optionally the
context identifier" -- the choice for whether there is a context
identifier is made once (at initial issuance), and subsequent usage
depends on whether one has been allocated or not. It's not like the AS
can decide at runtime "I gave you a context identifier for your original
security context, but I don't feel like giving it to you again" -- the
derived keys won't match up and it won't be reusable as the same
security context.
FP: Right, this again is a formulation problem. The optionality comes from if it has ever been assigned/allocated/set for that security context. What about reformulating into:
, and MUST carry the
client identifier and the context identifier (if it was set and included in the initial access token response byt the AS) in the 'kid'
field in the 'cnf' parameter of the token, with the same structure
That sounds good.
Also, I'm not sure this is fully defined for the case when the RS
overrides the AS's clientId assignment, as the kid array in the token
needs to be the value the RS will know, but the kid in req_cnf needs to
be the one the AS knows, and we don't really define a mechanism for the
AS to be able to do translation from one to the other.
FP: Right… this is getting complicated. If the client and the RS both kept track of AS-assigned and RS-assigned clientId, that could still work. Or if there was a mechanism for the client to communicate to the AS: “this is the RS-assigned kid, this is the AS-assigned kid, please talk to me as the former”. As mentioned, I think this is getting too complicated and propose removing this mechanism altogether.
37. defined in Figure 3. These identifiers need to be provisioned, in
order for the RS to identify the previously generated Security
Context.
nits: there's only one (not "these") identifier in the token, and
nothing in the token response; and a similar remark about "provisioned"
as was made above.
FP: Here it referred to both clientId and contextId (from the previous sentence), which are carried in the kid field, so I think “these” should be ok. Please correct me if I am wrong. Ok about provisioned, done in PR.
There's only the one ('kid') field in the token, but I think you're correct
here. Sorry for the mixup!
38. Figure 9 shows an example CWT, containing the necessary OSCORE
parameters in the 'cnf' claim for update of access rights, in CBOR
diagnostic notation without tag and value abbreviations.
I don't think this "kid" is a valid CBOR bstr wrapping the one- or
two-element array.
FP: OK
Section 3.2.1
39. [I-D.ietf-core-object-security]). The OSCORE_Security_Context object
can either be encoded as JSON object or as CBOR map. In both cases,
nits "a JSON object", "a CBOR map".
FP: Done in PR.
40. defined below. All parameters are optional. Table 1 provides a
summary of the OSCORE_Security_Context parameters defined in this
section.
They're optional to appear in the OSCORE_Security_Context object that's
included in a "cnf" value, but not necessarily optional for OSCORE to be
usable. What do we do for OSCORE when any given parameter is not
present in this structure? (Also, doesn't the AS always have to provide
things like 'ms' and 'serverId'?)
FP: This is just the structure definition, which is aimed to be more general than just for this spec. For example, this could be reused to send only a part of these parameters, for example if only the salt + identifiers need to be updated. Yes, that is correct, not all parameters are optional when used in this profile, as mentioned in a previous point. ms, serverId are not optional. In an OSCORE Security Context: master secret, sender Id and recipient Id are not optional. Section 4.3 describes what happens if any of the parameters is not present:
Maybe the text relating to my high-level point (1) could try to indicate
that the structure definition is also trying to be more general than just
this profile, as otherwise it's not entirely clear to me. (But if the
wording is too awkward, we can probably think of something else.)
“If any of the expected parameters is missing (e.g. any of the
mandatory parameters from the AS, or the 'clientId', either received
from the AS or in the 2.01 (Created) response from the RS), the
client MUST stop the exchange, and MUST NOT derive the Security
Context. The client MAY restart the exchange, to get the correct
security material.”
42. | rpl | 8 | bstr / int | | OSCORE Replay |
| | | | | Window Type |
| | | | | and Size |
Should just be bstr (not int), right?
FP: Yes. OK.
43. hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more
information about this field, see section 3.1 of
[I-D.ietf-core-object-security]. The values used MUST be
registered in the IANA "COSE Algorithms" registry and MUST be
HMAC-based HKDF algorithms. The value can either be the integer
It's a little unfortunate that we basically are relying on "I know it
when I see it" for determining which algorithms are HKDF algorithms.
FP: Agreed, but we don’t really have another way to say this. If you or COSE experts (Jim) have any idea please let us know.
I think we inherited this from JOSE :-/
Also, "HKDF" expands to "HMAC-based Extract-and-Expand Key Derivation
Function", i.e., is definitionally HMAC-based. So this should be
reworded to reflect the actual intent.
FP: Right, that is because COSE also defines HKDF using AES-MAC, see Table 12 of RFC8152, so we needed to specify that only HMAC-based can be used.
Oof, rather unfortunate IMO that the terminology was overloaded by RFC
8152.
44. alg: This parameter identifies the OSCORE AEAD Algorithm. For more
information about this field, see section 3.1 of
[I-D.ietf-core-object-security] The values used MUST be registered
in the IANA "COSE Algorithms" registry and MUST be AEAD
algorithms. The value can either be the integer or the text
Similarly, this seems to be "I know it when I see it".
FP: Yes.
45. contextId: This parameter identifies the security context as a byte
string. This identifier is used as OSCORE ID Context. For more
information about this field, see section 3.1 of
[I-D.ietf-core-object-security]. In JSON, the "contextID" value
is a Base64 encoded byte string. In CBOR, the "contextID" type is
bstr, and has label 7.
Do we need to forbid present-but-empty contextIds in order to avoid
cryptographic collision with absent-contextId?
FP: The field being present but empty (i.e. value is the empty byte string) is not the same as absent, in OSCORE. So we do not need to forbid that.
Cool.
46. rpl: This parameter is used to carry the OSCORE value, encoded as a
bstr. This parameter identifies the OSCORE Replay Window Size and
Type value, which is a byte string. For more information about
this field, see section 3.1 of [I-D.ietf-core-object-security].
In JSON, the "rpl" value is a Base64 encoded byte string. In
CBOR, the "rpl" type is bstr, and has label 8.
I tried to follow the reference, but I couldn't really find a
description of the encoding for this as a byte string (especially
noteworthy since we claim that it represents both size and type).
(Relatedly, I'm not sure why it's allowed to be either bstr or int.)
FP: Right, this is an old reference, where we actually gave a default encoding for rpl, I believe. Now this is entirely up to the application. I would keep this as bstr and specify that it is any format wrapped in a bstr.
"Up to the application" meaning known by prior agreement among all three of
C, AS, and RS?
Also I need to fix a couple of mistakes: “OSCORE value” is wrong; “Replay Window” and not "Size and Type". Also, I think we need to define a new IANA registry for rpl with 0 as default, so that applications can define their format.
I'm not entirely sure I understand that the registry is for (i.e., what you
propose).
Section 4
47. Can we get some CDDL or similar for both C-to-RS and RS-to-C (in the
respective subsections)?
FP: I am not sure what you’d like to see in CDDL in this subsection, could you expand?
I am not sure what the body of the POST and response thereto are formatted
as. Maybe CDDL is not quite right, if we only want to provide an example
with a particular content-format but allow many formats.
48. I'd naively expect a section titled "Client-RS Communication" to include
some discussion of normal protected OSCORE request/response pairs once
the security context is fully established, but this initial section
basically only talks about the authz-info interaction and disclaims that
the subsections will cover anything else.
FP: Ok, will add some introductory text about the OSCORE security context being used of future OSCORE protected communication.
Thanks!
49. The following subsections describe the details of the POST request
and response to the authz-info endpoint between client and RS. The
client generates a nonce N1 and posts it together with the token that
includes the materials provisioned by the AS to the RS. The RS then
derives a nonce N2 and use Section 3.2 of
nits: "provisioned" again, and the RS is going to be generating a nonce
from scratch, not deriving one from ... anything else, really.
FP: Done in PR.
50. [I-D.ietf-core-object-security] to derive a security context based on
a shared master secret and the two nonces, established between client
and server.
(The shared master secret is part of what the AS provisions^Wgives to
the RS, right?)
FP: Yes, correct. Actually here it is also the clientId, serverId and contextId (if any) that are used for deriving the OSCORE context.
51. Note that the proof-of-possession required to bind the access token
to the client is implicitly performed by generating the shared OSCORE
Security Context using the pop-key as master secret, for both client
and RS. An attacker using a stolen token will not be able to
generate a valid OSCORE context and thus not be able to prove
possession of the pop-key.
It may be worth saying something roughly equating "proof of possesion
performed by the RS" and "the RS authenticating itself to the client",
since there is not an external action for server authentication.
Also, ISTR getting some pushback on a different document that talked
about an attacker with a "stolen token", as something that can steal a
token from the client's local storage might also steal the associated
key. I forget if we ended up changing to some other phrasing or not,
though :(
FP: Ok, will rephrase to “the RS authenticating itself” instead of “pop performed by the RS”. Also, what about using eavesdrop here instead?
Eavesdrop may be too limited, as I think it's also in scope for the attack
when an RS receives (whether legitimately or by deception) the token in
question as the target of a CoAP request.
Section 4.1
52. The client MUST generate a nonce N1 very unlikely to have been
previously used with the same input keying material. This profile
RECOMMENDS to use a 64-bit long random number as nonce. The client
Why 64 instead of 128? I know that 128 is enough without having to
think about it; for 64 we have to be clear about what role the nonce is
serving.
FP: We brought this up in the wg and everybody seemed to be ok with 64. We can go up to 128 if you think it’s better. Also consider that OSCORE appendix B2 has a similar setting and does some considerations about that, mentioning that "typically nonces of at least 8 bytes will be used". Maybe add a reference? https://tools.ietf.org/html/rfc8613#page-72 I brought it up as one of the points the wg should agree on.
53. Note that the use of the payload and the Content-Format is different
from what described in section 5.8.1 of [I-D.ietf-ace-oauth-authz],
which only transports the token without any CBOR wrapping. In this
profile, the client MUST wrap the token and N1 in a CBOR map. The
client MUST use the Content-Format "application/ace+cbor" defined in
section 8.14 of [I-D.ietf-ace-oauth-authz]. The client MUST include
the access token using the correct CBOR label (e.g., "cwt" for CWT,
"jwt" for JWT) and N1 using the 'cnonce' parameter defined in section
5.1.2 of [I-D.ietf-ace-oauth-authz].
That's not what the 'cnonce' parameter is for -- 'cnonce' is protecting
the RS against replay, but N1 is protecting the client. I think we need
to use a different name (and maybe define some integer map label
values?) for this authz-info POST body.
FP: As mentioned, this was raised as an open point and ok by the wg (and particularly Ludwig and Jim).
54. The access token MUST be encrypted, since it is transferred from the
client to the RS over an unprotected channel.
This is probably worth stating in Section 3.2 as well, where we discuss
the AS-to-C token response in more detail.
FP: OK.
55. Note that a client may be required to re-POST the access token, since
an RS may delete a stored access token, due to lack of memory.
I'd suggest using the phrase "at any time" and noting that the client
will detect this by receiving an AS Request Creation Hints message since
the RS treated the request as an Unauthorized Resource Request, perhaps:
% Note that a client may be required to re-POST the access token in
% order to complete a request, since an RS may delete a stored access
% token at any time, for example due to all storage space being
% consumed. This situation is detected by the client when it receives
% an AS Request Creation Hints response.
FP: OK.
56. Payload:
{
"access_token": h'a5037674656d7053656e73 ...'
(remainder of access token omitted for brevity)',
"cnonce": h'018a278f7faab55a'
}
This does not appear to be using either a "cwt" label or "jwt" label, as
the second paragraph of the section would have us using.
FP: OK. Will use "cwt".
Section 4.2
57. token. If the token is valid, the RS MUST respond to the POST
request with 2.01 (Created). If the token is valid but is associated
We probably don't need to repeat the normative requirements from
the core framework with normative keywords again.
FP: OK.
58. to claims that the RS cannot process (e.g., an unknown scope), or if
any of the expected parameters in the OSCORE_Security_Context is
Hmm, "associated to claims that the RS cannot process" sounds like we're
telling the RS to abort if the token includes any unrecognized claims,
which IIUC is at odds with the OAuth 2.0 philosophy of ignoring
unrecognized parameters. (Hopefully someone will correct me if I'm
misremembering that.)
FP: This paragraph is meant to mirror what specified in 5.8.1.1 of ace-oauth-authz:
If the claims cannot be obtained the RS MUST discard the token
and, in case of an interaction via the authz-info endpoint, return
an error message with a response code equivalent to the CoAP code
4.00 (Bad Request).
Next, the RS MUST verify claims, if present, contained in the access
token. Errors are returned when claim checks fail, in the order of
priority of this list:
Ah, maybe the ace framework diverges from oauth here and I misremembered.
But is this behavior limited to "any of the four standard claims that have
a value that cannot be processed" or does it also include "there was an
unrecognized claim"?
59. missing (e.g. any of the mandatory parameters from the AS), or if any
nit: comma after "e.g.".
FP: Done in PR
60. Additionally, the RS MUST generate a nonce N2 very unlikely to have
been previously used with the same input keying material, and send it
within the 2.01 (Created) response. The payload of the 2.01
(Created) response MUST be a CBOR map containing the 'cnonce'
parameter defined in section 5.1.2 of [I-D.ietf-ace-oauth-authz], set
to N2. This profile RECOMMENDS to use a 64-bit long random number as
nonce. Moreover, if the OSCORE_Security_Context in the token did not
As above, we need to use a different name than 'cnonce', as it's
performing a different role (this time, contributing entropy to the
master secret). (Also, if we change our recommendation about nonce
length above we should do so here as well, of course.)
FP: OK, pending wg agreement, and OK.
61. contain a 'clientId' parameter, the RS MUST generate an identifier,
unique in the set of all its existing client identifiers, and send it
in a 'clientId' parameter in the CBOR map as a CBOR bstr. The RS MAY
generate and send a 'ClientId' identifier even though the
OSCORE_Security_Context contained such a parameter, in order to
guarantee the uniqueness of the client identifier. The RS MUST use
I'm not sure I understand the case where the AS wouldn't be able to
guarantee uniqueness of ClientId, and wonder if we could simplify by
always having the AS make ID assignment. Is there some more
background/usage scenarios here that I'm missing?
FP: No that's it. The case I was trying to cover is having several AS cover the same resource at the same RS. Then we would have to have them synchronized for uniqueness of ClientId. But yes. Agree on removing this mechanism.
62. When receiving an updated access token with updated authorization
information from the client (see section Section 3.1), it is
RECOMMENDED that the RS overwrites the previous token, that is only
the latest authorization information in the token received by the RS
is valid. This simplifies for the RS to keep track of authorization
information for a given client.
[this same recommendation is already in the core framework]
FP: OK, will remove normative text and reference framework.
Section 4.3
63. the 'clientId' in the CBOR map in the payload of the response. Then,
the client MUST set the Master Salt of the Security Context created
to communicate with the RS to the concatenation of salt, N1, and N2,
in this order: Master Salt = salt | N1 | N2, where | denotes byte
string concatenation, and where salt was received from the AS in
Section 3.2. The client MUST set the Master Secret and Recipient ID
I think it's general best practice to use an injective mapping of the inputs
to the Master Salt value (i.e., length-prefixes for the various fields, since
there are no reserved octet values).
FP: OK, using CBOR encoded bstr (or b64 if JSON is used) should fix that.
64. from the parameters received from the AS in Section 3.2. The client
MUST set the AEAD Algorithm, ID Context, HKDF, and Replay Window from
the parameters received from the AS in Section 3.2, if present. In
case these parameters are omitted, the default values are used as
described in section 3.2 of [I-D.ietf-core-object-security]. The
Ah, okay; I'd asked about default values earlier. That said, if stock OSCORE
ever changes the defaults we'd have to come up with a compatibility story for
communication between old/new nodes.
FP: Yes. Maybe adding a version number to this context structure? I think this is a good idea.
It's hard to argue that a version number would be a bad idea, so that seems
reasonable.
65. client MUST set the Sender ID from the 'clientId in the 2.01
(Created) response, if present; otherwise, the client MUST set the
Sender ID from the parameters received from the AS in Section 3.2.
[As written, this has the clientId from the RS take precedence over the one
from the AS when both are present. I understand that the claimed
justification is for the RS to be able to enforce clientId uniqueness, but it
still feels risky, since the value from the RS is unauthenticated.]
FP: Let's remove this mechanism.
66. If any of the expected parameters is missing (e.g. any of the
mandatory parameters from the AS, or the 'clientId', either received
from the AS or in the 2.01 (Created) response from the RS), the
client MUST stop the exchange, and MUST NOT derive the Security
Context. The client MAY restart the exchange, to get the correct
security material.
I think this means "restart at the AS" but it's probably worth being very
explicit about it.
FP: Yes, OK will clarify.
Also, is there anything to be said about rate-limiting/backoff for persistent
missing parameters?
FP: OK, will add a sentence about that.
67. After sending the 2.01 (Created) response, the RS MUST set the Master
Salt of the Security Context created to communicate with the client
to the concatenation of salt, N1, and N2, in this order: Master Salt
= salt | N1 | N2, where | denotes byte string concatenation, and
[It might be worth breaking this computation off into a standalone piece of
text that applies to both C and RS, including the edits for injectivity.]
FP: OK
68. where salt was received from the AS in Section 4.2. The RS MUST set
the Master Secret, Sender ID and Recipient ID from the parameters,
received from the client in the access token in Section 4.1 after
nit: I'd place the emphasis more on "in the access token" or even "from the
AS" rather than "from the client" -- the RS/AS preestablished relationship is
what authenticates these values.
FP: Done in PR: "from the AS forwarded by the client".
69. validation of the token as specified in Section 4.2. The RS MUST set
Does Section 4.2 really say much about validation other than "RS MUST verify
the validity of the token"?
FP: well, that and points to 5.8.1 of ace-oauth-authz. I pointed to the framework not to duplicate the reference, but we can do that if you think it’s best.
I think I was just wondering if we should skip the Section-4.2 indirection
and refer directly to the framework. What's in place now is okay, though.
70. [I-D.ietf-core-object-security]. After that, the RS MUST derive the
complete Security Context following section 3.2.1 of
[I-D.ietf-core-object-security], and MUST associate this Security
Context with the authorization information from the access token.
side note: it's sometimes useful as a rhetorical device to have a discussion
of the abstract data model the RS uses -- in this case, that it maintains a
collection of Security Contexts with associated authorization information,
for all the clients that it's currently communicating with, and that the
authorization information is policy that's used as input to processing
requests from those clients. Otherwise, this text about "MUST associate" can
be a bit vague to the reader.
FP: OK, will add this clarification in this section.
71. The RS then uses this Security Context to verify the request and send
responses to C using OSCORE. If OSCORE verification fails, error
(nit?) what is "the request"? I don't think we've talked about a specific
OSCORE request yet, so this would probably be better if talking about generic
incoming requests from a given client.
FP: Done in PR: "verify requests and sends responses".
72. responses are used, as specified in section 8 of
[I-D.ietf-core-object-security]. Additionally, if OSCORE
verification succeeds, the verification of access rights is performed
as described in section Section 4.4. The RS MUST NOT use the
Security Context after the related token has expired, and MUST
respond with a unprotected 4.01 (Unauthorized) error message.
nit: I suggest "MUST respond with an unprotected [...] error message to
requests received that correspond to a security context with an expired
token" to tie it back to which requests are affected.
FP: Done in PR.
73. If the exchange was an update of access rights, i.e. a new Security
nit: comma after "i.e.".
FP: Done in PR.
74. Context was derived from a client that already had a Security Context
in place, the is RECOMMENDED to delete the old Security Context after
OSCORE verification and verification of access rights succeed. The
RS MUST delete the Security Context if it deletes the access token
associated to it.
I'm not sure I understand what the workflow is, here -- I assume that the
deletion of the old security context occurs after a successful update via
the authz-info endpoint (as opposed to some particular OSCORE-protected
request), but I don't know what "verification of access rights" could be
performed at that time. Aren't access rights mostly tied to a specific
operation, or is this just supposed to be a more generic audience/scope
check?
FP: The RS deletes the old token and the old security context only after successfully processing a request from the client, using the new token and security context. That includes OSCORE verification and also access rights verification, like any normal request. Is that not clear? How to make it clearer?
It sounds like it's just my misreading: "OSCORE verification" clearly
implies an OSCORE request (i.e., not the authz-info endpoint).
Section 4.4
75. The RS MUST follow the procedures defined in section 5.8.2 of
[I-D.ietf-ace-oauth-authz]: if an RS receives an OSCORE-protected
request from a client, then the RS processes it according to
[I-D.ietf-core-object-security]. If OSCORE verification succeeds,
and the target resource requires authorization, the RS retrieves the
nit(?): is it appropriate to say "requires additional authorization" (over
the implicit authorization given to any authenticated client)? I'm not sure
if that would be confusing or not.
FP: I would think this is more confusing than clarifying because we don’t talk about implicit authorization in this document. We can make this change if other people agree that this formulation is better.
Understood; leaving it as-is is okay.
76. authorization information from the access token associated to the
Security Context. The RS then MUST verify that the authorization
information covers the resource and the action requested.
In the vein of my previous note about an abstract data model, we may not want
to be overly prescriptive about "retrieves [...] from the access token".
Per-request introspection is allowed, as is caching the authorization
information in a non-token local datastore.
FP: Ok, I understand but I am not sure how to implement this comment. “Retrieve” may be misinterpreted, but in my mind it can mean both by looking up caching info as well as introspecting. How to make this clearer?
Would s/from/using/ work?
I'd also consider rephrasing to "MUST verify that the resource and action
requested are authorized", since "covers" is perhaps a little vague.
FP: OK
77. The response code MUST be 4.01 (Unauthorized) in case the client has
not used the Security Context associated with the access token, or if
RS has no valid access token for the client. If RS has an access
The causality here seems a bit weird; how would the RS know what token was
intended just from an OSCORE request that's using a random or different
security context?
FP: The RS needs to keep this association between Security Context and token. This first section covers the case where the client is using a sec ctx not associated to any token or where that sec ctx was not used before (so the full OSCORE setup did not go through). Different (“valid”) security context associated to a token is covered in the next section. Is there anything I am missing here?
I think I'm just complaining about the wording: if a request comes in using
some other (wrong) security context, how does the RS know what the relevant
"the access token" is for that request?
78. token for the client but not for the resource that was requested, RS
MUST reject the request with a 4.03 (Forbidden). If RS has an access
I'd suggest rephrasing this to be in terms of authorization rather than
"token for X", perhaps as "if the RS has an access token for the client but
no actions are authorized on the target resource"
FP: OK
79. token for the client but it does not cover the action that was
requested on the resource, RS MUST reject the request with a 4.05
(Method Not Allowed).
Similarly, perhaps "but the requested action is not authorized".
FP: OK
Also, don't both of these descriptions have high overlap with Section 5.8.2
of the core framework? Is it necessary to reiterate those behavior
specifications?
FP: Yes, this whole second paragraph re-iterates that section. We can remove it, the only thing left will be to specify that “performed proof-of-possession” = “having an OSCORE security context established”
Section 5
80. Thank you for clearly stating that the OSCORE security contexts between RS/AS
and C/AS must be established independently of any of the mechanisms defined
in this document, and that the protocols used for the C/RS, C/AS, and RS/AS
steps can be selected independently.
FP: Good that it's clear.
81. Furthermore the requesting entity and the AS communicate using OSCORE
([I-D.ietf-core-object-security]) through the introspection endpoint
as specified in section 5.7 of [I-D.ietf-ace-oauth-authz] and through
the token endpoint as specified in section 5.6 of
[I-D.ietf-ace-oauth-authz].
I'm not entirely sure what this sentence is trying to say -- it comes across
a little bit as saying that when this document is in use, the indicated
interactions also use OSCORE, but that of course can't be what's actually
intended. Perhaps just saying that the behavior of the introspection
endpoing is specified in section 5.7 of [framework] and that of the token
endpoint is specified in section 5.6 of [framework] would suffice?''
FP: No, this sentence wanted to add to the previous (“if OSCORE is used”), and just point to the framework’s section for the specific behaviours. Will rephrase.
Section 6
82. o the client receives a number of 4.01 Unauthorized responses to
OSCORE requests using the same security context. The exact number
needs to be specified by the application.
Is this a global counter or does it get reset by a successful OSCORE
response?
FP: I would say this gets reset by a successful OSCORE response. But probably the application would have to define that as well. Do we need to add any text about this?
Probably not, since this is a pretty typical class of behavior. If it was
a global counter that never got reset that would be noteworthy.
83. o the client receives a new nonce in the 2.01 (Created) response
(see Section 4.2) to a POST request to the authz-info endpoint,
when re-posting a non-expired token associated to the existing
context.
Why is "non-expired" specifically relevant?
FP: because if it’s expired the RS will not accept that token. This was just for clarification.
What about adding a parenthesis “(non-expired)”?
Sure!
84. The RS MUST discard the current security context associated with a
client when:
o Sequence Number space ends.
o Access token associated with the context expires.
nit: we should make the grammar of the list elements parallel to the client's
list, so "the Sequence Number space ends." and "the access token associated
with the context expires".
FP: Done in PR.
Section 7
85. We talk about both nonces as needing to be "very unlikely to have been
previously used", and it might be worth trying to quantify that (e.g.,
"chance of inadvertent collision less than 2^-32").
FP: This is hard to quantify in a general case. But we can add some text about avoiding inadvertent collisions.
86. As alluded to in my high-level point, we should have more discussion of
the consequences of the authz-info exchange being completely
unprotected.
FP: Let's discuss that in the point above.
87. a secure binding between the request and the response(s). Thus the
basic OSCORE protocol is not intended for use in point-to-multipoint
communication (e.g. multicast, publish-subscribe). Implementers of
nit: comma after "e.g.".
FP: Done in PR.
88. provoke re-use. If that is not guaranteed, nodes are still
susceptible to re-using AEAD nonces and keys, in case the Security
Context is lost, and on-path attacker replay messages.
This text is talking about AEAD nonces, but the nonces (and 64-bit
recommendation) previously discussed are the nonces used in the Master Salt
(and thus Master Secret) calculation; we don't really talk about AEAD nonces
specifically anywhere in the document, other than to point out the risk of
(nonce, key) reuse. IIUC, vulnerable nodes would need to reuse both the
N1 or N2 values defined in this spec as well as the OSCORE partial IV in
order to collide the AEAD (nonce, key) pair (noting that both key and common
IV are influenced by the Master Salt). That said, if the N1 generation is
flawed it seems quite plausible that PIV generation is similarly flawed, so
we are right to document the concern.
Also, the grammar here is a little bit weird, so perhaps a rewording to:
% provoke re-use. If that is not guaranteed, nodes are
% susceptible to re-use of AEAD (nonces, keys) pairs, especially since an on-path
% attacker can cause the client to use an arbitrary nonce for Security
% Context establishment. Even partial loss of Security Context information
% can allow an on-path attacker to replay messages.
though I'm not entirely sure I understand which replay scenarios you had in
mind.
FP: I think the last sentence in your rewording is partially changing the intent of the paragraph. Partial loss does not allow attacker to replay messages; what was meant by that is that, if the context is lost (think reboot without use of persistent memory, where partial IV could reset to previously used IVs, and node’s nonce resets to previously used nonce) and at the same time the attacker replays an old message (so second nonce is previously used too), that creates the problem. I would just remove the last sentence of your reworded paragraph and would be fine with that.
Ah, right, so it's more like "Reuse of AEAD nonces and keys is also
possible by replay of client-to-server messages when state is lost." (IIUC
the replay attack and the "on-path attacker forces a nonce" case are
attacking different protocol actors.)
89. This profiles recommends that the RS maintains a single access token
nit: "This profile" singular.
FP: Done in PR.
90. Also, tokens may contradict each other which may lead the server to
enforce wrong permissions. If one of the access tokens expires
Could you give me an example of the contradiction scenarios? I see the
"common" case as being roughly "Token T1 gives access to the set X of
resources and token T2 gives access to a partially disjoint set Y of
resources", but I don't know that such a scenario would be considered a
"conflict". To get a conflict I'd expect more like "token T1 indicates that
access to X is to be denied, but token T2 indicates that access to X is to be
allowed" with some sort of explicit negative ACL, but I don't think OAuth
really has a concept of negative ACL.
FP: No, I meant what you describe as the common case. The contradiction coming from the fact that one token would give access to a set X of resource that the other token would not give access to. A server implementation might check only one token, which could lead to wrong permissions. Do we need to say anything else here?
How would "if tokens indicate different or disjoint permissions from each
other" work?
Section 8
91. There might be a few more privacy considerations worth mentioning:
the token is sent in the clear to the authz-info endpoint, so if a single
token is used with multiple audiences or RSes, a client that uses the same
token from multiple locations can be tracked/correlated by the access
token's value.
FP: OK
- the nonces exchanged in the authz-info exchange are also sent in the clear,
so using random nonces is best for privacy (as opposed to, e.g., a counter,
that might leak some information).
FP: OK
- the identifiers clientId/serverId that are created/assigned for this
protocol have some privacy considerations; they overlap a lot with the core
OSCORE considerations in terms of the potential privacy consequences but
there might be a little more to say about guidelines for how the
identifiers are generated. If I'm reading OSCORE correctly, for the uses
specified in this document only the clientId will actually go on the wire?
FP: that’s right, unless client and server swap roles, in which case also serverId (acting as client) could go on the wire. I thought OSCORE should have this covered. What additional details are missing here?
From memory the main new part is that the AS (a third party) is assigning
the identifiers and has information that could (whether by malice or
incompetence) aid in tracking the client/server.
- similarly, there may be considerations for the ID context values.
FP: same, referencing OSCORE should cover it, no?
Most likely.
Section 9.1
92. o Profile Description: Profile for using OSCORE to secure
communication between constrained nodes using the Authentication
and Authorization for Constrained Environments framework.
This is the registry for ACE profiles; "using the Authentication and
Authorization for Constrained Envirornments framework" feels redundant.
There's also perhaps something to say about defining "coap_oscore" for all
three interaction flows even though the procedures for two of the three are
essentially just "out of the scope of this specification", though having some identifier for "use OSCORE" is probably still useful.
FP: Ok, we can remove the last part. About the interaction flows between nodes, I am not sure what you mean, as by following definition https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-31#section-5.6.4.3 it is not mandatory for a profile to specify C-AS and RS-AS, those flows can be out of scope. Am I missing something?
It's not mandatory, though given that we talk about profiles not being able
to assume that the same profile is used for any/all of C/RS, C/AS, and
RS/AS, I guess I assumed that we use the profile identifier to talk about
the last two cases as well as the first one. Maybe I'm wrong to assume
that!
Regardless, I think the question here is whether we want to have people use
the "coap_oscore" string to indicate that C/AS and/or RS/AS use OSCORE, or
if that information is not expected to be encoded in any protocol element;
if the latter, then there's nothing to change.
Section 9.2
93. name The JSON name requested (e.g., "ms"). Because a core goal of
this specification is for the resulting representations to be
compact, it is RECOMMENDED that the name be short. This name is
case sensitive. Names may not match other registered names in a
case-insensitive manner unless the Designated Experts state that
there is a compelling reason to allow an exception. The name is
nit: I'd suggest s/state/determine/
FP: Done in PR
94. CBOR label The value to be used to identify this algorithm. Key map
labels MUST be unique. The label can be a positive integer, a
nit: s/Key map/Map key/
FP: Done in PR
95. negative integer or a string. Integer values between 0 and 255
and strings of length 1 are designated as Standards Track Document
required. Integer values from 256 to 65535 and strings of length
2 are designated as Specification Required. Integer values of
greater than 65535 and strings of length greater than 2 are
designated as expert review. Integer values less than -65536 are
marked as private use.
So use of negative integers from -65535 to -1 and positive integers greater
than or equal to 65536 is not defined?
FP: OK Right we missed it. We will fix it.
I'd also consider listing [I-D.ietf-core-object-security] as an
additional reference for the initial entries, since that specifies the
actual semantics of the fields in question.
FP: OK
Section 9.3
96. "OSCORE_Security_Context" feels like a somewhat long name in light of the
previous commentary about shorter names being preferred. :)
FP: Typically this whole name should not be sent when CBOR is used (so in constrained environments). But we’ll shorten it, what about "Sec_Ctx"?
There's no need to shorten it just on my account; as you note, it's
generally going to be the CBOR tag that's used.
97. o Confirmation Method Description: OSCORE_Security_Context carrying
the OSCORE Security Context parameters
I'd suggest rewording the description to "parameters for using OSCORE
per-message security with implicit key confirmation"
FP: Ok, still would like to keep OSCORE_Security_Context (or whatever the structure will be called) somewhere in the description.
Section 9.4
98.
[same suggested rewording]
FP: OK
Section 9.5
99. Thank you for indicating in which direction the various considerations should
sway the experts' decisions, as opposed to just what the experts should
consider. :)
FP: good.
100. The IANA registry established in this document is defined as expert
review. This section gives some general guidelines for what the
nit: I suggest "defined to use the Expert Review registration policy".
FP: Done in PR
101. The zones tagged as private use are intended for testing purposes
and closed environments, code points in other ranges should not be
assigned for testing.
nit: comma splice
FP: TIL comme splices. Done in PR.
102. o Specifications are required for the standards track range of point
assignment. Specifications should exist for specification
required ranges, but early assignment before a specification is
available is considered to be permissible. Specifications are
side note: this is a little awkward, as RFC 7120 formally does not allow
"early allocations" for the "Expert Review" policy, so there is not a formal
procedure in place to review and expire early allocations that end up not
being needed. It might be worth something to chat with the IANA table about
in Vancouver.
FP: Sure, we will check with IANA. We got inspired by (read shamelessly stole from) COSE here.
Section 10.2
103. We might get some sticklers asking for the terminology references to be made
normative, but I'm not concerned about it one way or the other for now.
FP: OK, will keep in mind.
Appendix A
104. Thank you for assembling this in list form for me.
Do we expect to keep this content in the final RFC? If we do, we should
resynchronize to the current list in Appendix C of the framework :)
FP: Definitely should resynchronize. Yes I’d like this content to stay.
105. o how/if the authz-info endpoint is protected: Security protocol
above
I thought authz-info was fully unprotected, per Section 4.1's "The authz-info
endpoint is not protected, nor are the responses from this resource."
FP: OK, will fix.
Thanks for working through all the comments!
-Ben
The text was updated successfully, but these errors were encountered:
This is mostly for me to keep track of what points have been closed in the draft.
For full discussion, see: https://mailarchive.ietf.org/arch/msg/ace/GE3Ilb9lQARBPvdgIqK2OTMn3G0
On 07/01/2020, 17:40, "Ace on behalf of Benjamin Kaduk" wrote:
Hi all,
Some high-level points before the section-by-section commentary:
While it's clear that we need something to specify the CBOR map key
labels to encode the structure for transit, it's not clear that we need
easy extensibility vs. a fixed table. A registry implies expectations
of future additions, but draft-ietf-core-object-security did not feel a
need to make a registry for future extensions; what has changed in the
past few months that makes extensibility needed now? Why is this
document the right place to create the registry as opposed to that one?
FP: Why extensibility now: an example is the Group OSCORE profile, which extends this registry with fields that the OSCORE profile does not need, related to countersignatures (see https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-04#page-22 ). The difference between OSCORE (RFC8613) and this doc is that in OSCORE the security context is never sent on the wire, it is assumed to be pre-established, while here we needed to define a structure to send. Yes, we could avoid defining the registry and define all the fields (we can think of right now), including those for ace-key-groupcomm-oscore as a fixed table, but we thought this would be better, also considering that the OSCORE security context could get extended in a future version of OSCORE.
I would suggest that we have some discussion about how "stock OSCORE"
treats the security context as a logical entity local to each endpoint, but
since we need to serialize it, the registry is required for extensibility.
We will probably still get questions from other IESG members about the
relationship between this registry and the core OSCORE spec, but we can
explain as needed.
CBOR-encoded array of one or two elements) for usage by things using
this profile. That's probably not problematic, as the "kid" can be an
arbitrary bstr and its interpretation is up to the recipient -- any
recipient that implements this profile will know to handle the
substructure, but it does feel a little unusual and perhaps worth an
early note. (IIUC, we also need to be careful about actually providing
the bstr framing in our examples.)
FP: Ok, I will add an early note and also make sure the array is wrapped in a bstr. Do you have any opinion on where best to add this note? Kid appears first in 3.1, should we have it in the introductory section 3.? Or were you thinking even before?
I think we may have to put something in Section 2, noting that OSCORE needs
to have identifiers for both parties, but these identifiers are only unique
within the scope of a given ID context, and that in order to have a
protocol element to convey both the client ID and the ID context, this
profiles uses a substructure within the "kid" bstr.
neither of which correspond to the "cnonce" behavior in the core
framework; I think we should pick a different parameter name for the
differeng semantic usage. Specifically, the core-framework "cnonce" is
a tool to give RSes some modicum of replay protection -- it verifies
that the client's authorization in the token is "fresh", since the token
includes the random nonce generated by the RS and conveyd to the AS via
the client. This document uses a parameter named "cnonce" in two ways:
(1) to convey the client-generated nonce N1 to the RS in the authz-info
request; this is giving the client contributory behavior to the
ephemeral randomness input to the Security Context computation but does
not provide any sort of replay-protection in and of itself
(2) to convey the RS-generated nonce N2 back to the client in the
authz-info response; this does serve as replay protection in some sense,
but in that it serves to cause repeated posting of the same token (as
might occur in a replay attack) to generate a different OSCORE context
(due to the RSes contributory nature) so that the resulting key material
will be unique for a given association, as opposed to detecting and
blocking replay outright. I think all three uses should have distinct
parameter names, based on my current understanding.
FP: Yes, your understanding is right. I don't see any problem at all with defining new parameters names for the nonces, the reason we used "cnonce" is that this exact point was brought up in the wg and everybody seemed to agree on no need to define a new one, despite the semantics of "cnonce". The authors did not have a strong opinion.
It's true that, at the moment, there's no ambiguity of interpretation once
the context in which the message is received is known. But it feels
awkward and constrains future extensions to alias the semantics in this
way, and it's not obvious that codepoints are so scarce that we need to
have such a confusing interpretation of the field across messages.
reuse, but to some extent leave it to the reader to figure out how that
works. Specifically, the only guidance we give on nonce selection is
for our N1 and N2 that go into the Master Salt; we don't say how varying
the Master Salt like that will cause the generated keys and (common) IVs
to differ across runs, thus by construction preventing the collision of
(key, nonce) pairs. (Implementation carelessness that just reuses
key+nonce for a given Security Context is still possible, of course.)
FP: Would it be sufficient to add a sentence in Section 2 saying that by construction if Master Salt is different that will generate different keys and common IVs (+ reference to OSCORE)? For example in this paragraph:
That sounds like a good plan, yes.
cryptographic role played by N1 and N2, so as to make the reader
confident that our 64-bit recommendation does provide full
Internet-grade security (as opposed to a weakened "IoT" variant). I'm
not specifically concerned, but we may get some reviewers asking for
more detail.
FP: would it be sufficient to add text along the lines of what you describe in point 3 above?
Hmm, I'm not entirely sure how related they are. What I had in mind here
is more along the lines of the analysis that I asked about in response to
Jim (downthread).
attacker for unprotected authz-info responses. There are two main
aspects I'm concerned about: identifier selection and nonce selection.
Letting the server override the client's idea of its own identity (even
when the AS has given the client an identifier!) seems to increase the
risk of a client being tricked into impersonating a different client,
and the stated justification (letting the RS preserve uniqueness)
doesn't seem to hold up in our one-AS-per-RS stated scope, where the AS
can equally well do so. Based on what I know right now, it doesn't feel
like we're at the right point on the cost/benefit curve. For the nonce
selection, this comes into play due to the lack of injectivity for the
mapping of initial AS-generated salt, N1, and N2 into the Master Salt.
Specifically, if a client chooses an N1 that's a prefix of some other N1
that was used, then the attacker can send an "N2" that contains the tail
end of that other N1 plus the actual N2 picked by the server in that
other exchange, causing a full nonce collision and having the
AS-generated portion be the only difference in Master Salt between
security contexts. Using a length prefix for the fields being
concatenated provides injectivity and thwarts this type of attack.
FP: Concerning identifier selection: after a number of points raised (here and in following points), I do believe that the mechanism of letting the RS pick the identifier of the client is not worth the additional complexity. So I propose we revert that, and go back to AS MUST pick the clientId, the clientId MUST be included in the token. This will only add some considerations about the scenario has several-AS-per-RS, in which case these AS need to be synchronized on clientIds they give out.
Okay. I think ASes need to be synchronized in other ways already (right?),
so that's not a substantial additional burden.
About nonce selection: we will define N1 and N2 as CBOR bstr, so that the length prefix will be included.
Nice and elegant :)
works for the case where the RS is (re)assigning the clientId; I've
tried to note them in the section-by-section comments.
FP: Yes, I agree, we missed some of those. As mentioned, I think it could be solved, but the additional complexity is probably not worth it.
manner (e.g., that the AS is assigning a shared symmetric key used as the
OSCORE master secret), and/or that asymmetric PoP semantics are not possible
with this mechanism (or OSCORE in general).
FP: OK Done
protocol element, but rather occurs implicitly based on knowledge of the
OSCORE Security Context. (This is essentially analogous to Kerberos, but a
reference is not strictly needed.) We do have a good treatment in
toplevel Section 4, but it might be worth saying earlier.
FP: OK Done
10. [I-D.ietf-ace-oauth-authz]. The access token request and response
MUST be confidentiality-protected and ensure authenticity. This
profile RECOMMENDS the use of OSCORE between client and AS, but TLS
or DTLS MAY be used additionally or instead.
Since the client/AS and client/RS profile are supposed to be completely
severable, I don't think we should use "MAY" here; perhaps "but other
protocols (such as TLS or DTLS) can be used as well".
FP: OK Done
11. Once the client has retrieved the access token, it generates a nonce
N1 and posts both the token and N1 to the RS using the authz-info
endpoint and mechanisms specified in section 5.8 of
[I-D.ietf-ace-oauth-authz] and Content-Format = application/ace+cbor.
Do we want to say explicitly that there is no cryptographic protection
applied for this POST to authz-info?
FP: OK (will add a note) Done
12. which contains a nonce N2 in a CBOR map. Moreover, the server
concatenates N1 with N2 and appends the result to the Master Salt in
the Security Context (see section 3 of
[I-D.ietf-core-object-security]). The RS then derives the complete
Security Context associated with the received token from it plus the
parameters received in the AS, following section 3.2 of
[I-D.ietf-core-object-security].
This passage feels strange to me, probably because it seems to use "Master
Salt" to both the portion with and without N1+N2, and also because it does
not introduce "the Master Salt" as a term or some other object that deserves
the definite article. Would it be equivalent to say "Moreover, the server
concatenates the input salt, N1, and N2 to obtain the Master Salt of the
OSCORE Security Context (see section 3 of [I-D.ietf-core-object-security]"
instead? (Though the details may yet change based on later comments...)
Is "from it" the resulting Master Salt?
There seems to be a word or two missing in "the parameters received in
the AS". (Presumably these parameters are contained in the token?)
FP: OK. Yes,that would be equivalent. Yes, "From it" referred to the Master Salt (the input salt concatenated with N1 and N2). Yes, it's missing "received in the access token from the AS". Done
13. After receiving the nonce N2, the client concatenates it with N1 and
appends the result to the Master Salt in its Security Context (see
section 3 of [I-D.ietf-core-object-security]). The client then
derives the complete Security Context from the nonces plus the
parameters received from the AS.
Similarly, IIUC we should be able to word this so that the "Master Salt" is
unique (and includes the nonces), as opposed to having it apparently refer to
both the pre- and post-nonce-includion strings.
Are these "parameters" received from the AS in the token response?
FP: OK. Yes, they are. Done
14. Finally, the client sends a request protected with OSCORE to the RS.
If the request verifies, then this Security Context is stored in the
server, and used in the response, and in further communications with
the client, until token expiration. This Security Context is
discarded if the same token is re-used to successfully derive a new
Security Context.
The conditional on storing the Security Context only if the request
verifies reads oddly to me, as the RS seems to have needed to store some
amount of security context information for the period betweeen receiving
the token and receiving the authenticated request, as a prerequisite to
being able to verify the request.
Also, is this security context discarded if a new token from the same
client is successfully used?
FP: "Storing" is probably not clear enough, the point is that only after the request passes verification the server marks this security context as "valid" for this client. I'd love suggestions on how to make this clearer. Yes, the security context is discarded if a new token (or a valid old one) is successfully used. Is anything missing here?
W.r.t. the wording, would it work to do something like s/then this Security
Context is stored in the server/the server stores the complete Security
Context state that is ready for use in protecting messages/?
On the discarding old security contexts point, I don't think it's
necessarily required to mention the new-token case here (as it's
semantically different), but as an editorial matter if it flows more
smoothly to talk about "context is discarded when a token (whether the same
or different) is used to derive a new Security Context for that client"
then we get coverage of both cases "for free".
15. The use of random nonces during the exchange prevents the reuse of
AEAD nonces and keys with different messages, in case of re-
derivation of the Security Context both for Clients and Resource
Servers from an old non-expired access token, e.g. in case of re-boot
of either the client or RS. In fact, by using random nonces as part
This sentence is pretty long and a little hard to parse. I'd suggest
something more like:
% The use of random nonces during the exchange prevents the reuse of
% an AEAD nonces/key pair for two different messages. This situation
% might occur when client and RS derive a new Security Context from an
% existing (non-expired) access token, as might occur when either party
% has just rebooted. [...]
FP: OK Done
FP: OK Done
16. of the Master Salt, the request to the authz-info endpoint posting
the same token results in a different Security Context, since Master
Secret, Sender ID and Recipient ID are the same but Master Salt is
different. Therefore, the main requirement for the nonces is that
nit: [more usage of "Master Salt" for pre- and post-nonce forms]
I'd also suggest to s/since/since even though the/ (and the s/but/the/
needed to fix up the end of the sentence).
FP: OK (reformulation already fixed in PR) I think this is fixed.
FP: Yes, it would use the same identifiers. Typically, the old security context would get discarded when the new one is validated. Applications could still decide to keep more than one context, and in that case yes, they'd have to rely on trial decryption, but that is not the goal of this document.
Okay, thanks for confirming.
17. they have a good amount of randomness. If random nonces were not
used, a node re-using a non-expired old token would be susceptible to
on-path attackers provoking the creation of OSCORE messages using old
AEAD keys and nonces.
I guess the focus on "good amount of randomness" is trying to emphasize
that we merely need to avoid a single node accidentally producing the
same value, as opposed to a stricter property of unguessability by an
on-path attacker? Or is unguessability also needed when the attacker
can delay traffic?
FP: Yes, that is correct (about the single node). We do not think unguessability is needed. Do you think it should?
I don't know of a reason why unguessability would be needed.
18. Section 3.2 of [I-D.ietf-core-object-security] defines how to derive
a Security Context based on a shared master secret and a set of other
parameters, established between client and server, which the client
receives from the AS in this exchange. The proof-of-possession key
We say that the client gets the OSCORE parameters from the AS in the
token response; where do we say how the RS gets the OSCORE parameters
from the AS?
FP: Do you mean this sentence from section 4.
And if not, what are we missing?
This may just have been a matter of "I didn't get to that part of the
document when I wrote the question". That said, it probably doesn't hurt
to say "the materials (e.g., OSCORE parameters) provisioned by the AS to
the RS" in the Section-4 passage.
FP: OK Done
19. The client MUST send this POST request to the token endpoint over a
secure channel that guarantees authentication, message integrity and
confidentiality (see Section 5).
(The framework already requires this, so we may not need the "MUST"
keyword again, though I'm not proposing to remove all mention of the
need for these properties.)
FP: OK, will remove normative MUST etc for the requirements coming from the framework.
Thanks. This is an aspect where opinions differ, but I generally fall into
the camp that says the risk of introducing conflicting requirements is
stronger than the desire to reinforce the requirement with normative
language multiple times.
20. An example of such a request, in CBOR diagnostic notation without the
tag and value abbreviations is reported in Figure 2
nit: only the payload is using CBOR diagnostic notation; the headers are
using CoAP notation.
FP: Done in PR.
21. If the client wants to update its access rights without changing an
existing OSCORE Security Context, it MUST include in its POST request
to the token endpoint a req_cnf object. The req_cnf MUST include a
kid field carrying a CBOR array object containing the client's
identifier (assigned in section Section 3.2) and optionally the
context identifier (if assigned in section Section 3.2). The CBOR
I'm not sure the best way to write a clear description that includes the
"bstr" framing for "kid".
FP: OK, it is missing here that the CBOR array is wrapped in a bstr. I did miss that the kid is a CBOR bstr and not a byte string.
FP: Why? the use of "assigned" was to highlight that that's the value the AS has set and communicated to the Client. How can we make it clearer?
I think it's because "assigned in Section 3.2" sounds like this spec is
making the assignment, but all that's actually in Section 3.2 is the
procedure/potential for making that assignment. So "assigned as discussed
in" would read more naturally to me.
FP: Good point, which we did not expand on. Yes, to make this mechanism work (RS can pick an identifier for the client + AS has already assigned one) the client would have to remember the original AS-assigned clientID and use that. Or we should define a mechanism for the client to communicate the RS-assigned clientId to the AS. This would be necessary also in case the AS did not assign the clientId at all. After thinking this through I think this complication makes this RS overwriting the clientId mechanism not worth having.
No argument from here :)
22. These identifiers can be used by the AS to determine the shared
secret to construct the proof-of-possession token and therefore MUST
identify a symmetric key that was previously generated by the AS as a
shared secret for the communication between the client and the RS.
nit: I suggest s/shared secret to construct/shared secret bound to/
FP: Done in PR.
FP: I am not sure that would be needed, in principle. If the client sends them, then yes, they could be used (and I can add text clarifying that), but if it doesn't, those identifiers should be enough.
I think I had in mind a case where the AS assigns the same client ID and
context ID to more than one (client, server) pairs (but of course with
different servers). The AS can choose to not do so, but I don't remember
anything that prevents it; in such cases the AS would need to know at least
which client (and maybe which server, if the client is duplicated in the
(client, server) pairs) is making the reuqest. This could be done by the
key used to authenticate to the AS, the requested audience (server), etc.,
but I think there are scenarios allowed by the spec where just "req_cnf" is
not enough.
23. The AS MUST verify that the received value identifies a proof-of-
possession key and token that have previously been issued to the
requesting client. If that is not the case, the Client-to-AS request
nit: It's not clear that we need it to identify a specific token, just a
key. (And in fact for multiple successive access-rights updates, there
will be more than one previous token.)
FP: Done in PR. Unrelated, but why would the AS keep more than one previous token?
It would be weird for the AS to keep more than one (but is, IIRC, allowed).
From a rhetorical sense, though, I think even tokens already deleted by the
RS would still qualify as "previous token"s absent further clarifying
language.
FP: correct, kid is missing the bstr wrapper, but req_cnf should be correct, as it should be a map (https://tools.ietf.org/html/draft-ietf-ace-oauth-params-11#section-3.1 defines it having the same structure of "cnf" from draft-ietf-ace-cwt-proof-of-possession, which in section 3.4 defines it as a CBOR map).
Right; I was just identifying that "kid" is a member of the "req_cnf" map.
Sorry for the confusion.
24. Moreover, the AS MUST provision the following data:
It's frequently the case in IETF documents that "provision" is a
euphimism for "out-of-band configuration", so if we mean "include in the
token response" it's probably better to say that directly.
FP: OK, Done in PR.
25. Additionally, the AS MAY provision the following data, in the same
response.
When the AS does not do so, how are these parameters determined?
FP: Context ID can be omitted and not used in OSCORE. AEAD alg, HKDF alg, salt and replay window can be omitted and then the default value would be used in OSCORE. That should be clear from section 4.3, specifically the sentence:
" In
case these parameters are omitted, the default values are used as
described in section 3.2 of [I-D.ietf-core-object-security]. "
Anything else we need to add?
No, this looks fine (and thanks for explaining).
26. The OSCORE_Security_Context is a CBOR map object, defined in
Section 3.2.1. The master secret MUST be communicated as the 'ms'
field in the OSCORE_Security_Context in the 'cnf' parameter of the
access token response as defined in Section 3.2 of
[I-D.ietf-ace-oauth-params]. The AEAD algorithm MAY be included as
nit: s/in the OSCORE_Security_Context/in the OSCORE_Security_Context
field/, I think?
FP: Done in PR. Yes it is.
27. the 'alg' parameter in the OSCORE_Security_Context; the HKDF
algorithm MAY be included as the 'hkdf' parameter of the
OSCORE_Security_Context, a salt MAY be included as the 'salt'
parameter of the OSCORE_Security_Context, and the replay window type
and size MAY be included as the 'rpl' of the OSCORE_Security_Context,
as defined in Section 3.2.1.
I think we want to reword all of these, as I understand what we're doing
to be defining the parameters in which these values are conveyed, if
they are conveyed at all. Just saying "<X MAY be conveyed in <Y" has
the connotation that <X might alternatively be conveyed in some other
<Z that is not mentioned. The relevant MAY for our purposes is the one
above the list -- "the AS MAY provision the following data".
FP: OK. I will remove all the normative MAY and replace them with may. Would that be sufficient?
Now that you reminded me about the defaults and Section 4.3, yes :)
28. The same parameters MUST be included as metadata of the access token.
This profile RECOMMENDS the use of CBOR web token (CWT) as specified
in [RFC8392]. If the token is a CWT, the same
OSCORE_Security_Context structure defined above MUST be placed in the
'cnf' claim of this token.
nit: "metadata of the access token" sounds like it's trying to be a term
of art, but it is not presently used as such. s/metadata/attributes/
would, IIUC, be more in keeping with OAuth 2.0 tradition.
FP: rephrased into "part of the access token" in PR, is that ok?
Yes, that works.
FP: I do agree there is some redundancy. The previous sentence’s MUST referred to the master secret and how it MUST be transported (‘ms’ field of ‘OSCORE_Security_Context’ in ‘cnf’), this sentence is about OSCORE_Security_Context in ‘cnf’. I suggest removing the first MUST, as that will be compliant with point 27, removing the normative MAYs.
I think that's okay, assuming I understand correctly ("master secret must
be communicated as the 'ms' field").
29. The AS MUST also assign an identifier to the RS (serverId), MAY
assign an identifier to the client (clientId), and MAY assign an
identifier to the context (contextId). These identifiers are then
used as Sender ID, Recipient ID and ID Context in the OSCORE context
as described in section 3.1 of [I-D.ietf-core-object-security]. The
couple (client identifier, context identifier) MUST be unique in the
set of all clients on a single RS. Moreover, when assigned,
serverId, clientId and contextId MUST be included in the
OSCORE_Security_Context, as defined in Section 3.2.1.
[Any time we're assigning identities we have to say something about the
privacy properties thereof, or a bunch of reviewers will complain.]
FP: OK. What about adding privacy considerations pointing to the privacy considerations in OSCORE? I feel that should cover it.
Yes, that looks like it will do just fine.
FP: Not necessarily.
FP: Done in PR. s/on/for
FP: Done in PR: "pair".
FP: Done in PR. I believe this is a formulation problem. Yes the serverId is always assigned, so it would always be included in the OSCORE_Security_Context. The point of this sentence was: whenever the AS assigns a value for the identifier, it also sets the corresponding field to that value in the OSCORE_Security_Context. I reformulated: The pair (client identifier, context identifier) MUST be unique in the set of all clients for a single RS. Moreover, clientId, serverId and (when assigned) contextId MUST be included in the OSCORE_Security_Context, as defined in ... This would be consistent with removing the option of clientId not being included in the OSCORE_Security_Context.
Yes, thanks!
FP: That was the case where the RS MUST assign a clientId, see section 4.2:
“Moreover, if the OSCORE_Security_Context in the token did not
contain a 'clientId' parameter, the RS MUST generate an identifier,
unique in the set of all its existing client identifiers, and send it
in a 'clientId' parameter in the CBOR map as a CBOR bstr.“
But if we agree on removing this mechanism, this becomes outdated.
FP: That is correct, a number of fields have default values when non present. Hkdf, alg, salt, contextId, rpl. On the other hand, ms, clientId and serverId need to be set.
Hmm, so there is not a great mechanism to distinguish "absent" from
"present with default value", but the practical consequences of such an
attack seem quite limited.
30. We assume in this document that a resource is associated to one
single AS, which makes it possible to assume unique identifiers for
each client requesting a particular resource to a RS. If this is not
I feel like this might be more clear if we can frame it in terms of the
AS enforcing the uniqueness of client identifiers (or, if you will, that
we delegate the enforcement thereof to the AS...)
FP: OK
31. the case, collisions of identifiers may appear in the RS, in which
case the RS needs to have a mechanism in place to disambiguate
identifiers or mitigate their effect.
nit: s/appear in/occur at/
FP: Done in PR.
FP: Done in PR.
32. Note that in Section 4.3 C sets the Sender ID of its Security Context
to the clientId value received and the Recipient ID to the serverId
value, and RS does the opposite.
(The way this is written implicitly assumes that both clientId and
serverId are received from the AS.)
FP: That's right. I would keep as is if we agree on removing the RS-assigns-identifier mechanism.
33. Figure 5 shows an example of such an AS response, in CBOR diagnostic
notation without the tag and value abbreviations.
I'd suggest s/such an AS response/an AS token response/
FP: OK
34. "access_token" : h'a5037674656d7053656e73 ...'
(remainder of access token omitted for brevity)',
In addition to the invalid-CBOR-diagnostic-notation-syntax comment, we
also have unbalanced quotes.
FP: Right, but this is not valid CBOR diagnostic notation syntax anyway, do you have a better idea? I do not think it would be useful to have the full token here. Will remove the unbalanced quote.
This is probably manageable, though we do often see people put a disclaimer
before the example that <certain fields are truncated for readability;
some other ADs may have other suggestions, too.
35. "profile" : "coap_oscore",
"expires_in" : "3600",
"cnf" : {
"OSCORE_Security_Context" : {
"alg" : "AES-CCM-16-64-128",
"clientId" : b64'qA',
"serverId" : b64'Qg',
Any reason to prefer b64'qA' over h'a8' which is shorter?
FP: No, this is a leftover of some previous example. Will remove b64 encodings.
36. If the client has requested an update to its access rights using the
same OSCORE Security Context, which is valid and authorized, the AS
MUST omit the 'cnf' parameter in the response, and MUST carry the
client identifier and optionally the context identifier in the 'kid'
field in the 'cnf' parameter of the token, with the same structure
I think we should be careful about referring to this as "optionally the
context identifier" -- the choice for whether there is a context
identifier is made once (at initial issuance), and subsequent usage
depends on whether one has been allocated or not. It's not like the AS
can decide at runtime "I gave you a context identifier for your original
security context, but I don't feel like giving it to you again" -- the
derived keys won't match up and it won't be reusable as the same
security context.
FP: Right, this again is a formulation problem. The optionality comes from if it has ever been assigned/allocated/set for that security context. What about reformulating into:
, and MUST carry the
client identifier and the context identifier (if it was set and included in the initial access token response byt the AS) in the 'kid'
field in the 'cnf' parameter of the token, with the same structure
That sounds good.
FP: Right… this is getting complicated. If the client and the RS both kept track of AS-assigned and RS-assigned clientId, that could still work. Or if there was a mechanism for the client to communicate to the AS: “this is the RS-assigned kid, this is the AS-assigned kid, please talk to me as the former”. As mentioned, I think this is getting too complicated and propose removing this mechanism altogether.
37. defined in Figure 3. These identifiers need to be provisioned, in
order for the RS to identify the previously generated Security
Context.
nits: there's only one (not "these") identifier in the token, and
nothing in the token response; and a similar remark about "provisioned"
as was made above.
FP: Here it referred to both clientId and contextId (from the previous sentence), which are carried in the kid field, so I think “these” should be ok. Please correct me if I am wrong. Ok about provisioned, done in PR.
There's only the one ('kid') field in the token, but I think you're correct
here. Sorry for the mixup!
38. Figure 9 shows an example CWT, containing the necessary OSCORE
parameters in the 'cnf' claim for update of access rights, in CBOR
diagnostic notation without tag and value abbreviations.
I don't think this "kid" is a valid CBOR bstr wrapping the one- or
two-element array.
FP: OK
39. [I-D.ietf-core-object-security]). The OSCORE_Security_Context object
can either be encoded as JSON object or as CBOR map. In both cases,
nits "a JSON object", "a CBOR map".
FP: Done in PR.
40. defined below. All parameters are optional. Table 1 provides a
summary of the OSCORE_Security_Context parameters defined in this
section.
They're optional to appear in the OSCORE_Security_Context object that's
included in a "cnf" value, but not necessarily optional for OSCORE to be
usable. What do we do for OSCORE when any given parameter is not
present in this structure? (Also, doesn't the AS always have to provide
things like 'ms' and 'serverId'?)
FP: This is just the structure definition, which is aimed to be more general than just for this spec. For example, this could be reused to send only a part of these parameters, for example if only the salt + identifiers need to be updated. Yes, that is correct, not all parameters are optional when used in this profile, as mentioned in a previous point. ms, serverId are not optional. In an OSCORE Security Context: master secret, sender Id and recipient Id are not optional. Section 4.3 describes what happens if any of the parameters is not present:
Maybe the text relating to my high-level point (1) could try to indicate
that the structure definition is also trying to be more general than just
this profile, as otherwise it's not entirely clear to me. (But if the
wording is too awkward, we can probably think of something else.)
“If any of the expected parameters is missing (e.g. any of the
mandatory parameters from the AS, or the 'clientId', either received
from the AS or in the 2.01 (Created) response from the RS), the
client MUST stop the exchange, and MUST NOT derive the Security
Context. The client MAY restart the exchange, to get the correct
security material.”
41. | hkdf | 4 | bstr / int | COSE | OSCORE HKDF |
| | | | Algorithm | value |
| | | | Values | |
| | | | (HMAC-based) | |
Should be tstr, not bstr, right?
FP: Yes, OK.
FP: because a COSE algorithm can be registered as a string (see https://tools.ietf.org/html/rfc8152#section-16.4 “Value”).
Ah, I missed that; sorry.
42. | rpl | 8 | bstr / int | | OSCORE Replay |
| | | | | Window Type |
| | | | | and Size |
Should just be bstr (not int), right?
FP: Yes. OK.
43. hkdf: This parameter identifies the OSCORE HKDF Algorithm. For more
information about this field, see section 3.1 of
[I-D.ietf-core-object-security]. The values used MUST be
registered in the IANA "COSE Algorithms" registry and MUST be
HMAC-based HKDF algorithms. The value can either be the integer
It's a little unfortunate that we basically are relying on "I know it
when I see it" for determining which algorithms are HKDF algorithms.
FP: Agreed, but we don’t really have another way to say this. If you or COSE experts (Jim) have any idea please let us know.
I think we inherited this from JOSE :-/
FP: Right, that is because COSE also defines HKDF using AES-MAC, see Table 12 of RFC8152, so we needed to specify that only HMAC-based can be used.
Oof, rather unfortunate IMO that the terminology was overloaded by RFC
8152.
44. alg: This parameter identifies the OSCORE AEAD Algorithm. For more
information about this field, see section 3.1 of
[I-D.ietf-core-object-security] The values used MUST be registered
in the IANA "COSE Algorithms" registry and MUST be AEAD
algorithms. The value can either be the integer or the text
Similarly, this seems to be "I know it when I see it".
FP: Yes.
45. contextId: This parameter identifies the security context as a byte
string. This identifier is used as OSCORE ID Context. For more
information about this field, see section 3.1 of
[I-D.ietf-core-object-security]. In JSON, the "contextID" value
is a Base64 encoded byte string. In CBOR, the "contextID" type is
bstr, and has label 7.
Do we need to forbid present-but-empty contextIds in order to avoid
cryptographic collision with absent-contextId?
FP: The field being present but empty (i.e. value is the empty byte string) is not the same as absent, in OSCORE. So we do not need to forbid that.
Cool.
46. rpl: This parameter is used to carry the OSCORE value, encoded as a
bstr. This parameter identifies the OSCORE Replay Window Size and
Type value, which is a byte string. For more information about
this field, see section 3.1 of [I-D.ietf-core-object-security].
In JSON, the "rpl" value is a Base64 encoded byte string. In
CBOR, the "rpl" type is bstr, and has label 8.
I tried to follow the reference, but I couldn't really find a
description of the encoding for this as a byte string (especially
noteworthy since we claim that it represents both size and type).
(Relatedly, I'm not sure why it's allowed to be either bstr or int.)
FP: Right, this is an old reference, where we actually gave a default encoding for rpl, I believe. Now this is entirely up to the application. I would keep this as bstr and specify that it is any format wrapped in a bstr.
"Up to the application" meaning known by prior agreement among all three of
C, AS, and RS?
Also I need to fix a couple of mistakes: “OSCORE value” is wrong; “Replay Window” and not "Size and Type". Also, I think we need to define a new IANA registry for rpl with 0 as default, so that applications can define their format.
I'm not entirely sure I understand that the registry is for (i.e., what you
propose).
respective subsections)?
FP: I am not sure what you’d like to see in CDDL in this subsection, could you expand?
I am not sure what the body of the POST and response thereto are formatted
as. Maybe CDDL is not quite right, if we only want to provide an example
with a particular content-format but allow many formats.
some discussion of normal protected OSCORE request/response pairs once
the security context is fully established, but this initial section
basically only talks about the authz-info interaction and disclaims that
the subsections will cover anything else.
FP: Ok, will add some introductory text about the OSCORE security context being used of future OSCORE protected communication.
Thanks!
49. The following subsections describe the details of the POST request
and response to the authz-info endpoint between client and RS. The
client generates a nonce N1 and posts it together with the token that
includes the materials provisioned by the AS to the RS. The RS then
derives a nonce N2 and use Section 3.2 of
nits: "provisioned" again, and the RS is going to be generating a nonce
from scratch, not deriving one from ... anything else, really.
FP: Done in PR.
50. [I-D.ietf-core-object-security] to derive a security context based on
a shared master secret and the two nonces, established between client
and server.
(The shared master secret is part of what the AS provisions^Wgives to
the RS, right?)
FP: Yes, correct. Actually here it is also the clientId, serverId and contextId (if any) that are used for deriving the OSCORE context.
51. Note that the proof-of-possession required to bind the access token
to the client is implicitly performed by generating the shared OSCORE
Security Context using the pop-key as master secret, for both client
and RS. An attacker using a stolen token will not be able to
generate a valid OSCORE context and thus not be able to prove
possession of the pop-key.
It may be worth saying something roughly equating "proof of possesion
performed by the RS" and "the RS authenticating itself to the client",
since there is not an external action for server authentication.
Also, ISTR getting some pushback on a different document that talked
about an attacker with a "stolen token", as something that can steal a
token from the client's local storage might also steal the associated
key. I forget if we ended up changing to some other phrasing or not,
though :(
FP: Ok, will rephrase to “the RS authenticating itself” instead of “pop performed by the RS”. Also, what about using eavesdrop here instead?
Eavesdrop may be too limited, as I think it's also in scope for the attack
when an RS receives (whether legitimately or by deception) the token in
question as the target of a CoAP request.
52. The client MUST generate a nonce N1 very unlikely to have been
previously used with the same input keying material. This profile
RECOMMENDS to use a 64-bit long random number as nonce. The client
Why 64 instead of 128? I know that 128 is enough without having to
think about it; for 64 we have to be clear about what role the nonce is
serving.
FP: We brought this up in the wg and everybody seemed to be ok with 64. We can go up to 128 if you think it’s better. Also consider that OSCORE appendix B2 has a similar setting and does some considerations about that, mentioning that "typically nonces of at least 8 bytes will be used". Maybe add a reference?
https://tools.ietf.org/html/rfc8613#page-72 I brought it up as one of the points the wg should agree on.
53. Note that the use of the payload and the Content-Format is different
from what described in section 5.8.1 of [I-D.ietf-ace-oauth-authz],
which only transports the token without any CBOR wrapping. In this
profile, the client MUST wrap the token and N1 in a CBOR map. The
client MUST use the Content-Format "application/ace+cbor" defined in
section 8.14 of [I-D.ietf-ace-oauth-authz]. The client MUST include
the access token using the correct CBOR label (e.g., "cwt" for CWT,
"jwt" for JWT) and N1 using the 'cnonce' parameter defined in section
5.1.2 of [I-D.ietf-ace-oauth-authz].
That's not what the 'cnonce' parameter is for -- 'cnonce' is protecting
the RS against replay, but N1 is protecting the client. I think we need
to use a different name (and maybe define some integer map label
values?) for this authz-info POST body.
FP: As mentioned, this was raised as an open point and ok by the wg (and particularly Ludwig and Jim).
54. The access token MUST be encrypted, since it is transferred from the
client to the RS over an unprotected channel.
This is probably worth stating in Section 3.2 as well, where we discuss
the AS-to-C token response in more detail.
FP: OK.
55. Note that a client may be required to re-POST the access token, since
an RS may delete a stored access token, due to lack of memory.
I'd suggest using the phrase "at any time" and noting that the client
will detect this by receiving an AS Request Creation Hints message since
the RS treated the request as an Unauthorized Resource Request, perhaps:
% Note that a client may be required to re-POST the access token in
% order to complete a request, since an RS may delete a stored access
% token at any time, for example due to all storage space being
% consumed. This situation is detected by the client when it receives
% an AS Request Creation Hints response.
FP: OK.
56. Payload:
{
"access_token": h'a5037674656d7053656e73 ...'
(remainder of access token omitted for brevity)',
"cnonce": h'018a278f7faab55a'
}
This does not appear to be using either a "cwt" label or "jwt" label, as
the second paragraph of the section would have us using.
FP: OK. Will use "cwt".
57. token. If the token is valid, the RS MUST respond to the POST
request with 2.01 (Created). If the token is valid but is associated
We probably don't need to repeat the normative requirements from
the core framework with normative keywords again.
FP: OK.
58. to claims that the RS cannot process (e.g., an unknown scope), or if
any of the expected parameters in the OSCORE_Security_Context is
Hmm, "associated to claims that the RS cannot process" sounds like we're
telling the RS to abort if the token includes any unrecognized claims,
which IIUC is at odds with the OAuth 2.0 philosophy of ignoring
unrecognized parameters. (Hopefully someone will correct me if I'm
misremembering that.)
FP: This paragraph is meant to mirror what specified in 5.8.1.1 of ace-oauth-authz:
If the claims cannot be obtained the RS MUST discard the token
and, in case of an interaction via the authz-info endpoint, return
an error message with a response code equivalent to the CoAP code
4.00 (Bad Request).
Next, the RS MUST verify claims, if present, contained in the access
token. Errors are returned when claim checks fail, in the order of
priority of this list:
Ah, maybe the ace framework diverges from oauth here and I misremembered.
But is this behavior limited to "any of the four standard claims that have
a value that cannot be processed" or does it also include "there was an
unrecognized claim"?
59. missing (e.g. any of the mandatory parameters from the AS), or if any
nit: comma after "e.g.".
FP: Done in PR
60. Additionally, the RS MUST generate a nonce N2 very unlikely to have
been previously used with the same input keying material, and send it
within the 2.01 (Created) response. The payload of the 2.01
(Created) response MUST be a CBOR map containing the 'cnonce'
parameter defined in section 5.1.2 of [I-D.ietf-ace-oauth-authz], set
to N2. This profile RECOMMENDS to use a 64-bit long random number as
nonce. Moreover, if the OSCORE_Security_Context in the token did not
As above, we need to use a different name than 'cnonce', as it's
performing a different role (this time, contributing entropy to the
master secret). (Also, if we change our recommendation about nonce
length above we should do so here as well, of course.)
FP: OK, pending wg agreement, and OK.
61. contain a 'clientId' parameter, the RS MUST generate an identifier,
unique in the set of all its existing client identifiers, and send it
in a 'clientId' parameter in the CBOR map as a CBOR bstr. The RS MAY
generate and send a 'ClientId' identifier even though the
OSCORE_Security_Context contained such a parameter, in order to
guarantee the uniqueness of the client identifier. The RS MUST use
I'm not sure I understand the case where the AS wouldn't be able to
guarantee uniqueness of ClientId, and wonder if we could simplify by
always having the AS make ID assignment. Is there some more
background/usage scenarios here that I'm missing?
FP: No that's it. The case I was trying to cover is having several AS cover the same resource at the same RS. Then we would have to have them synchronized for uniqueness of ClientId. But yes. Agree on removing this mechanism.
62. When receiving an updated access token with updated authorization
information from the client (see section Section 3.1), it is
RECOMMENDED that the RS overwrites the previous token, that is only
the latest authorization information in the token received by the RS
is valid. This simplifies for the RS to keep track of authorization
information for a given client.
[this same recommendation is already in the core framework]
FP: OK, will remove normative text and reference framework.
63. the 'clientId' in the CBOR map in the payload of the response. Then,
the client MUST set the Master Salt of the Security Context created
to communicate with the RS to the concatenation of salt, N1, and N2,
in this order: Master Salt = salt | N1 | N2, where | denotes byte
string concatenation, and where salt was received from the AS in
Section 3.2. The client MUST set the Master Secret and Recipient ID
I think it's general best practice to use an injective mapping of the inputs
to the Master Salt value (i.e., length-prefixes for the various fields, since
there are no reserved octet values).
FP: OK, using CBOR encoded bstr (or b64 if JSON is used) should fix that.
64. from the parameters received from the AS in Section 3.2. The client
MUST set the AEAD Algorithm, ID Context, HKDF, and Replay Window from
the parameters received from the AS in Section 3.2, if present. In
case these parameters are omitted, the default values are used as
described in section 3.2 of [I-D.ietf-core-object-security]. The
Ah, okay; I'd asked about default values earlier. That said, if stock OSCORE
ever changes the defaults we'd have to come up with a compatibility story for
communication between old/new nodes.
FP: Yes. Maybe adding a version number to this context structure? I think this is a good idea.
It's hard to argue that a version number would be a bad idea, so that seems
reasonable.
65. client MUST set the Sender ID from the 'clientId in the 2.01
(Created) response, if present; otherwise, the client MUST set the
Sender ID from the parameters received from the AS in Section 3.2.
[As written, this has the clientId from the RS take precedence over the one
from the AS when both are present. I understand that the claimed
justification is for the RS to be able to enforce clientId uniqueness, but it
still feels risky, since the value from the RS is unauthenticated.]
FP: Let's remove this mechanism.
66. If any of the expected parameters is missing (e.g. any of the
mandatory parameters from the AS, or the 'clientId', either received
from the AS or in the 2.01 (Created) response from the RS), the
client MUST stop the exchange, and MUST NOT derive the Security
Context. The client MAY restart the exchange, to get the correct
security material.
I think this means "restart at the AS" but it's probably worth being very
explicit about it.
FP: Yes, OK will clarify.
FP: OK, will add a sentence about that.
67. After sending the 2.01 (Created) response, the RS MUST set the Master
Salt of the Security Context created to communicate with the client
to the concatenation of salt, N1, and N2, in this order: Master Salt
= salt | N1 | N2, where | denotes byte string concatenation, and
[It might be worth breaking this computation off into a standalone piece of
text that applies to both C and RS, including the edits for injectivity.]
FP: OK
68. where salt was received from the AS in Section 4.2. The RS MUST set
the Master Secret, Sender ID and Recipient ID from the parameters,
received from the client in the access token in Section 4.1 after
nit: I'd place the emphasis more on "in the access token" or even "from the
AS" rather than "from the client" -- the RS/AS preestablished relationship is
what authenticates these values.
FP: Done in PR: "from the AS forwarded by the client".
69. validation of the token as specified in Section 4.2. The RS MUST set
Does Section 4.2 really say much about validation other than "RS MUST verify
the validity of the token"?
FP: well, that and points to 5.8.1 of ace-oauth-authz. I pointed to the framework not to duplicate the reference, but we can do that if you think it’s best.
I think I was just wondering if we should skip the Section-4.2 indirection
and refer directly to the framework. What's in place now is okay, though.
70. [I-D.ietf-core-object-security]. After that, the RS MUST derive the
complete Security Context following section 3.2.1 of
[I-D.ietf-core-object-security], and MUST associate this Security
Context with the authorization information from the access token.
side note: it's sometimes useful as a rhetorical device to have a discussion
of the abstract data model the RS uses -- in this case, that it maintains a
collection of Security Contexts with associated authorization information,
for all the clients that it's currently communicating with, and that the
authorization information is policy that's used as input to processing
requests from those clients. Otherwise, this text about "MUST associate" can
be a bit vague to the reader.
FP: OK, will add this clarification in this section.
71. The RS then uses this Security Context to verify the request and send
responses to C using OSCORE. If OSCORE verification fails, error
(nit?) what is "the request"? I don't think we've talked about a specific
OSCORE request yet, so this would probably be better if talking about generic
incoming requests from a given client.
FP: Done in PR: "verify requests and sends responses".
72. responses are used, as specified in section 8 of
[I-D.ietf-core-object-security]. Additionally, if OSCORE
verification succeeds, the verification of access rights is performed
as described in section Section 4.4. The RS MUST NOT use the
Security Context after the related token has expired, and MUST
respond with a unprotected 4.01 (Unauthorized) error message.
nit: I suggest "MUST respond with an unprotected [...] error message to
requests received that correspond to a security context with an expired
token" to tie it back to which requests are affected.
FP: Done in PR.
73. If the exchange was an update of access rights, i.e. a new Security
nit: comma after "i.e.".
FP: Done in PR.
74. Context was derived from a client that already had a Security Context
in place, the is RECOMMENDED to delete the old Security Context after
OSCORE verification and verification of access rights succeed. The
RS MUST delete the Security Context if it deletes the access token
associated to it.
I'm not sure I understand what the workflow is, here -- I assume that the
deletion of the old security context occurs after a successful update via
the authz-info endpoint (as opposed to some particular OSCORE-protected
request), but I don't know what "verification of access rights" could be
performed at that time. Aren't access rights mostly tied to a specific
operation, or is this just supposed to be a more generic audience/scope
check?
FP: The RS deletes the old token and the old security context only after successfully processing a request from the client, using the new token and security context. That includes OSCORE verification and also access rights verification, like any normal request. Is that not clear? How to make it clearer?
It sounds like it's just my misreading: "OSCORE verification" clearly
implies an OSCORE request (i.e., not the authz-info endpoint).
75. The RS MUST follow the procedures defined in section 5.8.2 of
[I-D.ietf-ace-oauth-authz]: if an RS receives an OSCORE-protected
request from a client, then the RS processes it according to
[I-D.ietf-core-object-security]. If OSCORE verification succeeds,
and the target resource requires authorization, the RS retrieves the
nit(?): is it appropriate to say "requires additional authorization" (over
the implicit authorization given to any authenticated client)? I'm not sure
if that would be confusing or not.
FP: I would think this is more confusing than clarifying because we don’t talk about implicit authorization in this document. We can make this change if other people agree that this formulation is better.
Understood; leaving it as-is is okay.
76. authorization information from the access token associated to the
Security Context. The RS then MUST verify that the authorization
information covers the resource and the action requested.
In the vein of my previous note about an abstract data model, we may not want
to be overly prescriptive about "retrieves [...] from the access token".
Per-request introspection is allowed, as is caching the authorization
information in a non-token local datastore.
FP: Ok, I understand but I am not sure how to implement this comment. “Retrieve” may be misinterpreted, but in my mind it can mean both by looking up caching info as well as introspecting. How to make this clearer?
Would s/from/using/ work?
FP: OK
77. The response code MUST be 4.01 (Unauthorized) in case the client has
not used the Security Context associated with the access token, or if
RS has no valid access token for the client. If RS has an access
The causality here seems a bit weird; how would the RS know what token was
intended just from an OSCORE request that's using a random or different
security context?
FP: The RS needs to keep this association between Security Context and token. This first section covers the case where the client is using a sec ctx not associated to any token or where that sec ctx was not used before (so the full OSCORE setup did not go through). Different (“valid”) security context associated to a token is covered in the next section. Is there anything I am missing here?
I think I'm just complaining about the wording: if a request comes in using
some other (wrong) security context, how does the RS know what the relevant
"the access token" is for that request?
78. token for the client but not for the resource that was requested, RS
MUST reject the request with a 4.03 (Forbidden). If RS has an access
I'd suggest rephrasing this to be in terms of authorization rather than
"token for X", perhaps as "if the RS has an access token for the client but
no actions are authorized on the target resource"
FP: OK
79. token for the client but it does not cover the action that was
requested on the resource, RS MUST reject the request with a 4.05
(Method Not Allowed).
Similarly, perhaps "but the requested action is not authorized".
FP: OK
FP: Yes, this whole second paragraph re-iterates that section. We can remove it, the only thing left will be to specify that “performed proof-of-possession” = “having an OSCORE security context established”
and C/AS must be established independently of any of the mechanisms defined
in this document, and that the protocols used for the C/RS, C/AS, and RS/AS
steps can be selected independently.
FP: Good that it's clear.
81. Furthermore the requesting entity and the AS communicate using OSCORE
([I-D.ietf-core-object-security]) through the introspection endpoint
as specified in section 5.7 of [I-D.ietf-ace-oauth-authz] and through
the token endpoint as specified in section 5.6 of
[I-D.ietf-ace-oauth-authz].
I'm not entirely sure what this sentence is trying to say -- it comes across
a little bit as saying that when this document is in use, the indicated
interactions also use OSCORE, but that of course can't be what's actually
intended. Perhaps just saying that the behavior of the introspection
endpoing is specified in section 5.7 of [framework] and that of the token
endpoint is specified in section 5.6 of [framework] would suffice?''
FP: No, this sentence wanted to add to the previous (“if OSCORE is used”), and just point to the framework’s section for the specific behaviours. Will rephrase.
82. o the client receives a number of 4.01 Unauthorized responses to
OSCORE requests using the same security context. The exact number
needs to be specified by the application.
Is this a global counter or does it get reset by a successful OSCORE
response?
FP: I would say this gets reset by a successful OSCORE response. But probably the application would have to define that as well. Do we need to add any text about this?
Probably not, since this is a pretty typical class of behavior. If it was
a global counter that never got reset that would be noteworthy.
83. o the client receives a new nonce in the 2.01 (Created) response
(see Section 4.2) to a POST request to the authz-info endpoint,
when re-posting a non-expired token associated to the existing
context.
Why is "non-expired" specifically relevant?
FP: because if it’s expired the RS will not accept that token. This was just for clarification.
What about adding a parenthesis “(non-expired)”?
Sure!
84. The RS MUST discard the current security context associated with a
client when:
nit: we should make the grammar of the list elements parallel to the client's
list, so "the Sequence Number space ends." and "the access token associated
with the context expires".
FP: Done in PR.
previously used", and it might be worth trying to quantify that (e.g.,
"chance of inadvertent collision less than 2^-32").
FP: This is hard to quantify in a general case. But we can add some text about avoiding inadvertent collisions.
the consequences of the authz-info exchange being completely
unprotected.
FP: Let's discuss that in the point above.
87. a secure binding between the request and the response(s). Thus the
basic OSCORE protocol is not intended for use in point-to-multipoint
communication (e.g. multicast, publish-subscribe). Implementers of
nit: comma after "e.g.".
FP: Done in PR.
88. provoke re-use. If that is not guaranteed, nodes are still
susceptible to re-using AEAD nonces and keys, in case the Security
Context is lost, and on-path attacker replay messages.
This text is talking about AEAD nonces, but the nonces (and 64-bit
recommendation) previously discussed are the nonces used in the Master Salt
(and thus Master Secret) calculation; we don't really talk about AEAD nonces
specifically anywhere in the document, other than to point out the risk of
(nonce, key) reuse. IIUC, vulnerable nodes would need to reuse both the
N1 or N2 values defined in this spec as well as the OSCORE partial IV in
order to collide the AEAD (nonce, key) pair (noting that both key and common
IV are influenced by the Master Salt). That said, if the N1 generation is
flawed it seems quite plausible that PIV generation is similarly flawed, so
we are right to document the concern.
Also, the grammar here is a little bit weird, so perhaps a rewording to:
% provoke re-use. If that is not guaranteed, nodes are
% susceptible to re-use of AEAD (nonces, keys) pairs, especially since an on-path
% attacker can cause the client to use an arbitrary nonce for Security
% Context establishment. Even partial loss of Security Context information
% can allow an on-path attacker to replay messages.
though I'm not entirely sure I understand which replay scenarios you had in
mind.
FP: I think the last sentence in your rewording is partially changing the intent of the paragraph. Partial loss does not allow attacker to replay messages; what was meant by that is that, if the context is lost (think reboot without use of persistent memory, where partial IV could reset to previously used IVs, and node’s nonce resets to previously used nonce) and at the same time the attacker replays an old message (so second nonce is previously used too), that creates the problem. I would just remove the last sentence of your reworded paragraph and would be fine with that.
Ah, right, so it's more like "Reuse of AEAD nonces and keys is also
possible by replay of client-to-server messages when state is lost." (IIUC
the replay attack and the "on-path attacker forces a nonce" case are
attacking different protocol actors.)
89. This profiles recommends that the RS maintains a single access token
nit: "This profile" singular.
FP: Done in PR.
90. Also, tokens may contradict each other which may lead the server to
enforce wrong permissions. If one of the access tokens expires
Could you give me an example of the contradiction scenarios? I see the
"common" case as being roughly "Token T1 gives access to the set X of
resources and token T2 gives access to a partially disjoint set Y of
resources", but I don't know that such a scenario would be considered a
"conflict". To get a conflict I'd expect more like "token T1 indicates that
access to X is to be denied, but token T2 indicates that access to X is to be
allowed" with some sort of explicit negative ACL, but I don't think OAuth
really has a concept of negative ACL.
FP: No, I meant what you describe as the common case. The contradiction coming from the fact that one token would give access to a set X of resource that the other token would not give access to. A server implementation might check only one token, which could lead to wrong permissions. Do we need to say anything else here?
How would "if tokens indicate different or disjoint permissions from each
other" work?
91. There might be a few more privacy considerations worth mentioning:
token is used with multiple audiences or RSes, a client that uses the same
token from multiple locations can be tracked/correlated by the access
token's value.
FP: OK
FP: OK
FP: that’s right, unless client and server swap roles, in which case also serverId (acting as client) could go on the wire. I thought OSCORE should have this covered. What additional details are missing here?
From memory the main new part is that the AS (a third party) is assigning
the identifiers and has information that could (whether by malice or
incompetence) aid in tracking the client/server.
FP: same, referencing OSCORE should cover it, no?
Most likely.
92. o Profile Description: Profile for using OSCORE to secure
communication between constrained nodes using the Authentication
and Authorization for Constrained Environments framework.
This is the registry for ACE profiles; "using the Authentication and
Authorization for Constrained Envirornments framework" feels redundant.
There's also perhaps something to say about defining "coap_oscore" for all
three interaction flows even though the procedures for two of the three are
essentially just "out of the scope of this specification", though having
some identifier for "use OSCORE" is probably still useful.
FP: Ok, we can remove the last part. About the interaction flows between nodes, I am not sure what you mean, as by following definition https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-31#section-5.6.4.3 it is not mandatory for a profile to specify C-AS and RS-AS, those flows can be out of scope. Am I missing something?
It's not mandatory, though given that we talk about profiles not being able
to assume that the same profile is used for any/all of C/RS, C/AS, and
RS/AS, I guess I assumed that we use the profile identifier to talk about
the last two cases as well as the first one. Maybe I'm wrong to assume
that!
Regardless, I think the question here is whether we want to have people use
the "coap_oscore" string to indicate that C/AS and/or RS/AS use OSCORE, or
if that information is not expected to be encoded in any protocol element;
if the latter, then there's nothing to change.
93. name The JSON name requested (e.g., "ms"). Because a core goal of
this specification is for the resulting representations to be
compact, it is RECOMMENDED that the name be short. This name is
case sensitive. Names may not match other registered names in a
case-insensitive manner unless the Designated Experts state that
there is a compelling reason to allow an exception. The name is
nit: I'd suggest s/state/determine/
FP: Done in PR
94. CBOR label The value to be used to identify this algorithm. Key map
labels MUST be unique. The label can be a positive integer, a
nit: s/Key map/Map key/
FP: Done in PR
95. negative integer or a string. Integer values between 0 and 255
and strings of length 1 are designated as Standards Track Document
required. Integer values from 256 to 65535 and strings of length
2 are designated as Specification Required. Integer values of
greater than 65535 and strings of length greater than 2 are
designated as expert review. Integer values less than -65536 are
marked as private use.
So use of negative integers from -65535 to -1 and positive integers greater
than or equal to 65536 is not defined?
FP: OK Right we missed it. We will fix it.
FP: OK
previous commentary about shorter names being preferred. :)
FP: Typically this whole name should not be sent when CBOR is used (so in constrained environments). But we’ll shorten it, what about "Sec_Ctx"?
There's no need to shorten it just on my account; as you note, it's
generally going to be the CBOR tag that's used.
97. o Confirmation Method Description: OSCORE_Security_Context carrying
the OSCORE Security Context parameters
I'd suggest rewording the description to "parameters for using OSCORE
per-message security with implicit key confirmation"
FP: Ok, still would like to keep OSCORE_Security_Context (or whatever the structure will be called) somewhere in the description.
98.
[same suggested rewording]
FP: OK
sway the experts' decisions, as opposed to just what the experts should
consider. :)
FP: good.
100. The IANA registry established in this document is defined as expert
review. This section gives some general guidelines for what the
nit: I suggest "defined to use the Expert Review registration policy".
FP: Done in PR
101. The zones tagged as private use are intended for testing purposes
and closed environments, code points in other ranges should not be
assigned for testing.
nit: comma splice
FP: TIL comme splices. Done in PR.
102. o Specifications are required for the standards track range of point
assignment. Specifications should exist for specification
required ranges, but early assignment before a specification is
available is considered to be permissible. Specifications are
side note: this is a little awkward, as RFC 7120 formally does not allow
"early allocations" for the "Expert Review" policy, so there is not a formal
procedure in place to review and expire early allocations that end up not
being needed. It might be worth something to chat with the IANA table about
in Vancouver.
FP: Sure, we will check with IANA. We got inspired by (read shamelessly stole from) COSE here.
normative, but I'm not concerned about it one way or the other for now.
FP: OK, will keep in mind.
Do we expect to keep this content in the final RFC? If we do, we should
resynchronize to the current list in Appendix C of the framework :)
FP: Definitely should resynchronize. Yes I’d like this content to stay.
105. o how/if the authz-info endpoint is protected: Security protocol
above
I thought authz-info was fully unprotected, per Section 4.1's "The authz-info
endpoint is not protected, nor are the responses from this resource."
FP: OK, will fix.
Thanks for working through all the comments!
-Ben
The text was updated successfully, but these errors were encountered: