Subject: Re: [Ace] WGLC draft-ietf-ace-oscore-profile-13.txt

From: Francesca Palombini <[email-masked]>
Date: Tue, 8 Dec 2020 15:42:22 +0000

Hi Marco,

Thanks, very helpful as always! I have implemented all the comments in this PR https://github.com/ace-wg/ace-oscore-profile/pull/44 , if you give me the OK I can merge and upload a new submission. Happy to see that the comments were about clarifications and editorials.

Inline detailed answers.

Thanks again!
Francesca

From: Marco Tiloca <[email-masked]>
Date: Thursday, 19 November 2020 at 17:04
To: <[email-masked]>, Ace Wg <[email-masked]>
Subject: Re: [Ace] WGLC draft-ietf-ace-oscore-profile-13.txt
Resent from: <[email-masked]>
Resent to: Francesca Palombini <[email-masked]>, <[email-masked]>, Göran Selander <[email-masked]>, <[email-masked]>
Resent date: Thu, 19 Nov 2020 08:03:54 -0800 (PST)

Hello OSCORE profile authors and ACE,

Please, find below some WGLC comments. Hope it helps!

Best,
/Marco

Section 1

* s/is not done by a/is not achieved through a

FP: Ok, fixed.

* s/after the first OSCORE exchange/after the first message exchange
using OSCORE

FP: Ok, fixed.

Section 2

* "This specific identifier, encoded as a byte string, is assigned by
the AS to be unique in the sets of its OSCORE Security Contexts ..."

   To avoid confusion, it's probably better to say "unique among the
issued sets of OSCORE input material", since the AS can have actual
OSCORE Security Contexts it uses to communicate with Clients or Resource
Servers.

FP: Ok, fixed. Replaced with OSCORE security input materials

* Referring to 'id' as specific identifier, the text says: "and is not
used as input material to derive the full OSCORE Security Context."

   That's correct, but then the identifier is later included in Table 1
"OSCORE_Input_Material Parameters" :-)

   Perhaps it's fine to just revert to OSCORE_Security_Context_Object,
both for the name of Table 1 and in different spots of the text? They
would still consider 'id' as OSCORE Input Material Identifier, while
aligned with the registry name from Section 9.4.

FP: I see your point, but the name was source of discussion before and I'd rather not go back on that. I don't think it is a problem that the 'id' is both part of the "OSCORE_Input_Material" object and also not part of the actual input material. After all it needs to be part of the object to identify it. What I did is to change its CBOR label though, to have it as 0, since I think that makes more sense that to be in the middle of other input materials. Note that this is a change that will affect implementations.

* s/If the request verifies/If the request is successfully verified

FP: Ok, fixed.

* s/until token expiration/until token deletion, due to e.g. expiration
or revocation

FP: thanks for this comment. I did only keep expiration as example,

* s/the same or different/the same or a different one

FP: Ok, fixed.

* Figure 1 can also show the achievement of mutual authentication,
following the OSCORE exchange at the end

FP: Good point, added.

Section 3.1

* s/object. kid field carrying/object, with the kid field carrying

FP: Ok, fixed.

Section 3.2

* "... profile negotiation can be omitted" - I think "profile signaling"
better reflects what may happen here, see also the beginning of the
paragraph.

FP: Ok, fixed.

* s/in the the/in the

FP: Ok, fixed.

* s/in the 'cnf' parameter of the token/in the 'cnf' claim of the token

FP: Ok, fixed.

Section 3.2.1

* In the text entries following Table 1, the CBOR integer labels need to
be aligned with the CDDL summary at the end of the section.

FP: I think it was? Now I moved id to index 0, so I switched the order there too.

* s/This parameter identifies the OSCORE_Input_Material/This parameter
identifies the OSCORE_Input_Material object

FP: I will let the RFC editors decide on that one :) Don't want to become too verbose if it's not needed.

* s/the "id" type is byte string/the "id" type is bstr

FP: ah, good point. I actually changed all the description to extend the type (so byte string instead of bstr, etc), in order not to use CDDL in text.

* This version -13 has removed 'clientId' and 'serverId' from Table 1
and thus as code points from the "OSCORE Security Context Parameters"
registry.

  No strong need to include them back, but even if this profile does not
