Draft: draft-ietf-ace-oscore-profile

Commentary: Address  's review : See also issues : for detailed resolution of each review comment . 
 That 's right . I will add an IANA section . I think the registry that should be to is in for CBOR and for  , as specified by 
 Looks fine 
 From  's review , point 7 : Appendix - I am not sure that I think that the EDHOC profile should be in this document as oppose to being in it 's own document . The fact that we have not even tried to get this to work in any of the interop tests means that I am less sure that it is well baked . 
 from  's review , point 6 : Section 6 - Ok I 'll bite - how does not echoing the nonce allow for a man - in - the - middle attack given that the salt and shared secret are still going to be known only to the C and  and not to the MITM . I can see a DOS attack being made , but that can be done even without this just by causing the response to never be delivered . 
 taken care of by 
 Partial IV space ends ( either C or RS ) ; the kid context on the RS side does not match with N1 ( RS ) ; C receives a number of Unauthorized ( C ) , although that is a consideration / recommendations , details would be application specific Other ? From  's review , point 5 : Please add an explicit section on when a RS and a client should discard the security context . 
 It is enough for ids to be unique in the set of all clients talking to the same  + RS From  's review , point 4 : Section 3.2 - Please provide a justification for the requirement that the ids must be unique over the set of all clients and  . I can see that the client ids need to be unique on a single  and RS ids need to be unique for any given client but not the broader statement . 
 From  's review , 3rd point : Section 3.2 - Does it really make sense to use ' COSE_Key ' to transport the key data ? Would a different field name be better ? 
 and use the name of the endpoints instead From  's review , point 2 : Section 3.1 - This is more general than the section , but you should not use the URI path in the text , instead you should be using the name that is in the authz document . 
 from  's review , first point : Section 1 - I understand the reasoning behind having the server send back a nonce , although it would be good to have a description someplace about why this is being done . ( I would also make it optional as not all RS need to do this . ) I do not understand the reasoning behind having the client send a nonce to the server .
