Draft: draft-ietf-ace-oscore-profile

Commentary: Looks good . 
 I am done , will merge and submit the new version in 3 - 4h unless I hear anybody ( particularly ) scream . 
 I am not happy with where the nonces are placed for doing key derivation . My code assume(d ) that if you pass in a context field , then it is a context field and should be sent as part of a message . It killed an experiment that I was going to run because I was just not sure how to go about it . I was going to run two different AS systems and I was going to use the context field to separate the two AS systems . This would have solved my client i d problem in this case as the client i d spaces would be unique to each of the AS systems ( unique context field ) . However , this is now hard to run esp as it is no longer included in the key derivation process . I would have been happier if nonces were appended to the end of the salt field . 
 I agree that putting the nonces in the salt field makes more sense than putting them in the id - context ( or was it context - id ? ) field . Can we make that change or do we need to wait for the AD reviews ? 
 Motivation for this was part of the decision made at IETF103 ( see and where people supported " proposal 3 " ) But I see the point of this issue and will go ahead and make the change . 
 where would the i d context be transported in case of update to access rights ? ( Right now we were only sending the client i d , we might need to send both I think ) My proposal : " kid " = CBOR array [ clientId , ? ID Context ] 
 Thanks ( and for not waiting for the AD review ) . 
 The example in figure 5 is incorrect . It should be single not double quotes for clientId and serverId . 
 Right , assuming you are actually talking about the value , " client " and " server " should be wrapped in CBOR bstr . 
 Yes that was the issue . 
 In section 3.2 , the following requirements are imposed : The AS MAY assign an identifier to the client The AS MUST assign an identifier to the RS The client identifiers MUST be unique in the set of all clients on a single  The RS identifiers MUST be unique in the set of all RS for any given client . If it is not required to assign an identifier for the client , how can it be unique ? If there are multiple AS , each with a set of unique  , are the AS servers expected to coordinate in order to make the RS identifiers unique ? 
 unique ? If I remember correctly , the MAY in " The AS MAY assign an identifier to the client " comes from the fact that the client can provide a client ID to the AS that it would like to use ( in the " client_id " field of the request to the AS ) . Then the AS can either use that ( if it does not collide with others ) , or change that to make it unique for the RS . We probably need more text about this ( in particular on the requirements on the AS to send a new client ID if the one provided is not good ) , would that work ? expected to coordinate in order to make the RS identifiers unique ? Do you mean : several  contacted by one client , each RS having a different AS ? Yes , I think that is missing . I will add a sentence about that . 
 Ok - One of use is very confused at this point and that seems to be a problem . The client i d is used by the server to identify the sender of the message . For this reason the identifier needs to be unique on the server side and must exist - and empty identifier is an identifier and needs to be set as such . As such , the same client ID can be assigned to a single client in when dealing with multiple contexts for different RSs as long as the client ID is unique for each RS . A client could want to request a specific server ID be assigned in a new context since it might want a unique ( for it ) server i d be assigned to an RS . In many cases a server ID is not ever put into a message as it is a response and thus the server 's context can be inferred . The exception to this being if an observe operation has been done . Only in that case would the server send it 's context as part of a message . Ok - which of us is totally out to sea . 
 I 'm trying to understand your issue still . I agree with your latest text , although I thought we were discussing uniqueness of Client ID , not Server ID . So let 's discuss both . Initial comment was : There are 2 cases : either the AS sets the Client ID of clients , or it does not . If it does , the AS is supposed to keep track of what IDs are available for the  , so it is able to assign a unique one . If it does not , the RS sets the Client ID in the 2.01 Created response to the POST request , as section 4.2 specifies : Note that if the AS assigns ID for some clients but not for others , this could be messed up , i.e. it might end up not keeping track and provide the client with an ID that the RS has already assigned to someone else . But this could be quickly solved , modifying the sentence above as follows : Does this make sense ? does it answer your comment about uniqueness of client ID ? This comment to me refers to the Server ID not being unique on the client : Are you saying it should not be necessary for the client that different RS are identified uniquely ? Because most of the time , the client knows what is expecting . I can agree with that . Also , there is no exception in the case of Observe , the client has saved the observation and the token so it knows what context to use . So yes , I agree that this action is needed in the text : remove requirement on Server ID being unique for its set of unique clients ( that 's true for Group OSCORE ) ( if this uniqueness requirement is necessary , then a sentence about AS needing to coordinate is needed , although that seems like unnecessary and very heavy ) 
 Concerning the " Uniqueness of Client ID " point , and the proposal to add the following sentence to the text : The text is actually already there , in the next sentence : 
 " In section 3.1 , it references the kid that was assigned in section 3.2 . I was not able to find a kid field in Table 1 . How is this value to be obtained ? " 
 Actually , the text specifically says that it is the client identifier that was assigned in section 3.2 , not the kid . So this is to be read as : " Take the value from the client identifier and put it in the " kid " field " . And the client identifier is present in Table 1 ( as clientId ) . Do we need to clarify that client identifier is in the clientId of Table 1 ? 
 There is a collision between the " nonce " parameter used in ACE and the " nonce " parameter defined by OpenID connect ( see : ) . We have thus changed the parameter from " nonce " -"cnonce " ( initially for client - nonce ) in the framework . This draft still uses ' nonce ' in several places as e.g. Figure 10 Figure 11 First paragraph of 4.1 ( " the ' nonce ' parameter defined in ... " ) Second paragraph of 4.2 ( " ... containing the ' nonce ' parameter ... " ) First paragraph of 4.3 ( " the ' nonce ' parameter and the client identifier ... " ) 
 In section 3.2.1 . 
 Currently the framework 's intention is that the access token is sent to the authz - info endpoint without any " wrapper " . Section 4.1 here requires the client to wrap the access token into a map and use the " access_token " key to identify it . This difference should be made clear in the profile . 
 Good point , thank you for bringing this up , as I had missed this . Should the access token really be sent without the map wrapping it ? I do n't see that detail in the framework . Also , if we talk about CWT for example , RFC8392 does not define the CWT without the map , on the contrary , to build the CWT the first step is to Which is a CBOR map . ( See ) Anyway , I do n't see the text in the OSCORE profile that says that the access token MUST be wrapped in a CBOR map , it says to use whatever token the AS wants to use . I think here we are doing the same , so I 'm not really sure on how to improve the text . 
 The map being referred to here is not the wrapper on the CWT but the application / ace+cbor map that is being used in this profile . 
 Ok , then it 's something else . It seems to me that 's always as this content format is used , also in the framework . If the content is application / ace+cbor then the payload is a CBOR map . And in this section we are explicitly saying : Not sure what else to add . 
 No the framework does not wrap the access token ( be it a CWT or something else ) in an additional CBOR map . Fw : client -RS / authz - info : POST payload : bytes of the access token OSCORE - Profile : client  / authz - info : POST payload ( CBOR ): { " access_token " : bytes of the access token } It is this difference I want explicitly stated in the profile ( also to punish you for all the programming pain it caused me ;-) ) 
 Ok , I think I got it . I will add a sentence to note this difference . Sorry about the pain , it was not the goal ! 
 This is now called " AS Request Creation Hints " 
 ... it also uses the even more obsolete term " RS Information " which is now called " Access Information " .