use them and does not send them on the wire, I think they still belong
to the same namespace, since they are descriptive of a security context
and are in fact also used as input material to derive it :-)
FP: I agree with that, and think the first draft to use them will register them. The registration of the OSCORE_Input_Material does not specify how this material is used, that is up to the draft describing the derivation process, so it does not make sense to register them here without explaining the derivation process using those parameters.

Section 4

* s/the RS and client authenticates themselves/the RS and client
authenticate each other

FP: Ok, fixed.
* s/successfully verified the response from the RS/successfully verified
a response from the RS as protected with the established OSCORE context

   (similar occurrences are also later in the text)

FP: Ok, fixed.

Section 4.1

* In the first paragraph, I suggest to rephrase as "and the posted
access token is still retained".

  That doesn't require to explicitly mention "valid", since asserting
especially validity can be non-trivial for the client, e.g. in case of
Token revocation.
  (similar occurrences are also later in the text)

FP: I am not sure about this one: I don't think talking about "retaining" an access token is precise enough (a token might be "retained" in memory, but expired). "Valid" to me seems less ambiguous. I would expect implementations to have a way to mark token as valid or non valid (e.g. if expired or revoked). What woud be difficult for implementations to assert validity?
* In the second paragraph, I suggest to extend the ending as:

  "... makes sure that it does not collide with any of its Recipient IDs
currently used. These include also Recipient IDs used as ID1 value for
ongoing executions of this profile."

FP: Good point, I think I got it. Rephrased it with " nor with any other identifier ID1 if the client is executing this exchange with a different RS at the same time."
* s/the client MUST wrap the token and N1 in a CBOR map/the client MUST
wrap the token, N1 and ID1 in a CBOR map
FP: Ok, fixed.

* s/using the "access_token" parameter/using the 'access_token' parameter

FP: Ok, fixed.

* In the sixth paragraph, the last sentence says "... as different
nonces will be used." Doesn't the client and the RS also negotiate new
IDs like they did in the first posting of the same original token?

FP: yes, but the client might decide to reuse the same ID, I don't really see a problem with that.

* In the last paragraph: "The client MUST only send the access token in
the payload, no nonce or identifier are sent."

   Just to be sure, can you expand on this request format? I suppose the
client still uses Content-Format "application/ace+cbor", just including
only the 'access_token' entry in the map. Correct?

FP: Yes that is correct. The request is the same as in Figure 10 with the exception that it is protected with OSCORE and that no nonce nor ids are sent.

* In the last paragraph: "... the RS will replace the old token with the
new one, maintaining the same Security Context."

   This replacement step can be expanded for clarity. A simple 1-to-1
replacement would overwrite also the stored 'cnf' claim from the
original token, among other things. So it should be more about
selectively replacing some information originally coming the first
token, while keeping some other from it. What to actually replace should
include, for instance, information related to access rights (e.g.
scope), and to the new token's lifetime (exp, exi).

FP: I believe what you were commenting here (i.e. the RS behavior) is actually described in details in section 4.2, starting with "If the RS receives the token in a OSCORE protected message...". I only want to give the intuition here, focusing more on the client without go into the details of what the RS has to do as a consequence, which is why I am tempted to not make a change here. But if you think something is missing from 4.2, let me know and I'll see if we can expand there.
* While reading this, I was wondering if one could repost the same first
token to rekey the OSCORE context. This is mentioned at the end of
Section 4.3, but anticipating the possibility here and adding a forward
pointer to Section 4.3 would help.

FP: I added a paragraph in section 4.1 (starting with "The client may also chose to re-POST the access token...")

Section 4.1.1 and Section 4.1.2

* The first sentence captures the case where the first token is posted
or re-posted. It can be rephrased to cover also the posting of a token
for updating access rights, where these parameters are not included.

FP: Ok, added text at the end of the sentence.

Section 4.2

* "any of the mandatory    parameters from the AS or the identifier) ..."

   It's worth making it explicit that the mentioned identifier is 'id'.

FP: I actually meant the identifier id1. Added it.

* s/in the 'osc'/in the 'osc' field

FP: Ok, done.

