Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-14.txt

[Francesca Palombini <[e-mail]>]

Hi Daniel!

Thank you for the review. I have answered your comments inline, and if you agree with them I believe I can implement the changes by next week and submit the final version. I am happy to see these are clarification comments.

Thanks,
Francesca

From: Daniel Migault <[e-mail]>
Date: Thursday, 7 January 2021 at 17:07
To: Francesca Palombini <[e-mail]>
Cc: Benjamin Kaduk <[e-mail]>, Ace Wg <[e-mail]>
Subject: Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-14.txt

Hi,

I apology for taking too long to review the document. Overall I think it is in good shape but I do have some minor comments on the current version. I have not been through the IANA section, I assumed it has already been validated by IANA.  Please find my comments below.

Once fixed, I do not expect any action from my p[art on the datatracker and expect the draft to move forward almost by itself.

Yours,
Daniel

OSCORE Profile of the Authentication and Authorization for Constrained
                         Environments Framework
                    draft-ietf-ace-oscore-profile-14

[...]

2.  Protocol Overview

   This section gives an overview of how to use the ACE Framework
   [I-D.ietf-ace-oauth-authz] to secure the communication between a
   client and a resource server using OSCORE [RFC8613].  The parameters
   needed by the client to negotiate the use of this profile with the
   authorization server, as well as the OSCORE setup process, are
   described in detail in the following sections.

   The RS maintains a collection of OSCORE Security Contexts with
   associated authorization information for all the clients that it is
   communicating with.  The authorization information is maintained as
   policy that is used as input to processing requests from those
   clients.

   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.6 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 other
   protocols (such as TLS or DTLS) can be used as well.

<mglt>
I usually expect a recommendation to be
motivated.  In this case, the recommendation
seems to be motivated by not having two
different libraries - OSCORE and TLSvXs as
opposed to taking of some properties that
OSCORE have as opposed to DTLS. I believe the
motivation should be explicitly stated.

FP: Yes, the first reason we recommend OSCORE between C and AS is to make use of only one library on the client. However, that is absolutely dependent on the application, and the client is typically not a constrained device, so something else could be used depending on the use case scenario. Without details on the use case, I don't think we have enough information to motivate a recommendation.

I believe that the RECOMMMENDation comes to
fill the section 5.8.1
draft-ietf-ace-oauth-authz.  I believe the
text should mention that such recommendation
is one attribute that needs to be completed
by the profile. This is mostly to avoid the
recommendation to be considered as anecdotal
or a comment.
It seems that SHOULD would make it more
normative than a RECOMMEND. But that is only
a personal though.

FP: The recommendation does not fill in 5.8.1, the MUST just before does. Its goal is to give one preferred choice to implementers on how the previous MUST can be fullfilled. The use of normative text makes it so that this text cannot be taken as a comment. Appendix A - Profile Requirements summarizes the requirements that this profile defines based on the framework.

</mglt>

   Once the client has retrieved the access token, it generates a nonce
   N1.  The client also generates its OSCORE Recipient ID (see
   Section 3.1 of [RFC8613]), ID1,

<mglt>
I believe that ID1 is the Recipient ID. I am
wondering if the text "OSCORE Recipient ID
ID1 (see Section 3.1... )" would not be
clearer. Though this might be clarified by
the RFC editor.

FP: Ok, will change.

I believe "its" should be clarified
especially in the overview section to expose
that the Recipient ID is being used by the
client to associate the received messages. In
other words, the RS will use this ID ( as
Sender ID) when sending responses to the
client.

FP: That's correct. I will change: s/its/its own. I think the next half sentence "for use with the keying material associated to the RS." is supposed to say exactly what you say above. I would rather not go into details of how exactly the Recipient ID works, as that is OSCORE details.

The reason is more that I believe the
overview section should provide a description
that is understandable for people that may
not be fully aware of the details of OSCORE
or that have not yet read the document. In my
case - belonging to these two categories - I
found the detailed section clearer than the
overview. This is just to clarify my
intention.

FP: Absolutely, which is why I am trying to keep it high level at this point. If the sentence "Recipient ID for use with the keying material associated to the RS" is not clear enough, could you point me to what is missing? (keeping in mind I'd rather not go into messaging level)

I have the impression that N1 is specific to
this profile. In other words, it is not
generated for the oauth-authz  (Client-Nonce)
nor for OSCORE.  One difficulty of these
profiles is that they have to put the glue
between the protocol OSCORE and the ACE
framework oauth-auth.  It would maybe ease
the reading to specify what is in the profile
and what is being defined outside.  I have
the impression that the implicit convention
you are using in the protocol overview
section is that by default what is being
mentioned is defined by the profile and what
is being defined outside the profile is being
explicitly referenced.  It might worth
stating that rule - at least in the overview
section.

FP: It is hard to draw a very strict line as some requirements spill over from the framework and OSCORE, even just to give the context of the more detailed requirements. I don't think I could correctly state that, but what I tried to do, as you noted, is a direct reference everytime (or almost) that I can easily point to.

This is at least clarified in the detailed
sections.

</mglt>

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.

   If the access token is valid, the RS replies to this request with a
   2.01 (Created) response with Content-Format = application/ace+cbor,
   which contains a nonce N2 and its newly generated OSCORE Recipient
   ID, ID2, for use with the keying material associated to the client.

   Moreover, the server concatenates the input salt received in the
   token, N1, and N2 to obtain the Master Salt of the OSCORE Security
   Context (see section 3 of [RFC8613]).  The RS then derives the
   complete Security Context associated with the received token from the
   Master Salt, the OSCORE Recipient ID generated by the client (set as



Palombini, et al.         Expires June 17, 2021                 [Page 4]

Internet-Draft            OSCORE Profile of ACE            December 2020


   its OSCORE Sender ID), its own OSCORE Recipient ID, plus the
   parameters received in the access token from the AS, following
   section 3.2 of [RFC8613].

   In a similar way, after receiving the nonce N2, the client
   concatenates the input salt, N1 and N2 to obtain the Master Salt of
   the OSCORE Security Context.  The client then derives the complete
   Security Context from the Master Salt, the OSCORE Recipient ID
   generated by the RS (set as its OSCORE Sender ID), its own OSCORE
   Recipient ID, plus the parameters received from the AS.

   Finally, the client sends a request protected with OSCORE to the RS.
<mglt>
It is unclear it that request is the
communication between the client and the RS
or something in the ace framework or oscore.

FP: This is any request, so what you call "communication between the client and RS". If it was something defined elsewhere there would have been a reference to the relevant section.

</mglt>

   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.

   The use of random nonces during the exchange prevents the reuse of an
   Authenticated Encryption with Associated Data (AEAD) nonces/key pair
   for two different messages.  Two-time pad might otherwise occur when

<mglt>
I am wondering if two time pad is correct as
opposed to a collision. I might be wrong but
two time pad seems to be correlated to OTP. I
see this closer to IV collision than OTP.
Unless you are very sure to be correct, I
would suggest to use collision instead.

FP: I believe two-time pad is the correct term.
</mglt>

   client and RS derive a new Security Context from an existing (non-
   expired) access token, as might occur when either party has just
   rebooted.  Instead, 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, by OSCORE construction,
   since even though the Master Secret, Sender ID and Recipient ID are
   the same, the Master Salt is different (see Section 3.2.1 of
   [RFC8613]).  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.

<mglt>
I might be missing something, but my
understanding of the text above is that
nonces MUST NOT repeat and I do not see the
necessity for nonce to be non predictable.
Typically would we have an issue using an
incrementing nonce that is persistent to
reboot.

FP: the randomness requirement for the nonces comes from the combination of the possibility of reboot (or loss of state/nonces) and using the same access token (hence OSCORE input material). We do not assume that the nodes have the capability to do persistent storage of nonces, since that would be very taxing, but if that was the case, then yes I would think counters would be fine (see section 7).

I think the cryptographic properties should
be clearly mentioned and maybe separated from
the implementation recommendation.

FP: this is just the overview, more detailed considerations are in fact separate and can be found in section 7.

</mglt>

   After the whole message exchange has taken place, the client can
   contact the AS to request an update of its access rights, sending a
   similar request to the token endpoint that also includes an
   identifier so that the AS can find the correct OSCORE security input
   material it has previously shared with the client.  This specific
   identifier, encoded as a byte string, is assigned by the AS to be
   unique in the sets of its OSCORE security input materials, and is not
   used as input material to derive the full OSCORE Security Context.

   An overview of the profile flow for the OSCORE profile is given in
   Figure 1.  The names of messages coincide with those of
   [I-D.ietf-ace-oauth-authz] when applicable.



Palombini, et al.         Expires June 17, 2021                 [Page 5]

Internet-Draft            OSCORE Profile of ACE            December 2020


      C                            RS                   AS
      |                            |                     |
      | ----- POST /token  ----------------------------> |
      |                            |                     |
      | <---------------------------- Access Token ----- |
      |                           + Access Information   |
      | ---- POST /authz-info ---> |                     |
      |   (access_token, N1, ID1)  |                     |
      |                            |                     |
      | <- 2.01 Created (N2, ID2)- |                     |
      |                            |                     |
    /Sec Context             /Sec Context                |
      derivation/              derivation/               |
      |                            |                     |
      | ---- OSCORE Request -----> |                     |
      |                            |                     |
      |                    /proof-of-possession          |
      |                    Sec Context storage/          |
      |                            |                     |
      | <--- OSCORE Response ----- |                     |
      |                            |                     |
   /proof-of-possession            |                     |
   Sec Context storage/            |                     |
      |                            |                     |
      | ---- OSCORE Request -----> |                     |
      |                            |                     |
      | <--- OSCORE Response ----- |                     |
      |                            |                     |
   /mutual        ...              |                     |
   authentication/


                        Figure 1: Protocol Overview

<mglt>
The figure is very clarifying, and though
this might be a very personal nit I would
have found it clearer to have the figure
before the explanatory text.

FP: I will leave this as is for now, willing to see what's best with the RFCEditor.
</mglt>

3.1.  C-to-AS: POST to token endpoint

[...]

       Header: POST (Code=0.02)
       Uri-Host: "as.example.com"
       Uri-Path: "token"
       Content-Format: "application/ace+cbor"
       Payload:
       {
         "req_aud" : "tempSensor4711",
         "scope" : "write",
         "req_cnf" : {
           "kid" : h'01'
        }

<mglt>
For my comprehension, the kid seems to me an
id to the security context.  Though this is
an example, I am a bit surprised the value is
01, which look small.  So I am just willing
to check my understanding.

FP: That is correct, and the value is just an example.
</mglt>

   Figure 3: Example C-to-AS POST /token request for updating rights to
                 an access token bound to a symmetric key.

3.2.  AS-to-C: Access Token

   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].

   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 Section 4.3 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.

<mglt>
The AS may indicate the type of communication
between the client and the RS.  However, it
seems to me the client does not provides the
AS the capabilities (i.e.  supported
profiles), which makes for example impossible
to the AS to pick one that fits the client.
I also have the impression the AS cannot
provide multiple available profiles and let
the client pick one that is implemented.  As
a result, the coap_oscore seems to be here to
indicate a "limitation" associated to the RS
- in this case OSCORE is mandatory.

While I agree that in pre-configuration
environment may things can be pre-agreed, I
am reading the text above as making the
specification of the profile as almost
useless.  I am wondering if we could not
instead mention that an AS willing to
indicate the use of OSCORE SHOULD set the
profile parameter to "coap_oscore".  A client
receiving such value and supporting this
profile SHOULD use this profile.  The
motivation for setting the profile may be
that OSCORE is only supported or that there
is a preference to use OSCORE.

FP: I believe negotiation of profiles is a point that has been brought up (possibly even by me if I remember correctly) and discussed within the ace framework,  and is much more general than for the OSCORE profile. I think if we want to take on this discussion again, we should do it with the Ace framework authors because they have strong views about this. The OSCORE profile only adapts what the ace framework specifies.

</mglt>

   Moreover, the AS MUST send the following data:

   o  a master secret

   o  an identifier of the OSCORE Input Material

   Additionally, the AS MAY send the following data, in the same
   response.

   o  a context identifier

   o  an AEAD algorithm

   o  an HMAC-based key derivation function (HKDF) algorithm



Palombini, et al.         Expires June 17, 2021                 [Page 8]

Internet-Draft            OSCORE Profile of ACE            December 2020


   o  a salt

   o  the OSCORE version number

   This data is transported in the OSCORE_Input_Material.  The
   OSCORE_Input_Material is a CBOR map object, defined in Section 3.2.1.
   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 Section 9.5 and
   Section 9.6.

   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].

<mglt>
It is unclear to me why such contextId is
needed. I suspect - but I am not sure - this
could be used as a reference for the AS of a
Context established between the client and
the RS. In such case I assume the context ID
(kid) is only shared by the client and the RS
so it could not be used for example when a
token needs to be updated /renewed.
I am wondering if that is correct and I
believe motivation for such id should be
clarified.

FP: Motivation of existence of ID Context is in OSCCORE, and we have a reference to the correct OSCORE section here (didn't want to repeat myself). No, the Context ID is not used as reference for the Sec Ctx by itself.

</mglt>

   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.

   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.

   The AS MUST send different OSCORE_Input_Material (and therefore
   different access tokens) to different authorized clients, in order
   for the RS to differentiate between clients.

   Figure 4 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.










Palombini, et al.         Expires June 17, 2021                 [Page 9]

Internet-Draft            OSCORE Profile of ACE            December 2020


       Header: Created (Code=2.01)
       Content-Type: "application/ace+cbor"
       Payload:
       {
         "access_token" : h'8343a1010aa2044c53 ...
          (remainder of access token (CWT) omitted for brevity)',
         "profile" : "coap_oscore",
         "expires_in" : "3600",
         "cnf" : {
           "osc" : {
             "id" : h'01',
             "ms" : h'f9af838368e353e78888e1426bd94e6f'
           }
         }
       }


   Figure 4: Example AS-to-C Access Token response with OSCORE profile.

   Figure 5 shows an example CWT Claims Set, including the relevant
   OSCORE parameters in the 'cnf' claim, in CBOR diagnostic notation
   without tag and value abbreviations.

   {
     "aud" : "tempSensorInLivingRoom",
     "iat" : "1360189224",
     "exp" : "1360289224",
     "scope" :  "temperature_g firmware_p",
     "cnf" : {
       "osc" : {
         "ms" : h'f9af838368e353e78888e1426bd94e6f',
         "id" : h'01'
       }
     }
   }


         Figure 5: Example CWT Claims Set with OSCORE parameters.

   The same CWT Claims Set as in Figure 5, using the value abbreviations
   defined in [I-D.ietf-ace-oauth-authz] and [RFC8747] and encoded in
   CBOR is shown in Figure 6.  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.

<mglt>
Just for my understanding. Figure 5 shows an
"access_token". I am wondering if that is
possible that some parameters may be in the
CWT but not mentioned in clear (to the
client) in the AS-to-C Access Token response.
In my mind, I see the CWT as being encrypted
so the client is not expected to interpret
it. Is that correct ?

FP: actually, figure 5 shows the "clamis set" of the access token. These claims are input to the encryption to create the actual CWT, so yes you are correct, and also the terminology used in the draft is correct.

</mglt>

[...]

3.2.1.  The OSCORE_Input_Material

   id:  This parameter identifies the OSCORE_Input_Material and is
      encoded as a byte string.  In JSON, the "id" value is a Base64
      encoded byte string.  In CBOR, the "id" type is byte string, and
      has label 8.

   version:  This parameter identifies the OSCORE Version number, which
      is an unsigned integer.  For more information about this field,



Palombini, et al.         Expires June 17, 2021                [Page 13]

Internet-Draft            OSCORE Profile of ACE            December 2020


      see section 5.4 of [RFC8613].  In JSON, the "version" value is an
      integer.  In CBOR, the "version" type is integer, and has label 0.

   ms:  This parameter identifies the OSCORE Master Secret value, which
      is a byte string.  For more information about this field, see
      section 3.1 of [RFC8613].  In JSON, the "ms" value is a Base64
      encoded byte string.  In CBOR, the "ms" type is byte string, and
      has label 1.

   hkdf:  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 4.

   alg:  This parameter identifies the OSCORE AEAD 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 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 text string or integer, and
      has label 5.

   salt:  This parameter identifies an input to the OSCORE Master Salt
      value, which is a byte string.  For more information about this
      field, see section 3.1 of [RFC8613].  In JSON, the "salt" value is
      a Base64 encoded byte string.  In CBOR, the "salt" type is byte
      string, and has label 6.

   contextId:  This parameter identifies the security context as a byte
      string.  This identifier is used as OSCORE ID Context.  For more
      information about this field, see section 3.1 of [RFC8613].  In
      JSON, the "contextID" value is a Base64 encoded byte string.  In
      CBOR, the "contextID" type is byte string, and has label 7.

<mglt>
I am wondering if there is any kind of
overlap between the id and contextId.  They
do represent different objects, but if Input
generate a single  Security Context, it seems
to me that both designates the same OSCORE
communication. I am thus wondering why do we
need these two ids.

FP: As mentioned above, no they do not designate the same data. In particular, the couple (sender ID, Context ID) identifies one particular OSCORE Security Context, while the id identifies not the Security Context but only some (incomplete) input material to derive the security context.

</mglt>

[...]

4.  Client-RS Communication

   The following subsections describe the details of the POST request
   and response to the authz-info endpoint between client and RS.  The
   client generates a nonce N1 and an identifier ID1 unique in the sets
   of its own Recipient IDs, and posts them together with the token that
   includes the materials (e.g., OSCORE parameters) received from the AS
   to the RS.  The RS then generates a nonce N2 and an identifier ID2
   unique in the sets of its own Recipient IDs, and uses Section 3.2 of
   [RFC8613] to derive a security context based on a shared master
   secret, the two nonces and the two identifiers, established between
   client and server.  The nonces and identifiers are encoded as CBOR
   byte string if CBOR is used, and as Base64 string if JSON is used.
   This security context is used to protect all future communication
   between client and RS using OSCORE, as long as the access token is
   valid.

<mglt>
all communication sounds strange to me. I am
wondering if that is not all communicationS
instead - though not being native English.

Similarly I think that the communication is
between a specific client and a specific RS -
at least once established. Thus I am
wondering if that should not be 'between THE
client and THE RS instead.

FP: Thanks, I will keep these points in mind when talking to the RFCEditor. Not a native English speaking either so can't really make a choice :)

</mglt>

   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 protectd with the generated OSCORE
   Security Context.

<mglt>
I think that is RS protected.

FP: Thanks, will fix.

It is unclear - at this stage of reading if
the exchange that performs the mutual
authentication is a specific exchange or the
communication between the client and the RS.

FP: Hopefully this can be clarified by clarifying the previous comment that talked about communication between RS and C.

</mglt>



Palombini, et al.         Expires June 17, 2021                [Page 15]

Internet-Draft            OSCORE Profile of ACE            December 2020


4.1.  C-to-RS: POST to authz-info endpoint

   The client MUST generate a nonce value 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).

<mglt>
Same comment as in the overview section
regarding the nonce randomly generated. It
seems that random generation does not require
storing any context resilient to reboot.

FP: That's correct. And as mentioned, I think the Sec Cons cover this.

</mglt>

   The client generates its own Recipient ID, ID1, for the OSCORE
   Security Context that it is establishing with the RS.  By generating
   its own Recipient ID, the client makes sure that it does not collide
   with any of its Recipient IDs, nor with any other identifier ID1 if
   the client is executing this exchange with a different RS at the same
   time.

<mglt>
This paragraph is really clarifying - and to
me necessary.

FP: Good! Thanks for the feedback.

</mglt>

   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, N1 and ID1 to the RS.

   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 Section 4.1.1, and ID1 using the 'ace_client_recipientid'
   parameter defined in Section 4.1.2.

<mglt>
The paragraph above is also really
clarifying.

FP: Good to hear. I understand at this point that what might be confusing at the overview section gets clarified here for the reader. At the same time, I don't want to go into so much detail in the overview, and don't want to do too many forward references... you see my dilemma?

</mglt>

[...]


4.2.  RS-to-C: 2.01 (Created)

[...]

<mglt>
It seems to me that the text is using
OSCORE_Input_Material, so I would say we
should remain coherent through the document.
I personnaly do not believe '_' are needed
and would probably favor the designation used
here.

FP: The idea behind the different names: the difference between with and without '_' is that the name of the actual CBOR object includes the underscore, while the more general concept of the data included in that object (i.e. the data without any format specification) doesn't.

</mglt>

   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.

   As specified in section 5.8.1 of [I-D.ietf-ace-oauth-authz], when
   receiving an updated access token with updated authorization
   information from the client (see Section 3.1), it is recommended that
   the RS overwrites the previous token, that is only the latest
   authorization information in the token received by the RS is valid.
   This simplifies the process needed by the RS to keep track of
   authorization information for a given client.

[...]

4.3.  OSCORE Setup

   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 Section 3.2, 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
   Figure 12.

N1, N2 and input salt expressed in CBOR diagnostic notation:
      nonce1 = h'018a278f7faab55a'
      nonce2 = h'25a8991cd700ac01'
      input salt = h'f9af838368e353e78888e1426bd94e6f'

N1, N2 and input salt as CBOR encoded byte strings:
      nonce1 = 0x48018a278f7faab55a
      nonce2 = 0x4825a8991cd700ac01
      input salt = 0x50f9af838368e353e78888e1426bd94e6f

Master Salt = 0x50 f9af838368e353e78888e1426bd94e6f 48 018a278f7faab55a 48 25a8991cd700ac01


    Figure 12: Example of Master Salt construction using CBOR encoding

   If JSON is used instead of CBOR, the Master Salt of the Security
   Context is the Base64 encoding of the concatenation of the same
   parameters, each of them prefixed by their size, encoded in 1 byte.
   When using JSON, the nonces and input salt have a maximum size of 255
   bytes.  An example of Master Salt construction using Base64 encoding
   is given in Figure 13.







Palombini, et al.         Expires June 17, 2021                [Page 20]

Internet-Draft            OSCORE Profile of ACE            December 2020


N1, N2 and input salt values:
      nonce1 = 0x018a278f7faab55a (8 bytes)
      nonce2 = 0x25a8991cd700ac01 (8 bytes)
      input salt = 0xf9af838368e353e78888e1426bd94e6f (16 bytes)

Input to Base64 encoding: 0x10 f9af838368e353e78888e1426bd94e6f 08 018a278f7faab55a 08 25a8991cd700ac01

Master Salt = b64'EPmvg4No41PniIjhQmvZTm8IAYonj3+qtVoIJaiZHNcArAE='


   Figure 13: Example of Master Salt construction using Base64 encoding

   The client MUST set the Sender ID to the ace_server_recipientid
   received in Section 4.2, and the Recipient ID to the
   ace_client_recipientid sent in Section 4.1.

<mglt>
It seems to me that the terminology used here
might be a bit misleading. If
ace_server_recipientid is being used as the
SID, it seems that ace_server_receipientid
and ace_client_recipientid could be
designated as ace_server_id and
ace_client_id.  What matters then is that the
IDs in a message can be interpreted by the
receiving side and that the receiving side
can see its ID.  In OSCORE that ID is called
the Sender ID (SID) which in this example
should be set to ace_server_id.  It seems to
me that these Sender and Recipient are only
here to indicate a direction and that Sender
ID is a bit misleading - but that is what we
have with OSCORE.  I am wondering if my
understanding is correct or if I am missing
something.

FP: Yes, your understanding is correct. The reason for not going with server id and client id (which we actually had in a previous version of the document) is that the roles of client and server can change in the communication, after the ace exchange has happened, i.e. the CoAP client can also act as a server and viceversa. The reasoning for going with "recipientid" instead of "senderid" (since those are mirrored - the server's recipient id is the same as the client's sender id) is that the node actually choses its own recipient id, i.e. the other node's sender id. So in this case the client sets its own Sender ID (OSCORE terminology) from the parameter generated from the server and sent in the "ace_server_recipientid" parameter.

</mglt>

The client MUST set the
   Master Secret from the parameter received from the AS in Section 3.2.
   The client MUST set the AEAD Algorithm, ID Context, HKDF, and OSCORE
   Version from the parameters received from the AS in Section 3.2, if
   present.  In case an optional parameter is omitted, the default value
   SHALL be 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.

   If any of the expected parameters is missing (e.g., any of the
   mandatory parameters from the AS or the RS), or if
   ace_client_recipientid equals ace_server_recipientid, then 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.

<mglt>
ace_client_id and ace_server_id may collide.
It is unclear to me what problem it causes.
Contexts are being indexed with the ID being
used as a recipient and the binding between
an RID and a context seems only be necessary
for a receiving party. When a node is sending
some data, it might needs the Sending Context
but it is not crucial to index it with an ID,
nor to have all Sending and Receiving Context
mixed together. As a result, I have the
impression that this case of equality is an
implementation issue. Of course I might be
missing something.

I suggest motivation is provided, and unless
we have some the corner case is removed and
let to implementations.

FP: The problem if they collide is that there would be collision of keys for client and server (Sender Key and Recipient Key). We will add a reference to the motivation in OSCORE, section 3.3 of OSCORE https://tools.ietf.org/html/rfc8613#section-3.3

</mglt>

   The client then uses this Security Context to send requests to the RS
   using OSCORE.

   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 the same way described
   above.  An example of Master Salt construction using CBOR encoding is
   given in Figure 12 and using Base64 encoding is given in Figure 13.
   The RS MUST set the Sender ID from the ace_client_recipientid
   received in Section 4.1, and the Recipient ID from the
   ace_server_recipientid sent in Section 4.2.  The RS MUST set the
   Master Secret from the parameter received from the AS and forwarded
   by the client in the access token in Section 4.1 after validation of
   the token as specified in Section 4.2.  The RS MUST set the AEAD
   Algorithm, ID Context, HKDF, and OSCORE Version from the parameters



Palombini, et al.         Expires June 17, 2021                [Page 21]

Internet-Draft            OSCORE Profile of ACE            December 2020


   received from the AS and forwarded by the client in the access token
   in Section 4.1 after validation of the token as specified in
   Section 4.2, if present.  In case an optional parameter is omitted,
   the default value SHALL be used as described in sections 3.2 and 5.4
   of [RFC8613].  After that, the RS MUST derive the complete Security
   Context following section 3.2.1 of [RFC8613], and MUST associate this
   Security Context with the authorization information from the access
   token.

   The RS then uses this Security Context to verify requests and send
   responses to the client using OSCORE.  If OSCORE verification fails,
  error responses are used, as specified in section 8 of [RFC8613].
   Additionally, if OSCORE verification succeeds, the verification of
   access rights is performed as described in section Section 4.4.  The
   RS MUST NOT use the Security Context after the related token has
   expired, and MUST respond with a unprotected 4.01 (Unauthorized)
   error message to requests received that correspond to a Security
   Context with an expired token.

   Note that the ID Context can be assigned by the AS, communicated and
   set in both the RS and client after the exchange specified in this
   profile is executed.  Subsequently, client and RS can update their ID
   Context by running a mechanism such as the one defined in
   Appendix B.2 of [RFC8613] if they both support it and are configured
   to do so.
<mglt>
I am reading the text as if that works they
will be able to update the ID, but there is
no guarantee for that. I would expect some
ways to announce the support of such
mechanism.

FP: If the server doesn't support this mechanism, it will reply with an error, and the exchange will fail. There is no need to communicate support of this mechanism.

</mglt>

In that case, the ID Context in the OSCORE Security
   Context will not match the "contextId" parameter of the corresponding
   OSCORE_Input_Material.

<mglt>

Well, I might be missing something, but I
have the impression the mechanism has been
designed to mitigate the contextID and the id
when they are equal.

FP: Actually no, these IDs are used independently, as mentioned in a previous answer. This mechanism is designed to easily update the keying material.

I suppose having these
id matching raises some issues, but it is
unclear to me what the issue is.  I am also
wondering - as mentioned earlier whether we
need to have these two ID, and if so, if that
could be possible to derive these IDs one
from another. This would prevent the defining
a mechanism.

FP: Hopefully this is clearer by the answers above. We do need both, they have different functions.

Currently here is how I see the situation:
a) the collision might be an issue, and
b) we might have a mechanism to address this
potential issue.

