Re: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-key-groupcomm-17: (with COMMENT)
Hi Marco! Thanks for the PR and the explanations below. It addresses my feedback. Thanks, Roman From: Marco Tiloca Sent: Friday, December 15, 2023 12:04 PM To: Roman Danyliw ; The IESG Cc: draft-ietf-ace-key-groupc...@ietf.org; ace-cha...@ietf.org; ace@ietf.org; mglt.i...@gmail.com; Francesca Palombini Subject: Re: Roman Danyliw's No Objection on draft-ietf-ace-key-groupcomm-17: (with COMMENT) Hello Roman, Thanks a lot for your review! Please find in line below our detailed replies to your comments. A Github PR where we have addressed your comments is available at [PR]. Unless any concern is raised, we plan to soon merge this PR (and the other ones related to other received reviews), and to submit the result as version -18 of the document. Thanks, /Marco [PR] https://github.com/ace-wg/ace-key-groupcomm/pull/161 On 2023-11-18 00:46, Roman Danyliw via Datatracker wrote: Roman Danyliw has entered the following ballot position for draft-ietf-ace-key-groupcomm-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F=05%7C01%7Cmarco.tiloca%40ri.se%7C5ff64a69992349e291ac08dbe7c7686f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638358615879941733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=C5pPlP9PcO9Y4%2F5EQfWSIH8%2BhSOcDCamoEL8vrSaHIE%3D=0<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-key-groupcomm%2F=05%7C01%7Cmarco.tiloca%40ri.se%7C5ff64a69992349e291ac08dbe7c7686f%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C638358615879941733%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=nFjixy8p0Ljocl6G2VzbisJF%2FULDZ1y%2BcjABa3MAXQM%3D=0<https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/> -- COMMENT: -- ** Section 1.1. Per the definition of “Group name” and GROUPNAME. The latter is defined as a “text string used in a URIs”. The former has no definition beyond saying it is an identifier. Is it not a text string? ==>MT Right, we have revised the definition of both group name and node name as below. NEW > Group name: the identifier of a group, as a text string. Once established, it > is invariant. NEW > Node name: the identifier of a node, as a text string. Once established, it > is invariant. <== ** Section 1.1. * Individual keying material: information exclusively pertaining to a group member, as associated with its group membership and related to other keying material and parameters used in the group. For example, this can be a member identifier that is unique within the group. -- unlike group and node identifier, member identifier is not defined -- how is a member identifier an example of “keying material”? Is it an identifier for a key? ==>MT We have clarified by expanding one sentence as follows. OLD > For example, this can be a member identifier that is unique within the group. NEW > For example, this can be an identifier that the secure communication protocol > employs to uniquely identify a node as a group member (e.g., a cryptographic > key identifier uniquely associated with the group member in question). <== ** Section 2. Per the comment “Defined in the ACE framework” in Figure 2, which framework is this text referencing? This document? RFC9200? ==>MT Yes, we have added a reference to RFC 9200. <== ** Section 3.1. Editorial * 'scope', specifying the name of the groups that the Client requests to access, Should this be “name_s_ of the groups ...”? Otherwise, it reads as if there is a single name for a collection of groups. ==>MT Yes, now fixed. <== ** Section 3.1 * 'audience', with an identifier of the KDC. The definition of audience from Section 5.8.1 of RFC9200 points to RFC8693 (OAuth’s definition of audience). It says: ==[ snip ]== The logical name of the target service where the client intends to use the requested security token. This serves a purpose similar to the resource parameter but with the client providing a logical name for the target service. Interpretation of the name requires that the value be something that both t
[Ace] Roman Danyliw's No Objection on draft-ietf-ace-key-groupcomm-17: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-ace-key-groupcomm-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ -- COMMENT: -- ** Section 1.1. Per the definition of “Group name” and GROUPNAME. The latter is defined as a “text string used in a URIs”. The former has no definition beyond saying it is an identifier. Is it not a text string? ** Section 1.1. * Individual keying material: information exclusively pertaining to a group member, as associated with its group membership and related to other keying material and parameters used in the group. For example, this can be a member identifier that is unique within the group. -- unlike group and node identifier, member identifier is not defined -- how is a member identifier an example of “keying material”? Is it an identifier for a key? ** Section 2. Per the comment “Defined in the ACE framework” in Figure 2, which framework is this text referencing? This document? RFC9200? ** Section 3.1. Editorial * 'scope', specifying the name of the groups that the Client requests to access, Should this be “name_s_ of the groups ...”? Otherwise, it reads as if there is a single name for a collection of groups. ** Section 3.1 * 'audience', with an identifier of the KDC. The definition of audience from Section 5.8.1 of RFC9200 points to RFC8693 (OAuth’s definition of audience). It says: ==[ snip ]== The logical name of the target service where the client intends to use the requested security token. This serves a purpose similar to the resource parameter but with the client providing a logical name for the target service. Interpretation of the name requires that the value be something that both the client and the authorization server understand. ==[ snip ]== Does the application profile have to specify the semantics of this audience value (just like the scope parameter)? ** Section 5. 2. The node has been found compromised or is suspected so. What triggers this behavior in #2? How does the KDC know about compromise? Can Clients tell it that? Can a Client evict another Client? ** Section 6.2.1. Reading this text as normative guidance seemed odd since the parent section 6.2 stated that the specifics of one-to-many is effectively out of scope and this document only provides high level guidance. ** Section 10. Security considerations are inherited from the ACE framework [RFC9200], and from the specific transport profile of ACE used between the Clients and the KDC, e.g., [RFC9202] and [RFC9203]. And from application profiles too which specify the details of the keys and tokens? ** Section 10 Unless otherwise defined by an application profile of this specification, the KDC SHOULD renew the group keying material upon a group membership change. ... Instead, the KDC might rekey the group after a minimum number of group members have joined or left within a given time interval, or after a maximum amount of time since the last group rekeying was completed, or yet during predictable network inactivity periods. The first sentence seems to be encouraging rekeying but subsequent text points out that this might not be reasonable. Should the initial “SHOULD” text be harmonized with this other more nuanced guidance? ** Typos -- Section 1. Typo. s/recommeded/recommended/ -- Section 2. Typo. s/membrs/members/ -- Section 3.1. Typo. s/ specificaton/specification/ -- Section 3.3.1. Typo. s/acces/access/ -- Section 4. Typo. s/trasferring/transferring/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Roman Danyliw's No Objection on draft-ietf-ace-cmpv2-coap-transport-09: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-ace-cmpv2-coap-transport-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-cmpv2-coap-transport/ -- COMMENT: -- Thank you to Valery Smyslov for the SECDIR review. ** RFC6712 chose to formally “update” RFC4210. Would such symmetry be appropriate in this document for RFC4210 and [I-D.ietf-lamps-cmp-updates]? ** Idnits returned the following actionable feedback: == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unused Reference: 'RFC5280' is defined on line 432, but no explicit reference was found in the text ** Section 1. This document specifies the use of CoAP over UDP as a transport medium for the CMP version 2 [RFC4210] , CMP version 3 [I-D.ietf-lamps-cmp-updates] designated as CMP in this document and Lightweight CMP Profile [I-D.ietf-lamps-lightweight-cmp-profile] . -- Editorial. There are extra spaces between the reference and punctuation. -- What does it mean for “CMP version 3” to be “designated as CMP in this document”? Are all statements which use “CMP” only referring to a particular version of CMP, specifically, [I-D.ietf-lamps-cmp-updates]? ** Section 4. Since the Proxy may have access to the CMP-Level metadata and control over the flow of CMP messages therefore proper role based access control should be in place. What is “CMP-Level metadata”? ** Section 4. -- RFC6712 provides the following caution to motivate the use of TLS: CMP provides inbuilt integrity protection and authentication. The information communicated unencrypted in CMP messages does not contain sensitive information endangering the security of the PKI when intercepted. However, it might be possible for an eavesdropper to utilize the available information to gather confidential technical or business critical information. Should this text be added to the following text bullet: The CMP protocol does not provide confidentiality of the CMP payloads. If confidentiality is desired, CoAP over DTLS [RFC9147] MAY be used to provide confidentiality for the CMP payloads, although it cannot conceal that the CMP protocol is used within the DTLS layer. -- RFC6712 also provides the following caution about unprotected HTTP Announcement messages: 4. If no measures to authenticate and protect the HTTP responses to pushed Announcement messages are in place, their information regarding the Announcement's processing state may not be trusted. In that case, the overall design of the PKI system must not depend on the Announcements being reliably received and processed by their destination. Section 3.7 seems to allow for these over CoAP. Should similar guidance be provided? ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] AD review of draft-ietf-ace-extend-dtls-authorize-04
Hi! Paul and I are load balancing, so I'll be the responsible AD for draft-ietf-ace-extend-dtls-authorize-04 moving forward. I performed an AD review on the document and my feedback is as follows: ** Document Meta-data. s/Updates: draft-ietf-ace-dtls-authorize /Updates: RFC9202/ ** Abstract. The abstract text needs to name the RFC that it is updating per the metadata. OLD This document updates the CoAP-DTLS profile for ACE by specifying that the profile applies to TLS as well as DTLS. NEW This document updates the CoAP-DTLS profile for ACE described in RFC9202 by specifying that the profile applies to TLS as well as DTLS. ** Section 1. Editorial clarity OLD This feature is supported by the OSCORE profile [RFC9203] but is lacking in the DTLS profile. NEW This dual support for TLS and DTLS is already supported by the OSCORE profile [RFC9203]. ** Section 1 The same access rights are valid in case transport layer security is provided by either DTLS or TLS, and the same access token can be used. Could this language please be refined so it is clearer on who the target is? Is guidance to the RS (that given a token, it should read anything into whether it was presented over DTLS or TLS)? ** Section 3. the Client MAY try to connect to the Resource Server via TLS, or try TLS and DTLS in parallel to accelerate the session setup. What happens if the RS responds to a connection on both protocols? ** Section 3. This error SHOULD be handled by the Client in the same way as unsupported ACE profiles. Can this be explained a bit more. The client has a token with "coap_dtls" but the connection failed. How would it distinguish between the peer being misconfigured (and not responding) vs. not supporting this protocol? What is the alternative way to handle it (given that this is SHOULD as opposed to a MUST)? ** Section 3. If the Client is modified accordingly or it learns that the Resource Server has been, the Client may try to connect to the Resource Server using the transport layer security mechanism that was previously not mutually supported. Does this imply some kind of state is kept? If so, how is that managed? ** Section 3. If this message exchange succeeds, the Client SHOULD first use the same underlying transport protocol for the establishment of the security association as well Is this the same things as roughly saying that the Client SHOULD connect to the AS for the token request over the same protocol it successfully contacted the RS? Recommend explicitly mentioning the AS here. ** Section 3. Clients that support either DTLS or TLS but not both SHOULD use the transport protocol underlying the supported transport layer security mechanism also for an initial unauthorized resource request. I'm not following something here. If the Client only supports one of the protocols, what's the optionality suggested by the SHOULD in using it. Either it tries to uses the single protocol it supports, or no connection can be made. ** Section 4. Please Use the exact registry field names: OLD The following updates have been done for the "ACE Profiles" registry for the profile with Profile ID 1 and Profile name coap_dtls: NEW The following updates have been done to the "ACE Profiles" registry for the profile with a "CBOR Value" field value of 1 and "Name" of "coap_dtls": ** Section 4. Is the WG sure it doesn't want two references, [RFC9202] and this [RFC-] ** Section 5. Should draft-ietf-uta-rfc7525bis apply here instead of RFC7525? ** Section 5. Don't the security considerations of RFC9202 also still apply here? Regards, Roman ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Roman Danyliw's No Objection on draft-ietf-ace-mqtt-tls-profile-15: (with COMMENT)
Hi Cigdem! Thanks for the quick response. The clarifications and proposed edits listed below address my feedback. Roman From: Cigdem Sengul Sent: Thursday, March 10, 2022 7:33 AM To: Roman Danyliw Cc: The IESG ; draft-ietf-ace-mqtt-tls-prof...@ietf.org; ace-cha...@ietf.org; Ace Wg ; Daniel Migault Subject: Re: Roman Danyliw's No Objection on draft-ietf-ace-mqtt-tls-profile-15: (with COMMENT) Dear Roman, Thank you for your comments. I tried to respond to them inline below. (I have made fixes here: https://github.com/ace-wg/mqtt-tls-profile/pull/104) On Tue, 8 Mar 2022 at 23:02, Roman Danyliw via Datatracker mailto:nore...@ietf.org>> wrote: Roman Danyliw has entered the following ballot position for draft-ietf-ace-mqtt-tls-profile-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ -- COMMENT: -- ** Section 2. If the Client is resource-constrained or does not support HTTPS, a separate Client Authorization Server may carry out the token request on behalf of the Client, and later, onboard the Client with the token. Appreciating that the CAS is out of scope, I’m trying to understand which of the (A) – (F) interactions are handled by the Client and which would be handled by the CAS. Figure 1 is a ambiguous. (A) and (B) seem like they would be covered by the CAS, but I’m assuming (C) and (D) are the Client after being provisioned with the access token (from A and B). Is that correct? If so, it would be helpful to clarify that in the text and/or diagram. [That is correct. CAS was expected to be helpful for clients that are not able to do the HTTPS. We have a CAS definiton in 1.2 - Client Authorization Server (CAS) An entity that prepares and endorses authentication and authorization data for a Client, and communicates using HTTPS to the AS. In the figure, we tried to capture the two separately: (1) Client Authorization interface, and (2) MQTT Pub/Sub Interface. Client may be able to do both (1) and (2), or rely on CAS for (1), and is expected to be provisioned with a otken for Pub/Sub Interface if aiming to publish/subscribe to proteced topics. We had the following text in the document: " If the Client is resource-constrained or does not support HTTPS, a separate Client Authorization Server may carry out the token request on behalf of the Client, and later, onboard the Client with the token. " Is revising it so that we point to the figure sufficient clarification? " If the Client is resource-constrained or does not support HTTPS, a separate Client Authorization Server may carry out the token request on behalf of the Client (Figure 1 (A) and (B)), and later, onboard the Client with the token. ] ** Section 3.3. As a response to the SUBSCRIBE packet, the Broker issues a SUBACK. For each Topic Filter, the SUBACK packet includes a return code matching the QoS level for the corresponding Topic Filter. In the case of failure, the return code is 0x87, indicating that the Client is 'Not authorized'. A reason code is returned for each Topic Filter. This may be a detail of MQTT. Does the explicit use of “not authorized” vs. “not authorized/not found” leak the existence of a topic name to an off-path attacker? It seems that with “not authorized” semantics, one could try to guess topic name with enumeration, say, try 1: “/topic/is-the-sensitive-project-called-A”, try 2: “/topic/is-the-sensitive-project-called-B”, etc. [CS : I see your point. MQTT has also the following error code: 0x80 Unspecified error The subscription is not accepted and the Server either does not wish to reveal the reason or none of the other Reason Codes apply. We can add: "The Broker MAY return 0x80 Unspecified error if they do not want to leak the topic names to unauthorised clients." Would that be OK? ] Editorial Nits ** Section 1. Editorial. s/The Client-AS and RS-AS/The Client-AS and RS-AS communication/ [CS: This was changed to "The client-AS and RS-AS exchanges" based on artart review.] ** Section 1.3. Editorial. Chose either the “65535” or “65,535” convention (comma or no comma). “UTF-8 string” uses the former and “binary data” uses the latter [CS: Fixed to 65535] ** Section 1.2. Editorial. SUBACK. Describe the who is the sender and receiver like in the other message types. OLD
[Ace] Roman Danyliw's No Objection on draft-ietf-ace-aif-06: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-ace-aif-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-aif/ -- COMMENT: -- ** Section 5.2. The registration policy is Specification required [RFC8126]. The designated expert will engage with the submitter to ascertain the requirements of this document are addressed. To help the DE, is there a way to be clearer on what requirements need to be satisfied? Is it the bulleted list in the SecCons? Section 4? ** Section 6. I was under the impression that AIF didn’t have an explicit requirement to use CoAP. For example, draft-ietf-ace-mqtt-tls-profile appears to use the information model but isn’t restricted to CoAP. Therefore, is it more accurate to say: OLD The security considerations of [RFC7252] apply NEW When AIF is used with CoAP, the security considerations of [RFC7252] apply. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Roman Danyliw's No Objection on draft-ietf-ace-mqtt-tls-profile-15: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-ace-mqtt-tls-profile-15: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ -- COMMENT: -- ** Section 2. If the Client is resource-constrained or does not support HTTPS, a separate Client Authorization Server may carry out the token request on behalf of the Client, and later, onboard the Client with the token. Appreciating that the CAS is out of scope, I’m trying to understand which of the (A) – (F) interactions are handled by the Client and which would be handled by the CAS. Figure 1 is a ambiguous. (A) and (B) seem like they would be covered by the CAS, but I’m assuming (C) and (D) are the Client after being provisioned with the access token (from A and B). Is that correct? If so, it would be helpful to clarify that in the text and/or diagram. ** Section 3.3. As a response to the SUBSCRIBE packet, the Broker issues a SUBACK. For each Topic Filter, the SUBACK packet includes a return code matching the QoS level for the corresponding Topic Filter. In the case of failure, the return code is 0x87, indicating that the Client is 'Not authorized'. A reason code is returned for each Topic Filter. This may be a detail of MQTT. Does the explicit use of “not authorized” vs. “not authorized/not found” leak the existence of a topic name to an off-path attacker? It seems that with “not authorized” semantics, one could try to guess topic name with enumeration, say, try 1: “/topic/is-the-sensitive-project-called-A”, try 2: “/topic/is-the-sensitive-project-called-B”, etc. Editorial Nits ** Section 1. Editorial. s/The Client-AS and RS-AS/The Client-AS and RS-AS communication/ ** Section 1.3. Editorial. Chose either the “65535” or “65,535” convention (comma or no comma). “UTF-8 string” uses the former and “binary data” uses the latter ** Section 1.2. Editorial. SUBACK. Describe the who is the sender and receiver like in the other message types. OLD Subscribe acknowledgement. NEW Subscribe acknowledgement from the Broker to the Client. ** Section 2. Editorial. The token request and response use the token endpoint at the AS, specified for HTTP-based interactions in Section 5.8 of the ACE framework [I-D.ietf-ace-oauth-authz]. This reference should likely read Section 4 of [I-D.ietf-ace-oauth-authz] as this section included the bullet protocol flow from (A) – (E). ** Section 2.3. Should it be MQTT messages vs. MQTT packets? For example, in “… to allow a Client’s future PUBLISH and SUBSCRIBE packets”. ** Section 3.3. Editorial. s/token token/token scope which/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Roman Danyliw's Discuss on draft-ietf-ace-dtls-authorize-16: (with DISCUSS and COMMENT)
Hi Steffi! Thank you for the explanations below and edits made in -17 in response to my review. All of my feedback is addressed and I've cleared my ballot. Thanks, Roman > -Original Message- > From: iesg On Behalf Of Stefanie Gerdes > Sent: Tuesday, May 11, 2021 8:42 AM > To: Roman Danyliw ; The IESG > Cc: ace-cha...@ietf.org; draft-ietf-ace-dtls-author...@ietf.org; ace@ietf.org > Subject: Re: Roman Danyliw's Discuss on draft-ietf-ace-dtls-authorize-16: > (with > DISCUSS and COMMENT) > > Hi Roman, > > Thank you for your detailed comments. We addressed most of your comments > in the latest version. Please find my comments inline. > > On 3/23/21 4:32 AM, Roman Danyliw via Datatracker wrote: > > > > -- > > DISCUSS: > > -- > > > > (A simple editorial fix) Per Section 5.8.2 of > > [I-D.ietf-ace-oauth-authz], the name of the parameter in the C-to-AS > > communication is “ace_profile” (not “profile”). The “ace_profile” parameter > is mistakenly referenced as “profile” > > in the following places: > > > > -- Section 3.2.1: > >The response MAY contain a "profile" parameter with the value > >"coap_dtls" to indicate that this profile MUST be used for > >communication between the client and the resource server. > > > > -- Section 3.3.1: > >If the > >profile parameter is present, it is set to "coap_dtls". > > Yes, you are correct. The name of the parameter changed in > ace-oauth-authz-25 and this occurrence must have slipped through. > > > > > > > -- > > COMMENT: > > -- > > > > Thank you to Russ Mundy for the SECDIR review, and thank you to the > > authors for responding to it. > > > > ** Does this profile only cover part of the oauth-authz framework? > > Section 3.3 explicitly says “the use of introspection is out of scope > > for this specification.” It might be helpful to note in the > > introduction that this profile only covers C-to-AS and C-to-RS > > communication. > > We added to the introduction that introspection is out of scope for this > specification. > > > > > ** Section 3.2.1 Figure 3, uses the “req_aud” parameter, but this was > > renamed to “audience” in -20 of draft-ietf-ace-oauth-authz > > Yes, fixed. > > > > > ** Section 3.2.1. Per ‘The response MAY contain a "profile" parameter > > with the value "coap_dtls" to indicate that this profile MUST be used > > for communication between the client and the resource server’, this is > > true (see the DISCUSS above though). However, it might be worthwhile > > to point out that per Section > > 5.8.2 of draft-ietf-ace-oauth-authz-38, this “MAY” is actually a MUST > > if the request has an empty “ace_profile” parameter. > > Okay, fixed. > > > > > ** Section 3.2.2. Per “This specification therefore mandates > > implementation support for curve25519 ...”, perhaps RFC2119 language > > should be used here > > Okay, changed to MUST. > > > > > ** Section 3.3.1. Per all of the text after “The method for how the > > resource server determines the symmetric key from an access token > > containing only a key identifier is application-specific; the > > remainder of this section provides one example”, consider removing all > > of the RFC2119 language is this text as its an example. > > The Gen-ART review from Paul Kyzivat of 19 Jul 2020 suggested to include the > normative language to avoid ending up with unclear specifications. > (The normative language has been added in > https://github.com/ace-wg/ace-dtls- > profile/commit/9ab383c0e08f8d4bff5335cbfadb1c6b48289472) > > > > > ** Section 3.3.2. Per “When the resource server receives an access > > token, it MUST check if the access token is still valid ...”, a > > reference to Section > > 5.10.1.1 of [I-D.ietf-ace-oauth-authz] for additional verification > > procedures might be helpful > > Okay, done. > > > > > ** Section 3.2.2. and 7: > > > > (a) Section 3.2.2. > >To be consistent with [RFC7252] which allows for shortened MAC tags > >in constrained environments, an implementation that supports the RPK > >mode of this profile MUST at least support the ciphersuite > >TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251].
[Ace] Roman Danyliw's Discuss on draft-ietf-ace-dtls-authorize-16: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-ace-dtls-authorize-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize/ -- DISCUSS: -- (A simple editorial fix) Per Section 5.8.2 of [I-D.ietf-ace-oauth-authz], the name of the parameter in the C-to-AS communication is “ace_profile” (not “profile”). The “ace_profile” parameter is mistakenly referenced as “profile” in the following places: -- Section 3.2.1: The response MAY contain a "profile" parameter with the value "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server. -- Section 3.3.1: If the profile parameter is present, it is set to "coap_dtls". -- COMMENT: -- Thank you to Russ Mundy for the SECDIR review, and thank you to the authors for responding to it. ** Does this profile only cover part of the oauth-authz framework? Section 3.3 explicitly says “the use of introspection is out of scope for this specification.” It might be helpful to note in the introduction that this profile only covers C-to-AS and C-to-RS communication. ** Section 3.2.1 Figure 3, uses the “req_aud” parameter, but this was renamed to “audience” in -20 of draft-ietf-ace-oauth-authz ** Section 3.2.1. Per ‘The response MAY contain a "profile" parameter with the value "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server’, this is true (see the DISCUSS above though). However, it might be worthwhile to point out that per Section 5.8.2 of draft-ietf-ace-oauth-authz-38, this “MAY” is actually a MUST if the request has an empty “ace_profile” parameter. ** Section 3.2.2. Per “This specification therefore mandates implementation support for curve25519 ...”, perhaps RFC2119 language should be used here ** Section 3.3.1. Per all of the text after “The method for how the resource server determines the symmetric key from an access token containing only a key identifier is application-specific; the remainder of this section provides one example”, consider removing all of the RFC2119 language is this text as its an example. ** Section 3.3.2. Per “When the resource server receives an access token, it MUST check if the access token is still valid ...”, a reference to Section 5.10.1.1 of [I-D.ietf-ace-oauth-authz] for additional verification procedures might be helpful ** Section 3.2.2. and 7: (a) Section 3.2.2. To be consistent with [RFC7252] which allows for shortened MAC tags in constrained environments, an implementation that supports the RPK mode of this profile MUST at least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. (b) As this specification aims at constrained devices and uses CoAP [RFC7252] as transfer protocol, at least the ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655] should be supported The text in (b) is weaker on the mandatory required of the ciphersuite. In (b), likely s/should be supported/must be supported/. ** Section 7. Per “For longer-lived access tokens, DHE ciphersuites should be used”, perhaps add a parenthetical at the end of this sentence of “(i.e., ciphersuites of the form TLS_DHE_PSK_*)”. ** Section 7.1. Session resumption is noted to be NOT RECOMMENDED. Is there a reason this can’t be stronger (MUST NOT)? ** Section 7.2. No issues with the guidance here. Is there anything DTLS specific that suggests that developers "SHOULD" avoid multiple access tokens per client? That guidance isn’t in the core framework. I made the comment on the core framework that perhaps this text should be there (too?). ** Please reviews all of the reference numbers to [I-D.ietf-ace-oauth-authz] as a number of them seem to be incorrect (likely due to renumbering). For example: -- Section 2. Per “the client MUST upload the access token to the authz-info resource, i.e. the authz-info endpoint, on the resource server before starting the DTLS handshake, as described in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]”, Section 5.8.1 is not the right reference. It’s likely 5.10.1. -- Section 3.4. Per “The authorization server may, e.g., specify a "cti" claim for the access token (see Section 5.8.3 of [I-D.ietf-ace-oauth
[Ace] Roman Danyliw's Discuss on draft-ietf-ace-oscore-profile-17: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-ace-oscore-profile-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/ -- DISCUSS: -- (A simple editorial fix) Per Section 5.8.2 of [I-D.ietf-ace-oauth-authz], the name of the parameter in the C-to-AS communication is “ace_profile” (not “profile”). The “ace_profile” parameter is mistakenly referenced as “profile” in the following place: (a) Section 3.2. 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 -- COMMENT: -- Thank you to Kathleen Moriarty for the SECDIR review. ** In addition to the normative text noted in the DISCUSS, the examples in Figure 4 and Figure 7 also have the same typo (but that doesn’t rise to a DISCUSS) ** Section 7. Per “Developers should avoid using multiple access tokens for a same client”, is there a reason not to use a normative SHOULD here? The DTLS profile has nearly the identical words and uses a normative SHOULD? Likewise should “This profile recommends that the that RS maintains a single access token for each client” be “This profile RECOMMENDS”? ** Editorial nits Section 3.2. Typo. s/The applications needs/The application needs/ Section 3.2. Typo. s/parameeter/parameter/ Section 4. Typo. s/Note that the RS and client authenticates/Note that the RS and client authenticate/ Section 4.1. Typo. s/The client may also chose/The client may also choose/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Roman Danyliw's Discuss on draft-ietf-ace-dtls-authorize-16: (with DISCUSS and COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-ace-dtls-authorize-16: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize/ -- DISCUSS: -- (A simple editorial fix) Per Section 5.8.2 of [I-D.ietf-ace-oauth-authz], the name of the parameter in the C-to-AS communication is “ace_profile” (not “profile”). The “ace_profile” parameter is mistakenly referenced as “profile” in the following places: -- Section 3.2.1: The response MAY contain a "profile" parameter with the value "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server. -- Section 3.3.1: If the profile parameter is present, it is set to "coap_dtls". -- COMMENT: -- Thank you to Russ Mundy for the SECDIR review, and thank you to the authors for responding to it. ** What is the motivation for specifying this profile around DTLS 1.2 instead of 1.3?? ** Does this profile only cover part of the oauth-authz framework? Section 3.3 explicitly says “the use of introspection is out of scope for this specification.” It might be helpful to note in the introduction that this profile only covers C-to-AS and C-to-RS communication. ** Section 3.2.1 Figure 3, uses the “req_aud” parameter, but this was renamed to “audience” in -20 of draft-ietf-ace-oauth-authz ** Section 3.2.1. Per ‘The response MAY contain a "profile" parameter with the value "coap_dtls" to indicate that this profile MUST be used for communication between the client and the resource server’, this is true (see the DISCUSS above though). However, it might be worthwhile to point out that per Section 5.8.2 of draft-ietf-ace-oauth-authz-38, this “MAY” is actually a MUST if the request has an empty “ace_profile” parameter. ** Section 3.2.2. Per “This specification therefore mandates implementation support for curve25519 ...”, perhaps RFC2119 language should be used here ** Section 3.3.1. Per all of the text after “The method for how the resource server determines the symmetric key from an access token containing only a key identifier is application-specific; the remainder of this section provides one example”, consider removing all of the RFC2119 language is this text as its an example. ** Section 3.3.2. Per “When the resource server receives an access token, it MUST check if the access token is still valid ...”, a reference to Section 5.10.1.1 of [I-D.ietf-ace-oauth-authz] for additional verification procedures might be helpful ** Section 3.2.2. and 7: (a) Section 3.2.2. To be consistent with [RFC7252] which allows for shortened MAC tags in constrained environments, an implementation that supports the RPK mode of this profile MUST at least support the ciphersuite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 [RFC7251]. (b) As this specification aims at constrained devices and uses CoAP [RFC7252] as transfer protocol, at least the ciphersuite TLS_PSK_WITH_AES_128_CCM_8 [RFC6655] should be supported The text in (b) is weaker on the mandatory required of the ciphersuite. In (b), likely s/should be supported/must be supported/. ** Section 7. Per “For longer-lived access tokens, DHE ciphersuites should be used”, perhaps add a parenthetical at the end of this sentence of “(i.e., ciphersuites of the form TLS_DHE_PSK_*)”. ** Section 7.1. Session resumption is noted to be NOT RECOMMENDED. Is there a reason this can’t be stronger (MUST NOT)? ** Section 7.2. No issues with the guidance here. Is there anything DTLS specific that suggests that developers "SHOULD" avoid multiple access tokens per client? That guidance isn’t in the core framework. I made the comment on the core framework that perhaps this text should be there (too?). ** Please reviews all of the reference numbers to [I-D.ietf-ace-oauth-authz] as a number of them seem to be incorrect (likely due to renumbering). For example: -- Section 2. Per “the client MUST upload the access token to the authz-info resource, i.e. the authz-info endpoint, on the resource server before starting the DTLS handshake, as described in Section 5.8.1 of [I-D.ietf-ace-oauth-authz]”, Section 5.8.1 is not the right reference. It’s likely 5.10.1. -- Section 3.4. Per “The authorization server may, e.g., specify
[Ace] Roman Danyliw's Yes on draft-ietf-ace-oauth-authz-38: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-ace-oauth-authz-38: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ -- COMMENT: -- Thank you to Stephen Kent for the SECDIR review, and thank you to the authors for responding to it. ** Section 5.3. Per “The RS sending this response (i.e., RS) uses an internal clock that is only loosely synchronized with the clock of the AS”, a more precise phrase that “loosely synchronized” would be helpful. ** Section 6.2. It would be worthwhile to clarify the following: Section 6.2. (a) Developers MUST ensure that ephemeral credentials … are not leaked to third parties. (b) An adversary in possession of the ephemeral credentials bound to the access token will be able to impersonate the client. Be aware that this is a real risk with many constrained environments, since adversaries can often easily get physical access to the devices. (a) is helpful guidance; and independently (b) is a good reminder. However, the risk of a leak to a third party seems independent of getting physical access. ** Section 6.4. Per “C therefore MUST determine if an AS is authorized to provide access tokens for a certain RS.”, this is good advice. Additionally, it should be clarified that the means for a C to determine if the AS has the authority to issue access tokens for a given RS is left to the application and out of scope of this document. ** Fully appreciating that this document is already quite long, consider whether it would be helpful to implementers to add another block of text to explicitly enumerate how this framework alters OAuth. For example: ==[ snip ]== This document adapts OAuth v2 to be suitable for the IoT environment. In particular it differs from the normative requirements of OAuth in the following ways: *Use of TLS -- OAuth 2.0 requires the use of TLS both to protect the communication between AS and client when requesting an access token; between client and RS when accessing a resource and between AS and RS if introspection is used. This framework requires similar security properties, but does not require that they be realized with TLS. Section 5. * Cardinality of grant_type parameter -- In client-to-AS requests using OAuth 2.0, the grant_type parameter is required (per [RFC6749]). In this framework, this parameter is optional. See Section 5.8.1. * Encoding of scope parameter – In client-to-AS requests using OAuth 2.0, the scope parameter is string encoded (per [RFC6749]). In this framework, this parameter may also be encoded as a byte string. See Section 5.8.1. * Cardinality of token_type parameter – in AS-to-client responses using OAuth 2.0, the token_type parameter is required (per [RFC 6749]). In this framework, this parameter is optional. See Section 5.8.2. * Access token retention – in OAuth 2.0, the access token is sent with each request to the RS. In this framework, the RS must be able to store these tokens for later use. See Section 5.10.1. ==[ end ]== ** Would the first paragraph of Section 7.2 of draft-ietf-ace-dtls-authorize providing caution about the challenges of multiple access tokens be better served by placing it in this document? Section 7 of draft-ietf-ace-oscore-profile has similar words too. ** Editorial Nits -- Section 3.1. Typo. s/token token/token/ -- Section 5.3. Typo s/nevetheless/nevertheless/ -- Section 6.6. Typo s/loose the current/lose the current/ -- Section 6.6. Typo s/the the/the/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Roman Danyliw's No Objection on draft-ietf-ace-coap-est-17: (with COMMENT)
Roman Danyliw has entered the following ballot position for draft-ietf-ace-coap-est-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ -- COMMENT: -- * Section 4. Per “the DTLS connections SHOULD only be kept alive for EST messages that are relatively close to each other”, I think the text means that some EST messages are more likely to occur one after another. It would be worth being clearer what these would be. * Section 5.1. Per “These URIs are shorter than the ones in [RFC7030]”, does Table 1 imply that when using EST-coaps the “longer names” from RFC7030 wouldn’t be valid? * Section 5.2 Per “The latter ones are deemed to expensive …”, was difficult to parse as the sentence prior has three things (instead of two). Is this sentence referring to the “not specified functions” only? * Section 5.3, Per “30% smaller payload for DER-encoded ASN.1”, if you can cite this metric, please do. * Section 5.8. Per “In summary, the symmetrically encrypted key is included in the encryptedKey attribute in a KEKRecipientInfo structure”, if this is done in a server-side key generation scenario, where is the client getting the key to decrypt the server computed key material? Should the DecryptKeyIdentifier/ AsymmetricDecryptKeyIdentifier attributes be populated in the CSR per Sections 4.4.1.1/4.4.1.2 of RFC7030? * Section 10.1. Per “When server-side key generation is used, the constrained device depends on the server to generate the private key randomly, but it still needs locally generated random numbers for use in security protocols, as explained in Section 12 of [RFC7925].”, is the “security protocols” referenced here anything beyond DTLS? * Section 10.1. Per “In such occasions, checking the certificate revocation status or authorizing the client using another method is important for the server to ensure that the client is to be trusted.” -- does this text suggest that expired+revoked certificates should not be used? -- to word-smith: s/for the server to ensure that the client is to be trusted/for the server to raise its confidence that the client can be trusted/ * Section 10.1. Per “More information about recommendations of TLS and DTLS are included in [BCP195]”, thanks for referencing BCP195. Could you please clarify with normative language if these recommendations SHOULD/MUST be followed? * Editorial - Section 4. Per “Authenticating and negotiating DTLS keys requires resources on low- end endpoints and consumes valuable bandwidth”, I’m not sure this sentence is needed. Technically, “authenticating and negotiating DTLS keys requires resources” on any endpoint. - Section 4. OLD: Given that after a successful enrollment, it is more likely that a new EST transaction will take place after a significant amount of time, NEW: Given that after a successful enrollment, it is more likely that a new EST transaction will not take place for a significant amount of time, - Section 5.5. Typo. s/successfull/successful/ - Section 5.8. s/Such scenarios could be when it is …/Such scenarios apply when it is …/ - Section 5.8. s/ client, or when the resources/client, when the resources/ - Section 5.8. s/Then the private key/The private key/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Call for IETF 104 agenda items
Hello! The ACE WG has been tentatively scheduled for Friday, March 29, 2019 from 1050-1250 per the draft agenda [1]. If you would like time on the agenda please let the chairs know. Regards, Roman and Jim [1] https://datatracker.ietf.org/meeting/agenda/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] [Secdispatch] EDHOC
Hi Kathleen! There are multiple slots offered during the week of March 4 as possible times for the meeting. Perhaps one of them doesn’t conflict? Yes, we’ll record it. We appreciate everyone’s flexibility given the conflict with RSA. Roman From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com] Sent: Monday, February 11, 2019 7:30 PM To: Roman Danyliw Cc: Richard Barnes ; John Mattsson ; secdispa...@ietf.org; Francesca Palombini ; ace@ietf.org; Göran Selander Subject: Re: [Ace] [Secdispatch] EDHOC If I’m reading it correctly, it looks like I will be speaking at RSA during that time slot. Can the recording be posted? It’s a tough week for anyone attending, so I suspect attendance will be impacted. Thank you, Kathleen Sent from my mobile device On Feb 11, 2019, at 6:13 PM, Roman Danyliw mailto:r...@cert.org>> wrote: Hi Kathleen! Yes. A doodle poll to determine the most agreeable time the week of March 4 was just sent: https://mailarchive.ietf.org/arch/msg/secdispatch/KU3SWW_4UeJ9JMH9abmzaKeXXgc Roman From: Kathleen Moriarty [mailto:kathleen.moriarty.i...@gmail.com] Sent: Monday, February 04, 2019 12:30 PM To: Göran Selander mailto:goran.selan...@ericsson.com>> Cc: Richard Barnes mailto:r...@ipv.sx>>; Roman Danyliw mailto:r...@cert.org>>; John Mattsson mailto:john.matts...@ericsson.com>>; secdispa...@ietf.org<mailto:secdispa...@ietf.org>; Francesca Palombini mailto:francesca.palomb...@ericsson.com>>; ace@ietf.org<mailto:ace@ietf.org> Subject: Re: [Ace] [Secdispatch] EDHOC Will there be an interim for this topic? Thank you, Kathleen On Thu, Jan 24, 2019 at 2:15 PM Kathleen Moriarty mailto:kathleen.moriarty.i...@gmail.com>> wrote: Thanks for the very helpful message, Goran. A couple of comments inline. On Thu, Jan 24, 2019 at 11:31 AM Göran Selander mailto:goran.selan...@ericsson.com>> wrote: Hi Richard, Roman, all Thanks for kind welcome and for progressing the discussion. Apologies for a long email. From: Richard Barnes mailto:r...@ipv.sx>> Summing up where I believe the conversation stands now, it seems like what folks are asking for is either: 1. An analysis that shows that EDHOC is equivalent to an existing AKE (e.g., IKE or TLS), or 2. An argument that a new AKE is necessary (vs. a re-encoding of an existing AKE) Göran et al: Do you have thoughts on those points? Yes. I’ll get back to this later in this email. It seems like it could be a productive use of an hour or two of virtual interim time to help the group understand one of those lines of argument. Agree. Anything to prevent further hold ups on this work would be appreciated. --Richard As requested in a previous email, here is a background. The work on EDHOC is motivated by the need for an authentication and key exchange protocol for OSCORE (draft-ietf-core-object-security) optimized for constrained-node networks (RFC 7228). OSCORE is applied within the IETF, e.g. in 6TiSCH minimal security (draft-ietf-6tisch-minimal-security), but also requested by other SDOs and industry fora such as OMA Specworks, Open Connectivity Foundation and Fairhair Alliance. The properties of OSCORE motivating its use include: support for CoAP forward proxies, support for change of underlying transports including non-IP, low overhead, low additional footprint and memory to existing CoAP implementations, support for multicast security, security for end-to-end REST. Given the large interest in OSCORE already before it has become an RFC we anticipate a wide range of deployments. For example, we see an interest for OSCORE in Cellular IoT with traffic running over the cellular air interface control channel, where we can have end-to-end CoAP, but not necessarily end-to-end IP between an application server and a cellular device. Or between an application server and a device behind a cellular gateway. Comparing just these two cases, the difference in capabilities of the devices can be significant which makes it difficult to point at some sort of “reference devices” for benchmarking. In order to support the low end use cases the AKE must be performant in low bandwidth deployments with battery powered devices restricted in RAM and ROM. Message sizes and round trips have a direct impact on latency, power consumption and battery lifetime, and can be calculated which is the reason for this being a commonly used metric. While it may be more difficult to compare memory and storage requirements, the ability to reuse existing code is an important indication. If a device can support a CoAP stack (in the sense of memory and flash, etc) it is expected to also be able to support OSCORE. Similarly, it is desirable that a device with CoAP and OSCORE implemented should be able to support an additional AKE. Considering that EDHOC reuses CBOR and COSE primitives from OSCORE the additional code for EDHOC can
[Ace] FW: Poll to choose the date of the Virtual Interim Meeting for EDHOC
-Original Message- From: Secdispatch [mailto:secdispatch-boun...@ietf.org] On Behalf Of Roman Danyliw Sent: Monday, February 11, 2019 5:20 PM To: secdispa...@ietf.org Subject: [Secdispatch] Poll to choose the date of the Virtual Interim Meeting for EDHOC Hello WG! In coordination with the ACE co-chairs, SECDISPATCH will have a virtual interim meeting focused on dispatching EDHOC [1]. Help suggest the best day for this virtual meeting during the week of March 4, 2019 by completing this doodle poll -- https://doodle.com/poll/fevqfmn57rbb4rdg. Your input would be appreciated by Saturday, February 16, 2019. Regards, Roman and Richard [1] https://mailarchive.ietf.org/arch/msg/secdispatch/UollkQtwBu8TbTo9ANpnkcmpBxQ ___ Secdispatch mailing list secdispa...@ietf.org https://www.ietf.org/mailman/listinfo/secdispatch ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm
Hello! Per the IETF 103 face-to-face meeting and the call on the mailing list, there is support to adopt this draft (draft-palombini-ace-key-groupcomm). Authors: please submit this draft as a -00 WG document (draft-ietf-ace-key-groupcomm-00). Regards, Roman and Jim > -Original Message- > From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Roman Danyliw > Sent: Friday, November 30, 2018 4:59 PM > To: ace@ietf.org > Subject: [Ace] Call for adoption of draft-palombini-ace-key-groupcomm > > Hello! > > This is the start of a two week call for input on the WG adoption of the > document: > > draft-palombini-ace-key-groupcomm > https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02 > > The document has been presented and discussed at the last few meetings; > and revisions have been made based on WG feedback. At the IETF 103 > meeting, there was support for adoption; and volunteers to review and > implement the draft. > > Please provide feedback to the list/chairs if you believe that this document > should be adopted as a WG document.The adoption call will end on > December 14 2018. > > Regards, > Roman and Jim > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] Call for adoption of draft-tiloca-ace-oscoap-joining
Hello! Per the IETF 103 face-to-face meeting and the call on the mailing list, there is support to adopt this draft (draft-tiloca-ace-oscoap-joining). Authors: please submit this draft as a -00 WG document (draft-ietf-ace-oscoap-joining-00). Regards, Roman and Jim > -Original Message- > From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Roman Danyliw > Sent: Friday, November 30, 2018 4:59 PM > To: ace@ietf.org > Subject: [Ace] Call for adoption of draft-tiloca-ace-oscoap-joining > > Hello! > > This is the start of a two week call for input on the WG adoption of the > document: > > draft-tiloca-ace-oscoap-joining > https://tools.ietf.org/html/draft-tiloca-ace-oscoap-joining-05 > > The document has been presented and discussed at the last few meetings; > and revisions have been made based on WG feedback. At the IETF 103 > meeting, there was support for adoption; and volunteers to review and > implement the draft. > > Please provide feedback to the list/chairs if you believe that this document > should be adopted as a WG document.The adoption call will end on > December 14 2018. > > Regards, > Roman and Jim > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] FW: The ACE WG has placed draft-boucadair-dots-server-discovery in state "Call For Adoption By WG Issued"
This document state change is an error on my part. I selected the wrong WG in the datatracker interface. ACE is NOT considering this draft for adoption! Regards, Roman -Original Message- From: IETF Secretariat [mailto:ietf-secretariat-re...@ietf.org] Sent: Friday, November 30, 2018 5:25 PM To: ace-cha...@ietf.org; draft-boucadair-dots-server-discov...@ietf.org; ace@ietf.org Subject: The ACE WG has placed draft-boucadair-dots-server-discovery in state "Call For Adoption By WG Issued" The ACE WG has placed draft-boucadair-dots-server-discovery in state Call For Adoption By WG Issued (entered by Roman Danyliw) The document is available at https://datatracker.ietf.org/doc/draft-boucadair-dots-server-discovery/ ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Call for adoption of draft-tiloca-ace-oscoap-joining
Hello! This is the start of a two week call for input on the WG adoption of the document: draft-tiloca-ace-oscoap-joining https://tools.ietf.org/html/draft-tiloca-ace-oscoap-joining-05 The document has been presented and discussed at the last few meetings; and revisions have been made based on WG feedback. At the IETF 103 meeting, there was support for adoption; and volunteers to review and implement the draft. Please provide feedback to the list/chairs if you believe that this document should be adopted as a WG document.The adoption call will end on December 14 2018. Regards, Roman and Jim ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Call for adoption of draft-palombini-ace-key-groupcomm
Hello! This is the start of a two week call for input on the WG adoption of the document: draft-palombini-ace-key-groupcomm https://tools.ietf.org/html/draft-palombini-ace-key-groupcomm-02 The document has been presented and discussed at the last few meetings; and revisions have been made based on WG feedback. At the IETF 103 meeting, there was support for adoption; and volunteers to review and implement the draft. Please provide feedback to the list/chairs if you believe that this document should be adopted as a WG document.The adoption call will end on December 14 2018. Regards, Roman and Jim ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Syntax check of examples in draft-ietf-ace-cwt-proof-of-possession-05
Hello!
As part of my shepherd review, I ran all of the examples in
draft-ietf-ace-cwt-proof-of-possession-05 through a CBOR diagnostic-to-CBOR
validator (thanks Carsten for cbor.me). All of the examples were fine but the
first one in Section 3.3:
--[current text]--
{
/kty/ 1 : /Symmetric/ 4,
/alg/ 3 : /HMAC256/ 5,
/k/ -1 : h'6684523ab17337f173500e5728c628547cb37df
e68449c65f885d1b73b49eae1A0B0C0D0E0F10'
}
--[end]--
The error was:
Expected one of [ \t\n\r], "/", [0-9a-fA-F] at line 5, column 56 (byte 184)
after { /kty/ 1 : /Symmetric/ 4, /alg/ 3 : /HMAC256/ 5, /k/ -1 :
h'6684523ab17337f173500e5728c628547cb37df e68449c65f885d1b73b49eae1A0B0C0D0E0F10
It appears that the string of hex encoded octets in /k/ is short one character.
Roman
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
[Ace] Idnits on draft-ietf-ace-cwt-proof-of-possession-05
Hi!
As part of the shepherd review, I ran idnits on
draft-ietf-ace-cwt-proof-of-possession-05. The following nits were found.
Could these please be fixed in a revised draft.
--[ snip ]--
Checking nits according to https://www.ietf.org/id-info/checklist :
** There is 1 instance of too long lines in the document, the longest one
being 1 character in excess of 72.
Checking references for intended status: Proposed Standard
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
== Outdated reference: A later version (-17) exists of
draft-ietf-ace-oauth-authz-16
-- Obsolete informational reference (is this intentional?): RFC 7159
(Obsoleted by RFC 8259)
Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--).
--[ snip ]--
The line which exceeds 72 characters is in Section 3.4. Specifically:
/protected header / h'A1010A' /{ \alg\ 1:10 \AES-CCM-16-64-128\}/,
Regards,
Roman
___
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
[Ace] Draft update schedule from IETF 103
Hello WG! It got captured in the meeting minutes [1], but for easy reference, the following is the draft update schedule we discussed at IETF 103: ** draft-ietf-ace-oauth-authz -- Second-half of December 2018 ** draft-ietf-ace-dtls-authorize -- December 2018 ** draft-ietf-ace-oscore-profile -- Early December 2018 ** draft-ietf-ace-cwt-proof-of-possession -- Week of November 12, 2018 ** draft-ietf-ace-coap-est -- Early December 2018 Regards, Roman and Jim [1] https://datatracker.ietf.org/meeting/103/materials/minutes-103-ace-00 ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] IPR Conformance check for draft-ietf-ace-cwt-proof-of-possession
Hello draft-ietf-ace-cwt-proof-of-possession authors, (Hi Mike, Ludwig, Goeran, Samuel and Hannes,) As the shepherd for draft-ietf-ace-cwt-proof-of-possession, I'd like to confirm with the authors that all IPR disclosures have occurred per RFC6702: --[ shepherd questions ]-- (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? --[end question]-- Can you please respond to the list answering this question (e.g., "As a co-author, I don't hold any IPR nor am I aware of any related to this draft"). Thanks, Roman ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Draft IETF 103 minutes available
Hello! Thanks to Ivaylo Petrov, a preliminary version of the minutes from the Bangkok meeting is available at: https://datatracker.ietf.org/meeting/103/materials/minutes-103-ace-00 If you have corrections or revisions, please provide it to the chairs. Regards, Roman and Jim ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Summarizing WGLC discussion of draft-ietf-ace-cwt-proof-of-possession
Hello! This email is intended to summarize the outcome of the WGLC on draft-ietf-ace-cwt-proof-of-possession-02 to date. This call was started on May 8 [1] and discussion occurred around two reviews of this -02 draft: ** Jim Schaad [Schaad], per https://www.ietf.org/mail-archive/web/ace/current/msg02747.html ** Roman Danyliw [Danyliw], per https://www.ietf.org/mail-archive/web/ace/current/msg02793.html After discussion on the mailing list, -03 of the draft was produced. Synthesizing the robust mailing list discussion, I see the following previously identified issues as still needing closure. The nature of the resolution varies. Given the volume of the discussion threads, I may have missed a response or failed to line up a text change in -03 to an issue. Please correct the status of any given point of feedback below. ==[ -03 contains changes, but ML discussion doesn't indicate closure ]== The following feedback was made about the -02 draft; changes to the relevant text was made in -03; but follow-up discussions on the mailing list doesn't indicate closure of the issue. If the originator of the feedback (it looks like only Jim for this section) feels the issue is closed, please speak up. [Schaad #6] Under what circumstances would a 'sub' claim be present and it is not the presenter? I can see that a holder of the key may be implicitly (or anonymously) named, but putting something in the subject field which is not identifying the presenter is something that I would reject without a good presentation of why in the document. [Schaad #7] I would disagree with the claim that if the 'sub' claim is missing then it would normally be the issuer. For the world of IoT, I would expect that the subject would not be present because there is no need to identify the subject to the recipient. I.e. it is an anonymous subject. [Schaad #8] It is not clear to me that either of the sub and iss claims would normally be present. They might be present but neither is needed. The subject can be anonymous and the issuer is identified by the key used to validate the security on the CWT. [Schaad #9] In section 3.1 the first two sentences appear to be contradictory. Members are used to identify the POP key. Other things than a POP key can be used than a POP key. If they are used to identify the POP key- why would they not deal with the POP key? I think that you should do a separation and define the 'cnf' file which can hold any number of confirmation methods and then have a section on defining some POP cnf method field holders. [Schaad #10] In section 3.1 P1 - I am not sure why you have something here about confirming the authenticity of the token as oppose to confirming the identity of the presenter. Why would that type of information be placed here where it is not useful.] ==[ change was proposed, but not made ]== The draft editors proposed a changes on the mailing list to address the issue but it did not appear in the -03 draft. See the inline text of https://www.ietf.org/mail-archive/web/ace/current/msg02788.html for the proposed changes for [Schaad #12, 13, 16, 21]. [Schaad #12] I am unclear why there should be a restriction on the number of POP keys that can be in a 'cnf' object. If there are multiple keys, then any or all of them are of equal value in doing the confirmation. Just like there can be multiple confirmation methods and an application could choose to use any one of them. [Schaad #13] Not sure which section this belongs in, but the use of an COSE_Encrypt0 would be one way to combat tracking of identities based on the key value being used. Different encrypted values could be sent to different servers and they would not necessarily know about use w/o internal collusion between them. Similar effect by using an encrypted CWT. Potentially requires use of TLS1.3 to protect the RPKs. YMMV [Schaad #16] Section 4 - Are audience restrictions not done in CWT? -- same issues as [Danyliw #12] [Schaad #21] Section 6.2.2 - the value type is not an array for COSE_Encrypt or COSE_Encyrpt0, these are the values. As written I could put in an array which is not one of those two structures and be valid. Ditto for COSE_Key, although w/ slightly less justification. See the inline text of https://www.ietf.org/mail-archive/web/ace/current/msg02802.html for the proposed change for [Danyliw #7]. [Danyliw #7] Page 6, Section 3.3, The sentence "The COSE_Key could, for instance, be encrypted using a COSE_Encrypt0 representation using the AES-CCM-16-64-128 algorithm" seems out of place. What is this text explaining relative to the examples? ==[ face to face discussion required ]== Certain issues were deemed sufficiently complex to required face-to-face discussion at IETF 102. [Schaad #14] I have real problems w/ the use of a KID for POP identification. It may identify the wrong key or, if used for granting access, may have
Re: [Ace] Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02
Hi Hannes! > -Original Message- > From: Hannes Tschofenig [mailto:hannes.tschofe...@arm.com] > Sent: Friday, June 22, 2018 9:36 AM > To: Roman Danyliw ; ace@ietf.org > Subject: Replay ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of- > possession-02 > > Hi Roman, > > Thanks for your review. > > As I was re-reading the reviews I spotted this comment: > > > (14) (Editorial) Page 8, Section 4, Per "Replay can also be avoided if a > > sub- > key is derived from a shared secret that is specific to the instance of the > PoP > demonstration." PoP is spelled out everywhere else in this draft but here. > Yes, the acronym is defined, but for readability, I recommend against it using > it and consistently spelling it out here too. > > I believe the current text is a bit confusing. Here is what it says: > > Proof of possession via encrypted symmetric secrets is subject to replay > attacks. > This attack can, for example, be avoided when a signed nonce or challenge is > used since the recipient can use a distinct nonce or challenge for each > interaction. > Replay can also be avoided if a sub-key is derived from a shared secret that > is > specific to the instance of the proof-of-possession demonstration. > > This somehow gives the impression that replay attacks are only a concern for > symmetric key techniques. > Of course, this is not true. Furthermore, the text gives the impression that > this attack is actually something that can be covered within the CWT-PoP > token spec itself. This is also not the case. > > For this reason I am suggesting to change the paragraph to: > " > CBOR Web Tokens with proof-of-possession keys are used in context of an > architecture, such as ACE-OAuth [REF], where protocols are used by a > presenter to request these tokens and to subsequently use them with > recipients. To avoid replay attacks when the proof-of-possession tokens are > sent to presenters a security protocol, which uses nonces or timestamps, has > to be utilized. > Note that a discussion of the architecture or specific protocols CWT proof-of- > possession tokens are used with are outside the scope of this specification. " This new paragraph is easier to understand. It addresses my feedback. Thanks, Roman > Ciao > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
Re: [Ace] "sub" and "iss" ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02
Hi Hannes! > -Original Message- > From: Hannes Tschofenig [mailto:hannes.tschofe...@arm.com] > Sent: Friday, June 22, 2018 9:36 AM > To: Roman Danyliw ; ace@ietf.org > Subject: "sub" and "iss" ... RE: WGLC feedback on draft-ietf-ace-cwt-proof-of- > possession-02 > > Hi Roman, > > this is also a good question: > > > (3) (Editorial) Page 4, Section 3.0, I read to the end of this section by > > which > point there has been discussion of "sub" or "iss". I was left wondering about > how to interpret the case where both are present and none are. > > Here is the text from the draft: > > " >The presenter can be identified in one of several ways by the CWT >depending upon the application requirements. If the CWT contains a >"sub" (subject) claim [CWT], the presenter is normally the subject >identified by the CWT. (In some applications, the subject identifier >will be relative to the issuer identified by the "iss" (issuer) claim >[CWT].) If the CWT contains no "sub" claim, the presenter is >normally the issuer identified by the CWT using the "iss" claim. The >case in which the presenter is the subject of the CWT is analogous to >Security Assertion Markup Language (SAML) 2.0 >[OASIS.saml-core-2.0-os] SubjectConfirmation usage. At least one of >the "sub" and "iss" claims is typically present in the CWT and some >use cases may require that both be present. > " > > The CWT PoP document does not define the subject or issuer claims. > The document also not mandate a specific set of claims to be included in a > CWT since this is application profile specific. > > Hence, I am wondering whether we could shorten the paragraph above, > which is actually a bit confusing. > > " > This specification adds a new claim to offer the proof-of-possession > functionality. > There are various claims already defined and the IANA claims registry [REF] > contains the most up-to-date list of standardized claims. Application using > the CWT functionality define what claims have to be used. > > The presenter can, if necessary, be identified in one of several ways by the > CWT >depending upon the application requirements. If the CWT contains a >"sub" (subject) claim [CWT], the presenter is the subject >identified by the CWT. In some cases, there CWT may not include a "sub" >claim, which allows the presenter to remain anonymous. > " I like this shortened paragraph proposed above. IMO, it's simpler and more appropriate in this draft. Thanks, Roman > Ciao > Hannes > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] WGLC feedback on draft-ietf-ace-cwt-proof-of-possession-02
Hello! (chair hat off) I reviewed draft-ietf-ace-cwt-proof-of-possession-02 in WGLC and have the following feedback: (1) (Editorial) Page 3, "The value of the 'cnf' claim is a CBOR map and the ...". Isn't it more precise to say "The _representation_ of the 'cnf' claim is a CBOR map ..."? (2) (Editorial) Page 3, Why is the sentence "(In some applications, the subject identifier ..." in parenthesis? (3) (Editorial) Page 4, Section 3.0, I read to the end of this section by which point there has been discussion of "sub" or "iss". I was left wondering about how to interpret the case where both are present and none are. (4) (Editorial) Page 4, Section 3.1, Per " At most one of the "COSE_Key" and "Encrypted_COSE_Key" confirmation values defined below may be present." Defined below where specifically? I recommend citing Figure 1 explicitly by s/below/in Figure 1/. (5) Page 5, Typo in Section 3.2, s/diagonstic/diagnostic/ (6) (Editorial) Page 5, Section 2.3, Per "If the CWT is not encrypted, the symmetric key MUST be encrypted as described below." Described where below? I recommend citing Section 3.3 by s/below/In Section 3.3/ (7) Page 6, Section 3.3, The sentence "The COSE_Key could, for instance, be encrypted using a COSE_Encrypt0 representation using the AES-CCM-16-64-128 algorithm" seems out of place. What is this text explaining relative to the examples? (8) Page 7, Section 3.4, Per "The proof-of-possession key can also be identified by the use of a Key ID instead of communicating the actual key, provided the recipient is able to obtain the identified key using the Key ID." How would the sender know whether the recipient can "obtain the key using the Key ID"? Additionally, I would recommend adding language that states that this retrieval process is out of scope for this draft. (9) (Editorial) Page 7, Section 3.4, Per "In this case, the issuer of a CWT declares that the presenter possesses a particular key and that the recipient can cryptographically confirm proof of possession of the key by the presenter by including a "cnf" claim in the CWT whose value is a CBOR map with the CBOR map containing a "kid" member identifying the key." I recommend s/is a CBOR map with the CBOR map/is a CBOR map/ (10) Page 8, Section 4. RFC 2119 capitalizations seem more appropriate in these sentences: (MUST) "Appropriate means *must* be used to ensure that unintended parties do not learn private key or symmetric key values." (SHOULD) "Applications utilizing proof of possession *should* also utilize audience restriction, as described in Section 4.1.3 of [JWT], as it provides different protections." (MUST) "Applications that require the proof-of-possession keys communicated with it to be understood and processed *must* ensure that the parts of this specification that they use are implemented." (11) Page 8, Section 4. Per "Applications utilizing proof of possession should also utilize audience restriction, as described in Section 4.1.3 of [JWT], as it provides different protections." I recommend s/different/additional/ (12) (Editorial) Page 8, Section 4, Per Applications utilizing proof of possession should also utilize audience restriction, as described in Section 4.1.3 of [JWT], as it provides different protections. Proof of possession can be used by recipients to reject messages from unauthorized senders. Audience restriction can be used by recipients to reject messages intended for different recipients. The flow of this sentence is off for me. Sentence #1 asserts the need for audience restrictions. Sentence #3 describes the benefit of Sentence #1. Sentence #2 interjects with something that seems unrelated to this need-benefit pairing. (13) Page 8, Section 4, Per "Applications that require the proof-of-possession keys communicated with it to be understood and processed must ensure that the parts of thisspecification that they use are implemented." How is this being ensured? What happens if the needed parts aren't specified? Also, it seems like the "must" here should be "MUST". (14) (Editorial) Page 8, Section 4, Per "Replay can also be avoided if a sub-key is derived from a shared secret that is specific to the instance of the PoP demonstration." PoP is spelled out everywhere else in this draft but here. Yes, the acronym is defined, but for readability, I recommend against it using it and consistently spelling it out here too. (15) Page 8, Section 4, Per "Special care has to be applied when carrying symmetric keys inside the CWT since those not only require integrity protection but also confidentiality protection." What is that care? (16) Page 8, Section 4. Per "Proof-of-possession signatures made with keys not meeting the application's trust criteria MUST NOT not be relied upon.", remove the double "not" by s/MUST NOT not/MUST NOT/. Roman ___ Ace mailing
[Ace] Reminder -- WGLC on draft-ietf-ace-cwt-proof-of-possession-02
Hello! A reminder to the WG, draft-ietf-ace-cwt-proof-of-possession is in WGLC. Please send feedback to the mailing list by Wednesday, May 23. Thanks, Roman and Jim > -Original Message- > From: Ace [mailto:ace-boun...@ietf.org] On Behalf Of Roman Danyliw > Sent: Tuesday, May 08, 2018 6:19 PM > To: ace@ietf.org > Subject: [Ace] WGLC on draft-ietf-ace-cwt-proof-of-possession-02 > > Hello! > > Consistent with the feedback from the editor team at the London meeting, > we are starting a working group last call (WGLC) for the "Proof-of-Possession > Key Semantics for CBOR Web Tokens (CWTs)" draft: > > ** draft-ietf-ace-cwt-proof-of-possession-02 > ** https://tools.ietf.org/html/draft-ietf-ace-cwt-proof-of-possession-02 > > Please send comments to the mailing list -- feedback on issues or needed > changes; as well as endorsements that this draft is ready. > > This WGLC will end on Wednesday, May 23, 2018. > > Thanks, > Roman and Jim > > ___ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
[Ace] Draft minutes from the IETF 101 meeting
Hello WG! Draft minutes from the IETF 101 meeting have been published at: https://datatracker.ietf.org/meeting/101/materials/minutes-101-ace-00 Please send all updates and corrections to the chairs. Regards, Roman and Jim ___ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