* "... the RS must respond" --- Should this not be a MUST ?

FP: No, this requirement comes from the framework, so it is non normative (the normative one is "The RS MUST follow the procedures defined in section 5.8.1 of
   [I-D.ietf-ace-oauth-authz]")
* s/is different from the ace_client_recipientid/is different from the
value specified in the received 'ace_client_recipientid' parameter

FP: Ok, done.

* Second paragraph after Figure 11

   - s/MUST discard/MUST ignore

FP: Ok, done.

   - s/the "cnf" parameter of/the 'cnf' claim of

FP: Ok, done.

   - s/matches the OSCORE Input/matches with the identifier of the
OSCORE Input

FP: Ok, done.

   - Related to a previous comment about token replacement, some
information has to be retained from the first token, as not present in
the new one.

FP: I am not sure how to implement this comment without making it very hard to read. I trust readers at this point will understand what "discard the old token and associate the new token" means.

   -s/in the "cnf" parameter/in the 'cnf' claim

FP: Ok, done.

* It can happen that all is fine for the RS, it installs the OSCORE
Security Context, it responds to the client, and the response gets lost.
In this case:

   - After a timeout expiration, can the client simply repost the same
token as mentioned at the end of Section 4.3? This can be another reason
for reposting the original token, to mention in the sixth paragraph of
Section 4.1.

FP: Yes, added.

   - Should the server delete the token and the OSCORE Security Context,
if not receiving an OSCORE protected request from the client before a
timeout expires? After all, it's reasonable to assume that a client
sends a request right away or not long after the token post is
completed. If this is included, it would be one more point in the bullet
list for the RS in Section 6.

FP: It is reasonable, however I don't want to add it to Section 6 as I don't want to make it a requirement to the RS. It is up to applications to define policies for such a timeout. We make it clear that it's only after the first OSCORE exchange has happened that C and RS are assure that the exchange succeeded. How long to wait, I think should be out of scope.

Section 4.2.1 and 4.2.2

* The first sentence captures the case where the first token is posted
or re-posted. It can be rephrased to cover also the posting of a token
for updating access rights, where these parameters are not included.

FP: Ok, done

Section 4.3

* s/Secret from the parameter, received/Secret from the parameter received

FP: Ok, done

* If the client stops the exchange, it should also unlock the ID1 value
previously offered.

FP: I believe this is implementation details. I think this should be covered by the clarifications above.

* s/to RS/to the RS

FP: Ok, done

* The end of the last paragraph mentions possibly reposting the same
first token to rekey the OSCORE context. Consistently with the fourth
paragraph of Section 4, I suggest to mention here again that this
request is not protected, since not related to updating access rights.

FP: Ok, done

Section 5

* s/profile, other/profile, but other

FP: s/,/; instead, but done

Section 6

* s/context expires/context expires or is revoked   (2 instances)

FP: Again, I am hesitant to add revoked here, as the framework barely touches on revocations of tokens, and explicitely states that expiration is the norm instead.

* In the fourth bullet point, isn't this actually fine if the reposted
token is exactly the original first token? In that case, new nonces (and
I guess also IDs) are exchanged.

FP: This is fine, but it means the RS is wishing to re-derive a new context, so the old one must be discarded.

* I think there should be one more bullet point in the client list, for
when the client receives back ID2 == ID1 from the RS, after having
reposted the original first access token.

(This relates to a previous comment for Section 4.1; I thought a
reposting of the first original token involves an exchange of new nonces
as well as of new IDs)

FP: Why? I don't understand why this is not already covered. Ah ok so maybe this is not valid anymore?

Section 7

* s/usecase/use case

FP: Ok, done

* s/for a client/for a same client   (2 instances)

FP: Ok, done (I am sure the RFCEditor will change this to something else too :) )

* I think it's better to expand C and Cs to "client" and "clients"

FP: Ok, done

On 2020-11-08 23:51, Daniel Migault wrote:
Hi,

This email starts a WGLC for the draft draft-ietf-ace-oscore-profile until Monday November 23. We would like to send the document back to the IESG with sufficient confidence, so please take the time to review it carefully provide comments and feed backs.
Note that also that the document (13) is being reviewed by the security directorate.

Yours,
Daniel

