Draft: draft-ietf-ace-oscore-profile

Commentary: Following interim discussion   review
Paragraph (version A):
The AS MUST also assign an identifier to the RS (serverId), MAY
assign an identifier to the client (clientId), and MAY assign an
identifier to the context (contextId).  These identifiers are then
used as Sender ID, Recipient ID and ID Context in the OSCORE context
as described in section 3.1 of RFC8613.  Applications need to
consider that these identifiers are sent in the clear and may reveal
information about the endpoints, as mentioned in section 12.8 of
RFC8613.  The pair (client identifier, context identifier) MUST be
unique in the set of all clients for a single RS.  Moreover,
clientId, serverId and (when assigned) contextId MUST be included in
the OSCORE_Security_Context, as defined in oscore-sec-ctx.
Paragraph (version B):
The AS MUST also assign an identifier to the RS (serverId), and to
the client (clientId), and MAY assign an identifier to the context
(contextId).  These identifiers are then used as Sender ID, Recipient
ID and ID Context in the OSCORE context as described in section 3.1
of RFC8613.  Applications need to consider that these identifiers are
sent in the clear and may reveal information about the endpoints, as
mentioned in section 12.8 of RFC8613.  The pair (client identifier,
context identifier) MUST be unique in the set of all clients for a
single RS.  Moreover, clientId, serverId and (when assigned)
contextId MUST be included in the OSCORE_Security_Context, as defined
in oscore-sec-ctx.
Paragraph (version B):
Moreover, implementers of this specification need to be aware that if
other authentication mechanisms are used to set up OSCORE between the
same client and RS, that do not rely on AS assigning identifiers,
collisions may happen and need to be mitigated.
Paragraph (version B):
Note that the use of the payload and the Content-Format is different
from what described in section 5.8.1 of I-D.ietf-ace-oauth-authz,
which only transports the token without any CBOR wrapping.  In this
profile, the client MUST wrap the token and N1 in a CBOR map.  The
client MUST use the Content-Format "application/ace+cbor" defined in
section 8.14 of I-D.ietf-ace-oauth-authz.  The client MUST include
the access token using the correct CBOR label (e.g., "cwt" for CWT,
"jwt" for JWT) and N1 using the 'nonce1' parameter defined in nonce1.
Paragraph (version B):
This parameter MUST be sent from the client to the RS, together with
the access token, if the ace profile used is coap_oscore.  The
parameter is encoded as a byte string for CBOR-based interactions,
and as a string (Base64 encoded binary) for JSON-based interactions.
This parameter is registered in iana-nonces.
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 send it
within the 2.01 (Created) response.  The payload of the 2.01
(Created) response MUST be a CBOR map containing the 'cnonce'
parameter defined in section 5.1.2 of I-D.ietf-ace-oauth-authz, set
to N2.  This profile RECOMMENDS to use a 64-bit long random number as
nonce's value.  Moreover, if the 'osc' field 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 'osc' field
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):
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 'nonce2'
parameter defined in nonce2, set to N2.  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):
Once receiving the 2.01 (Created) response from the RS, following the
POST request to authz-info endpoint, the client MUST extract the CBOR
bstr nonce N2 from the 'cnonce' parameter and the client identifier
from the 'clientId' in the CBOR map in the payload of the response.
Then, the client MUST set the Master Salt of the Security Context
created to communicate with the RS to the concatenation of salt, N1,
and N2, in this order: Master Salt = salt | N1 | N2, where | denotes
byte string concatenation, where salt was received from the AS in as-
c, and where N1 and N2 are the two nonces encoded as CBOR bstr.  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, ID Context, HKDF, and OSCORE Version 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
sections 3.2 and 5.4 of RFC8613.  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 RFC8613.  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):
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):
Once receiving the 2.01 (Created) response from the RS, following the
POST request to authz-info endpoint, the client MUST extract the CBOR
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
was received from the AS in as-c, and where N1 and N2 are the two
nonces encoded as CBOR bstr.  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, ID Context, HKDF,
and OSCORE Version 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 sections 3.2 and 5.4 of RFC8613.  After
that, the client MUST derive the complete Security Context following
section 3.2.1 of RFC8613.  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, 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 A):
If the exchange was an update of access rights, i.e., a new Security
Context was derived from a client that already had a Security Context
in place, the is RECOMMENDED to delete the old Security Context after
OSCORE verification and verification of access rights succeed.  The
RS MUST delete the Security Context if it deletes the access token
associated to it.
Paragraph (version B):
If the exchange was an update of access rights, i.e., a new Security
Context was derived from a client that already had a Security Context
in place, the RS is RECOMMENDED to delete the old Security Context
after OSCORE verification and verification of access rights succeed.
The RS MUST delete the Security Context if it deletes the access
token associated to it.