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

[Daniel Migault <[e-mail]>]

Hi Francesca,

Thanks for the update, I believe that all concerns I raised have been
addressed.   Given the latest update of draft-ietf-ace-dtls-authorize due
to a comment raised by the secdir, I am tempted to think that we may sync a
bit the wording between the two drafts. This is to me the only point we
need to resolve. Before sending this back to Ben.

I provide the remaining concern below. I has been extracted from my more
complete comments/responses to your comments.

Thanks for the update!

Yours,
Daniel

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>
>
> I understand that it will be clarified that MUST fulfills oauth-authz
> section 5.8.1.  I do see SHOULD as a bit stronger than RECOMMEND - but that
> may not be true. However, I would suggest to emphasize that OSCORE should
> be use unless there is a good reason to not use it.
>
> If we would like clients to use OSCORE and not implement other means, we
> may need to emphasize that AS supporting this profile are expected to
> support OSCORE.
>
>
>
> FP: that is not necessary. I did not add a ref to the section as it is
> referenced in the sentence just before.
>
> </mglt>
>
> <mglt>
ok, fine for the reference. Given the comment from Russ  and the current
wording draft-ietf-ace-dtls-authorize, I believe we should harmonize the
wording.

This is how has just been updated.

 The use of CoAP
   and DTLS for this communication is RECOMMENDED *REQUIRED* in this
profile, other *profile.  Other*
   protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be
   used instead. *will
   require specification of additional profile(s).*


</mglt>


On Tue, Jan 26, 2021 at 9:57 AM Francesca Palombini <
[e-mail]> wrote:

> Hi Daniel,
>
>
>
> Thank you. I have now submitted v-15 including changes to answer your
> review comments.
>
> Detailed comments below. Please let me know if I missed anything.
>
>
>
> Thanks,
>
> Francesca
>
>
>
> From: Daniel Migault <[e-mail]>
>
> Date: Thursday, 14 January 2021 at 23:33
>
> 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,
>
>
>
> As mentioned during the interim meeting this morning, please find my
> comments below.
>
>
>
> Yours,
>
> Daniel
>
>
>
> On Thu, Jan 14, 2021 at 9:02 AM Francesca Palombini <
> [e-mail]> wrote:
>
> 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.
>
> <mglt>
>
> Fine, I understand this will be specified.
>
>
>
> FP: Done now.
>
> </mglt>
>
> <mglt>
ok, it seems fine. thanks.
</mglt>

>
>
> 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>
>
> I understand that it will be clarified that MUST fulfills oauth-authz
> section 5.8.1.  I do see SHOULD as a bit stronger than RECOMMEND - but that
> may not be true. However, I would suggest to emphasize that OSCORE should
> be use unless there is a good reason to not use it.
>
> If we would like clients to use OSCORE and not implement other means, we
> may need to emphasize that AS supporting this profile are expected to
> support OSCORE.
>
>
>
> FP: that is not necessary. I did not add a ref to the section as it is
> referenced in the sentence just before.
>
> </mglt>
>
> <mglt>
ok, fine for the reference. Given the comment from Russ  and the current
wording draft-ietf-ace-dtls-authorize, I believe we should harmonize the
wording.

This is how has just been updated.

 The use of CoAP
   and DTLS for this communication is RECOMMENDED *REQUIRED* in this
profile, other *profile.  Other*
   protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be
   used instead. *will
   require specification of additional profile(s).*


</mglt>

>
>
> </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.
>
> <mglt>
>
> Ok
>
>
>
> FP: Ok done now.
>
> </mglt>
>
<mglt>
ok, thank you.
</mglt>

>
>
> 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.
>
> <mglt>
>
> It seems crucial to me that reading the overview section the reader has a
> good sense of what information is being sent to who and what for. Currently
> this is expressed using the OSCORE terminology which requires a relatively
> deep understanding of OSCORE. It seems to me beneficial to adopt a more
> common language that does not require this expertise. This is well
> explained in the detailed section, but - at least when I was reading the
> document - the overview section was more confusing than helping me. This is
> why I suggest being a bit more explicit.
>
>
>
> FP: I don't agree here, simply because I would expect someone implementing
> the OSCORE profile of Ace to be familiar with the OSCORE terminology.
> Understanding OSCORE terminology is a requirement for understanding and
> implementing the draft, and I have now added a sentence about that in the
> Terminology section.
>
>
>
<mglt>
I think that is appropriate and probably the right choice between writing
less and writing too much. Thanks.
</mglt>

