Hi Valery,
That explanation helps a lot! Would "PPK with an ID" be accurate?
Perhaps:
1. If the responder is configured with a PPK with an ID that is among the
IDs sent by the initiator, and if this PPK matches the
initiator's PPK (based on the information from the PPK
Confirmation field), then the responder selects this PPK and
returns its identity in the PPK_IDENTITY notification.
Thoughts?
Sarah Tarrant
RFC Production Center
> On Sep 23, 2025, at 8:49 AM, Valery Smyslov <[email protected]> wrote:
>
> Hi Sarah,
>
>> Hi Valery,
>>
>> Thank you for your reply. We have updated the document accordingly.
>
> Thank you.
>
>> We have one followup question, regarding:
>>>> 2) <!-- [rfced] Sections 3.1 and 3.2: We're having trouble parsing "one
>>>> of the PPKs which IDs were sent" and "initiator's one". Would the
>>>> following match the intended meaning or is there another way this
>>>> can be written for clarity and consistency?
>>>>
>>>> a) Section 3.1:
>>>>
>>>> Original:
>>>> 1. If the responder is configured with one of the PPKs which IDs
>>>> were sent by the initiator and this PPK matches the initiator's
>>>> one (based on the information from the PPK Confirmation field),
>>>> then the responder selects this PPK and returns back its identity
>>>> in the PPK_IDENTITY notification.
>>>>
>>>> Perhaps:
>>>> 1. If the responder is configured with a PPK that was among the
>>>> IDs sent by the initiator, and if this PPK matches the
>>>> initiator's PPK (based on the information from the PPK
>>>> Confirmation field), then the responder selects this PPK and
>>>> returns its identity in the PPK_IDENTITY notification.
>>>
>>> I would modify this a bit:
>>>
>>> NEW:
>>> 1. If the responder is configured with a PPK having ID that is among the
>>> IDs sent by the initiator, and if this PPK matches the
>>> initiator's PPK (based on the information from the PPK
>>> Confirmation field), then the responder selects this PPK and
>>> returns its identity in the PPK_IDENTITY notification.
>>
>> For "configured with a PPK having ID":
>>
>> Does a) the ID have the PPK ("PPK-having ID") or b) the PPK have the ID
>> ("PPK that has an ID")?
>
> b) is correct.
>
>> Perhaps a:
>> 1. If the responder is configured with a PPK-having ID that is among the
>> IDs sent by the initiator, and if this PPK matches the
>> initiator's PPK (based on the information from the PPK
>> Confirmation field), then the responder selects this PPK and
>> returns its identity in the PPK_IDENTITY notification.
>>
>> Perhaps b:
>> 1. If the responder is configured with a PPK that has an ID that is among
>> the
>> IDs sent by the initiator, and if this PPK matches the
>> initiator's PPK (based on the information from the PPK
>> Confirmation field), then the responder selects this PPK and
>> returns its identity in the PPK_IDENTITY notification.
>>
>> Please let us know how we may update.
>
> Variant b) is correct.
>
> Alternatively, instead of "PPK that has an ID" it is possible to use
> something like
> "PPK identified by an ID", "PPK marked with an ID" etc. I don't know what is
> clearer, thus I rely on your choice.
>
> The idea is that the responder has a set of PPKs, each PPK has an associated
> "name" (ID),
> the initiator sends a list of IDs and the responder selects an appropriate
> PPK by
> comparing each ID sent by the initiator with ID of each PPK it has. If a
> match
> is found, the responder uses the corresponding PPK.
>
> Regards,
> Valery.
>
>
>> The updated files have been posted here (please refresh):
>> https://www.rfc-editor.org/authors/rfc9867.txt
>> https://www.rfc-editor.org/authors/rfc9867.pdf
>> https://www.rfc-editor.org/authors/rfc9867.html
>> https://www.rfc-editor.org/authors/rfc9867.xml
>>
>> The relevant diff files have been posted here (please refresh):
>> https://www.rfc-editor.org/authors/rfc9867-diff.html (comprehensive diff)
>> https://www.rfc-editor.org/authors/rfc9867-auth48diff.html (AUTH48 changes
>> only)
>>
>> Note that it may be necessary for you to refresh your browser to view the
>> most recent version.
>>
>> For the AUTH48 status of this document, please see:
>> https://www.rfc-editor.org/auth48/rfc9867
>>
>> Thank you,
>> Sarah Tarrant
>> RFC Production Center
>>
>>
>>
>>> On Sep 23, 2025, at 1:07 AM, Valery Smyslov <[email protected]> wrote:
>>>
>>> Hi Sarah and Karen,
>>>
>>> thank you, please find my answers inline.
>>>
>>>> Authors,
>>>>
>>>> While reviewing this document during AUTH48, please resolve (as necessary)
>>>> the following questions, which
>> are
>>>> also in the source file.
>>>>
>>>> 1) <!-- [rfced] Document title and abbreviated title.
>>>>
>>>> a) Please note that the document title has been updated as
>>>> follows. The abbreviation "IKEv2" has been expanded
>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide").
>>>
>>> OK, thank you.
>>>
>>>> Additionally, may we make the document title more concise by
>>>> removing "IKE_INTERMEDIATE" and "CREATE_CHILD_SA", as they are
>>>> not mentioned in the Abstract, and by potentially adding "PPK",
>>>> which is mentioned in the Abstract? Please let us know if one
>>>> of the suggestions below retains the intended meaning or if
>>>> you prefer otherwise.
>>>>
>>>> Original:
>>>> Mixing Preshared Keys in the IKE_INTERMEDIATE and in the
>>>> CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security
>>>>
>>>> Current:
>>>> Mixing Preshared Keys in the IKE_INTERMEDIATE and
>>>> CREATE_CHILD_SA Exchanges of the Internet Key Exchange
>>>> Protocol Version 2 (IKEv2) for Post-Quantum Security
>>>>
>>>> Perhaps A:
>>>> Mixing Preshared Keys in Exchanges of the Internet
>>>> Key Exchange Protocol Version 2 (IKEv2) for
>>>> Post-Quantum Security
>>>>
>>>> or
>>>> Perhaps B:
>>>> Enhanced Use of Post-Quantum Preshared Keys (PPKs) in the
>>>> Internet Key Exchange Protocol Version 2 (IKEv2) for
>>>> Post-Quantum Security
>>>
>>> I think that the current title (albeit a bit long) is OK, no need to change
>>> it.
>>> The title was discussed in the WG and the decision was that it should
>>> resemble RFC 8784 title (which this document relates to), but stress,
>>> that preshared key is used in IKE_INTERMEDIATE and CREATE_CHILD_SA.
>>>
>>>> b) Please verify that the abbreviated title that spans the header
>>>> of the PDF file still matches the document title.
>>>>
>>>> Original/Current:
>>>> Enhanced Use of PPKs in IKEv2
>>>> -->
>>>
>>> Good point, thank you. Please change it to:
>>>
>>> CURRENT:
>>> Enhanced Use of PPKs in IKEv2
>>>
>>> NEW:
>>> Enhanced Mixing PSKs in IKEv2 for PQ Security
>>>
>>>
>>> (this would also resemble RFC 8784 abbreviated title).
>>>
>>>
>>>> 2) <!-- [rfced] Sections 3.1 and 3.2: We're having trouble parsing "one
>>>> of the PPKs which IDs were sent" and "initiator's one". Would the
>>>> following match the intended meaning or is there another way this
>>>> can be written for clarity and consistency?
>>>>
>>>> a) Section 3.1:
>>>>
>>>> Original:
>>>> 1. If the responder is configured with one of the PPKs which IDs
>>>> were sent by the initiator and this PPK matches the initiator's
>>>> one (based on the information from the PPK Confirmation field),
>>>> then the responder selects this PPK and returns back its identity
>>>> in the PPK_IDENTITY notification.
>>>>
>>>> Perhaps:
>>>> 1. If the responder is configured with a PPK that was among the
>>>> IDs sent by the initiator, and if this PPK matches the
>>>> initiator's PPK (based on the information from the PPK
>>>> Confirmation field), then the responder selects this PPK and
>>>> returns its identity in the PPK_IDENTITY notification.
>>>
>>> I would modify this a bit:
>>>
>>> NEW:
>>> 1. If the responder is configured with a PPK having ID that is among the
>>> IDs sent by the initiator, and if this PPK matches the
>>> initiator's PPK (based on the information from the PPK
>>> Confirmation field), then the responder selects this PPK and
>>> returns its identity in the PPK_IDENTITY notification.
>>>
>>>
>>> Reason for correction: initiator sends a list of PPK identifiers (IDs), the
>>> responder
>>> is configured with a PPK with its own IDs, which it looks among supplied
>>> IDs.
>>>
>>> Is it clearer now?
>>>
>>>
>>>> b) Section 3.1:
>>>>
>>>> Original
>>>> 2. If the responder does not have any of the PPKs which IDs were
>>>> sent by the initiator or it has some of the proposed PPKs, but
>>>> their values mismatch the initiator's ones (based on the
>>>> information from the PPK Confirmation field), and using PPK is
>>>> mandatory for the responder, then it MUST return
>>>> AUTHENTICATION_FAILED notification and abort creating the IKE SA.
>>>>
>>>> Perhaps:
>>>> 2. If the responder does not have any of the PPKs that were among
>>>> the IDs sent by the initiator, or if the responder has some of
>>>> the proposed PPKs but their values are mismatched from the
>>>> initiator's PPKs (based on the information from the PPK
>>>> Confirmation field), and if using PPK is mandatory for the
>>>> responder, then it MUST return an AUTHENTICATION_FAILED
>>>> notification and abort creating the IKE SA.
>>>
>>> Again, I would propose minor modification:
>>>
>>> NEW:
>>> 2. If the responder does not have a PPK with ID that matches any of IDs
>>> sent by the initiator, or if the responder has some of
>>> the proposed PPKs but their values are mismatched from the
>>> initiator's PPKs (based on the information from the PPK
>>> Confirmation field), and if using PPK is mandatory for the
>>> responder, then it MUST return an AUTHENTICATION_FAILED
>>> notification and abort creating the IKE SA.
>>>
>>>
>>>> c) Section 3.2:
>>>>
>>>> Original:
>>>> In case the responder does not support (or is not configured for)
>>>> using PPKs in the CREATE_CHILD_SA exchange, or does not have any of
>>>> the PPKs which IDs were sent by the initiator, or it has some of
>>>> proposed PPKs, but their values mismatch the initiator's ones (based
>>>> on the information from the PPK Confirmation field), then it does not
>>>> include any PPK_IDENTITY notification in the response and new SA is
>>>> created as defined in IKEv2 [RFC7296].
>>>>
>>>> Perhaps:
>>>> If the responder does not support (or is not configured for)
>>>> using PPKs in the CREATE_CHILD_SA exchange or does not have any of
>>>> the PPKs that were among the IDs sent by the initiator, or if the
>>>> responder has some of proposed PPKs but their values are mismatched
>>>> from the initiator's PPKs (based on the information from the PPK
>>>> Confirmation field), then it does not include any PPK_IDENTITY
>>>> notifications in the response, and new SA is created as defined in
>>>> IKEv2 [RFC7296].
>>>
>>> Again, I would propose minor modification:
>>>
>>> NEW:
>>> If the responder does not support (or is not configured for)
>>> using PPKs in the CREATE_CHILD_SA exchange or does not have a PPK
>>> with ID that matches any of IDs sent by the initiator, or if the
>>> responder has some of proposed PPKs but their values are mismatched
>>> from the initiator's PPKs (based on the information from the PPK
>>> Confirmation field), then it does not include any PPK_IDENTITY
>>> notifications in the response, and new SA is created as defined in
>>> IKEv2 [RFC7296].
>>>
>>>
>>>> d) Section 3.2:
>>>>
>>>> Original:
>>>> If using PPKs in CREATE_CHILD_SA is mandatory for the responder and
>>>> the initiator does not include any PPK_IDENTITY_KEY notification in
>>>> the request or the responder does not have any of the PPKs which IDs
>>>> were sent by the initiator, or it has some of proposed PPKs, but
>>>> their values mismatch the initiator's ones (based on the information
>>>> from the PPK Confirmation field), then the responder MUST return the
>>>> NO_PROPOSAL_CHOSEN notification.
>>>>
>>>> Perhaps:
>>>> If using PPKs in CREATE_CHILD_SA is mandatory for the responder and
>>>> the initiator does not include any PPK_IDENTITY_KEY notification in
>>>> the request, or if the responder does not have any of the PPKs that
>>>> were among the IDs sent by the initiator, or if the responder has some
>>>> of the proposed PPKs but with mismatched values from the initiator's PPKs
>>>> (based on the information from the PPK Confirmation field), then the
>>>> responder MUST return the NO_PROPOSAL_CHOSEN notification.
>>>> -->
>>>
>>> Again, I would propose similar modification:
>>>
>>> NEW:
>>> If using PPKs in CREATE_CHILD_SA is mandatory for the responder and
>>> the initiator does not include any PPK_IDENTITY_KEY notification in
>>> the request, or if the responder does not have a PPK
>>> with ID that matches any of IDs sent by the initiator, or if the
>>> responder has some
>>> of the proposed PPKs but with mismatched values from the initiator's PPKs
>>> (based on the information from the PPK Confirmation field), then the
>>> responder MUST return the NO_PROPOSAL_CHOSEN notification.
>>>
>>>
>>>> 3) <!--[rfced] Is the use of the apostrophe in "SKEYSEED'" correct? We
>>>> ask as only "SKEYSEED" appears in RFCs 7296 and 8784. We note
>>>> that there are five instances in this document.
>>>>
>>>> One example
>>>>
>>>> Original:
>>>> A new SKEYSEED' value is computed using the
>>>> negotiated PPK and the most recently computed
>>>> SK_d key.
>>>> -->
>>>
>>> This is correct. This way we show that this is a re-calculated SKEYSEED key
>>> that will be used instead of original SKEYSEED (in RFC 8784 the same syntax
>>> was used
>>> for SK_d, SK_pi and SK_pr keys).
>>>
>>>
>>>> 4) <!-- [rfced] We're having trouble parsing "impact of appearing a CRQC
>>>> to". Is "appearing" the preferred term, or could this sentence be
>>>> rephrased as shown below for clarity?
>>>>
>>>> Original:
>>>> Section 4 of [RFC9370] discusses the potential impact of appearing a
>>>> CRQC to various cryptographic primitives used in IKEv2.
>>>>
>>>> Perhaps:
>>>> Section 4 of [RFC9370] discusses the potential impact of when a
>>>> CRQC is accessible to various cryptographic primitives used in IKEv2.
>>>> -->
>>>
>>> "Appearing" is not a preferred term and I'm generally fine with your text.
>>> However, I would suggest a very minor edit (to my ear this eliminates
>>> possible ambiguity):
>>>
>>> NEW:
>>> Section 4 of [RFC9370] discusses the potential impact of when a
>>> CRQC is accessible on various cryptographic primitives used in IKEv2.
>>>
>>>
>>>> 5) <!-- [rfced] Some author comments are present in the XML. Please
>>>> confirm that
>>>> no updates related to these comments are outstanding. Note that the
>>>> comments will be deleted prior to publication.
>>>> -->
>>>
>>> Oh, sorry. Please disregard and delete them.
>>>
>>>
>>>> 6) <!-- [rfced] FYI - We have added expansions for the following
>>>> abbreviations
>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
>>>> expansion in the document carefully to ensure correctness.
>>>>
>>>> Security Parameter Index (SPI)
>>>> -->
>>>
>>> OK, thank you.
>>>
>>>
>>>> 7) <!-- [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.
>>>>
>>>> Note that our script did not flag any words in particular, but this should
>>>> still be reviewed as a best practice.
>>>> -->
>>>
>>> I didn't find any violations of inclusive language guide.
>>>
>>>
>>> I also have some proposals for text changing.
>>>
>>> 8) Section 3.1.
>>>
>>> CURRENT:
>>> If a series of the IKE_INTERMEDIATE exchanges takes place, the
>>> PPK_IDENTITY_KEY notification(s) MUST be sent in the last one, i.e.,
>>> in the IKE_INTERMEDIATE exchange immediately preceding the IKE_AUTH
>>> exchange. If the last IKE_INTERMEDIATE exchange contains other
>>> payloads aimed for some other purpose, then the notification(s) MAY
>>> be piggybacked with these payloads.
>>>
>>> NEW:
>>> If a series of the IKE_INTERMEDIATE exchanges takes place, the
>>> PPK_IDENTITY_KEY notification(s) MUST be sent in the last one, i.e.,
>>> in the IKE_INTERMEDIATE exchange immediately preceding the IKE_AUTH
>>> exchange. If this IKE_INTERMEDIATE exchange contains other
>>> payloads aimed for some other purpose, then the notification(s) MAY
>>> be piggybacked with these payloads. Note that future IKEv2 extensions
>>> utilizing the IKE_INTERMEDIATE exchange may allow one or more this
>>> exchanges
>>> to happen after the one concerned with PPK for the case when such
>>> extensions
>>> are negotiated.
>>>
>>>
>>> 9) Section 3.1.1
>>>
>>> CURRENT:
>>> Once the PPK is negotiated in the last IKE_INTERMEDIATE exchange, the
>>> IKE SA keys are recalculated. Note that if the IKE SA keys are also
>>> recalculated as the result of the other actions performed in the
>>> IKE_INTERMEDIATE exchange (for example, as defined in [RFC9370]),
>>> then applying the PPK MUST be done after all of them so that
>>> recalculating IKE SA keys with the PPK is the last action before they
>>> are used in the IKE_AUTH exchange.
>>>
>>> NEW:
>>> Once the PPK is negotiated in the IKE_INTERMEDIATE exchange, the
>>> IKE SA keys are recalculated. Note that if the IKE SA keys are also
>>> recalculated as a result of other actions performed in this
>>> IKE_INTERMEDIATE exchange (for example, as defined in [RFC9370]),
>>> then applying the PPK MUST be done after all of them so that
>>> recalculating IKE SA keys with the PPK is the last action before they
>>> are used in the next exchange. Note that future IKEv2 extensions
>>> utilizing the IKE_INTERMEDIATE exchange may update this requirement
>>> for the case when such extensions are negotiated.
>>>
>>>
>>> The above two changes allow to leave a room for extensibility.
>>>
>>> Regards,
>>> Valery.
>>>
>>>> Thank you.
>>>>
>>>> Sarah Tarrant and Karen Moore
>>>> RFC Production Center
>>>>
>>>>
>>>> On Sep 18, 2025, at 6:04 PM, RFC Editor via auth48archive
>>>> <[email protected]> wrote:
>>>>
>>>> *****IMPORTANT*****
>>>>
>>>> Updated 2025/09/18
>>>>
>>>> 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/rfc9867.xml
>>>> https://www.rfc-editor.org/authors/rfc9867.html
>>>> https://www.rfc-editor.org/authors/rfc9867.pdf
>>>> https://www.rfc-editor.org/authors/rfc9867.txt
>>>>
>>>> Diff file of the text:
>>>> https://www.rfc-editor.org/authors/rfc9867-diff.html
>>>> https://www.rfc-editor.org/authors/rfc9867-rfcdiff.html (side by side)
>>>>
>>>> Diff of the XML:
>>>> https://www.rfc-editor.org/authors/rfc9867-xmldiff1.html
>>>>
>>>>
>>>> Tracking progress
>>>> -----------------
>>>>
>>>> The details of the AUTH48 status of your document are here:
>>>> https://www.rfc-editor.org/auth48/rfc9867
>>>>
>>>> Please let us know if you have any questions.
>>>>
>>>> Thank you for your cooperation,
>>>>
>>>> RFC Editor
>>>>
>>>> --------------------------------------
>>>> RFC9867 (draft-ietf-ipsecme-ikev2-qr-alt-10)
>>>>
>>>> Title : Mixing Preshared Keys in the IKE_INTERMEDIATE and in
>>>> the CREATE_CHILD_SA Exchanges of
>>>> IKEv2 for Post-quantum Security
>>>> Author(s) : V. Smyslov
>>>> 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]