Paragraph (version B):
Concise Data Definition Language (CDDL) RFC8610 is used in this
specification.
Paragraph (version A):
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 A):
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 A):
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 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):
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 appends the result to the Master Salt in
the Security Context (see section 3 of I-D.ietf-core-object-
security).  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
appends the result to the Master Salt in its Security Context (see
section 3 of I-D.ietf-core-object-security).  The client then derives
the complete Security Context from the nonces plus the parameters
received from the AS.
Paragraph (version B):
Finally, the client sends a request protected with OSCORE to the RS.
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.
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 part
of the Master Salt, the request to the authz-info endpoint posting
the same token results in a different Security Context, since Master
Secret, Sender ID and Recipient ID are the same but Master Salt is
different.  Therefore, the main requirement for the nonces is that
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 A):
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):
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.  The req_cnf MUST include a
kid field carrying a CBOR array object containing the client's
identifier (assigned in section as-c) and optionally the context
identifier (if assigned in section as-c).  The CBOR array is defined
in kid, and follows the notation of RFC8610.  These identifiers can
be used by the AS to determine the shared secret to construct the
proof-of-possession token and therefore MUST identify a symmetric key
that was previously generated by the AS as a shared secret for the
communication between the client and the RS.  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):
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 OSCORE_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 OSCORE_Security_Context is a CBOR map object, defined in oscore-
sec-ctx.  The master secret MUST be communicated as the 'ms' field in
the OSCORE_Security_Context in the 'cnf' parameter of the access
token response as defined in Section 3.2 of I-D.ietf-ace-oauth-
params.  The AEAD algorithm MAY be included as the 'alg' parameter in
the OSCORE_Security_Context; the HKDF algorithm MAY be included as
the 'hkdf' parameter of the OSCORE_Security_Context, a salt MAY be
included as the 'salt' parameter of the OSCORE_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 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 AS MUST also assign an identifier to the RS (serverId), MAY
assign an identifier to the client (clientId), and MAY assign an
identifier to the context (contextId).  These identifiers are then
used as Sender ID, Recipient ID and ID Context in the OSCORE context
as described in section 3.1 of I-D.ietf-core-object-security.  The
couple (client identifier, context identifier) MUST be unique in the
set of all clients on a single RS.  Moreover, when assigned,
serverId, clientId and contextId MUST be included in the
OSCORE_Security_Context, as defined in oscore-sec-ctx.
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
client identifier in the 'kid' field in the 'cnf' parameter of the
token.  The client identifier needs to be provisioned, in order for
the RS to identify the previously generated Security Context.
Paragraph (version B):
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
client identifier and optionally the context identifier in the 'kid'
field in the 'cnf' parameter of the token, with the same structure
defined in kid.  These identifiers need to be provisioned, in order
for the RS to identify the previously generated Security Context.
Paragraph (version A):
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):
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 object or as CBOR map.  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 A):
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 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.
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 MAY
include the kid context if the application needs to, with value ID
Context, i.e. N1 concatenated with N2.
Paragraph (version A):
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 B):
The client then uses this Security Context to send requests to RS
using OSCORE.
Paragraph (version B):
After sending the 2.01 (Created) response, the RS MUST set the Master
Salt of the Security Context created to communicate with the client
to the concatenation of salt, N1, and N2, in this order: Master Salt
= salt | N1 | N2, where | denotes byte string concatenation, and
where salt was received from the AS in rs-c.  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, ID Context, 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 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 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.