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).
[x] 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.
[x] 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/
[x] 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.)
[x] 24.
Moreover, the AS MUST provision the following data:
It's frequently the case in IETF documents that "provision" is a
euphemism for "out-of-band configuration", so if we mean "include in the
token response" it's probably better to say that directly.
[x] 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?
[x] 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.
[x] 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.
[x] nit: "all clients on a single RS" reads oddly to me; maybe s/on/of/?
[x] nit: I'd suggest to replace "couple" with "tuple" or "pair".
[x] 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.
[x] 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.
[x] 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".
[x] 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.
[x] 59.
missing (e.g. any of the mandatory parameters from the AS), or if any
nit: comma after "e.g.".
[x] 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.
[x] 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.
[x] 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.
[x] 73.
If the exchange was an update of access rights, i.e. a new Security
nit: comma after "i.e.".
[x] 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".
[x] 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.".
[x] 89.
This profiles recommends that the RS maintains a single access token
nit: "This profile" singular.
[x] 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/
[x] 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/
[x] 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".
[x] 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.
@kaduk review of the document: https://mailarchive.ietf.org/arch/msg/ace/rgVfs3dzcWQnNlXn331DdpQfwwQ This issue collects almost all nits from Ben's review (excluding 21. and 75. which require more information)
[x] 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).
[x] 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.
[x] 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/
[x] 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.)
[x] 24.
Moreover, the AS MUST provision the following data:
It's frequently the case in IETF documents that "provision" is a euphemism for "out-of-band configuration", so if we mean "include in the token response" it's probably better to say that directly.
[x] 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?
[x] 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.
[x] 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.
[x] nit: "all clients on a single RS" reads oddly to me; maybe s/on/of/?
[x] nit: I'd suggest to replace "couple" with "tuple" or "pair".
[x] 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.
[x] 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.
[x] 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".
[x] 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.
[x] 59.
missing (e.g. any of the mandatory parameters from the AS), or if any
nit: comma after "e.g.".
[x] 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.
[x] 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.
[x] 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.
[x] 73.
If the exchange was an update of access rights, i.e. a new Security
nit: comma after "i.e.".
[x] 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".
[x] 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.".
[x] 89.
This profiles recommends that the RS maintains a single access token
nit: "This profile" singular.
[x] 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/
[x] 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/
[x] 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".
[x] 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