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

[Daniel Migault <[e-mail]>]

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.
</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.
</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
</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.
</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.
 </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.
</mglt>

> This is at least clarified in the detailed
>
> sections.
>
>
>
> </mglt>
>
>
>
> for use with the keying material
>
>    associated to the RS.  The client posts the token, N1 and its
>
>    Recipient ID to the RS using the authz-info endpoint and mechanisms
>
>    specified in section 5.8 of [I-D.ietf-ace-oauth-authz] and Content-
>
>    Format = application/ace+cbor.  When using this profile, the
>
>    communication with the authz-info endpoint is not protected, except
>
>    for update of access rights.
>
>
>
>    If the access token is valid, the RS replies to this request with a
>
>    2.01 (Created) response with Content-Format = application/ace+cbor,
>
>    which contains a nonce N2 and its newly generated OSCORE Recipient
>
>    ID, ID2, for use with the keying material associated to the client.
>
>
>
>    Moreover, the server concatenates the input salt received in the
>
>    token, N1, and N2 to obtain the Master Salt of the OSCORE Security
>
>    Context (see section 3 of [RFC8613]).  The RS then derives the
>
>    complete Security Context associated with the received token from the
>
>    Master Salt, the OSCORE Recipient ID generated by the client (set as
>
>
>
>
>
>
>
> Palombini, et al.         Expires June 17, 2021                 [Page 4]
>
>
>
> Internet-Draft            OSCORE Profile of ACE            December 2020
>
>
>
>
>
>    its OSCORE Sender ID), its own OSCORE Recipient ID, plus the
>
>    parameters received in the access token from the AS, following
>
>    section 3.2 of [RFC8613].
>
>
>
>    In a similar way, after receiving the nonce N2, the client
>
>    concatenates the input salt, N1 and N2 to obtain the Master Salt of
>
>    the OSCORE Security Context.  The client then derives the complete
>
>    Security Context from the Master Salt, the OSCORE Recipient ID
>
>    generated by the RS (set as its OSCORE Sender ID), its own OSCORE
>
>    Recipient ID, plus the parameters received from the AS.
>
>
>
>    Finally, the client sends a request protected with OSCORE to the RS.
>
> <mglt>
>
> It is unclear it that request is the
>
> communication between the client and the RS
>
> or something in the ace framework or oscore.
>
>
>
> FP: This is any request, so what you call "communication between the
> client and RS". If it was something defined elsewhere there would have been
> a reference to the relevant section.
>
>
>
<mglt>
I believe this should be clarified.
</mglt>

> </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.
</mglt>

> </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.
</mglt>

>
>
> </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>

> 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>
>
>
>
>    Moreover, the AS MUST send the following data:
>
>
>
>    o  a master secret
>
>
>
>    o  an identifier of the OSCORE Input Material
>
>
>
>    Additionally, the AS MAY send the following data, in the same
>
>    response.
>
>
>
>    o  a context identifier
>
>
>
>    o  an AEAD algorithm
>
>
>
>    o  an HMAC-based key derivation function (HKDF) algorithm
>
>
>
>
>
>
>
> Palombini, et al.         Expires June 17, 2021                 [Page 8]
>
>
>
> Internet-Draft            OSCORE Profile of ACE            December 2020
>
>
>
>
>
>    o  a salt
>
>
>
>    o  the OSCORE version number
>
>
>
>    This data is transported in the OSCORE_Input_Material.  The
>
>    OSCORE_Input_Material is a CBOR map object, defined in Section 3.2.1.
>
>    This object is transported in the 'cnf' parameter of the access token
>
>    response as defined in Section 3.2 of [I-D.ietf-ace-oauth-params], as
>
>    the value of a field named 'osc', registered in Section 9.5 and
>
>    Section 9.6.
>
>
>
>    The AS MAY assign an identifier to the context (context identifier).
>
>    This identifier is used as ID Context in the OSCORE context as
>
>    described in section 3.1 of [RFC8613].  If assigned, this parameters
>
>    MUST be communicated as the 'contextId' field in the
>
>    OSCORE_Input_Material.  The applications needs to consider that this
>
>    identifier is sent in the clear and may reveal information about the
>
>    endpoints, as mentioned in section 12.8 of [RFC8613].
>
>
>
> <mglt>
>
> It is unclear to me why such contextId is
>
> needed. I suspect - but I am not sure - this
>
> could be used as a reference for the AS of a
>
> Context established between the client and
>
> the RS. In such case I assume the context ID
>
> (kid) is only shared by the client and the RS
>
> so it could not be used for example when a
>
> token needs to be updated /renewed.
>
> I am wondering if that is correct and I
>
> believe motivation for such id should be
>
> clarified.
>
>
>
> FP: Motivation of existence of ID Context is in OSCCORE, and we have a
> reference to the correct OSCORE section here (didn't want to repeat
> myself). No, the Context ID is not used as reference for the Sec Ctx by
> itself.
>
>
>
<mglt>
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 ?

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.

</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>
>
>
>
>
>
>
>
> 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>

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