> </mglt>
>
> 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)
>
> <mglt>
>
> """
>
> The client also generates its OSCORE Recipient ID (see
>
>    Section 3.1 of [RFC8613]), ID1, for use with the keying material
>
>    associated to the RS.  The client posts the token, N1 and its
>
>    Recipient ID to the RS [...]
>
> """
>
> When the client and the RS are communicating, it could legitimately being
> inferred that the recipient of a message sent by the client is the RS. In
> fact Recipient ID does not designate the recipient from a client
> perspective, but the recipient from the RS - that is to say the recipient's
> perspective. In this case, the sender ID of the recipient is expected to be
> set with the Recipient ID.
>
> So, I believe the term recipient can be misleading, if not being
> clarified.
>
>
>
> FP: I understand your point, but really I see this as a note to the OSCORE
> terminology, which we are not going to change here. I hope that by adding
> the note in the terminology about OSCORE this becomes less of an issue for
> this document.
>
<mglt>
ok.
</mglt>

> </mglt>
>
>
>
> 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.
>
> <mglt>
>
> If I recall correctly, mentioning that Nonce are profile specific would
> probably be clarifying - and maybe sufficient.
>
>
>
> FP: Ok, done now.
>
> </mglt>
>
> This is at least clarified in the detailed
>
> sections.
>
>
>
> </mglt>
>
<mglt>
I think what you propose is clear. Thanks.
</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>
>
> I believe this should be clarified.
>
>
>
> FP: Ok, done now.
>
</mglt>
>
> </mglt>
>
<mglt>
Thanks.
</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>
>
> So far what I found is that two time pad is really related to two key
> stream re-use, but I will defer to Ben to check if the use here is
> appropriated.
>
>
>
> FP: I checked with John (who was the one to bring this issue up in the
> first place) and he mentioned two-time pad is the correct for
> confidentiality, but does not consider the integrity part. Now rephrased
> according to his suggestion.
>
</mglt>
>
> </mglt>
>
<mglt>
Fine. Thanks to you for updating and thanks to John for the feed back.
</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>
>
> The text of section 7 is clear to me, the text mentioned here seems wrong
> to me - there is no randomness requirements. I suggest the text
> "Therefore... nonce" be replaced by some text from section 7 or by a
> reference to section 7.
>
>
>
> FP: I see. I have now rephrased to not talk about randomness in this
> section, and only talk about reuse.
>
> </mglt>
>
>
>
> </mglt>
>

<mglt>
I believe that is fine thanks.
</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>
>
> <mglt>
>
> sure
>
> </mglt>
>
<mglt>
just to re-iterate, I do not see this a a real matter.
</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>
>
> thanks for the response
>
> </mglt>
>
> </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>
>
> ok, it seems very unidirectional, but we may leave it as it is.
>
> </mglt>
>
> </mglt>
>
ok

>    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 OSCORE, 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>
>
> Sorry, I think I messed up with and rather had 'id' in mind. So I
> understand that id identifies OSCORE_Input_Material and contextId
> identifies the OSCORE ID Context. My initial question was why would we need
> a id, and I suspected that the reason was to enable some reference between
> the client and the AS, as the contextId may be changed between the RS and
> client. Is that correct ?
>
>
>
> FP: We need an id for the client to identify the same OSCORE input
> material on the AS in case of updatet of access right. Yes the contextId
> might change. Also id is unique for the AS, while contextId isn't
> necessarily - contextId (together with the Sender ID which is negotiated
> later on) identifies the security context once established.
>
>
>
> If I remember correctly, id and contextId could not be of the same value,
> but I currently do not remember why.Could you just briefly remember me. In
> any case, the reason I am asking is that if we were able to have one id or
> contextId, we would avoid the collision.  Typically, if contextId would be
> sufficient to derive the id, we could avoid such collision issue. So
> basically,  what I wanted to clarify - maybe for only myself - is id cannot
> be derived from contextId and that there is a need to have the separate
> id.
>
>
>
> FP: No, they don't have to be distinct values. So there is really no
> collision issue. As I said above, they identify different material.
>
>
>
> </mglt>
>