Note that I might emphasize the issue too
much, that is just to clarify my thoughts.

</mglt>

Running Appendix B.2 results in the keying
   material in the Security Contexts of client and RS being updated;
   this same result can also be achieved by the client reposting the
   access token to the unprotected /authz-info endpoint at the RS, as
   described in Section 4.1, but without updating the ID Context.

[...]

6.  Discarding the Security Context

On Mon, Dec 14, 2020 at 10:46 AM Francesca Palombini <francesca.palombini=[e-mail]> wrote:
Ah, of course, they are indeed out of sync, thank you for noticing! I am fixing it already in the github, but I am thinking of waiting for Daniel's go ahead before submitting one more version, see if he wanted to review one last time.

Francesca

On 14/12/2020, 16:32, "Benjamin Kaduk" <[e-mail]> wrote:

    Thanks, Francesca!

    It looks like the CBOR label values have gotten out of sync between Table 1
    and the prose.  (The IANA Considerations just refer to Table 1, so I think
    that Section 3.2.1 is the only thing that needs to be kept in sync.)

    -Ben

    On Mon, Dec 14, 2020 at 09:58:21AM +0000, Francesca Palombini wrote:
    > Hi all,
    >
    > This update answers Marco's latest review (thanks Marco!), answering all comments received as WGLC.
    >
    > Thanks,
    > Francesca
    >
    > On 14/12/2020, 09:49, "Ace on behalf of [e-mail]" <[e-mail] on behalf of [e-mail]> wrote:
    >
    >
    >     A New Internet-Draft is available from the on-line Internet-Drafts directories.
    >     This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF.
    >
    >             Title           : OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework
    >             Authors         : Francesca Palombini
    >                               Ludwig Seitz
    >                               Göran Selander
    >                               Martin Gunnarsson
    >           Filename        : draft-ietf-ace-oscore-profile-14.txt
    >           Pages           : 33
    >           Date            : 2020-12-14
    >
    >     Abstract:
    >        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.
    >
    >
    >     The IETF datatracker status page for this draft is:
    >     https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/
    >
    >     There are also htmlized versions available at:
    >     https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-14
    >     https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-14
    >
    >     A diff from the previous version is available at:
    >     https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-14
    >
    >
    >     Please note that it may take a couple of minutes from the time of submission
   >     until the htmlized version and diff are available at tools.ietf.org.
    >
    >     Internet-Drafts are also available by anonymous FTP at:
    >     ftp://ftp.ietf.org/internet-drafts/
    >
    >
    >     _______________________________________________
    >     Ace mailing list
    >     [e-mail]
    >     https://www.ietf.org/mailman/listinfo/ace
    >
    > _______________________________________________
    > Ace mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ace


--
Daniel Migault
Ericsson