[1] https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/<https://protect2.fireeye.com/v1/url?k=561b951b-0980ac2a-561bd580-86e2237f51fb-7e8ff0f2b460277b&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-ietf-ace-oscore-profile%252F%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727980974848%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DDCzcOuQ7MnBLs0hxiHbIAi%252B1VjBHLBJRzi4N8P9VDV4%253D%26reserved%3D0>

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Tue, Oct 27, 2020 at 12:14 PM
Subject: [Ace] I-D Action: draft-ietf-ace-oscore-profile-13.txt
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>

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-13.txt
        Pages           : 32
        Date            : 2020-10-27

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/<https://protect2.fireeye.com/v1/url?k=577dc830-08e6f101-577d88ab-86e2237f51fb-0882f337db2a5b4a&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fdraft-ietf-ace-oscore-profile%252F%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727980974848%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DDCzcOuQ7MnBLs0hxiHbIAi%252B1VjBHLBJRzi4N8P9VDV4%253D%26reserved%3D0>

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-13<https://protect2.fireeye.com/v1/url?k=76148db7-298fb486-7614cd2c-86e2237f51fb-6db7a86c1af38e00&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Ftools.ietf.org%252Fhtml%252Fdraft-ietf-ace-oscore-profile-13%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727980984842%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DOaxJICL6Bp%252Fzt5DMwUWcv04yU07JkvEILCNy17Moqro%253D%26reserved%3D0>
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-13<https://protect2.fireeye.com/v1/url?k=6a06d0a5-359de994-6a06903e-86e2237f51fb-61db490b8c9907fa&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fdatatracker.ietf.org%252Fdoc%252Fhtml%252Fdraft-ietf-ace-oscore-profile-13%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727980984842%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3D7Ac6UdrbH6IBIcm2%252BYWd4iwufwIblv76Nq4VretJZuw%253D%26reserved%3D0>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-13<https://protect2.fireeye.com/v1/url?k=71594c3d-2ec2750c-71590ca6-86e2237f51fb-f0c9e033402ad200&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Frfcdiff%253Furl2%253Ddraft-ietf-ace-oscore-profile-13%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727980994840%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DR%252Bj8cmPnyb8DUEcygCzhOpCJBqQbS8gDalwSsVZtdkw%253D%26reserved%3D0>

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<https://protect2.fireeye.com/v1/url?k=ca0c6a74-95975345-ca0c2aef-86e2237f51fb-f8b34619f6d31a0a&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%252F%252Ftools.ietf.org%252F%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727980994840%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3Dpec0ClOMPHj%252BsHa%252ByDBFOvDj90aPwlcEURCcQI6igxI%253D%26reserved%3D0>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<https://protect2.fireeye.com/v1/url?k=ec181a40-b3832371-ec185adb-86e2237f51fb-0c8012effe9f8cf8&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dftp%253A%252F%252Fftp.ietf.org%252Finternet-drafts%252F%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727981004834%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DAJhNeMUrwuGWnKk7Oazo4jFxm0gX1t7hMcI9IvRIQCk%253D%26reserved%3D0>

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace<https://protect2.fireeye.com/v1/url?k=8c63f3f8-d3f8cac9-8c63b363-86e2237f51fb-12f198f7f4eaea38&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Face%26data%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727981004834%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26sdata%3DwMdtJRfiWur2dXXZw8z84usAX7P9vHcvhGy%252BPNHeDVg%253D%26reserved%3D0>

--
Daniel Migault
Ericsson

_______________________________________________

Ace mailing list

[email-masked]<mailto:[email-masked]>

https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C330189d7d82b48dd1e8e08d88438f043%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637404727981024818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=SlpecuiDXwgoE5ogL8jSqtUO7zVut7dr1q6VXX8y9Z8%3D&amp;reserved=0<https://protect2.fireeye.com/v1/url?k=1b3a6707-44a15e36-1b3a279c-86e2237f51fb-a3272a3cd4614bf8&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Feur02.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fwww.ietf.org%252Fmailman%252Flistinfo%252Face%26amp%3Bdata%3D04%257C01%257Cmarco.tiloca%2540ri.se%257C330189d7d82b48dd1e8e08d88438f043%257C5a9809cf0bcb413a838a09ecc40cc9e8%257C0%257C0%257C637404727981024818%257CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%253D%257C3000%26amp%3Bsdata%3DSlpecuiDXwgoE5ogL8jSqtUO7zVut7dr1q6VXX8y9Z8%253D%26amp%3Breserved%3D0>