<mglt>
I think I am starting to understand that simply means it has been updated
and that having different values is not a goal in itself. Sorry for the
multiple iterations.

"""

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

""
</mglt>


> </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>
>
> thanks for the response. NOte that I was not questioning the terminology
> here.
>
> </mglt>
>
> </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>
>
> This concern can be grouped with the above comments/questions.
>
> </mglt>
>
> </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>
>
> sure
>
> </mglt.
>
> </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>
>
> sure.
>
> </mglt>
>
>
>
> </mglt
>

 <mglt>
yes this is clearer at least to me. Thanks.
</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>
>
> I believe the assumptions of the client are outside the scope of the
> protocol, so it seems to me there is no need for a MUST. As detailled
> previously I woudl either refer to eth security consideration section or
> provide the requirement for not repeating without considering how this
> could be implemented.
>
> </mglt>
>
>
>
> FP: I believe assumptions on the client, as well as implementation
> recommendations, are in scope of this document.
>
>
>
 <mglt>
The text works fine for me. Thanks.
</mglt>


> </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>
>
> I got the dilemma. I think that currently either the overview provides a
> bit more details to clarify or removes details. Currently the overview
> seems to me raising question more than indicating a direction. I am fine
> either way, but I suspect that clarifying is more straight forward.
>
>
>
> FP: I gave a shot at clarifying the points above.
>
>
>
> </mglt>
>
>
>
<mglt>
I like the way it is.
</mglt>

> </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>
>
> Sure. I believe that either we use always the same one or explain the
> difference. I have the impression for OSCORE we were using non CBOR object
> terminology. At least we could limit to a single notation in the document.
>
>
>
> FP: I have attempted to keep it consistent, and changed a couple of places
> where it wasn't. Most of the time in the doc we talk about
> OSCORE_Input_Material because we refer to the CBOR object, but in my
> opinion it's still useful to be able to distinguish between the theoretical
> and the CBOR object.
>
> </mglt>
>
>
>
<mglt>
The inconsistency - if any - was viable to me. With your further look at
it, I consider you made the right choice.
</mglt>

</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>
>
> As a note this seems to me to be a rather common situation - TLS /
> IPsec/HIP. TLS uses client/ server IPsec uses initiator responder and that
> is only valid for the handshake exchanges, so that could be seen as
> reasonable. That said I am fine with whatever is clearer to everyone.
>
> </mglt>
>
> </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>
>
> ok, yes that would help.
>
>
>
> FP: Ok, done.
>
> </mglt
>
 <mglt>
 thanks.
</mglt>

> </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>
>
> This may be something related to OSCORE, but I am not so convinced it is a
> good thing not to have any means to communicate the support of some
> mechanism. I would be happy to understand more on whether this is not
> needed, or if that could be added to OSCORE.
>
>
>
> FP: Right, that is really a comment on OSCORE, nothing we can do about it
> in this specification.
>
> </mglt>
>
<mglt>
ok.
</mglt>

> </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.
>
> <mglt>
>
> Just for me, I understood that if there id and contextId matches, we
> re-key so the contextId. I assume that re-keying update the contextId, in
> which case, contextId is likely to be different from id. In other words, if
> there is a match, a re-key operation is performed.
>
> This also means that any rekey operation that is performed could result in
> a collision. If that is the case, I believe could clarify and generalise
> this to any rekey operation.
>
>
>
> FP: As previously mentioned, contextId and id are really different, they
> identify different things and it is not a problem if they collide. We do
> nott re-key to avoid the collision between the two. The re-key can make so
> that the contextId changes, while id will remain the same.
>
> </mglt>
>
>
>
> 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
>
>
>
>
>
>
>
> --
>
> Daniel Migault
>
> Ericsson
>


-- 
Daniel Migault
Ericsson