Hi Brian,
thank you for the careful review of the proposed changes. Please see inline.
(To conserve space I deleted parts of the message that you didn’t comment or
that do not need comments from me).
Hi Madison and Karen,
I have added to Valery’s comments. Suggested resolutions on which I did not
comment seem correct to me.
8) <!--[rfced] In the following, should "Data-Security SAs" be singular
since "TEK" is singular? Also, are all of these items optional
(option A), or are only the Rekey SA and Group-wide policy
optional (option B)?
Original:
This policy describes the optional Rekey SA (KEK),
Data-Security SAs (TEK), and optional Group-wide (GW)
policy.
Perhaps A:
This policy describes the Rekey SA (KEK),
Data-Security SA (TEK), and Group-wide (GW)
policy, which are all optional.
or
Perhaps B:
This policy describes the Data-Security SA (TEK), optional
Rekey SA (KEK), and optional Group-wide (GW) policy.
-->
I propose the following text instead:
NEW:
This policy describes one or more Data-Security SAs (TEK), zero or one Rekey
SA (KEK),
and zero or one Group-wide (GW) policy.
I realize that TEK is still in a singular form, but I hope this is acceptable.
Let me know if this must be changed by all means.
The TEK (or TEKs) could also be optional as well. Here is clarifying text from
Section 4.4.1:
GSA payload may contain zero or one GSA KEK policy,
zero or more GSA TEK policies, and zero or one GW policy, where either one GSA
KEK or one
GSA TEK policy MUST be present.
I would suggest an amended version of Valery’s proposal. Perhaps:
NEW:
This policy describes zero or more Data-Security SAs (TEK), zero or one
Rekey SA (KEK),
and zero or one Group-wide (GW) policy (although at least one TEK or KEK
policy MUST be
Present).
(Technical Rationale): The prime use case for this is a multicast video event
where the GCKS delivered a
KEK during registration to all group members, followed by TEKs sent in a rekey
just before the event begins.
You are absolutely right, sorry for confusion. I agree with your
proposed text.
Notify Message vs. Notify message vs. notify message
Please, make the following changes:
Section 4.7
CURRENT:
There are additional Notify Message types introduced by G-IKEv2 to
communicate error conditions and status (see Section 9).
NEW:
There are additional Notify Message types introduced by G-IKEv2 to
communicate error conditions and status (see Section 9).
Valery, your NEW text seems to be identical to the CURRENT text. I think you
intended:
Oh… Perhaps I copy-pasted the original text and forgot to modify it.
Sorry.
NEW:
There are additional Notify message types introduced by G-IKEv2 to
communicate error conditions and status (see Section 9).
Rationale: to be consistent with RFC 7296, “Notify message” would be best
in the text. (Or alternatively, “the use of “notification” as suggested by
Valery below.)
The exception are the IANA registries, where “Notify Message” is used.
I agree with your proposed text.
b) We note that the following terms are used inconsistently. Please review and
let us know which form you prefer to use throughout the document.
Data-Security GSA TEK vs. GSA TEK vs. Data-Security SA policy (GSA TEK)
[Note: Are any of these terms the same?]
Yes, they are referring to the same concept, but I’m not sure they can all be
normalized.
— “Data-Security SA” is the type of policy used (see Terminology)
— "GSA TEK" is the vehicle in the protocol for relaying that policy.
Agree.
I would suggest the following clarifications though:
Setion 2.4.1
OLD
creates new Data-Security GSA TEKs
NEW
creates new Data-Security SAs
I agree with this change.
Section 4.4.1
OLD
GSA policies may further be classified as Rekey SA policy (GSA KEK)
and Data-Security SA policy (GSA TEK).
NEW
GSA policies may further be classified as Rekey SA (GSA KEK) policy
and Data-Security SA (GSA TEK) policy.
Fine with me.
group key management vs. group key management protocol
The function of “group key management” includes a “group key management
protocol”
in order to distriubute group keys and policy. For example, the heading for
Section 3
is “Group Key Management and Access Control”, and it would be inappropriate to
add
the word “Protocol” because it’s referring to the overall function.
Perhaps this would be clearer if the first sentence of Section 1 were updated.
OLD
This document presents an extension to IKEv2 [RFC7296] called
G-IKEv2, which allows performing group key management.
NEW
This document presents an extension to IKEv2 [RFC7296] called
G-IKEv2, which accomodates group key management.
No objections, this is more accurate definition.
Multicast Security (MSEC) Group Key Management Architecture vs.
Multicast Security (MSEC) key management architecture
The Abstract should be corrected to match the later reference:
OLD
The protocol is in conformance with the Multicast Security (MSEC) key
management architecture
NEW
The protocol is in conformance with the Multicast Security (MSEC) Group Key
Management architecture
(This is the name of RFC 4046, but I believe that references are not included
in an Abstract.)
Agree.
39) <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether the term "man-in-the-middle" should be
updated. -->
I believe we can use "person-in-the-middle" instead.
I failed to find other issues with inclusive language guide in the text.
Alternatively, “On-Path Attack Protection”.
I think that there must be some recommended replacement term for
“man-in-the-middle”.
If such a recommendation exists (I didn’t find any in the NIST’s
guide) then I think we should
use it. If not, then I’m fine with either proposals.
I did not detect any additional issues. Many thanks to all of you for your fine
updates.
Thank you!
Regards,
Valery.
Thanks,
Brian
I also have a proposal. The draft references draft-ietf-ipsecme-ikev2-qr-alt-10,
which is currently in the RFC Editor queue in the state "AUTH48".
While it is only informatively referenced, I think that it would be better if
it is referenced
as RFC and not as I-D. Can you please make this possible (I think it would
require adding
draft-ietf-ipsecme-ikev2-qr-alt-10 to C532 cluster).
Regards,
Valery.
Thank you.
Madison Church and Karen Moore
RFC Production Center
On Sep 11, 2025, at 7:14 PM, RFC Editor via auth48archive
<[email protected]> wrote:
*****IMPORTANT*****
Updated 2025/09/11
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* [email protected] (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* [email protected], which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
[email protected] will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9838.xml
https://www.rfc-editor.org/authors/rfc9838.html
https://www.rfc-editor.org/authors/rfc9838.pdf
https://www.rfc-editor.org/authors/rfc9838.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9838-diff.html
https://www.rfc-editor.org/authors/rfc9838-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9838-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9838
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9838 (draft-ietf-ipsecme-g-ikev2-23)
Title : Group Key Management using IKEv2
Author(s) : V. Smyslov, B. Weis
WG Chair(s) : Yoav Nir, Tero Kivinen
Area Director(s) : Deb Cooley, Paul Wouters
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