--

Marco Tiloca

Ph.D., Senior Researcher

RISE Research Institutes of Sweden

Division ICT

Isafjordsgatan 22 / Kistagången 16

SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501

https://www.ri.se<https://protect2.fireeye.com/v1/url?k=1ed65bc0-414d62f1-1ed61b5b-86e2237f51fb-af23a91f66f28bf9&q=1&e=50e404d5-8770-4cd3-bd41-476381ce5ab8&u=https%3A%2F%2Fwww.ri.se%2F>

---

From: Marco Tiloca <[email-masked]>
Date: Wed, 9 Dec 2020 17:26:45 +0100

Hi Francesca,

Thank you for taking care of the review! I think the commits in the PR
address all my comments.

Best,
/Marco

On 2020-12-08 16:42, Francesca Palombini wrote:
>
> Hi Marco,
>
>  
>
> Thanks, very helpful as always! I have implemented all the comments in
> this PR https://github.com/ace-wg/ace-oscore-profile/pull/44
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Face-wg%2Face-oscore-profile%2Fpull%2F44&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720883194%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UPQbvAjheecQ3qFTNZrfA%2F2rXtocuc5U5AQdvhFxxNI%3D&reserved=0>
> , if you give me the OK I can merge and upload a new submission. Happy
> to see that the comments were about clarifications and editorials.
>
>  
>
> Inline detailed answers.
>
>  
>
> Thanks again!
> Francesca
>
>  
>
> *From: *Marco Tiloca <[email-masked]>
> *Date: *Thursday, 19 November 2020 at 17:04
> *To: *<[email-masked]>, Ace Wg <[email-masked]>
> *Subject: *Re: [Ace] WGLC draft-ietf-ace-oscore-profile-13.txt
> *Resent from: *<[email-masked]>
> *Resent to: *Francesca Palombini <[email-masked]>,
> <[email-masked]>, Göran Selander
> <[email-masked]>, <[email-masked]>
> *Resent date: *Thu, 19 Nov 2020 08:03:54 -0800 (PST)
>
>  
>
> FP: I see your point, but the name was source of discussion before and
> I'd rather not go back on that. I don't think it is a problem that the
> 'id' is both part of the "OSCORE_Input_Material" object and also not
> part of the actual input material. After all it needs to be part of
> the object to identify it. What I did is to change its CBOR label
> though, to have it as 0, since I think that makes more sense that to
> be in the middle of other input materials. Note that this is a change
> that will affect implementations.
>
>  
>
> FP: ah, good point. I actually changed all the description to extend
> the type (so byte string instead of bstr, etc), in order not to use
> CDDL in text.
>
>  
>
> FP: I agree with that, and think the first draft to use them will
> register them. The registration of the OSCORE_Input_Material does not
> specify how this material is used, that is up to the draft describing
> the derivation process, so it does not make sense to register them
> here without explaining the derivation process using those parameters.
>
>  
>
> Section 4
>
>  
>
> FP: I am not sure about this one: I don't think talking about
> "retaining" an access token is precise enough (a token might be
> "retained" in memory, but expired). "Valid" to me seems less
> ambiguous. I would expect implementations to have a way to mark token
> as valid or non valid (e.g. if expired or revoked). What woud be
> difficult for implementations to assert validity?
>
> FP: Good point, I think I got it. Rephrased it with " nor with any
> other identifier ID1 if the client is executing this exchange with a
> different RS at the same time."
>
> FP: Yes that is correct. The request is the same as in Figure 10 with
> the exception that it is protected with OSCORE and that no nonce nor
> ids are sent.
>
>  
>
> FP: I believe what you were commenting here (i.e. the RS behavior) is
> actually described in details in section 4.2, starting with "If the RS
> receives the token in a OSCORE protected message...". I only want to
> give the intuition here, focusing more on the client without go into
> the details of what the RS has to do as a consequence, which is why I
> am tempted to not make a change here. But if you think something is
> missing from 4.2, let me know and I'll see if we can expand there.
>
> FP: I added a paragraph in section 4.1 (starting with "The client may
> also chose to re-POST the access token...")
>
>  
>
> FP: No, this requirement comes from the framework, so it is non
> normative (the normative one is "The RS MUST follow the procedures
> defined in section 5.8.1 of
>
> FP: I am not sure how to implement this comment without making it very
> hard to read. I trust readers at this point will understand what
> "discard the old token and associate the new token" means.
>
>  
>
> FP: It is reasonable, however I don't want to add it to Section 6 as I
> don't want to make it a requirement to the RS. It is up to
> applications to define policies for such a timeout. We make it clear
> that it's only after the first OSCORE exchange has happened that C and
> RS are assure that the exchange succeeded. How long to wait, I think
> should be out of scope.
>
>  
>
> Section 4.2.1 and 4.2.2
>
>  
>
> FP: Again, I am hesitant to add revoked here, as the framework barely
> touches on revocations of tokens, and explicitely states that
> expiration is the norm instead.
>
>  
>
> FP: This is fine, but it means the RS is wishing to re-derive a new
> context, so the old one must be discarded.
>
>  
>
>     This email starts a WGLC for the draft
>     draft-ietf-ace-oscore-profile until Monday November 23. We would
>     like to send the document back to the IESG with sufficient
>     confidence, so please take the time to review it carefully provide
>     comments and feed backs.
>
>     [1]
>     https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D561b951b-0980ac2a-561bd580-86e2237f51fb-7e8ff0f2b460277b%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fdatatracker.ietf.org%25252Fdoc%25252Fdraft-ietf-ace-oscore-profile%25252F%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980974848%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DDCzcOuQ7MnBLs0hxiHbIAi%25252B1VjBHLBJRzi4N8P9VDV4%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720893147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qok50i4u7VVFEl1OFeUXLRKDiGgpbk4dLbpvkU6Bei4%3D&reserved=0>
>
>      
>
>     From: <[email-masked] <mailto:[email-masked]>>
>     To: <[email-masked] <mailto:[email-masked]>>
>     Cc: <[email-masked] <mailto:[email-masked]>>
>
>
>
>
>     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
>     https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D577dc830-08e6f101-577d88ab-86e2237f51fb-0882f337db2a5b4a%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fdatatracker.ietf.org%25252Fdoc%25252Fdraft-ietf-ace-oscore-profile%25252F%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980974848%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DDCzcOuQ7MnBLs0hxiHbIAi%25252B1VjBHLBJRzi4N8P9VDV4%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720893147%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zruCrjBZvRmdiFa4COi2psW7iHU4V63fVCOxILxDSyk%3D&reserved=0>
>
>     https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-13
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D76148db7-298fb486-7614cd2c-86e2237f51fb-6db7a86c1af38e00%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Ftools.ietf.org%25252Fhtml%25252Fdraft-ietf-ace-oscore-profile-13%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980984842%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DOaxJICL6Bp%25252Fzt5DMwUWcv04yU07JkvEILCNy17Moqro%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720903105%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hp433XpyJUn9JsGQChpyoRYt4cJfZJ38YcBps34MEWc%3D&reserved=0>
>     https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-13
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D6a06d0a5-359de994-6a06903e-86e2237f51fb-61db490b8c9907fa%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fdatatracker.ietf.org%25252Fdoc%25252Fhtml%25252Fdraft-ietf-ace-oscore-profile-13%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980984842%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253D7Ac6UdrbH6IBIcm2%25252BYWd4iwufwIblv76Nq4VretJZuw%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720903105%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=m3u076VCs%2FiJaJhjlmeJ7TU6wD0pmnt5gqOvx092rZY%3D&reserved=0>
>
>     https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-13
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D71594c3d-2ec2750c-71590ca6-86e2237f51fb-f0c9e033402ad200%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fwww.ietf.org%25252Frfcdiff%25253Furl2%25253Ddraft-ietf-ace-oscore-profile-13%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980994840%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DR%25252Bj8cmPnyb8DUEcygCzhOpCJBqQbS8gDalwSsVZtdkw%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720913129%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=F8QwAqDXoF0BILw9dlX81bR1mf5A%2FEnqzxPu%2FIYtGWM%3D&reserved=0>
>
>
>     until the htmlized version and diff are available at
>     tools.ietf.org
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dca0c6a74-95975345-ca0c2aef-86e2237f51fb-f8b34619f6d31a0a%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttp%25253A%25252F%25252Ftools.ietf.org%25252F%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727980994840%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253Dpec0ClOMPHj%25252BsHa%25252ByDBFOvDj90aPwlcEURCcQI6igxI%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720923031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=UpddxCFd%2B31znTW3iXzzX2xacrnj6GRnHhJher5nX3E%3D&reserved=0>.
>
>     ftp://ftp.ietf.org/internet-drafts/
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3Dec181a40-b3832371-ec185adb-86e2237f51fb-0c8012effe9f8cf8%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dftp%25253A%25252F%25252Fftp.ietf.org%25252Finternet-drafts%25252F%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727981004834%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DAJhNeMUrwuGWnKk7Oazo4jFxm0gX1t7hMcI9IvRIQCk%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720923031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=RCz5%2FveS9uLDPSZ3vKyXGniIfA%2Bled5V4tVIZ8lihQY%3D&reserved=0>
>
>
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/ace
>     <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D8c63f3f8-d3f8cac9-8c63b363-86e2237f51fb-12f198f7f4eaea38%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fwww.ietf.org%25252Fmailman%25252Flistinfo%25252Face%2526data%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727981004834%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526sdata%253DwMdtJRfiWur2dXXZw8z84usAX7P9vHcvhGy%25252BPNHeDVg%25253D%2526reserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720932989%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BSo5ma5lttya0kAzk8VDD9KHRlptjqENzbl%2FSyVf9xM%3D&reserved=0>
>
>
>      
>
>     -- 
>
>     Daniel Migault
>
>     Ericsson
>
>
>
>     [email-masked] <mailto:[email-masked]>
>
>     https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C330189d7d82b48dd1e8e08d88438f043%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637404727981024818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=SlpecuiDXwgoE5ogL8jSqtUO7zVut7dr1q6VXX8y9Z8%3D&amp;reserved=0 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D1b3a6707-44a15e36-1b3a279c-86e2237f51fb-a3272a3cd4614bf8%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Feur02.safelinks.protection.outlook.com%252F%253Furl%253Dhttps%25253A%25252F%25252Fwww.ietf.org%25252Fmailman%25252Flistinfo%25252Face%2526amp%253Bdata%253D04%25257C01%25257Cmarco.tiloca%252540ri.se%25257C330189d7d82b48dd1e8e08d88438f043%25257C5a9809cf0bcb413a838a09ecc40cc9e8%25257C0%25257C0%25257C637404727981024818%25257CUnknown%25257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%25253D%25257C3000%2526amp%253Bsdata%253DSlpecuiDXwgoE5ogL8jSqtUO7zVut7dr1q6VXX8y9Z8%25253D%2526amp%253Breserved%253D0&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720932989%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qtS%2BkSgOGR5xYUBZJzmjz4uRcoTaPvsOOkwqYWwvFMs%3D&reserved=0>
>
>
>
> -- 
> Marco Tiloca
> Ph.D., Senior Researcher
>  
> https://www.ri.se <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D1ed65bc0-414d62f1-1ed61b5b-86e2237f51fb-af23a91f66f28bf9%26q%3D1%26e%3D50e404d5-8770-4cd3-bd41-476381ce5ab8%26u%3Dhttps%253A%252F%252Fwww.ri.se%252F&data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720942944%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Zqn8Rl0IDx8BQ%2BgAeZ9t8%2BQYkSVkdg3qqtnWWo7kla8%3D&reserved=0>
>
> [email-masked]
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cd4ee5984b023490a0e4a08d89b8fead7%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637430389720972812%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=rr8CAJby1Nbe7VD2Hyl%2FxhrfQ8wU4SwB21y%2B06NdP2U%3D&amp;reserved=0

-- 
Marco Tiloca
Ph.D., Senior Researcher

https://www.ri.se