Hi Göran,Thanks a lot for your review! Please, see my comments inline marked as "==>MT".
Best, /Marco On 2021-08-24 18:52, Göran Selander wrote:
Hi, Here is a review of ace-key-groupcomm-13. General === This draft provides a link between the ACE-OAuth authorization framework (including its transport profiles) and specifications of communication security in groups of constrained devices, e.g. the coap-groupcomm work currently developed in CORE. The document is intended to support different group communication schemes, but the details of those are defined in separate “application profiles” such as draft-ietf-ace-key-groupcomm-oscore (for Group OSCORE) and draft-ietf-ace-pubsub-profile (for pub/sub). This draft instead defines a common interface to a KDC acting as RS in the ACE-OAuth architecture, how to use this interface to perform various key management operations, and requirements for such application profiles. As such, this draft is thus an “intermediary” specification, and its usefulness will be determined by the application profiles which I've glanced at but are not part of this review. While this approach seems reasonable from a structure point of view, I have a question about abstracting the underlying communication in comment 1 below. The content of the draft is quite elaborate and with detailed examples which is good but also leads to my comment number 2. Now for the main comments: 1. How does this scale to large groups? Depending on application it may not be necessary to update keys during join of new members, and depending on the dynamics of the members rekeying may not be a major issue. But if it is a large group and all group members need to be updated at joining or leaving then this may require a lot of communication for which the underlying group communication may be helpful. For example, in case of a new member joining then a new group key or the new node's public key may be distributed using broadcast/multicast and protected with some existing group key.
==>MTDefinitely the new group key material to use before completing the joining of the new member.
As to the public key of the new group member (if there is one at all, depending on the member's roles), it's actually good to admit its provisioning _together_ with the group key material. It would spare other group members to perform dedicated retrieval traffic with the KDC just for that later on. This can be added to the last paragraph of Section 4.3.
As to using "some existing group key", yes, this requires a separate set of administrative key material, possibly organized into a hierarchy whose root is the administrative group key (see also later comments). That's the key material used to protect rekeying messages at the application layer, and in principle unrelated to the secure communication protocol used in the group.
<==
In case of rekeying a group key after a node has been evicted, a similar method could be used if it was possible to apply some key hierarchy scheme like e.g. LKH, i.e. distributing new keys corresponding to a path from the evicted node to the root in a key hierarchy.
==>MTYes. This is explicitly mentioned in Section 4.4, in the second bullet point after Figure 15.
As above, this requires a separate set of administrative key material, possibly organized into a hierarchy whose root is the administrative group key (see also later comments). Also as above, that's the key material used to protect rekeying messages at the application layer, and in principle unrelated to the secure communication protocol used in the group.
<==
Two sub-questions: a. Is it possible to extend the interface to make use of the underlying group communication?
==>MT It should already be able to accommodate it. In particular:* In Section 4.4, the second bullet point after Figure 15 already mentions this possibility. An application profile or a separate specification that builds on and extends it would have to define the exact rekeying scheme to use and its message formats.
* At the end of Section 4.1.2.1, it is defined that the Joining Response can include an optional parameter 'mgt_key_material'. In case of rekeying schemes more advanced than a basic point-to-point approach using pairwise security associations, this parameter provides a group member with the administrative key material _it_ needs to have to participate in a group rekeying.
For example, if a hierarchy-based scheme is used, the parameter specifies the administrative keys in the key tree from the leaf node associated to the group member all the way up along the path from that leaf node to the root (which is the administrative group key shared by all the group members).
* In Section 4.4, the third bullet point after Figure 15 refers to a local "control" resource at a group member, where the KDC can send requests such as rekeying messages. The group member can provide the KDC with the URI of such a local resource when joining the group, in the 'control_uri' parameter of the Joining Request.
This is more generally intended as a resource where the KDC can reach the group member with a request, and is potentially usable for several administrative operations, including a group rekeying. In the previous, second bullet point, it can be explicitly mentioned that this resource can also be the target of a group rekeying request sent over multicast.
Note that 'control_uri' may indicate an administrative "root path", that the group member determines as relevant for that security group. I would imagine requests for different administrative tasks to target different sub-resources identified by well-known path segments under that path.
There are still two missing things, though.* A group member would need to know the multicast address where the KDC sends group rekeying messages. This might also be provided as an additional parameter in the Joining Response.
Several versions ago, we proposed to include this in draft, but the idea was dismissed to keep things simple. Should we revisit this and add an optional parameter of this kind in the Joining Response?
Note that this goes hand-in-hand with _requiring_ a joining node to provide also the URI of a local control resource, in the 'control_uri' parameter of the Joining Request. Hence, it becomes (even more) important for the joining node to know as much as possible about how the group works (e.g. by means of early discovery), before attempting to join it by sending the Joining Request.
* When joining the group, a node also needs to know the exactly used group rekeying scheme. The easiest way I see to signal it is defining one more integer-valued ACE Groupcomm Policy (see Figure 9 in Section 4.1.2.1) to be specified in the optional 'group_policies' parameter of the Joining Response.
Its value would indicate the exact rekeying scheme (and we would need a new IANA registry). If the KDC does not say anything about that, the joining node assumes that a group rekeying is performed point-to-point, thus relying on the pairwise communication channel it has with the KDC.
<==
b. Is it possible to apply this interface with a key hierarchy scheme?
==>MTYes, it is totally up to the application profile and what it defines. The answer above should already give more practical details on what we have and what seems to be still missing.
<==
These features are not necessarily in scope of this draft, but it would be good to understand if a specification of these features would be able to use the interface defined here, or if some generalization is required in which case that change may be considered already now.
==>MTAgree. The draft key-groupcomm-oscore is defining in detail a simple, point-to-point approach. Based on a comment above, it can be extended so that, in case of rekeying upon joining of a new member, the rekeying messages include also the public key and Sender ID of the new node (if this is not a Monitor).
More generally, a multicast-based approach (e.g. relying on key hierarchy) should be totally possible to separately define and use, once some general aspects mentioned in the comments above are finalized here in key-groupcomm to be inheritable in an application profile.
<==
2. How would a "minimal" profile look like? The target setting for ACE in general and this draft in particular is constrained devices and networks. Some parts of the draft give example of thinking about lightweight aspects, but other parts are not at all minimalistic and includes a large number of features, however in many cases optional. It would be interesting to have a “minimal” example, where care has been taken in trying to define a group setting such that the resulting messages are as few and as small as possible (for a certain security level). The same comment applies to code size and state machine: There are a number of options and “nice to have” features, which if all implemented could have a measurable impact on the footprint. The use of the word "minimal" is not intended in an absolute sense but to target as little as possible and still provide authorized group key functionality. Perhaps such an exercise makes more sense in an application profile, such as draft-ace-key-groupcomm-oscore. But this draft may be provide a partial answer by indicating what handlers to include (sec. 4), what groupcomm parameters (sec. 7), what error ids (sec 8), etc.
==>MT I try to reply separately on each of the affected aspects mentioned above.* The handlers as such (Section 4) run at the KDC, which is not intended to be constrained. So, we defined the KDC as expected to offer the full interface specified in Section 4.1. I can imagine an application profile that really does not need a particular subset of handlers to declare them as not to be implemented, possibly under certain conditions.
Thinking of a group member, I can imagine as important to have minimally implemented the logic for:
FETCH on ace-group/- To retrieve the group name and joining URI from the specified group identifier.
POST/GET on ace-group/GROUPNAME/- To join the group (POST) and retrieve the current group key material as group member (GET).
GET/FETCH on ace-group/GROUPNAME/pub-key- To retrieve the public keys of all the other group members (GET) or only of some by filtering (FETCH). Admittedly, the latter might be sacrificed, but it allows to reduce the number of transferred public keys a lot.
GET on ace-group/GROUPNAME/num - To retrieve only the current version of the group key material. DELETE on ace-group/GROUPNAME/nodes/NODENAME - To leave the group.Instead, the following logic might be omitted in the implementation of a minimal group member:
GET on ace-group/GROUPNAME/active - To check the status of the group GET on ace-group/GROUPNAME/policies- To retrieve the group policies. Thus, they would be obtainable only when joining the group with a POST on ace-group/GROUPNAME/ (see above).
GET/PUT on ace-group/GROUPNAME/nodes/NODENAME- GET is for obtaining the current group key material plus the "individual node key material" (e.g., the Sender ID in the Group OSCORE case). The former can be obtained with a GET on ace-group/GROUPNAME/ (see above). The latter would not be possible to re-obtain as group member, thus expecting the group member to just remember that information, whose possible change happens in a synchronized way with the KDC anyway (see right below). - PUT is requesting new "individual node key material" (which can result in the KDC providing new one, or rekeying the group, or both things together). This can also be sacrificed, so that a group member needing a new individual node key material would re-join the group with a POST on ace-group/GROUPNAME/ (see above).
POST on ace-group/GROUPNAME/nodes/NODENAME/pub-key- To upload a new public key of its own. This can be sacrificed, assuming that a group member does not change its public key during its membership.
* About the Error IDs (Section 8), error responses will be sent anyway in case of errors at the KDC.
The group members can of course not understand those error IDs. Also, based on the third from last paragraph in Section 4.0, the accompanying textual 'error_description' is already optional.
Maybe it can help to:- Remove the parameter 'error_description' altogether; or, even more aggressively,
- Make it just optional for the KDC to use these extended error responses with content format application/ace-groupcomm+cbor and payload the CBOR map with 'error' and 'error_description'.
Thoughts?* About the ACE Groupcomm Parameters summarized in Section 7), most of them are required or practically required. Some of them can be conditionally not supported, e.g. by particular group members. Trying to have a first classification below:
Must be supported:- 'scope', 'gkty', 'key', 'num' and 'exp', as related to the group in question and the retrieval of its key material.
- 'gid', 'gname' and 'guri', as required for FETCH to /ace-group .- 'pub_keys' and 'peer_identifiers', since public keys are sooner or later going to be retrieved, accompanied by the node identifiers of the corresponding nodes.
Practically must be supported:- 'get_pub'keys' is practically necessary, except for the inconvenient and undesirable behavior where: i) a group member does not ask for the other group members' public keys upon joining; and ii) later on, the group member only retrieves the public keys of all group members with a GET to ace-group/GROUPNAME/pub-key (i.e., never by using FETCH).
Conditionally not supported- 'client_cred', 'cnonce' and 'client_cred_verify' are not needed to be supported by a node if this does not have a public key of its own that it uses in the group. - 'kdcchallenge' is not needed to be supported by a node if this does not have a public key of its own that it uses in the group, or if it does not post the Token to /authz-info at the KDC. The PoP input share N_S of the KDC has thus to be determined differently and it's up to the profiles to define how (see REQ21). - 'pub_keys_repos' is not needed to be supported by a node if this does not have a public key of its own that it uses in the group, or if it does not store the public key in a repo to point to with this parameter. - 'group_policies' might be sent by the KDC anyway. It may not be supported by a node if it is already aware of all group policies. These may include a particular group rekeying scheme (see comment above). In other words, it may not be supported by a node that never joins a group without knowing its group policies in advance. - 'peer_roles' goes hand-in-hand with 'pub_keys' and 'peer_identifiers'. Generally, it should be fine that it is not needed to be supported by a node if this does not have to care of the exact role of the node associated to a retrieved public key. - 'control_uri', is already optional to include in the Joining Request. However, its support is preferable to enable even point-to-point group rekeying initiated by the KDC. On the other other hand, it would rather become necessary to support, if the group uses an advanced key management scheme. In such a case, a node willing to join such a group has to support this parameter, in order to indicate the URI of a local resource to the KDC. - 'mgt_key_material' would be sent by the KDC anyway, if the group uses an advanced key management schemes. In such a case, a node willing to join such a group has to support this parameter. In other words, it may not be supported by a node that never joins a group which uses an advanced group key management scheme.
May generally be not supported: - 'error' and 'error_description', see comment above. - 'ace_groupcomm_profile', as already defined optional in Section 4.1.2.1. Would this kind of reasoned classification help? <==
(This comment actually applies also to the transport profiles, which this draft does not need to take responsibility for.)
==>MTRight, to be kept in mind for the profiles too, considering the additional profile-specific parameter that they can add.
<==
More detailed comments=== I found the terminology “POST /token” vs. “Token Post”/“token POST”/“POST Token” for the different message exchanges, respectively, quite confusing. For a long time I thought the latter referred to the former. It is true that the access token is carried with the method POST in the second exchange, but I think that is irrelevant and would suggest to instead use some other consistent terminology. For example, use “POST /token” and “POST /authz-info” to refer to the exchanges, respectively. Alternatively, call the latter “Token provisioning” or something similar without reference to the actual method by which the token is provisioned. This applies in particular to: Figure 2 “Token Post” Figure 3 “POST Token” “3.3. Token Post” 3.3.1. “an OPTIONAL parameter of the Token Post response message “ 3.3.2 “Token Post response” etc.
==>MTRight, I can replace this occurrences of "Token Post" with "Token Uploading".
The use of "POST /token" and "POST /authz-info" is limited to Figures 2 and 3, where it should be appropriate.
<==
4.1 Section 4.1 specifies the handlers, 20 pages. This is followed by how the handlers are used 4.2 - 4.10, roughly one page per subsection. When reading I ended up having two copies of the draft side by side looking at the handler and its corresponding use. I'm not sure this is a problem, but reading the handlers is more motivating after having read about how they are used. There is a summary in the bullet list in 4.0 but this is merely a forward reference and didn't make me do the mapping from handler to action in my head. Maybe just move content such that 4.2-4.10 comes before 4.1 (and then you can remove the bullet list in 4.0).
==>MTThe issue is that each example in Sections 4.2-4.10 also refers to the corresponding handler description, which defines also the payload format for that operation. In particular, all the ACE Groupcomm parameters are introduced in Section 4.1. An example shown before that risks to not say that much.
I think that a middle ground can be the following, and it should also be aligned with and address similar comments that Cigdem gave in her review [1].
1) Merging the points from the bullet list of Section 4.0 into the corresponding resource description of Section 4.1, while still preserving the forward pointers. This can make it easier to map between actions from a client point of view with resources at the KDC, even though no details have been introduced yet.
2) Separately moving each current Section 4.2-4.10 right after the corresponding handler section, now numbered 4.1.x.y. After that, a better structuring can also be achieved, so that:
- Section 4.1 is renamed "Overview of the Interface at the KDC".- The following sections lose one numbering level, e.g. current 4.1.1 "ace-group" becomes 4.2 "ace-group". - Each Section 4.x can be about a KDC resource. This in turn includes 4.x.y with a handler description for resource x, followed by 4.x.y.z with the example for handler y or resource x (taken from current Sections 4.2-4.10).
That is: 4. Keying Material Provisioning and Group Membership Management 4.1 Overview of the Interface at the KDC 4.2 ace-group 4.2.1 FETCH handler 4.2.1.1 Example <Content from current Section 4.2> 4.3 ace-group/GROUPNAME 4.3.1 POST handler 4.3.1.1 Example <Content from current Section 4.3> 4.3.2 GET handler 4.3.1.1 Example <currently missing> ... How does it sound? [1] https://mailarchive.ietf.org/arch/msg/ace/gv_uRo2Y45jqOLJghVSbAARWky0/ <==
"It is REQUIRED of the application profiles of this specification to
define what operations (e.g., CoAP methods) are allowed on each
resource"
It speaks of operations on each resource, but it does not say which resources
are mandatory to implement. Where is that written?
==>MTBuilding on a comment above, the KDC is supposed to implement all these resources (and possibly add more if needed and defined by a specific application profile).
As discussed above, a minimal group member may however not need to implement the logic to use some of those resources.
This requirement was more intended to require application profiles to produce something like Figure 2 of ace-key-groupcomm-oscore , see its Section 5.5 "Admitted Methods".
<==
9. The security consideration speaks about different key update strategies. I was looking for considerations when to not rekey in case of new member joining a group. I would imagine in e.g. a building automation setting where a new actuator device is added into a group it may not always be necessary to renew the group key of existing actuators. This is in particular assuming by the nature of security for actuations there are already means in place to determine freshness etc. preventing misuse of an old group key.
==>MTWe can add something along these lines, especially on when it might be acceptable to not ensure backward security (or anyway not rigorously upon every single new joining). Ultimately, it is up to the specific application to decide and define policies for the KDC to enforce.
Besides the freshness aspects you mention, this is more about accepting that the newly joined node would have access to communications in the group prior its joining, if it has recorded such exchanged messages.
<==
Nits === 3.1 s/Toid/“Toid” s/Tperm/“Tperm”
==>MT OK <==
3.2 If this parameter is not present, the granted scope is equal to the one requested in Section 3.1}. - remove the “}”
==>MT OK <==
3.3. Token Post
- - -
“The CBOR map MAY additionally include the following
parameter, which, if included, MUST have the corresponding values:
* 'sign_info' defined in Section 3.3.1, encoding the CBOR simple
value Null to require information about the signature algorithm,
signature algorithm parameters, signature key parameters and on
the exact encoding of public keys used in the group.”
This seems to unnecessary duplicate information coming just after:
“3.3.1. 'sign_info' Parameter
The 'sign_info' parameter is an OPTIONAL parameter of the Token Post
response message defined in Section 5.10.1. of
[I-D.ietf-ace-oauth-authz]. This parameter contains information and
parameters about the signature algorithm and the public keys to be
used between the Client and the RS. Its exact content is application
specific.
- - -
When used in the request, the 'sign_info' encodes the CBOR simple
value Null, to require information and parameters on the signature
algorithm and on the public keys used.
The CDDL notation [RFC8610] of the 'sign_info' parameter formatted as
in the request is given below.
sign_info_req = nil”
==>MTOk, we can remove the redundancy and also be more explicit, pointing to the exact format 'sign_info_req' or 'sign_info_resp' used in the message in question.
<==
3.3.1 I got the impression from the text above that ‘sign_info’ is the name of the parameter, but it turns out that the actual parameter is either called “sign_info_req” or “sign_info_res”. So, when it is stated that ‘sign_info’ encoding the CBOR simple value Null, which seems like a straightforward assignment, there is actually no ‘sign_info’ parameter. This is a minor, still slightly confusing.
==>MTYes, there is only one actual parameter, 'sign_info', and we want a single CBOR abbreviation registered for it to use in the payload map.
Using the different _req and _resp versions in Section 3.3.1 is just a way to make a hard distinction between the request and response case. It might help to improve the CDDL definition, i.e.:
sign_info = sign_info_req / sign_info_resp sign_info_req = nil ; used in a request sign_info_resp = [ + sign_info_entry ] ; used in a response ... <==
3.3.1
"This format is consistent with every signature algorithm currently
considered in [I-D.ietf-cose-rfc8152bis-algs], "
s/considered/defined
==>MT Ok <==
3.3.2
"(see the 'client_cred_verify' parameter in
Section 4)"
Refer instead to 4.1.2.1
==>MT Ok <==
4.1.3.1
“in case both the 'role_filter' array and the 'id_filter'
array are not empty”
s/not empty/non-empty
==>MT Ok <==
4.1.3.1
"Finally, as mentioned in Section 4.1.2.1, both arrays 'role_filter'
and 'id_filter' MUST NOT be both empty."
replace with
"Finally, as mentioned in Section 4.1.2.1, the arrays 'role_filter'
and 'id_filter' MUST NOT both be empty."
==>MT Ok <==
4.4 A missing comma at the end of the following line: "get_pub_keys": [true, ["sender"], []], "client_cred": PUB_KEY
==>MT Ok <==
Göran
On 2021-07-12, 18:16, "Ace on behalf of internet-dra...@ietf.org"
<ace-boun...@ietf.org on behalf of internet-dra...@ietf.org> 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 : Key Provisioning for Group Communication using
ACE
Authors : Francesca Palombini
Marco Tiloca
Filename : draft-ietf-ace-key-groupcomm-13.txt
Pages : 78
Date : 2021-07-12
Abstract:
This document defines message formats and procedures for requesting
and distributing group keying material using the ACE framework, to
protect communications between group members.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3D08daa3fb-57419b19-08dae360-86073b36ea28-572fafc3ef6c5ed5%26q%3D1%26e%3Dfd87b927-3fdc-4d5a-ab71-6248ac68bf5d%26u%3Dhttps%253A%252F%252Fgithub.com%252Face-wg%252Face-key-groupcomm&data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jG%2Fl8n4csOXfzoKTQSg9ajkCz21q7wjqAjt2GSFECyY%3D&reserved=0.
The IETF datatracker status page for this draft is:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-key-groupcomm%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lDO4CzJ0LM%2F7hB3C8giMlJdNAUGkrJjqygkUCsZZUVM%3D&reserved=0
There is also an htmlized version available at:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-key-groupcomm-13&data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X%2FkLzQBW4i9tol6MvK304fGENoTlZgRT7skgeg4KH%2FM%3D&reserved=0
A diff from the previous version is available at:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-key-groupcomm-13&data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Szj2SV16cyAp2YJYN149C22YRR1oaSBb%2Bvk1NYFidRU%3D&reserved=0
Internet-Drafts are also available by anonymous FTP at:
https://eur02.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Cg%2FMHmh0M9fwDouhpjAM%2FjKyXdk4nshAazRn5llh84M%3D&reserved=0
_______________________________________________
Ace mailing list
Ace@ietf.org
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9G1CcMTA4z1i9WfLsgmfbz4fuqeu0J958I9QwrCZj6k%3D&reserved=0
_______________________________________________
Ace mailing list
Ace@ietf.org
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&data=04%7C01%7Cmarco.tiloca%40ri.se%7C7cabd8ed745844c4d98f08d9671f9b5c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637654207716474531%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9G1CcMTA4z1i9WfLsgmfbz4fuqeu0J958I9QwrCZj6k%3D&reserved=0
-- Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistagången 16 SE-164 40 Kista (Sweden)
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
