Draft: draft-ietf-ace-oscore-profile

Commentary: as decided at IETF103 ( sl . 15 of the ) 
 Hi , could you take a look at the latest changes and see if they work for you ? Additionally to the nonces construction , the last 3 commits make some changes in order for the profile to be consistent with the ace - key - groupcomm to implement your review changes : I am done with the PR on ace - key - groupcomm as well , I will post it to the mailing list as reply to your review , feel free to check it out ! 
 I will get to the review , but one of the cases that need to be thought through is also going to be the introspection case . 
 I think I should have answered all your points . Let me know if you think they are correctly addressed . We were hoping to submit a new version very soon , also because the ace - key - groupconmm needs the OSCORESecurityContext defined here . So we need to update this before updating that one . 
 Go ahead and publish - we can always make more updates if it is really needed
Paragraph (version A):
Once the client has retrieved the access token, it posts it to the RS
using the authz-info endpoint and mechanisms specified in section 5.8
of I-D.ietf-ace-oauth-authz.  If the access token is valid, the RS
replies to this request with a 2.01 (Created) response, which
contains a nonce N1.
Paragraph (version A):
After receiving the nonce N1, the client generates a nonce N2,
concatenates it with N1 and sets the ID Context in its Security
Context (see section 3 of I-D.ietf-core-object-security) to N1
concatenated with N2.  The client then derives the complete Security
Context from the ID Context plus the parameters received from the AS.
Paragraph (version A):
Finally, the client sends a request protected with OSCORE to the RS.
This message contains the ID Context value.  When receiving this
request after the 2.01 (Created) response, the server extract the ID
Context from it, verifies that the first part is equal to the nonce
N1 it previously sent, and if so, sets its own ID Context and derives
the complete Security Context from it plus the parameters received in
the AS, following section 3.2 of I-D.ietf-core-object-security.  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.  Once the client receives a valid
response, it does not continue to include the ID Context value in
further requests.
Paragraph (version B):
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.
Paragraph (version B):
If the access token is valid, the RS replies to this request with a
which contains a nonce N2 in a CBOR map.  Moreover, the server
concatenates N1 with N2 and sets the ID Context in the Security
Context (see section 3 of I-D.ietf-core-object-security) to N1
concatenated with N2.  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.
Paragraph (version B):
After receiving the nonce N2, the client concatenates it with N1 and
sets the ID Context in its Security Context (see section 3 of I-
D.ietf-core-object-security) to N1 concatenated with N2.  The client
then derives the complete Security Context from the ID Context plus
the parameters received from the AS.
Paragraph (version B):
Finally, the client sends a request protected with OSCORE to the RS.
This message may contain the ID Context value.  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.
Once the client receives a valid response, it does not continue to
include the ID Context value in further requests.
Paragraph (version A):
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
OSCORE_Security_Context is a CBOR map object, defined in oscore-sec-
ctx.  The AEAD algorithm MAY be included as the 'alg' parameter in
the OSCORE_Security_Context; the HKDF algorithm MAY be included as
the 'hkdf' parameter of the OSCORE_Security_Context, the salt MAY be
included as the 'salt' parameter of the COSCORE_Security_Context and
the replay window type and size MAY be included as the 'rpl' of the
OSCORE_Security_Context, as defined in oscore-sec-ctx.
Paragraph (version B):
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
OSCORE_Security_Context is a CBOR map object, defined in oscore-sec-
ctx.  The AEAD algorithm MAY be included as the 'alg' parameter in
the OSCORE_Security_Context; the HKDF algorithm MAY be included as
the 'hkdf' parameter of the OSCORE_Security_Context, the salt MAY be
included as the 'salt' parameter of the COSCORE_Security_Context, and
the replay window type and size MAY be included as the 'rpl' of the
OSCORE_Security_Context, as defined in oscore-sec-ctx.
Paragraph (version A):
The AS MUST also assign identifiers to both client and RS, which are
then used as Sender ID and Recipient ID in the OSCORE context as
described in section 3.1 of I-D.ietf-core-object-security.  The
client identifiers MUST be unique in the set of all clients on a
single RS, and RS identifiers MUST be unique in the set of all RS for
any given client.  Moreover, these MUST be included in the
OSCORE_Security_Context, as defined in oscore-sec-ctx.
Paragraph (version B):
The AS MUST also assign an identifier to the RS, and MAY assign an
identifier to the client.  These identifiers are then used as Sender
ID and Recipient ID in the OSCORE context as described in section 3.1
of I-D.ietf-core-object-security.  The client identifiers MUST be
unique in the set of all clients on a single RS, and RS identifiers
MUST be unique in the set of all RS for any given client.  Moreover,
when assigned, these MUST be included in the OSCORE_Security_Context,
as defined in oscore-sec-ctx.
Paragraph (version B):
The same CWT token as in ex2, using the value abbreviations defined
in I-D.ietf-ace-oauth-authz and I-D.ietf-ace-cwt-proof-of-possession
and encoded in CBOR is shown in ex2-cbor.
Paragraph (version B):
NOTE TO THE RFC EDITOR: before publishing, it should be checked (and
in case fixed) that the values used below (which are not yet
registered) are the final values registered in IANA.
Paragraph (version A):
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 "repl" value is a Base64 encoded byte string.  In CBOR,
the "repl" type is bstr, and has label 7.
Paragraph (version B):
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.
Paragraph (version B):
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 "repl" value is a Base64 encoded byte string.  In CBOR,
the "repl" type is bstr, and has label 8.
Paragraph (version A):
The following subsections describe the details of the POST request
and response to the authz-info endpoint between client and RS.  The
client posts the token that includes the materials provisioned by the
AS to the RS, which can then use Section 3.2 of I-D.ietf-core-object-
security to derive a security context based on a shared master secret
and a set of other parameters, established between client and server.
Paragraph (version B):
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 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.
Paragraph (version A):
The client MUST use CoAP and the Authorization Information resource
as described in section 5.8.1 of I-D.ietf-ace-oauth-authz to
transport the token to the RS.
Paragraph (version B):
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
MUST store this nonce as long as the response from the RS is not
received and the access token related to it is still valid.  The
client MUST use CoAP and the Authorization Information resource as
described in section 5.8.1 of I-D.ietf-ace-oauth-authz to transport
the token and N1 to the RS.  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
'nonce' parameter defined in section 5.1.2 of I-D.ietf-ace-oauth-
authz.
Paragraph (version A):
ex3 shows an example of the request sent from the client to the RS.
Paragraph (version B):
ex3 shows an example of the request sent from the client to the RS,
in CBOR diagnostic notation without the tag and value abbreviations.
Paragraph (version A):
The RS MUST follow the procedures defined in section 5.8.1 of I-
D.ietf-ace-oauth-authz: the RS MUST verify the validity of the token.
If the token is valid, the RS MUST respond to the POST request with
that the RS cannot process (e.g., an unknown scope) the RS MUST
respond with a response code equivalent to the CoAP code 4.00 (Bad
Request).  In the latter case the RS MAY provide additional
information in the error response, in order to clarify what went
wrong.  The RS MAY make an introspection request to validate the
token before responding to the POST request to the authz-info
endpoint.
Paragraph (version A):
Additionally, the RS MUST generate a nonce (N1) with a good amount of
randomness, and include it in the payload of the 2.01 (Created)
response as a CBOR byte string.  This profile RECOMMENDS to use a
nonce of 64 bits.  The RS MUST store this nonce as long as the access
token related to it is still valid.
Paragraph (version A):
Note that, when using this profile, an identifier of the token (e.g.,
the cti for a CWT) is not transported in the payload of this request,
as section 5.8.1 of I-D.ietf-ace-oauth-authz allows.
Paragraph (version B):
The RS MUST follow the procedures defined in section 5.8.1 of I-
D.ietf-ace-oauth-authz: the RS MUST verify the validity of the token.
If the token is valid, the RS MUST respond to the POST request with
that the RS cannot process (e.g., an unknown scope), or if any of the
expected parameters in the OSCORE_Security_Context is missing (e.g.
any of the mandatory parameters from the AS), the RS MUST respond
with a response code equivalent to the CoAP code 4.00 (Bad Request).
In the latter case the RS MAY provide additional information in the
error response, in order to clarify what went wrong.  The RS MAY make
an introspection request to validate the token before responding to
the POST request to the authz-info endpoint.
Paragraph (version B):
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 'nonce'
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
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
the Content-Format "application/ace+cbor" defined in section 8.14 of
I-D.ietf-ace-oauth-authz.
Paragraph (version B):
ex4 shows an example of the response sent from the RS to the client,
in CBOR diagnostic notation without the tag and value abbreviations.
Paragraph (version A):
Once receiving the 2.01 (Created) response from the RS, following the
POST request to authz-info endpoint, the client MUST extract the
nonce N1 from the CBOR byte string in the payload of the response.
The client MUST generate itself a nonce (N2) with a good amount of
randomness.  This profile RECOMMENDS to use a nonce of 64 bits.
Then, the client MUST set the ID Context of the Security Context
created to communicate with the RS to the concatenation of N1 and N2,
in this order: ID Context = N1 | N2, where | denotes byte string
concatenation.  The client MUST set the Master Secret, Sender ID and
Recipient ID from the parameters received from the AS in as-c.  The
client MUST set the AEAD Algorithm, Master Salt, HKDF and Replay
Window from the parameters received from the AS in as-c, 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.  After
that, the client MUST derive the complete Security Context following
section 3.2.1 of I-D.ietf-core-object-security.  From this point on,
the client MUST use this Security Context to communicate with the RS
when accessing the resources as specified by the authorization
information.
Paragraph (version A):
The client then uses this Security Context to send requests to RS
using OSCORE.  In the first request sent to the RS, the client MUST
include the kid context, with value ID Context, i.e. N1 concatenated
with N2.  The client needs to make sure the RS receives the kid
context, possibly adding the kid context to later requests, until it
receives a valid OSCORE response from the RS using the same Security
Context.
Paragraph (version A):
When the RS receives this first OSCORE-protected request, it MUST
extract the kid context from the message first.  Then, it needs to
verify that the first part of the kid context corresponds to the
nonce N1 it previously sent, and that it is followed by a non-zero-
length byte string.  If that is verified, the RS MUST set the ID
Context to the kid context value.  Then, the RS MUST set the Master
Secret, Sender ID and Recipient ID from the parameters received from
the client in the access token in c-rs.  The RS MUST set the AEAD
Algorithm, Master Salt, HKDF and Replay Window from the parameters
received from the client in the access token in c-rs, 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.  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.  Then, the RS MUST delete the nonce N1 from memory.
Paragraph (version B):
Once receiving the 2.01 (Created) response from the RS, following the
POST request to authz-info endpoint, the client MUST extract the
nonce N2 from the 'nonce' parameter and the client identifier from
the 'clientId' in the CBOR map in the payload of the response.  Then,
the client MUST set the ID Context of the Security Context created to
communicate with the RS to the concatenation of N1 and N2, in this
order: ID Context = N1 | N2, where | denotes byte string
concatenation.  The client MUST set the Master Secret and Recipient
ID from the parameters received from the AS in as-c.  The client MUST
set the AEAD Algorithm, Master Salt, HKDF, and Replay Window from the
parameters received from the AS in as-c, 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 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 as-c.  After that, the client MUST
derive the complete Security Context following section 3.2.1 of I-
D.ietf-core-object-security.  From this point on, the client MUST use
this Security Context to communicate with the RS when accessing the
resources as specified by the authorization information.
Paragraph (version B):
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.
Paragraph (version B):
The client then uses this Security Context to send requests to RS
using OSCORE.  In the first request sent to the RS, the client MAY
include the kid context, with value ID Context, i.e. N1 concatenated
with N2.
Paragraph (version B):
After sending the 2.01 (Created) response, the RS MUST set the ID
Context of the Security Context created to communicate with the
client to the concatenation of N1 and N2, in this order: ID Context =
N1 | N2, where | denotes byte string concatenation.  The RS MUST set
the Master Secret, Sender ID and Recipient ID from the parameters,
received from the client in the access token in c-rs after validation
of the token as specified in rs-c.  The RS MUST set the AEAD
Algorithm, Master Salt, HKDF, and Replay Window from the parameters
received from the client in the access token in c-rs after validation
of the token as specified in rs-c, 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.  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.
Paragraph (version A):
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 it processes according to I-D.ietf-core-object-
security.  If OSCORE verification succeeds, and the target resource
requires authorization, the RS retrieves the 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.
Paragraph (version B):
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 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.
Paragraph (version A):
the client receives a new nonce in the 2.01 Created response (see
rs-c) to a POST request to the authz-info endpoint, when re-
posting a non-expired token associated to the existing context.
Paragraph (version B):
the client receives a new nonce in the 2.01 (Created) response
(see rs-c) to a POST request to the authz-info endpoint, when re-
posting a non-expired token associated to the existing context.
Paragraph (version A):
Since the use of nonces in the exchange guarantees uniqueness of AEAD
keys and nonces even in case of re-boots, a good amount of randomness
is required.  If that is not guaranteed, nodes are still susceptible
to re-using nonces and keys, in case the Security Context is lost,
and on-path attacker replaying messages.
Paragraph (version B):
Since the use of nonces in the exchange guarantees uniqueness of AEAD
keys and nonces, it is REQUIRED that nonces are not reused with the
same input keying material even in case of re-boots.  This document
RECOMMENDS the use of 64 bit random nonces to guarantee non-reuse; if
applications use something else, such as a counter, they need to
guarantee that reboot and lost of state on either node does not
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.
Paragraph (version A):
It is requested that IANA create a new registry entitled "OSCORE
Security Context Parameters" registry.  The registry is to be created
as Expert Review Required.  Guidelines for the experts is provided
review.  It should be noted that in additional to the expert review,
some portions of the registry require a specification, potentially on
standards track, be supplied as well.
Paragraph (version A):
This is a descriptive name that enables easier reference to the
item.  It is not used in the CBOR encoding.
Paragraph (version B):
It is requested that IANA create a new registry entitled "OSCORE
Security Context Parameters" registry.  The registry is to be created
as Expert Review Required.  Guidelines for the experts is provided
review.  It should be noted that in addition to the expert review,
some portions of the registry require a specification, potentially on
standards track, be supplied as well.
Paragraph (version B):
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 not
used in the CBOR encoding.