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

[Daniel Migault <[e-mail]>]

I am fine with the proposed text and bring the discussion to the WG.

Yours,
Daniel
________________________________
From: Ace <[e-mail]> on behalf of Francesca Palombini <francesca.palombini=[e-mail]>
Sent: Thursday, January 28, 2021 11:33 AM
To: Daniel Migault <[e-mail]>; Benjamin Kaduk <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-14.txt


Hi Daniel, Ben,



I believe RECOMMENDing OSCORE between C and AS and allowing for alternatives (while clarifying that any protocol used must still fulfil the ACE framework requirements) is a better solution than mandating OSCORE between C and AS: we want to keep some level of flexibility, as the client and AS are not going to be constrained and could use something else instead.



I went ahead and did the following clarification: https://github.com/ace-wg/ace-oscore-profile/commit/b806de9c5ad48049994dc8dbfe9ee908d8492515<https://protect2.fireeye.com/v1/url?k=8eb136bb-d12a0f96-8eb17620-8692dc8284cb-7ab1296a8bec3d96&q=1&e=137511cf-e65b-4e1c-8a58-222ad5ade409&u=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oscore-profile%2Fcommit%2Fb806de9c5ad48049994dc8dbfe9ee908d8492515> and I think the draft is much better for it. I am going to upload a new version.



At the same time I want to note that I don’t believe this change (RECOMMEND • REQUIRED) on the DTLS profile was necessary nor an improvement: I don’t think that defining one additional profile for each different security protocol used between client and AS is a good idea. Nor I think this has been discussed in the working group (I for one completely missed this update, so thank you for bringing this up Daniel). Just want to make sure Ben is aware.



Francesca



From: Daniel Migault <[e-mail]>
Date: Wednesday, 27 January 2021 at 15:12
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 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]<mailto:[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]<mailto:[e-mail]>>

Date: Thursday, 14 January 2021 at 23:33

To: Francesca Palombini <[e-mail]<mailto:[e-mail]>>

Cc: Benjamin Kaduk <[e-mail]<mailto:[e-mail]>>, Ace Wg <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>

Date: Thursday, 7 January 2021 at 17:07

To: Francesca Palombini <[e-mail]<mailto:[e-mail]>>

Cc: Benjamin Kaduk <[e-mail]<mailto:[e-mail]>>, Ace Wg <[e-mail]<mailto:[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<http://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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[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<http://tools.ietf.org>.

    >

    >     Internet-Drafts are also available by anonymous FTP at:

    >     ftp://ftp.ietf.org/internet-drafts/

    >

    >

    >     _______________________________________________

    >     Ace mailing list

    >     [e-mail]<mailto:[e-mail]>

    >     https://www.ietf.org/mailman/listinfo/ace

    >

    > _______________________________________________

    > Ace mailing list

    > [e-mail]<mailto:[e-mail]>

    > https://www.ietf.org/mailman/listinfo/ace

_______________________________________________

Ace mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/ace



--

Daniel Migault

Ericsson







--

Daniel Migault

Ericsson




--

Daniel Migault

Ericsson