Draft: draft-ietf-ace-oscore-profile

Commentary: Answering IESG review and Telechat comments .
Mailing list commentary: Reviewer : Elwyn Davies Review result : Ready with Nits I am the assigned Gen - ART reviewer for this draft . The General Area Review Team ( Gen - ART ) reviews all IETF documents being processed by the IESG for the IETF Chair . Please wait for direction from your document shepherd or AD before posting a new version of the draft . For more information , please see the FAQ at . Document : draft - ietf - ace - oscore - profile-17 Reviewer : Elwyn Davies Review Date : 2021 - 03 - 23 IETF LC End Date : 2020 - 07 - 20 IESG Telechat date : 2021 - 03 - 25 Summary : Ready with nits . A very great improvement on the previously reviewed version . Thanks . Major issues : None Minor issues : Would it be useful to provide some advice on the length of salts and IDs to go with the advice on length of nonces ? There is some in s3.3 of RFC 8613 but some other reference might be helpful , maybe placed in s3.2.1 . and/or s4 . Nits / editorial comments : General : The RFC Editor conforms rigorously to American practice and allows only the use of double quote marks ( " ) in the text when marking strings as quotations and such like . The document makes extensive but not totally consistent , use of single quotes to flag up field names and such like ( e.g. , ' ' ) . In practice these are unnecessary , but may be replaced by the RFC Editor if left in place . Personally . I think most of them can be removed . NB this does not affect CBOR items such as . General : There are lots of usages of ' CBOR diagnostic notation without the tag and value abbreviations ' . An abbreviation would reduce the verbiage . General : It is slightly confusing to have Nonce 1 / N1 / nonce1 and Nonce 2 / N2 / nonce2 used in the document . Am I right in thinking Nonce 1 and N1 are the same with nonce1 being the name of the JSON / CBOR parameter used to carry the value ? A few words of clarrification would help . Abstract / s1 : It would be useful to introduce the name of the profile ( coaposcore ) up front . It rather sneaks out in s3 . s1 , para 2 : Need to expand CBOR on first use . s2 , end of para 3 : s / as well / instead/ ? or s / as well / alternatively/. s2 , para 7 and s6 , bullet 2 : s / e.g. expiration./for example , expiration./ s3.1 , para 3 and last para : s / reported / shown/ s3.1 , Figure 2 and Figure 3 : Appendix F.3 of draft - ietf - ace - oauth - authz reports that reqaud was replaced by audence at version 19 of the document . s3.2 , second set of bullets : Need to expand HMAC and HKDF on first use ( not well - known in RFC Editor list ) . It would also be useful to put a pointer to section 11.1 of RFC 8152 here to indicate the allowed HKDF algorithms . s3.2 , 2nd para after 2nd set of bullets : s / The applications needs / The application needs/ s3.2 , 3rd para after 2nd set of bullets : s / parameeter / parameter/ s3.2 , 4th para after 2nd set of bullets : s / the use of CBOR web token / the use of a CBOR web token/ s3.2.1 : OLD : IANA " OSCORE Security Context Parameters " registry ( Section 9.4 ) , defined for extensibility , and is specified below . NEW : IANA " OSCORE Security Context Parameters " registry ( Section 9.4 ) , defined for extensibility , and the initial set of parameters defined in this document is specified below . END s3.2.1 , below Figure 9 : Expand CDDL . s4.1 , para 1 and s4.2 , para 2 : s / RECOMMENDS to use / RECOMMENDS using/ s4.1 , para 1 and s4.2 . para 2 : s / as nonce 's value / as the nonce 's value/ s4.1 , para 7 : s / renew / update/ [ renew implies the same identifiers are used - which is already specified ! ] s4.1 , last para and s4.3 , last para : Does /authz - info have some special meaning ? s4.3 , para 1 : s/ Once receiving the 2.01 ( Created ) response from the RS/ Once the 2.01 ( Created ) response is received from the RS/ s4.3 , Figure 12 : I assume is supposed to be a CBOR indefinite length string encoding ( it does n't say so ) as it it consists of the concatenated CBOR strings of its component byte strings . It would be strictly correct to start it with 0x5f and end with ( 0x)ff I would have thought . Be that as it may , I do not understand why the document is concerned with either CBOR or JSON / base64 encodings of the master salt . It may be that I am missing something , but I did n't think that the master salt was ever put in a protocol message as such ( deliberately ) , but only as one or two of its components such that it could be privately constructed at both endpoints once the three components had been shared , and was just the concatenation of the data bytes of the 3 components rather than involving their lengths . s6 .   : s / observation / observations/ s7 , para 3 : s / RS pass / RS passes/ s9 : It is now usual to give the URLs for the various existing registries as normative references . s9.4 : I am not aware that a single registry can have different review / specfication requirements for portions of its parameter space . Is it seriously expected that there will be significant numbers of requests for values in this registry ? My instinct would be to go for specification required and advise allocation according to the orign and type of the specification .
Paragraph (version A):
This memo specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework.  It
utilizes Object Security for Constrained RESTful Environments
(OSCORE) to provide communication security and proof-of-possession
for a key owned by the client and bound to an OAuth 2.0 access token.
Paragraph (version B):
This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework.  It
utilizes Object Security for Constrained RESTful Environments
(OSCORE) to provide communication security and proof-of-possession
for a key owned by the client and bound to an OAuth 2.0 access token.
Paragraph (version A):
This memo specifies a profile of the ACE framework I-D.ietf-ace-
oauth-authz.  In this profile, a client and a resource server use the
Constrained Application Protocol (CoAP) RFC7252 to communicate.  The
client uses an access token, bound to a symmetric key (the proof-of-
possession key) to authorize its access to the resource server.  Note
that this profile uses a symmetric-crypto-based scheme, where the
symmetric secret is used as input material for keying material
derivation.  In order to provide communication security and proof of
possession, the client and resource server use Object Security for
Constrained RESTful Environments (OSCORE) RFC8613.  Note that the
proof of possession is not achieved through a dedicated protocol
element, but rather occurs after the first message exchange using
OSCORE.
Paragraph (version A):
OSCORE specifies how to use CBOR Object Signing and Encryption (COSE)
RFC8152 to secure CoAP messages.  Note that OSCORE can be used to
secure CoAP messages, as well as HTTP and combinations of HTTP and
CoAP; a profile of ACE similar to the one described in this document,
with the difference of using HTTP instead of CoAP as communication
protocol, could be specified analogously to this one.
Paragraph (version B):
This document specifies the "coap_oscore" profile of the ACE
framework I-D.ietf-ace-oauth-authz.  In this profile, a client and a
resource server use the Constrained Application Protocol (CoAP)
RFC7252 to communicate.  The client uses an access token, bound to a
symmetric key (the proof-of-possession key) to authorize its access
to the resource server.  Note that this profile uses a symmetric-
crypto-based scheme, where the symmetric secret is used as input
material for keying material derivation.  In order to provide
communication security and proof of possession, the client and
resource server use Object Security for Constrained RESTful
Environments (OSCORE) RFC8613.  Note that the proof of possession is
not achieved through a dedicated protocol element, but rather occurs
after the first message exchange using OSCORE.
Paragraph (version B):
OSCORE specifies how to use CBOR Object Signing and Encryption (COSE)
I-D.ietf-cose-rfc8152bis-algs to secure CoAP messages.  Note that
OSCORE can be used to secure CoAP messages, as well as HTTP and
combinations of HTTP and CoAP; a profile of ACE similar to the one
described in this document, with the difference of using HTTP instead
of CoAP as communication protocol, could be specified analogously to
this one.
Paragraph (version A):
Certain security-related terms such as "authentication",
"authorization", "confidentiality", "(data) integrity", "message
authentication code", and "verify" are taken from RFC4949.
Paragraph (version B):
Certain security-related terms such as "authentication",
"authorization", "confidentiality", "(data) integrity", "Message
Authentication Code (MAC)", "Hash-based Message Authentication Code
(HMAC)", and "verify" are taken from RFC4949.
Paragraph (version A):
Concise Binary Object Representation (CBOR) RFC8949 and Concise Data
Definition Language (CDDL) RFC8610 are used in this specification.
CDDL predefined type names, especially bstr for CBOR byte strings and
tstr for CBOR text strings, are used extensively in the document.
Paragraph (version A):
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 B):
Concise Binary Object Representation (CBOR) RFC8949 and Concise Data
Definition Language (CDDL) RFC8610 are used in this document.  CDDL
predefined type names, especially bstr for CBOR byte strings and tstr
for CBOR text strings, are used extensively in this document.
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 document.
Paragraph (version B):
Examples throughout this document are expressed in CBOR diagnostic
notation without the tag and value abbreviations.
Paragraph (version A):
This profile requires a client to retrieve an access token from the
AS for the resource it wants to access on an RS, by sending an access
token request to the token endpoint, as specified in section 5.8 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, to reduce the
number of libraries the client has to support, but other protocols
fulfilling the security requirements defined in section 5 of I-
D.ietf-ace-oauth-authz (such as TLS or DTLS) MAY be used as well.
Paragraph (version A):
Once the client has retrieved the access token, it generates a nonce
N1, defined in this specification (see nonce1).  The client also
generates its own OSCORE Recipient ID ID1 (see Section 3.1 of
RFC8613), for use with the keying material associated to the RS.  The
client posts the token, N1 and its Recipient ID 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.
When using this profile, the communication with the authz-info
endpoint is not protected, except for update of access rights.
Paragraph (version B):
This profile requires a client to retrieve an access token from the
AS for the resource it wants to access on an RS, by sending an access
token request to the token endpoint, as specified in section 5.8 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, to reduce the
number of libraries the client has to support, but other protocols
fulfilling the security requirements defined in section 5 of I-
D.ietf-ace-oauth-authz MAY alternatively be used, such as TLS RFC8446
or DTLS I-D.ietf-tls-dtls13.
Paragraph (version B):
Once the client has retrieved the access token, it generates a nonce
N1, defined in this document (see nonce1).  The client also generates
its own OSCORE Recipient ID ID1 (see Section 3.1 of RFC8613), for use
with the keying material associated to the RS.  The client posts the
token, N1 and its Recipient ID 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.  When using
this profile, the communication with the authz-info endpoint is not
protected, except for update of access rights.
Paragraph (version A):
Finally, the client starts the communication with the RS by sending a
request protected with OSCORE to the RS.  If the request is
successfully verified, the server stores the complete Security
Context state that is ready for use in protecting messages, and uses
it in the response, and in further communications with the client,
until token deletion, due to e.g. expiration.  This Security Context
is discarded when a token (whether the same or a different one) is
used to successfully derive a new Security Context for that client.
Paragraph (version B):
Finally, the client starts the communication with the RS by sending a
request protected with OSCORE to the RS.  If the request is
successfully verified, the server stores the complete Security
Context state that is ready for use in protecting messages, and uses
it in the response, and in further communications with the client,
until token deletion due to, for example, expiration.  This Security
Context is discarded when a token (whether the same or a different
one) is used to successfully derive a new Security Context for that
client.
Paragraph (version A):
declined with the error code 'invalid_request' as defined in
Section 5.8.3 of I-D.ietf-ace-oauth-authz.
Paragraph (version B):
as defined in Section 5.8.3 of I-D.ietf-ace-oauth-authz.
Paragraph (version A):
The AS can signal that the use of OSCORE is REQUIRED for a specific
access token by including the "profile" parameter with the value
"coap_oscore" in the access token response.  This means that the
client MUST use OSCORE towards all resource servers for which this
access token is valid, and follow oscore-setup to derive the security
context to run OSCORE.  Usually it is assumed that constrained
devices will be pre-configured with the necessary profile, so that
this kind of profile signaling can be omitted.
Paragraph (version B):
The AS can signal that the use of OSCORE is REQUIRED for a specific
access token by including the "ace_profile" parameter with the value
"coap_oscore" in the access token response.  This means that the
client MUST use OSCORE towards all resource servers for which this
access token is valid, and follow oscore-setup to derive the security
context to run OSCORE.  Usually it is assumed that constrained
devices will be pre-configured with the necessary profile, so that
this kind of profile signaling can be omitted.
Paragraph (version A):
This data is transported in the OSCORE_Input_Material.  The
OSCORE_Input_Material is a CBOR map object, defined in oscore-sec-
ctx.  This object is transported in the 'cnf' parameter of the access
token response as defined in Section 3.2 of I-D.ietf-ace-oauth-
params, as the value of a field named 'osc', registered in osc-cwt
and osc-jwt.
Paragraph (version A):
The AS MAY assign an identifier to the context (context identifier).
This identifier is used as ID Context in the OSCORE context as
described in section 3.1 of RFC8613.  If assigned, this parameters
MUST be communicated as the 'contextId' field in the
OSCORE_Input_Material.  The applications needs to consider that this
identifier is sent in the clear and may reveal information about the
endpoints, as mentioned in section 12.8 of RFC8613.
Paragraph (version A):
The master secret and the identifier of the OSCORE_Input_Material
MUST be communicated as the 'ms' and 'id' field in the 'osc' field in
the 'cnf' parameeter of the access token response.  If included, the
AEAD algorithm is sent in the 'alg' parameter in the
OSCORE_Input_Material; the HKDF algorithm in the 'hkdf' parameter of
the OSCORE_Input_Material; a salt in the 'salt' parameter of the
OSCORE_Input_Material; and the OSCORE version in the 'version'
parameter of the OSCORE_Input_Material.
Paragraph (version A):
The same parameters MUST be included in the claims associated with
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_Input_Material structure defined above MUST be placed in the
'osc' field of the 'cnf' claim of this token.
Paragraph (version A):
ex1 shows an example of an AS response, with payload in CBOR
diagnostic notation without the tag and value abbreviations.  The
access token has been truncated for readability.
Paragraph (version A):
ex2 shows an example CWT Claims Set, including the relevant OSCORE
parameters in the 'cnf' claim, in CBOR diagnostic notation without
tag and value abbreviations.
Paragraph (version A):
The same CWT Claims Set as in ex2, using the value abbreviations
defined in I-D.ietf-ace-oauth-authz and RFC8747 and encoded in CBOR
is shown in ex2-cbor.  The bytes in hexadecimal are reported in the
first column, while their corresponding CBOR meaning is reported
after the '#' sign on the second column, for easiness of readability.
Paragraph (version B):
field in the OSCORE_Input_Material.  The application needs to
consider that this identifier is sent in the clear and may reveal
information about the endpoints, as mentioned in section 12.8 of
RFC8613.
Paragraph (version B):
parameter of the OSCORE_Input_Material.
Paragraph (version B):
claim of this token.
Paragraph (version B):
ex1 shows an example of an AS response.  The access token has been
truncated for readability.
Paragraph (version B):
claim.
Paragraph (version B):
sign on the second column, for easiness of readability.
Paragraph (version A):
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
OSCORE Input Material identifier in the 'kid' field in the 'cnf'
claim of the token.  This identifier needs to be included in the
token in order for the RS to identify the correct OSCORE Input
Material.
Paragraph (version A):
ex5 shows an example of such an AS response, with payload in CBOR
diagnostic notation without the tag and value abbreviations.  The
access token has been truncated for readability.
Paragraph (version A):
ex6 shows an example CWT Claims Set, containing the necessary OSCORE
parameters in the 'cnf' claim for update of access rights, in CBOR
diagnostic notation without tag and value abbreviations.
Paragraph (version B):
claim of the token.  This identifier needs to be included in the
token in order for the RS to identify the correct OSCORE Input
Material.
Paragraph (version B):
ex5 shows an example of such an AS response The access token has been
truncated for readability.
Paragraph (version B):
claim for update of access rights.
Paragraph (version A):
params-reg), defined for extensibility, and is specified below.  All
parameters are optional.  key-labels provides a summary of the
OSCORE_Input_Material parameters defined in this section.
Paragraph (version B):
params-reg), defined for extensibility, and the initial set of
parameters defined in this document is specified below.  All
parameters are optional.  key-labels provides a summary of the
OSCORE_Input_Material parameters defined in this section.
Paragraph (version A):
This parameter identifies the OSCORE HKDF Algorithm.  For more
information about this field, see section 3.1 of RFC8613.  The
values used MUST be registered in the IANA "COSE Algorithms"
registry (see COSE.Algorithms) 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
text string or integer, 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 RFC8613.  The
values used MUST be registered in the IANA "COSE Algorithms"
registry (see COSE.Algorithms) and MUST be HMAC-based HKDF
algorithms (see section 3.1 of I-D.ietf-cose-rfc8152bis-algs).
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 text string or integer, and
has label 3.
Paragraph (version A):
Note that the RS and client authenticates each other by generating
the shared OSCORE Security Context using the pop-key as master
secret.  An attacker posting a valid token to the RS will not be able
to generate a valid OSCORE Security Context and thus not be able to
prove possession of the pop-key.  Additionally, the mutual
authentication is only achieved after the client has successfully
verified a response from the RS protected with the generated OSCORE
Security Context.
Paragraph (version B):
Note that the RS and client authenticate each other by generating the
shared OSCORE Security Context using the pop-key as master secret.
An attacker posting a valid token to the RS will not be able to
generate a valid OSCORE Security Context and thus not be able to
prove possession of the pop-key.  Additionally, the mutual
authentication is only achieved after the client has successfully
verified a response from the RS protected with the generated OSCORE
Security Context.
Paragraph (version A):
The client MUST generate a nonce value 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's value.  The
client MUST store the nonce N1 as long as the response from the RS is
not received and the access token related to it is still valid (to
the best of the client's knowledge).
Paragraph (version B):
The client MUST generate a nonce value N1 very unlikely to have been
previously used with the same input keying material.  This profile
RECOMMENDS using a 64-bit long random number as the nonce's value.
The client MUST store the nonce N1 as long as the response from the
RS is not received and the access token related to it is still valid
(to the best of the client's knowledge).
Paragraph (version A):
Note that the use of the payload and the Content-Format is different
from what is 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, N1 and ID1 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 'access_token' parameter, N1 using the
'nonce1' parameter defined in nonce1, and ID1 using the
'ace_client_recipientid' parameter defined in id1.
Paragraph (version B):
parameter defined in id1.
Paragraph (version A):
The client may also chose to re-POST the access token in order to
renew its OSCORE Security Context.  In that case, the client and the
RS will exchange newly generated nonces, re-negotiate identifiers,
and derive new keying material.  The client and RS might decide to
keep the same identifiers or renew them during the re-negotiation.
Paragraph (version A):
ex3 shows an example of the request sent from the client to the RS,
with payload in CBOR diagnostic notation without the tag and value
abbreviations.  The access token has been truncated for readability.
Paragraph (version B):
The client may also choose to re-POST the access token in order to
update its OSCORE Security Context.  In that case, the client and the
RS will exchange newly generated nonces, re-negotiate identifiers,
and derive new keying material.  The client and RS might decide to
keep the same identifiers or renew them during the re-negotiation.
Paragraph (version B):
ex3 shows an example of the request sent from the client to the RS.
The access token has been truncated for readability.
Paragraph (version A):
If the client has already posted a valid token, has already
established a security association with the RS, and wants to update
its access rights, the client can do so by posting the new token
(retrieved from the AS and containing the update of access rights) to
the /authz-info endpoint.  The client MUST protect the request using
the OSCORE Security Context established during the first token
exchange.  The client MUST only send the 'access_token' field in the
CBOR map in the payload, no nonce or identifier are sent.  After
proper verification (see rs-c), the RS will replace the old token
with the new one, maintaining the same Security Context.
Paragraph (version B):
field in the CBOR map in the payload, no nonce or identifier are
sent.  After proper verification (see rs-c), the RS will replace the
old token with the new one, maintaining the same Security Context.
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), or if any of the
expected parameters is missing (e.g., any of the mandatory parameters
from the AS or the identifier 'id1'), or if any parameters received
in the 'osc' field is unrecognized, the RS must respond with an error
response code equivalent to the CoAP code 4.00 (Bad Request).  In the
latter two cases, the RS may provide additional information in the
error response, in order to clarify what went wrong.  The RS may make
an introspection request (see Section 5.9.1 of I-D.ietf-ace-oauth-
authz) to validate the token before responding to the POST request to
the authz-info endpoint.
Paragraph (version B):
field is unrecognized, the RS must respond with an error response
code equivalent to the CoAP code 4.00 (Bad Request).  In the latter
two cases, the RS may provide additional information in the error
response, in order to clarify what went wrong.  The RS may make an
introspection request (see Section 5.9.1 of I-D.ietf-ace-oauth-authz)
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 N2 very unlikely to have
been previously used with the same input keying material, and its own
Recipient ID, ID2.  The RS makes sure that ID2 does not collide with
any of its Recipient IDs.  The RS MUST ensure that ID2 is different
from the value received in the ace_client_recipientid parameter.  The
RS sends N2 and ID2 within the 2.01 (Created) response.  The payload
of the 2.01 (Created) response MUST be a CBOR map containing the
'nonce2' parameter defined in nonce2, set to N2, and the
'ace_server_recipientid' parameter defined in id2, set to ID2.  This
profile RECOMMENDS to use a 64-bit long random number as nonce's
value.  The RS MUST use the Content-Format "application/ace+cbor"
defined in section 8.14 of I-D.ietf-ace-oauth-authz.
Paragraph (version A):
ex4 shows an example of the response sent from the RS to the client,
with payload in CBOR diagnostic notation without the tag and value
abbreviations.
Paragraph (version B):
parameter defined in id2, set to ID2.  This profile RECOMMENDS using
a 64-bit long random number as the nonce's value.  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.
Paragraph (version A):
If the RS receives the token in a OSCORE protected message, it means
that the client is requesting an update of access rights.  The RS
MUST ignore any nonce and identifiers in the request, if any was
sent.  The RS MUST check that the "kid" of the 'cnf' claim of the new
access token matches the identifier of the OSCORE Input Material of
the context used to protect the message.  If that is the case, the RS
MUST overwrite the old token and associate the new token to the
Security Context identified by the "kid" value in the 'cnf' claim.
The RS MUST respond with a 2.01 (Created) response protected with the
same Security Context, with no payload.  If any verification fails,
the RS MUST respond with a 4.01 (Unauthorized) error response.
Paragraph (version B):
claim.  The RS MUST respond with a 2.01 (Created) response protected
with the same Security Context, with no payload.  If any verification
fails, the RS MUST respond with a 4.01 (Unauthorized) error response.
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 bstr
nonce N2 from the 'nonce2' parameter 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, where salt
is the CBOR byte string received from the AS in as-c, and where N1
and N2 are the two nonces encoded as CBOR byte strings.  An example
of Master Salt construction using CBOR encoding is given in ms-ex.
Paragraph (version B):
parameter 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, where salt is the CBOR byte string received from the
AS in as-c, and where N1 and N2 are the two nonces encoded as CBOR
byte strings.  An example of Master Salt construction using CBOR
encoding is given in ms-ex.
Paragraph (version A):
the access token associated with the context becomes invalid, due
to e.g. expiration.
Paragraph (version B):
the access token associated with the context becomes invalid due
to, for example, expiration.
Paragraph (version A):
Whenever one more access token is successfully posted to the RS, and
a new Security Context is derived between the client and RS, messages
in transit that were protected with the previous Security Context
might not pass verification, as the old context is discarded.  That
means that messages sent shortly before the client posts one more
access token to the RS might not successfully reach the destination.
Analogously, implementations may want to cancel CoAP observations at
the RS registered before the Security Context is replaced, or
conversely they will need to implement a mechanism to ensure that
those observation are to be protected with the newly derived Security
Context.
Paragraph (version B):
Whenever one more access token is successfully posted to the RS, and
a new Security Context is derived between the client and RS, messages
in transit that were protected with the previous Security Context
might not pass verification, as the old context is discarded.  That
means that messages sent shortly before the client posts one more
access token to the RS might not successfully reach the destination.
Analogously, implementations may want to cancel CoAP observations at
the RS registered before the Security Context is replaced, or
conversely they will need to implement a mechanism to ensure that
those observations are to be protected with the newly derived
Security Context.
Paragraph (version A):
As previously stated, the proof-of-possession in this profile is
performed by both parties verifying that they have established the
same Security Context, as specified in oscore-setup, which means that
both the OSCORE request and OSCORE response pass verification.  RS
authentication requires both that the client trusts the AS and that
the OSCORE response from the RS pass verification.
Paragraph (version B):
As previously stated, the proof-of-possession in this profile is
performed by both parties verifying that they have established the
same Security Context, as specified in oscore-setup, which means that
both the OSCORE request and the OSCORE response passes verification.
RS authentication requires both that the client trusts the AS and
that the OSCORE response from the RS passes verification.
Paragraph (version A):
Since the use of nonces N1 and N2 during the exchange guarantees
uniqueness of AEAD keys and nonces, it is REQUIRED that the exchanged
nonces are not reused with the same input keying material even in
case of re-boots.  This document RECOMMENDS the exchange of 64 bit
random nonces.  Considering the birthday paradox, the average
collision for each nonce will happen after 2^32 messages, which is
considerably more token provisionings than expected for intended
applications.  If applications use something else, such as a counter,
they need to guarantee that reboot and loss of state on either node
does not provoke reuse.  If that is not guaranteed, nodes are
susceptible to reuse of AEAD (nonce, key) pairs, especially since an
on-path attacker can cause the use of a previously exchanged client
nonce N1 for Security Context establishment by replaying the
corresponding client-to-server message.
Paragraph (version B):
Since the use of nonces N1 and N2 during the exchange guarantees
uniqueness of AEAD keys and nonces, it is REQUIRED that the exchanged
nonces are not reused with the same input keying material even in
case of re-boots.  This document RECOMMENDS the exchange of 64 bit
random nonces.  Considering the birthday paradox, the average
collision for each nonce will happen after 2^32 messages, which is
considerably more token provisioned than would be expected for
intended applications.  If applications use something else, such as a
counter, they need to guarantee that reboot and loss of state on
either node does not provoke reuse.  If that is not guaranteed, nodes
are susceptible to reuse of AEAD (nonce, key) pairs, especially since
an on-path attacker can cause the use of a previously exchanged
client nonce N1 for Security Context establishment by replaying the
corresponding client-to-server message.
Paragraph (version A):
Note to RFC Editor: Please replace all occurrences of "[[this
specification]]" with the RFC number of this specification and delete
this paragraph.
Paragraph (version B):
Note to RFC Editor: Please replace all occurrences of "[[this
document]]" with the RFC number of this document.  Please add a
reference to the IANA ACE Profile registry in the nextt subsection
once it has been created by IANA, and then delete this paragraph.
Paragraph (version A):
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 determine that
there is a compelling reason to allow an exception.  The name is
not used in the CBOR encoding.
Paragraph (version B):
The JSON name requested (e.g., "ms").  Because a core goal of this
document 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 determine that there is a
compelling reason to allow an exception.  The name is not used in
the CBOR encoding.