Mailing list commentary: Section 1 - I understand the reasoning behind having the server send back a nonce , although it would be good to have a description someplace about why this is being done . ( I would also make it optional as not all RS need to do this . ) I do not understand the reasoning behind having the client send a nonce to the server . Section 3.1 - This is more general than the section , but you should not use the URI path in the text , instead you should be using the name that is in the authz document . Section 3.2 - Does it really make sense to use ' COSE_Key ' to transport the key data ? Would a different field name be better ? Section 3.2 - Please provide a justification for the requirement that the ids must be unique over the set of all clients and . I can see that the client ids need to be unique on a single and RS ids need to be unique for any given client but not the broader statement . Please add an explicit section on when a RS and a client should discard the security context . Section 6 - Ok I 'll bite - how does not echoing the nonce allow for a man - in - the - middle attack given that the salt and shared secret are still going to be known only to the C and and not to the MITM . I can see a DOS attack being made , but that can be done even without this just by causing the response to never be delivered . Appendix - I am not sure that I think that the EDHOC profile should be in this document as oppose to being in it 's own document . The fact that we have not even tried to get this to work in any of the interop tests means that I am less sure that it is well baked .
Section 1 - I understand the reasoning behind having the server send back a nonce , although it would be good to have a description someplace about why this is being done . ( I would also make it optional as not all RS need to do this . ) I do not understand the reasoning behind having the client send a nonce to the server . Section 3.1 - This is more general than the section , but you should not use the URI path in the text , instead you should be using the name that is in the authz document . Section 3.2 - Does it really make sense to use ' COSE_Key ' to transport the key data ? Would a different field name be better ? Section 3.2 - Please provide a justification for the requirement that the ids must be unique over the set of all clients and . I can see that the client ids need to be unique on a single and RS ids need to be unique for any given client but not the broader statement . Please add an explicit section on when a RS and a client should discard the security context . Section 6 - Ok I 'll bite - how does not echoing the nonce allow for a man - in - the - middle attack given that the salt and shared secret are still going to be known only to the C and and not to the MITM . I can see a DOS attack being made , but that can be done even without this just by causing the response to never be delivered . Appendix - I am not sure that I think that the EDHOC profile should be in this document as oppose to being in it 's own document . The fact that we have not even tried to get this to work in any of the interop tests means that I am less sure that it is well baked .
Section 1 - I understand the reasoning behind having the server send back a nonce , although it would be good to have a description someplace about why this is being done . ( I would also make it optional as not all RS need to do this . ) I do not understand the reasoning behind having the client send a nonce to the server . Section 3.1 - This is more general than the section , but you should not use the URI path in the text , instead you should be using the name that is in the authz document . Section 3.2 - Does it really make sense to use ' COSE_Key ' to transport the key data ? Would a different field name be better ? Section 3.2 - Please provide a justification for the requirement that the ids must be unique over the set of all clients and . I can see that the client ids need to be unique on a single and RS ids need to be unique for any given client but not the broader statement . Please add an explicit section on when a RS and a client should discard the security context . Section 6 - Ok I 'll bite - how does not echoing the nonce allow for a man - in - the - middle attack given that the salt and shared secret are still going to be known only to the C and and not to the MITM . I can see a DOS attack being made , but that can be done even without this just by causing the response to never be delivered . Appendix - I am not sure that I think that the EDHOC profile should be in this document as oppose to being in it 's own document . The fact that we have not even tried to get this to work in any of the interop tests means that I am less sure that it is well baked .
Section 1 - I understand the reasoning behind having the server send back a nonce , although it would be good to have a description someplace about why this is being done . ( I would also make it optional as not all RS need to do this . ) I do not understand the reasoning behind having the client send a nonce to the server . Section 3.1 - This is more general than the section , but you should not use the URI path in the text , instead you should be using the name that is in the authz document . Section 3.2 - Does it really make sense to use ' COSE_Key ' to transport the key data ? Would a different field name be better ? Section 3.2 - Please provide a justification for the requirement that the ids must be unique over the set of all clients and . I can see that the client ids need to be unique on a single and RS ids need to be unique for any given client but not the broader statement . Please add an explicit section on when a RS and a client should discard the security context . Section 6 - Ok I 'll bite - how does not echoing the nonce allow for a man - in - the - middle attack given that the salt and shared secret are still going to be known only to the C and and not to the MITM . I can see a DOS attack being made , but that can be done even without this just by causing the response to never be delivered . Appendix - I am not sure that I think that the EDHOC profile should be in this document as oppose to being in it 's own document . The fact that we have not even tried to get this to work in any of the interop tests means that I am less sure that it is well baked .
Section 1 - I understand the reasoning behind having the server send back a nonce , although it would be good to have a description someplace about why this is being done . ( I would also make it optional as not all RS need to do this . ) I do not understand the reasoning behind having the client send a nonce to the server . Section 3.1 - This is more general than the section , but you should not use the URI path in the text , instead you should be using the name that is in the authz document . Section 3.2 - Does it really make sense to use ' COSE_Key ' to transport the key data ? Would a different field name be better ? Section 3.2 - Please provide a justification for the requirement that the ids must be unique over the set of all clients and . I can see that the client ids need to be unique on a single and RS ids need to be unique for any given client but not the broader statement . Please add an explicit section on when a RS and a client should discard the security context . Section 6 - Ok I 'll bite - how does not echoing the nonce allow for a man - in - the - middle attack given that the salt and shared secret are still going to be known only to the C and and not to the MITM . I can see a DOS attack being made , but that can be done even without this just by causing the response to never be delivered . Appendix - I am not sure that I think that the EDHOC profile should be in this document as oppose to being in it 's own document . The fact that we have not even tried to get this to work in any of the interop tests means that I am less sure that it is well baked .
Section 1 - I understand the reasoning behind having the server send back a nonce , although it would be good to have a description someplace about why this is being done . ( I would also make it optional as not all RS need to do this . ) I do not understand the reasoning behind having the client send a nonce to the server . Section 3.1 - This is more general than the section , but you should not use the URI path in the text , instead you should be using the name that is in the authz document . Section 3.2 - Does it really make sense to use ' COSE_Key ' to transport the key data ? Would a different field name be better ? Section 3.2 - Please provide a justification for the requirement that the ids must be unique over the set of all clients and . I can see that the client ids need to be unique on a single and RS ids need to be unique for any given client but not the broader statement . Please add an explicit section on when a RS and a client should discard the security context . Section 6 - Ok I 'll bite - how does not echoing the nonce allow for a man - in - the - middle attack given that the salt and shared secret are still going to be known only to the C and and not to the MITM . I can see a DOS attack being made , but that can be done even without this just by causing the response to never be delivered . Appendix - I am not sure that I think that the EDHOC profile should be in this document as oppose to being in it 's own document . The fact that we have not even tried to get this to work in any of the interop tests means that I am less sure that it is well baked .
Section 1 - I understand the reasoning behind having the server send back a nonce , although it would be good to have a description someplace about why this is being done . ( I would also make it optional as not all RS need to do this . ) I do not understand the reasoning behind having the client send a nonce to the server . Section 3.1 - This is more general than the section , but you should not use the URI path in the text , instead you should be using the name that is in the authz document . Section 3.2 - Does it really make sense to use ' COSE_Key ' to transport the key data ? Would a different field name be better ? Section 3.2 - Please provide a justification for the requirement that the ids must be unique over the set of all clients and . I can see that the client ids need to be unique on a single and RS ids need to be unique for any given client but not the broader statement . Please add an explicit section on when a RS and a client should discard the security context . Section 6 - Ok I 'll bite - how does not echoing the nonce allow for a man - in - the - middle attack given that the salt and shared secret are still going to be known only to the C and and not to the MITM . I can see a DOS attack being made , but that can be done even without this just by causing the response to never be delivered . Appendix - I am not sure that I think that the EDHOC profile should be in this document as oppose to being in it 's own document . The fact that we have not even tried to get this to work in any of the interop tests means that I am less sure that it is well baked .
Section 1 - I understand the reasoning behind having the server send back a nonce , although it would be good to have a description someplace about why this is being done . ( I would also make it optional as not all RS need to do this . ) I do not understand the reasoning behind having the client send a nonce to the server . Section 3.1 - This is more general than the section , but you should not use the URI path in the text , instead you should be using the name that is in the authz document . Section 3.2 - Does it really make sense to use ' COSE_Key ' to transport the key data ? Would a different field name be better ? Section 3.2 - Please provide a justification for the requirement that the ids must be unique over the set of all clients and . I can see that the client ids need to be unique on a single and RS ids need to be unique for any given client but not the broader statement . Please add an explicit section on when a RS and a client should discard the security context . Section 6 - Ok I 'll bite - how does not echoing the nonce allow for a man - in - the - middle attack given that the salt and shared secret are still going to be known only to the C and and not to the MITM . I can see a DOS attack being made , but that can be done even without this just by causing the response to never be delivered . Appendix - I am not sure that I think that the EDHOC profile should be in this document as oppose to being in it 's own document . The fact that we have not even tried to get this to work in any of the interop tests means that I am less sure that it is well baked .
Paragraph (version B):
Note that the term "endpoint" is used here, as in I-D.ietf-ace-oauth-
authz, following its OAuth definition, which is to denote resources
such as token and introspect at the AS and authz-info at the RS.  The
CoAP RFC7252 definition, which is "An entity participating in the
CoAP protocol" is not used in this memo.
Paragraph (version A):
This profile requires a client to retrieve an access token from the
AS for the resource it wants to access on a RS, using the token
resource, as specified in section 5.6 of I-D.ietf-ace-oauth-authz.
To determine the AS in charge of a resource hosted at the RS, the
client C MAY send an initial Unauthorized Resource Request message to
the RS.  The RS then denies the request and sends the address of its
AS back to the client C as specified in section 5.1 of 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.
Paragraph (version B):
This profile requires a client to retrieve an access token from the
AS for the resource it wants to access on a RS, using the token
endpoint, as specified in section 5.6 of I-D.ietf-ace-oauth-authz.
To determine the AS in charge of a resource hosted at the RS, the
client C MAY send an initial Unauthorized Resource Request message to
the RS.  The RS then denies the request and sends the address of its
AS back to the client C as specified in section 5.1 of 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.
Paragraph (version A):
Once the client has retrieved the access token, it posts it to the RS
using the authz-info resource 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 B):
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):
The following subsections describe the details of the POST /token
request and response between client and AS.  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 (pop-key) provisioned
from the AS MUST be used as master secret in OSCORE.
Paragraph (version A):
The client MUST send this POST /token request over a secure channel
that guarantees authentication, message integrity and confidentiality
(see introsp).
Paragraph (version A):
If the client wants to update its access rights without changing an
existing OSCORE Security Context, it MUST include in its POST /token
request a req_cnf object carrying the client's identifier (that was
assigned in section as-c) in the kid field.  This identifier 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.  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 MUST be declined with the
error code 'invalid_request' as defined in Section 5.6.3 of I-D.ietf-
ace-oauth-authz.
Paragraph (version A):
After verifying the POST /token request and that the client is
authorized to obtain an access token corresponding to its access
token request, the AS responds as defined in section 5.6.2 of I-
D.ietf-ace-oauth-authz.  If the client request was invalid, or not
authorized, the AS returns an error response as described in section
5.6.3 of I-D.ietf-ace-oauth-authz.
Paragraph (version B):
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 ID
Context, 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 ID Context is different.
Therefore, the main requirement for the nonces is that 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.
Paragraph (version B):
The following subsections describe the details of the POST request
and response to the token endpoint between client and AS.
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
(pop-key) provisioned from the AS MUST be used as master secret in
OSCORE.
Paragraph (version B):
The client MUST send this POST request to the token endpoint over a
secure channel that guarantees authentication, message integrity and
confidentiality (see introsp).
Paragraph (version B):
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 carrying the client's
identifier (that was assigned in section as-c) in the kid field.
This identifier 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.
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
MUST be declined with the error code 'invalid_request' as defined in
Section 5.6.3 of I-D.ietf-ace-oauth-authz.
Paragraph (version B):
After verifying the POST request to the token endpoint and that the
client is authorized to obtain an access token corresponding to its
access token request, the AS responds as defined in section 5.6.2 of
I-D.ietf-ace-oauth-authz.  If the client request was invalid, or not
authorized, the AS returns an error response as described in section
5.6.3 of I-D.ietf-ace-oauth-authz.
Paragraph (version A):
The master secret MUST be communicated as COSE_Key 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 the
'alg' parameter in the COSE_Key; the HKDF algorithm MAY be included
as the 'hkdf' parameter of the COSE_Key and the salt MAY be included
as the 'slt' parameter of the COSE_Key as defined in tab1.
Paragraph (version A):
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 COSE_Key structure
defined above MUST be placed in the 'cnf' claim of this token.
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.  These
identifiers MUST be unique in the set of all clients and RS
identifiers for a certain AS.  Moreover, these MUST be included in
the COSE_Key as header parameters, as defined in tab1.
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 B):
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.
Paragraph (version B):
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 A):
The following subsections describe the details of the POST /authz-
info request and response 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):
An OSCORE_Security_Context is an object that represents part or all
of an OSCORE Security Context (Section 3.1 of I-D.ietf-core-object-
security).  The OSCORE_Security_Context object can either be encoded
as JSON or as CBOR.  In both cases, the set of common parameters that
can appear in an OSCORE_Security_Context object can be found in the
IANA "OSCORE Security Context Parameters" registry (Section sec-ctx-
params-reg) and is defined below.  All parameters are optional.
table-key-labels provides a summary of the OSCORE_Security_Context
parameters defined in this section.
Paragraph (version B):
This parameter identifies the OSCORE Master Secret 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 "ms" value is
a Base64 encoded byte string.  In CBOR, the "ms" type is bstr, and
has label 1.
Paragraph (version B):
This parameter identifies a client identifier as a byte string.
This identifier is used as OSCORE Sender ID in the client and
OSCORE Recipient ID in the server.  For more information about
this field, see section 3.1 of I-D.ietf-core-object-security.  In
JSON, the "clientID" value is a Base64 encoded byte string.  In
CBOR, the "clientID" type is bstr, and has label 2.
Paragraph (version B):
This parameter identifies a server identifier as a byte string.
This identifier is used as OSCORE Sender ID in the client and
OSCORE Recipient ID in the server.  For more information about
this field, see section 3.1 of I-D.ietf-core-object-security.  In
JSON, the "serverID" value is a Base64 encoded byte string.  In
CBOR, the "serverID" type is bstr, and has label 3.
Paragraph (version B):
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 or the text string value of
the HMAC-based HKDF algorithm in the "COSE Algorithms" registry.
In JSON, the "hkdf" value is a case-sensitive ASCII string or an
integer.  In CBOR, the "hkdf" type is tstr or int, and has label
4.
Paragraph (version B):
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 string value of the HMAC-
based HKDF algorithm in the "COSE Algorithms" registry.  In JSON,
the "alg" value is a case-sensitive ASCII string or an integer.
In CBOR, the "alg" type is tstr or int, and has label 5.
Paragraph (version B):
This parameter identifies the OSCORE Master Salt 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 "salt" value
is a Base64 encoded byte string.  In CBOR, the "salt" type is
bstr, and has label 6.
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 7.
Paragraph (version B):
An example of JSON OSCORE_Security_Context is given in JSON-osc.
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 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 A):
The authz-info resource is not protected, nor are the responses from
this resource.
Paragraph (version B):
The authz-info endpoint is not protected, nor are the responses from
this resource.
Paragraph (version A):
resource.
Paragraph (version B):
endpoint.
Paragraph (version A):
Once receiving the 2.01 (Created) response from the RS, following the
POST /authz-info request, 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 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 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):
As specified in the ACE framework (section 5.7 of I-D.ietf-ace-oauth-
authz), the requesting entity (RS and/or client) and the AS
communicates via the introspection or token resource.  The use of
CoAP and OSCORE for this communication is RECOMMENDED in this
profile, other protocols (such as HTTP and DTLS or TLS) MAY be used
instead.
Paragraph (version B):
As specified in the ACE framework (section 5.7 of I-D.ietf-ace-oauth-
authz), the requesting entity (RS and/or client) and the AS
communicates via the introspection or token endpoint.  The use of
CoAP and OSCORE for this communication is RECOMMENDED in this
profile, other protocols (such as HTTP and DTLS or TLS) MAY be used
instead.
Paragraph (version A):
If OSCORE is used, the requesting entity and the AS are expected to
have pre-established security contexts in place.  How these security
contexts are established is out of scope for this profile.
Furthermore the requesting entity and the AS communicate using OSCORE
(I-D.ietf-core-object-security) through the introspection resource as
specified in section 5.7 of I-D.ietf-ace-oauth-authz and through the
token resource as specified in section 5.6 of I-D.ietf-ace-oauth-
authz.
Paragraph (version B):
There are a number of scenarios where a client or RS needs to discard
the OSCORE security context, and acquire a new one.
Paragraph (version B):
the Sequence Number space ends.
Paragraph (version B):
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.
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 B):
Sequence Number space ends.
Paragraph (version B):
Access token associated with the context expires.
Paragraph (version A):
The use of nonces during the OSCORE Setup oscore-setup prevents the
reuse of AEAD nonces in the RS Security Context, in case the RS loses
the Security Context associated with a client (e.g. in case of
unplanned reboot) and receives a replayed access token.  In fact, by
using random nonces as ID Context, the POST /auth-info request
results in a different Security Context, since Master Secret, Sender
ID and Recipient ID are the same but ID Context is different.
Therefore, the main requirement for the nonces is that they have a
good amount of randomness.  Moreover, the client echoes the nonce
created by the RS, which verifies it before deriving the Security
Context, and this protects against an adversary acting as a Man-in-
the-Middle and substituting the nonce in transit from client to RS to
provoke the creation of different Security Contexts in the client and
RS.
Paragraph (version B):
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):
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 B):
This registry will be initially populated by the values in table-key-
labels.  The specification column for all of these entries will be
this document.
Paragraph (version B):
The IANA registry established in this document is defined as expert
review.  This section gives some general guidelines for what the
experts should be looking for, but they are being designated as
experts for a reason so they should be given substantial latitude.