Skip to main content

Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)
draft-ietf-ipsecme-ikev2-multiple-ke-12

Revision differences

Document history

Date Rev. By Action
2024-01-26
12 Gunter Van de Velde Request closed, assignment withdrawn: Nagendra Nainar Last Call OPSDIR review
2024-01-26
12 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2023-05-18
12 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2023-03-28
12 Yoav Nir Added to session: IETF-116: ipsecme  Wed-0630
2023-02-22
12 (System) RFC Editor state changed to AUTH48
2023-02-07
12 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2023-01-26
12 Bernie Volz Closed request for Telechat review by INTDIR with state 'Overtaken by Events'
2022-12-28
12 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2022-12-26
12 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2022-12-26
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2022-12-26
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2022-12-26
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2022-12-23
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2022-12-23
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2022-12-20
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2022-12-20
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2022-12-19
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2022-12-15
12 (System) IANA Action state changed to In Progress from Waiting on Authors
2022-12-14
12 (System) IANA Action state changed to Waiting on Authors from In Progress
2022-12-09
12 (System) RFC Editor state changed to EDIT
2022-12-09
12 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-12-09
12 (System) Announcement was received by RFC Editor
2022-12-09
12 (System) IANA Action state changed to In Progress
2022-12-09
12 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2022-12-09
12 Amy Vezza IESG has approved the document
2022-12-09
12 Amy Vezza Closed "Approve" ballot
2022-12-09
12 Amy Vezza Ballot approval text was generated
2022-12-01
12 Roman Danyliw IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2022-12-01
12 (System) Removed all action holders (IESG state changed)
2022-12-01
12 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2022-12-01
12 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2022-12-01
12 Paul Wouters
[Ballot comment]
# Sec AD review of draft-ietf-ipsecme-ikev2-multiple-ke-10

CC @paulwouters

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. …
[Ballot comment]
# Sec AD review of draft-ietf-ipsecme-ikev2-multiple-ke-10

CC @paulwouters

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.

This review uses the format specified in https://github.com/mnot/ietf-comments/ which allows
automated tools to process items (eg to produce github issers)

Let me first apologize to Valery for not getting to review this document earlier. He surely
reminded me enough times to do it before it landed at the IESG.


This is a very well written document. Thanks to everyone involved. While I have a few DISCUSS
comments, these should be easy to address or convince me why no changes are required.

Note to self (and Valery): draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt needs to be updated
to support this document. It currently only supports sending one KE payload.

## OLD DISCUSSes resolved


### IANA entries mentions in the Introduction ?

Shouldn't the introduction mention this draft introduces the IKE_FOLLOWUP_KE Exchange
and the STATE_NOT_FOUND Notify Message Type, along with additional entries to the
(now renamed) Key Exchanges Methods registry?

### Additional key exchanges DoS ?

The following paragraph raised an issue for me:
```
  If the responder selects NONE for some Additional Key Exchange types
  (provided they are proposed by the initiator), then the corresponding
  IKE_INTERMEDIATE exchanges MUST NOT take place.
```   
If the initiator's local policy requires at least one Additional Key Exchange,
an attacker sending back a quick reply with only NONE replies would be a DoS.
I think similar to like the original IKE_SA_INIT, perhaps we need to give some
advise that if the local policy would lead to permanent failure, that it
should wait for other (more legitimate) responses to this IKE_SA_INIT ?

### ADDITIONAL_KEY_EXCHANGE
```
  After IKE SA is created the window size may be greater than one and
  multiple concurrent exchanges may be in progress, it is essential to
  link the IKE_FOLLOWUP_KE exchanges together
```
I had some trouble figuring out why these are needed. For Child SA rekeys, these
would not be needed, because we would have an old SPI and MSGID that would make the
order obvious. But for adding addtional Child SA's, we have no old SPI. But we have
a new SPI on the initiator (and then a new SPI on the responder in the answer. Since
these are coupled by MSGID, I wonder if ADDITIONAL_KEY_EXCHANGE is really needed?
Looking at the useful appendix examples, I realise that the IKE_FOLLOWUP_KE exchange
does not have an SA payload so no SPI, so it makes sense to me now. Perhaps a sentence
in the document would be useful to explain this?

I still do not know why not to use the SPI as value for ADDITIONAL_KEY_EXCHANGE instead
of an opaque linking blob? The SPI is traditionally our linking blob.

Could the IKE_FOLLOWUP_KE set the SPI value in the IKE header instead of using
a new ADDITIONAL_KEY_EXCHANGE payload and use that with the MSGID as linking blob?


### State loss issue
```   
  After receiving this notification the initiator MAY start
  a new CREATE_CHILD_SA exchange which may eventually be followed by
  the IKE_FOLLOWUP_KE exchanges, to retry the failed attempt.  If the
  initiator continues to receive STATE_NOT_FOUND notifications [...]
```
How could this happen? If the state was lost, eg due to reboot, there would
need to come a new IKE SA, that can then send a new CREATE_CHILD_SA. I don't
see how that could lead to another STATE_NOT_FOUND. But the paragraph then
also continues with "and delete [the] IKE SA". But this IKE SA is brand new?
I would just remove this entire paragraph as I think this cannot happen. Or
at least it is not a special case and existing abort code handles this already.

### IKE session resumption

Should there be a section updating RFC 5723 Section 5.1, or is the method there
specified quantum-safe if the initial IKE SA was protected using this document's
mechanism? See https://www.rfc-editor.org/rfc/rfc5723.html#section-5.1

I think the IKE resumption can work "as normal", as no KE payload is
involved in the resumption, but it would be nice if a sentence somewhere
in this document could confirm this.

Also RFC 5723 states:
```
The keys and cryptographic protection algorithms should be at
      least 128 bits in strength.
```
IF we live in Grover universe, perhaps that should be 256 bits in strength? And since
we are making things quantum safe with this document, perhaps we should then at least
state session tickets should be 256 bits. Note if we do, then this document must
Update: RFC 5723. Perhaps this note on 5723 can be added in the Security Considerations
Section paragraph that talks about Grover and Shor.

### non-fatal NO_PROPOSAL_CHOSEN?
```
  In this case, the responder may respond with
  non-fatal error such as NO_PROPOSAL_CHOSEN notify message type.
```   
Technically, this error is non-fatal. But in this context, wouldn't it be fatal if the
responder insists on additional exchanges during the initial exchange and the initiator
doesn't suppor this? It is sort of a lame duck IKE SA ? :)

Also the "may" responder is unclear to me. What other response could there be and why?

### misplaced text?
```
  Note that if the initial IKE SA is used to transfer sensitive
  information, then this information will not be protected using the
  additional key exchanges [...]
```
This paragraph appears in the Section "Interaction with Childless IKE SA", but should probably
be moved to the Security Considerations section.

### IKE_FOLLOWUP_KE name

I find the name IKE_FOLLOWUP_KE a little confusing, as this exchange applies to
IKE and IPsec SA rekey negotiations. Why is it not called FOLLOWUP_ADDITIONAL_KE ?
Or CREATE_CHILD_SA_FOLLOWUP(_KE) (a sort of bad name too but that at least follows the
bad name from the original IKEv2 spec)


### authentication ?

```
        This document does not address authentication since it is less urgent
        at this stage.
```
While true, it does state that PPKs can be used. It might also want to say that
no IKE protocol level changes would be needed for authentication. A new RFC 7427
Digital Signature algorithm that is quantum-safe could be defined for X.509 and would
become available immediately without any IKEv2 level changes. So in a way, this
issue will be addressed but no IKEv2 document is needed for that. Perhaps this
can be clarified in the draft?

Related to this is text in the Security Considerations:

```
  In particular, the authenticity of the SAs established
  under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA
  algorithms.
```
This text is also incorrect as RFC 7427 allows us to use post-quantum authentication
algorithms that have a SubjectPublicKeyInfo (SPKI) definition. There might not be any
now, but there will presumbly be some in the future.

### AH

Section 4 lists AH. Is there much point in using this document when deploying AH?
The idea was the protect against _future_ quantum computers breaking encryption,
not MITM style packet modification. So using AH (or ESP_NULL) with this document
seems pointless :)

And the Security Considerations kind of agree with me here:
```
  Until quantum computers
  become available there is no point in attacking the authenticity of a
  connection because there are no possibilities for exploitation.
```

## Comments



### Section 2

I would probably have moved the Design Criteria to a later Section or Appendix, after
the entire protocol specification and Security Considerations. It's nice to know the
background, but this is "optional information" and shouldn't be as much at the focus
at the start of the document. (this is comment, you are fine to disagree and leave it
where it is)

### should -> could
```
  However, if such a requirement is
  needed, [I-D.tjhai-ikev2-beyond-64k-limit] discusses approaches that
  should be taken to exchange huge payloads.
```
I think this should should be a could, because it is a draft and it isn't
even adopted yet. I don't think that is suitable for a "should" even in lowercase.

### Design Criterea

One design criteria I do not see mentioned is "limit the extra number of RTTs as
much as possible". I do believe that was an important design criterea ?

The "future proof" design criterea is probably better named as "not post-quantum specific" ?

### Section 3

```
  A hybrid solution, when multiple
  key exchanges are performed and the calculated shared key depends on
  all of them, allows us to deal with this uncertainty by combining a
  classical key exchange with a post-quantum one, as well as leaving
  open the possibility of multiple post-quantum key exchanges.
```

This is an excellent summary sentence. It would be great to actually have this one in the
introduction :)

### IKE_INTERMEDIATE "is encrypted"
```
  The additional key exchanges are performed using
  IKE_INTERMEDIATE messages; because these messages are encrypted, the
  standard IKE fragmentation mechanism is available.
```
I think this is confusing. It is not really "because" they are encrypted that the fragmentation
mechanism "is available". Additionally, "encrypted" probably should clarify the level of
encryption - eg it would not me post-quantum safe. And of course it does not need to be.
Mabye something like:

  The additional key exchanges are performed using IKE_INTERMEDIATE messages that follow the
  IKE_SA_INIT exchange. This is to allow for standard IKE fragmentation mechanisms to be
  available for the potentially large post-quantum Key Exchange algorithm payloads. The IKE_SA_INIT
  exchange does not [cannot?] support fragmentation.

###
```
      and that hybrid key exchange is not needed.
```
Maybe:

      and that a hybrid key exchange containing a classic (EC)DH is no longer needed.

### Section 3.1 Childless?
```
    Following that, the IKE_AUTH exchange authenticates peers
    and completes IKE SA establishment.
```
This made me wonder if it was required to do a Childless IKE SA. I think a clarification is in order
here. Perhaps:

Following that, the IKE_AUTH exchange comples at normal and authenticates the peers, completes
the IKE SA establishment and when not childless, a Child SA is also established.


### Section 3.1 ASCII art

Probably, it should be clarified here that {} means "encrypted", or point a sentence on syntax to the
explanation in RFC7296? While this is obvious to readers of IKEv2 documents, this document has not
actually stated that this is the meaning. Additionally, perhaps introduce a {{foo}} that means
encrypted safely for classic and quantum ?

### duplicated algorithms

```
  MUST NOT contain duplicated algorithms
```
But it goes on saying this _can_ be possible, if the algorithm properties are the same, so this
sentence needs to reflect that to avoid misimplementation. Maybe:

MUST NOT contain duplicated algorithms with identical attributes

### Section 3.2.1.  MUST stop SA
```
  the initiator should log the
  error and MUST stop creating the SA or delete the SA if it is a
  rekey.
```

There is ambiguity here on the "delete the SA if it is a rekey". I think you mean to say to
stop creating or delete the SA being negotiated, and not to delete the SA that was attempted
to be rekeyed. How about the simpler:

the initiator should log the error and MUST abort the exchange with a permanent error.

### Section 3.2.1 IKE_INTERMEDIATE
```
    then the corresponding IKE_INTERMEDIATE exchanges MUST NOT take place.
```
You are already then clarifying this statement, but perhaps to avoid misimplementing, rewrite this to:

then the corresponding Additional Key Exchange(s) in the IKE_INTERMEDIATE exchanges MUST NOT take place.
If there is no Additional Key Exchange left to negotiate, this could mean that there is no more need
to perform any IKE_INTERMEDIATE exchanges.
[and remove the following paragraph completely]

### Section 3.2.2
```
  The other keying materials SK_d, SK_ai, SK_ar, SK_ei,
  SK_er, SK_pi, SK_pr are updated as:

  [...]
```
Why not say: The other keying materials SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr are generated
from the SKEYSEED(n) as per RFC 7296.

### Section 3.2.3
```
  This exchange is the
  standard IKE exchange, except that the initiator and responder signed
  octets are modified as described in [RFC9242].
```
Instead of "modified", which might mislead the reader into thinking this documents "modifies" that
process, I would say:

This exchange is the standard IKE exchange as described in [RFC7296] and [RFC9242].

### Section 3.2.4 missed rename
```
    the peers may optionally perform a Diffie-Hellman key exchange
```
Should this not also be renamed into: perform an additional Key Exchange Method

### Section 3.2.4 Simultanious rekey
```
  the initiator of this exchange just stops the
  rekeying process and it MUST NOT initiate the IKE_FOLLOWUP_KE
  exchange.
```
should this clarify with: and MUST delete the state and MUST NOT send a Delete/notify  ?

### Section 3.2.5 Childless IKE SA

This section explains how to use establish Child SAs without using the
IKE_INTERMEDIATE exchange.

I guess I would prefer that there are not two ways to do something, as IKEv2 is
already complex enough. But I guess the infrastructure needed for rekeying causes
this additional method to creep in whether we want it or not.

### I did?
```
    Thanks to Paul Wouters for reviewing the document.
```
I have no memory of this. Or was this pro-actively added? More serious, I guess I did
review this a long long time ago when the document looked very different :)

### Example is a bit contrived :)
```
      Transform AKE1 (ID = PQ_KEM_1)
      Transform AKE1 (ID = PQ_KEM_2)
      Transform AKE1 (ID = NONE)
      Transform AKE2 (ID = PQ_KEM_3)
      Transform AKE2 (ID = PQ_KEM_4)
      Transform AKE2 (ID = NONE)
      Transform AKE3 (ID = PQ_KEM_5)
      Transform AKE3 (ID = PQ_KEM_6)
      Transform AKE3 (ID = NONE)
```
I understand this is just an example to show the processing, but it would be a little odd
that both the order of (1|2) before (3|4) before (5|6) would matter if these sets are all
themselves optional - they are "optional requirements" ? :)

### Sending post-quantum proposals and policies in KE payload only

This solution was rejected because of a downgrade attack. Note though, that a new notify
payload of 'I_TRIED_POST_QUANTUM_FIRST' could be sent and the attacker would have been caught
in IKE_AUTH by the responder seeing this notify but never having seen the PQ KE payloads.
(not saying we should abandon this doc and go back to this proposal :)


### NITS
```
    needs to be integrated into IPsec protocol
```

should be "into the IPsec protocol"

```
        Currently, there does not exist a post-quantum key
        exchange that is trusted at the level that (EC)DH is trusted
        against conventional (non-quantum) adversaries.  A hybrid post-
        quantum algorithm to be introduced next to well-established
        primitives, since the overall security is at least as strong as
        each individual primitive.
```

I found this hard to read. How about:

        There is currently no post-quantum key exchange that is trusted at
        the level that (EC)DH is trusted for against conventional (non-quantum)
        adversaries.  A hybrid post-quantum algorithm to be introduced along with
        the well-established primitives addresses this concern, since the overall
        security is at least as strong as each individual primitive.

```
        A passive attacker can
        eavesdrop on IPsec communication today and decrypt it once a
        quantum computer is available in the future.
```

I think "eavesdrop" can be misinterpreted here. How about:

        A passive attacker can store all monitored encrypted IPsec communication
        today and decrypt it once a quantum computer is available in the future.

```
        This is a very
        serious attack for which we do not have a solution.
```

We have a solution, this document. It reads a bit as if this is undefendable now.

How about:

        This attack can have serious consequences that won't be visible for
        years to come. This document presents a defense against this serious attack.


```
        Nonetheless, it is possible to
        combine this post-quantum algorithm with a FIPS complaint key
        establishment method so that the overall design is FIPS
        compliant
```

I would change "is FIPS compliant" to "remains FIPS compliant"

```
  The fact, that
```
Remove the comma

```
  but this behavior is already specified
```

change to "but that this behaviour ....."

```
    The responder performs negotiation
```

The responder performs the negotiation  (added "the")

```
    rekeying them and rekeying IKE SA itself.
```
change to: rekeying these and rekeying the IKE SA itself.

```
  Its Exchange Type is 44.
```
change to: Its Exchange Type value is 44.

```
  After IKE SA is created the window size
```
After an IKE SA is [...]

```
    Its Notify Message Type is 16441
```
Its Notify Message Type value is 16441

```
  that would allow linking current exchange
```
that would allow linkinng the current exchange

```
  When rekeying IKE SA or Child SA
```
When rekeying the IKE SA or [the] Child SA

```
multiple key exchanges using post-quantum algorithm can be composed
```
using a post-quantum algorithm

```
    Simply increasing the key length can dwarfed this attack.
```

```
IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange
      Payloads
```
Note this "Payloads" word is not rendered in bold like the rest of this text

```
the responder decides not to perform the additional key exchange.
```

"require" instead of "perform" ?

```
Both peers then computes
```
Both peers then compute  (no s)
2022-12-01
12 Paul Wouters [Ballot Position Update] Position for Paul Wouters has been changed to No Objection from Discuss
2022-12-01
12 C. Tjhai New version available: draft-ietf-ipsecme-ikev2-multiple-ke-12.txt
2022-12-01
12 (System) New version approved
2022-12-01
12 (System)
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott …
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott Fluhrer , Valery Smyslov
2022-12-01
12 C. Tjhai Uploaded new revision
2022-12-01
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2022-12-01
11 C. Tjhai New version available: draft-ietf-ipsecme-ikev2-multiple-ke-11.txt
2022-12-01
11 (System) New version approved
2022-12-01
11 (System)
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott …
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott Fluhrer , Valery Smyslov
2022-12-01
11 C. Tjhai Uploaded new revision
2022-12-01
10 Francesca Palombini [Ballot comment]
Thank you for the work on this document.

Many thanks to Russ Housley for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/vuHfHEaOT8HvzHwHpnCNw23T_PM/.
2022-12-01
10 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2022-11-30
10 Murray Kucherawy
[Ballot comment]
This document has seven authors while the RFC Editor guideline is five.  Have we considered moving a couple of them to Section 6? …
[Ballot comment]
This document has seven authors while the RFC Editor guideline is five.  Have we considered moving a couple of them to Section 6?

While not a DISCUSS-level concern, I would really like to see more division among the actions requested of IANA in Section 4.  There are 12 actions across two sections; it wouldn't take much to put each action in its own section, for example.  I can see in the datatracker that IANA has already indicated they understand what's being asked of them, but still I think it's helpful to other readers to organize it.
2022-11-30
10 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2022-11-30
10 John Scudder
[Ballot comment]
Thanks for this. I have just one comment, about what's probably just a typographical error but it interfered with my understanding of the …
[Ballot comment]
Thanks for this. I have just one comment, about what's probably just a typographical error but it interfered with my understanding of the point in question so it seemed worth mentioning.

### Section 2, (2) is missing a verb, but what verb?

```
Hybrid. Currently, there does not exist a post-quantum key exchange that is trusted at the level that (EC)DH is trusted against conventional (non-quantum) adversaries. A hybrid post-quantum algorithm to be introduced next to well-established primitives, since the overall security is at least as strong as each individual primitive.
```

The second sentence seems, at minimum, to be missing a verb. For instance you could interpolate "needs" between "algorithm" and "to be", but I'm not sure if that properly captures your intended meaning.
2022-11-30
10 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2022-11-30
10 Andrew Alston [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston
2022-11-29
10 Erik Kline
[Ballot comment]
# Internet AD comments for draft-ietf-ipsecme-ikev2-multiple-ke-10
CC @ekline

## Nits

### S2

* s/FIPS complaint/FIPS compliant/

### S3.2.1

* I take it that …
[Ballot comment]
# Internet AD comments for draft-ietf-ipsecme-ikev2-multiple-ke-10
CC @ekline

## Nits

### S2

* s/FIPS complaint/FIPS compliant/

### S3.2.1

* I take it that it's not relevant to the example flow that there is no
  transform called AKE4.  :-)

### S5

* "can dwarfed"?
2022-11-29
10 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2022-11-29
10 Warren Kumari
[Ballot comment]
Thank you for writing this document (and also making it easy for someone like me to understand :-))
Also thanks to Geoff Huston …
[Ballot comment]
Thank you for writing this document (and also making it easy for someone like me to understand :-))
Also thanks to Geoff Huston for his DNSDOR review (https://datatracker.ietf.org/doc/review-ietf-ipsecme-ikev2-multiple-ke-07-dnsdir-lc-huston-2022-10-10/)


I have a few non-blocking comments -- feel free to address them or not.

I think that moving Section 2, Bullet 2 towards to top of the document would help the reader better understand why this document exists...


1: "While solving such a problem remains difficult with current
  computing power, it is believed that general purpose quantum
  computers will be able to solve this problem, implying that the
  security of IKEv2 is compromised."

'solving such a problem remains difficult with current computing power' implies that they *can* be solved with current computing power, while 'it is *believed* that general purpose quantum computers will be able to solve this problem' implies that quantum only *might* be able to solve them...this makes it sound like quantum machines are less of a concern than current ones :-). Perhaps 'general purpose quantum computers will *easily* be able to solve this problem'? Or 'solving such a problem is infeasible with current computing power'? (handwaving away trivial parameters) My suggestion isn't great, but hopefully I've managed to explain my concern?


2: Design Criteria - 3)  Focus on post-quantum confidentiality.
I understand what this is trying to say, but it feels very disjointed. I don't really have any suggested test to fix it, but just dropping the last sentence (or folding it into an earlier one) would make it much much easier to read.
2022-11-29
10 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2022-11-29
10 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2022-11-29
10 Éric Vyncke
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-ikev2-multiple-ke-10
CC @evyncke

Thank you for the work put into this document. Even if my IPsec …
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-ikev2-multiple-ke-10
CC @evyncke

Thank you for the work put into this document. Even if my IPsec knowledge is now very dated, I find it relatively easy to read.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Tero Kivinen for the shepherd's write-up including the WG consensus *but* the justification of the intended status is missing.

Other thanks to Geoff Huston for his Last Call DNS directorate review at: https://datatracker.ietf.org/doc/review-ietf-ipsecme-ikev2-multiple-ke-07-dnsdir-lc-huston-2022-10-10/

Please note that Charles Perkins is the Internet directorate reviewer (at my request) and you may want to consider this int-dir reviews as well when Charles will complete the review (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/reviewrequest/16618/

I hope that this review helps to improve the document,

Regards,

-éric

## COMMENTS

Out of all Paul Wouters's points, I support the last one about AH (I am not experience enough to appreciate the other ones). It is also related to bullet 3) of section 2.

### Missing reference RFC 8247

As indicated by idnits tool, RFC 8247 is used as a reference but is not defined ;-)

### Section 2

The bullet 2) is a nice explanation about *why* there must be multiple key exchanges with different methods. Until reading that part, I was really wondering why this I-D was about the link with PQC and multiple key exchanges. Should this be mentioned in the abstract already ?

Should "FIPS" be prefixed by "USA" as in "USA FIPS" ?


## NITS

### Section 1.2

`payloads longer than 64k` suggest to specify the units of measure.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
2022-11-29
10 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2022-11-28
10 Paul Wouters
[Ballot discuss]
# Sec AD review of draft-ietf-ipsecme-ikev2-multiple-ke-10

CC @paulwouters

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. …
[Ballot discuss]
# Sec AD review of draft-ietf-ipsecme-ikev2-multiple-ke-10

CC @paulwouters

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.

This review uses the format specified in https://github.com/mnot/ietf-comments/ which allows
automated tools to process items (eg to produce github issers)

Let me first apologize to Valery for not getting to review this document earlier. He surely
reminded me enough times to do it before it landed at the IESG.


This is a very well written document. Thanks to everyone involved. While I have a few DISCUSS
comments, these should be easy to address or convince me why no changes are required.

Note to self (and Valery): draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt needs to be updated
to support this document. It currently only supports sending one KE payload.

## DISCUSS


### IANA entries mentions in the Introduction ?

Shouldn't the introduction mention this draft introduces the IKE_FOLLOWUP_KE Exchange
and the STATE_NOT_FOUND Notify Message Type, along with additional entries to the
(now renamed) Key Exchanges Methods registry?

### Additional key exchanges DoS ?

The following paragraph raised an issue for me:
```
  If the responder selects NONE for some Additional Key Exchange types
  (provided they are proposed by the initiator), then the corresponding
  IKE_INTERMEDIATE exchanges MUST NOT take place.
```   
If the initiator's local policy requires at least one Additional Key Exchange,
an attacker sending back a quick reply with only NONE replies would be a DoS.
I think similar to like the original IKE_SA_INIT, perhaps we need to give some
advise that if the local policy would lead to permanent failure, that it
should wait for other (more legitimate) responses to this IKE_SA_INIT ?

### ADDITIONAL_KEY_EXCHANGE
```
  After IKE SA is created the window size may be greater than one and
  multiple concurrent exchanges may be in progress, it is essential to
  link the IKE_FOLLOWUP_KE exchanges together
```
I had some trouble figuring out why these are needed. For Child SA rekeys, these
would not be needed, because we would have an old SPI and MSGID that would make the
order obvious. But for adding addtional Child SA's, we have no old SPI. But we have
a new SPI on the initiator (and then a new SPI on the responder in the answer. Since
these are coupled by MSGID, I wonder if ADDITIONAL_KEY_EXCHANGE is really needed?
Looking at the useful appendix examples, I realise that the IKE_FOLLOWUP_KE exchange
does not have an SA payload so no SPI, so it makes sense to me now. Perhaps a sentence
in the document would be useful to explain this?

I still do not know why not to use the SPI as value for ADDITIONAL_KEY_EXCHANGE instead
of an opaque linking blob? The SPI is traditionally our linking blob.

Could the IKE_FOLLOWUP_KE set the SPI value in the IKE header instead of using
a new ADDITIONAL_KEY_EXCHANGE payload and use that with the MSGID as linking blob?


### State loss issue
```   
  After receiving this notification the initiator MAY start
  a new CREATE_CHILD_SA exchange which may eventually be followed by
  the IKE_FOLLOWUP_KE exchanges, to retry the failed attempt.  If the
  initiator continues to receive STATE_NOT_FOUND notifications [...]
```
How could this happen? If the state was lost, eg due to reboot, there would
need to come a new IKE SA, that can then send a new CREATE_CHILD_SA. I don't
see how that could lead to another STATE_NOT_FOUND. But the paragraph then
also continues with "and delete [the] IKE SA". But this IKE SA is brand new?
I would just remove this entire paragraph as I think this cannot happen. Or
at least it is not a special case and existing abort code handles this already.

### IKE session resumption

Should there be a section updating RFC 5723 Section 5.1, or is the method there
specified quantum-safe if the initial IKE SA was protected using this document's
mechanism? See https://www.rfc-editor.org/rfc/rfc5723.html#section-5.1

I think the IKE resumption can work "as normal", as no KE payload is
involved in the resumption, but it would be nice if a sentence somewhere
in this document could confirm this.

Also RFC 5723 states:
```
The keys and cryptographic protection algorithms should be at
      least 128 bits in strength.
```
IF we live in Grover universe, perhaps that should be 256 bits in strength? And since
we are making things quantum safe with this document, perhaps we should then at least
state session tickets should be 256 bits. Note if we do, then this document must
Update: RFC 5723. Perhaps this note on 5723 can be added in the Security Considerations
Section paragraph that talks about Grover and Shor.

### non-fatal NO_PROPOSAL_CHOSEN?
```
  In this case, the responder may respond with
  non-fatal error such as NO_PROPOSAL_CHOSEN notify message type.
```   
Technically, this error is non-fatal. But in this context, wouldn't it be fatal if the
responder insists on additional exchanges during the initial exchange and the initiator
doesn't suppor this? It is sort of a lame duck IKE SA ? :)

Also the "may" responder is unclear to me. What other response could there be and why?

### misplaced text?
```
  Note that if the initial IKE SA is used to transfer sensitive
  information, then this information will not be protected using the
  additional key exchanges [...]
```
This paragraph appears in the Section "Interaction with Childless IKE SA", but should probably
be moved to the Security Considerations section.

### IKE_FOLLOWUP_KE name

I find the name IKE_FOLLOWUP_KE a little confusing, as this exchange applies to
IKE and IPsec SA rekey negotiations. Why is it not called FOLLOWUP_ADDITIONAL_KE ?
Or CREATE_CHILD_SA_FOLLOWUP(_KE) (a sort of bad name too but that at least follows the
bad name from the original IKEv2 spec)


### authentication ?

```
        This document does not address authentication since it is less urgent
        at this stage.
```
While true, it does state that PPKs can be used. It might also want to say that
no IKE protocol level changes would be needed for authentication. A new RFC 7427
Digital Signature algorithm that is quantum-safe could be defined for X.509 and would
become available immediately without any IKEv2 level changes. So in a way, this
issue will be addressed but no IKEv2 document is needed for that. Perhaps this
can be clarified in the draft?

Related to this is text in the Security Considerations:

```
  In particular, the authenticity of the SAs established
  under IKEv2 is protected using a pre-shared key, RSA, DSA, or ECDSA
  algorithms.
```
This text is also incorrect as RFC 7427 allows us to use post-quantum authentication
algorithms that have a SubjectPublicKeyInfo (SPKI) definition. There might not be any
now, but there will presumbly be some in the future.

### AH

Section 4 lists AH. Is there much point in using this document when deploying AH?
The idea was the protect against _future_ quantum computers breaking encryption,
not MITM style packet modification. So using AH (or ESP_NULL) with this document
seems pointless :)

And the Security Considerations kind of agree with me here:
```
  Until quantum computers
  become available there is no point in attacking the authenticity of a
  connection because there are no possibilities for exploitation.
```
2022-11-28
10 Paul Wouters
[Ballot comment]
## Comments



### Section 2

I would probably have moved the Design Criteria to a later Section or Appendix, after
the entire protocol …
[Ballot comment]
## Comments



### Section 2

I would probably have moved the Design Criteria to a later Section or Appendix, after
the entire protocol specification and Security Considerations. It's nice to know the
background, but this is "optional information" and shouldn't be as much at the focus
at the start of the document. (this is comment, you are fine to disagree and leave it
where it is)

### should -> could
```
  However, if such a requirement is
  needed, [I-D.tjhai-ikev2-beyond-64k-limit] discusses approaches that
  should be taken to exchange huge payloads.
```
I think this should should be a could, because it is a draft and it isn't
even adopted yet. I don't think that is suitable for a "should" even in lowercase.

### Design Criterea

One design criteria I do not see mentioned is "limit the extra number of RTTs as
much as possible". I do believe that was an important design criterea ?

The "future proof" design criterea is probably better named as "not post-quantum specific" ?

### Section 3

```
  A hybrid solution, when multiple
  key exchanges are performed and the calculated shared key depends on
  all of them, allows us to deal with this uncertainty by combining a
  classical key exchange with a post-quantum one, as well as leaving
  open the possibility of multiple post-quantum key exchanges.
```

This is an excellent summary sentence. It would be great to actually have this one in the
introduction :)

### IKE_INTERMEDIATE "is encrypted"
```
  The additional key exchanges are performed using
  IKE_INTERMEDIATE messages; because these messages are encrypted, the
  standard IKE fragmentation mechanism is available.
```
I think this is confusing. It is not really "because" they are encrypted that the fragmentation
mechanism "is available". Additionally, "encrypted" probably should clarify the level of
encryption - eg it would not me post-quantum safe. And of course it does not need to be.
Mabye something like:

  The additional key exchanges are performed using IKE_INTERMEDIATE messages that follow the
  IKE_SA_INIT exchange. This is to allow for standard IKE fragmentation mechanisms to be
  available for the potentially large post-quantum Key Exchange algorithm payloads. The IKE_SA_INIT
  exchange does not [cannot?] support fragmentation.

###
```
      and that hybrid key exchange is not needed.
```
Maybe:

      and that a hybrid key exchange containing a classic (EC)DH is no longer needed.

### Section 3.1 Childless?
```
    Following that, the IKE_AUTH exchange authenticates peers
    and completes IKE SA establishment.
```
This made me wonder if it was required to do a Childless IKE SA. I think a clarification is in order
here. Perhaps:

Following that, the IKE_AUTH exchange comples at normal and authenticates the peers, completes
the IKE SA establishment and when not childless, a Child SA is also established.


### Section 3.1 ASCII art

Probably, it should be clarified here that {} means "encrypted", or point a sentence on syntax to the
explanation in RFC7296? While this is obvious to readers of IKEv2 documents, this document has not
actually stated that this is the meaning. Additionally, perhaps introduce a {{foo}} that means
encrypted safely for classic and quantum ?

### duplicated algorithms

```
  MUST NOT contain duplicated algorithms
```
But it goes on saying this _can_ be possible, if the algorithm properties are the same, so this
sentence needs to reflect that to avoid misimplementation. Maybe:

MUST NOT contain duplicated algorithms with identical attributes

### Section 3.2.1.  MUST stop SA
```
  the initiator should log the
  error and MUST stop creating the SA or delete the SA if it is a
  rekey.
```

There is ambiguity here on the "delete the SA if it is a rekey". I think you mean to say to
stop creating or delete the SA being negotiated, and not to delete the SA that was attempted
to be rekeyed. How about the simpler:

the initiator should log the error and MUST abort the exchange with a permanent error.

### Section 3.2.1 IKE_INTERMEDIATE
```
    then the corresponding IKE_INTERMEDIATE exchanges MUST NOT take place.
```
You are already then clarifying this statement, but perhaps to avoid misimplementing, rewrite this to:

then the corresponding Additional Key Exchange(s) in the IKE_INTERMEDIATE exchanges MUST NOT take place.
If there is no Additional Key Exchange left to negotiate, this could mean that there is no more need
to perform any IKE_INTERMEDIATE exchanges.
[and remove the following paragraph completely]

### Section 3.2.2
```
  The other keying materials SK_d, SK_ai, SK_ar, SK_ei,
  SK_er, SK_pi, SK_pr are updated as:

  [...]
```
Why not say: The other keying materials SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr are generated
from the SKEYSEED(n) as per RFC 7296.

### Section 3.2.3
```
  This exchange is the
  standard IKE exchange, except that the initiator and responder signed
  octets are modified as described in [RFC9242].
```
Instead of "modified", which might mislead the reader into thinking this documents "modifies" that
process, I would say:

This exchange is the standard IKE exchange as described in [RFC7296] and [RFC9242].

### Section 3.2.4 missed rename
```
    the peers may optionally perform a Diffie-Hellman key exchange
```
Should this not also be renamed into: perform an additional Key Exchange Method

### Section 3.2.4 Simultanious rekey
```
  the initiator of this exchange just stops the
  rekeying process and it MUST NOT initiate the IKE_FOLLOWUP_KE
  exchange.
```
should this clarify with: and MUST delete the state and MUST NOT send a Delete/notify  ?

### Section 3.2.5 Childless IKE SA

This section explains how to use establish Child SAs without using the
IKE_INTERMEDIATE exchange.

I guess I would prefer that there are not two ways to do something, as IKEv2 is
already complex enough. But I guess the infrastructure needed for rekeying causes
this additional method to creep in whether we want it or not.

### I did?
```
    Thanks to Paul Wouters for reviewing the document.
```
I have no memory of this. Or was this pro-actively added? More serious, I guess I did
review this a long long time ago when the document looked very different :)

### Example is a bit contrived :)
```
      Transform AKE1 (ID = PQ_KEM_1)
      Transform AKE1 (ID = PQ_KEM_2)
      Transform AKE1 (ID = NONE)
      Transform AKE2 (ID = PQ_KEM_3)
      Transform AKE2 (ID = PQ_KEM_4)
      Transform AKE2 (ID = NONE)
      Transform AKE3 (ID = PQ_KEM_5)
      Transform AKE3 (ID = PQ_KEM_6)
      Transform AKE3 (ID = NONE)
```
I understand this is just an example to show the processing, but it would be a little odd
that both the order of (1|2) before (3|4) before (5|6) would matter if these sets are all
themselves optional - they are "optional requirements" ? :)

### Sending post-quantum proposals and policies in KE payload only

This solution was rejected because of a downgrade attack. Note though, that a new notify
payload of 'I_TRIED_POST_QUANTUM_FIRST' could be sent and the attacker would have been caught
in IKE_AUTH by the responder seeing this notify but never having seen the PQ KE payloads.
(not saying we should abandon this doc and go back to this proposal :)


### NITS
```
    needs to be integrated into IPsec protocol
```

should be "into the IPsec protocol"

```
        Currently, there does not exist a post-quantum key
        exchange that is trusted at the level that (EC)DH is trusted
        against conventional (non-quantum) adversaries.  A hybrid post-
        quantum algorithm to be introduced next to well-established
        primitives, since the overall security is at least as strong as
        each individual primitive.
```

I found this hard to read. How about:

        There is currently no post-quantum key exchange that is trusted at
        the level that (EC)DH is trusted for against conventional (non-quantum)
        adversaries.  A hybrid post-quantum algorithm to be introduced along with
        the well-established primitives addresses this concern, since the overall
        security is at least as strong as each individual primitive.

```
        A passive attacker can
        eavesdrop on IPsec communication today and decrypt it once a
        quantum computer is available in the future.
```

I think "eavesdrop" can be misinterpreted here. How about:

        A passive attacker can store all monitored encrypted IPsec communication
        today and decrypt it once a quantum computer is available in the future.

```
        This is a very
        serious attack for which we do not have a solution.
```

We have a solution, this document. It reads a bit as if this is undefendable now.

How about:

        This attack can have serious consequences that won't be visible for
        years to come. This document presents a defense against this serious attack.


```
        Nonetheless, it is possible to
        combine this post-quantum algorithm with a FIPS complaint key
        establishment method so that the overall design is FIPS
        compliant
```

I would change "is FIPS compliant" to "remains FIPS compliant"

```
  The fact, that
```
Remove the comma

```
  but this behavior is already specified
```

change to "but that this behaviour ....."

```
    The responder performs negotiation
```

The responder performs the negotiation  (added "the")

```
    rekeying them and rekeying IKE SA itself.
```
change to: rekeying these and rekeying the IKE SA itself.

```
  Its Exchange Type is 44.
```
change to: Its Exchange Type value is 44.

```
  After IKE SA is created the window size
```
After an IKE SA is [...]

```
    Its Notify Message Type is 16441
```
Its Notify Message Type value is 16441

```
  that would allow linking current exchange
```
that would allow linkinng the current exchange

```
  When rekeying IKE SA or Child SA
```
When rekeying the IKE SA or [the] Child SA

```
multiple key exchanges using post-quantum algorithm can be composed
```
using a post-quantum algorithm

```
    Simply increasing the key length can dwarfed this attack.
```

```
IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange
      Payloads
```
Note this "Payloads" word is not rendered in bold like the rest of this text

```
the responder decides not to perform the additional key exchange.
```

"require" instead of "perform" ?

```
Both peers then computes
```
Both peers then compute  (no s)
2022-11-28
10 Paul Wouters [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters
2022-11-28
10 Sean Turner Request for Telechat review by SECDIR Completed: Has Nits. Reviewer: Sean Turner. Sent review to list.
2022-11-21
10 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2022-11-09
10 C. Tjhai New version available: draft-ietf-ipsecme-ikev2-multiple-ke-10.txt
2022-11-09
10 (System) New version approved
2022-11-09
10 (System)
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott …
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott Fluhrer , Valery Smyslov
2022-11-09
10 C. Tjhai Uploaded new revision
2022-11-07
09 C. Tjhai New version available: draft-ietf-ipsecme-ikev2-multiple-ke-09.txt
2022-11-07
09 (System) New version approved
2022-11-07
09 (System)
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott …
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott Fluhrer , Valery Smyslov
2022-11-07
09 C. Tjhai Uploaded new revision
2022-10-31
08 Bernie Volz Request for Telechat review by INTDIR is assigned to Charles Perkins
2022-10-31
08 Bernie Volz Request for Telechat review by INTDIR is assigned to Charles Perkins
2022-10-30
08 Tero Kivinen Request for Telechat review by SECDIR is assigned to Sean Turner
2022-10-30
08 Tero Kivinen Request for Telechat review by SECDIR is assigned to Sean Turner
2022-10-30
08 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2022-10-29
08 Éric Vyncke Requested Telechat review by INTDIR
2022-10-26
08 Russ Housley Request for Last Call review by ARTART Completed: Ready. Reviewer: Russ Housley. Sent review to list.
2022-10-24
08 Roman Danyliw Placed on agenda for telechat - 2022-12-01
2022-10-24
08 Roman Danyliw Ballot has been issued
2022-10-24
08 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2022-10-24
08 Roman Danyliw Created "Approve" ballot
2022-10-24
08 Roman Danyliw IESG state changed to IESG Evaluation from Waiting for Writeup
2022-10-24
08 Roman Danyliw Ballot writeup was changed
2022-10-24
08 (System) IESG state changed to Waiting for Writeup from In Last Call
2022-10-21
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2022-10-21
08 C. Tjhai New version available: draft-ietf-ipsecme-ikev2-multiple-ke-08.txt
2022-10-21
08 (System) New version approved
2022-10-21
08 (System)
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott …
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott Fluhrer , Valery Smyslov
2022-10-21
08 C. Tjhai Uploaded new revision
2022-10-19
07 David Dong
(BEGIN IANA COMMENTS)

IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ipsecme-ikev2-multiple-ke-07. If any part of this review is inaccurate, please let …
(BEGIN IANA COMMENTS)

IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ipsecme-ikev2-multiple-ke-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are six actions which we must complete.

Note: The last paragraph in Section 4 appears to be instructions for designated experts. If this is correct, we recommend including this paragraph in a sub-section for instructions to designated experts of the relevant registries.

First, in the IKEv2 Exchange Types registry on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

https://www.iana.org/assignments/ikev2-parameters/

the existing registration for:

Value: 44
Exchange Type: IKE_FOLLOWUP_KE

will have it's reference changed to [ RFC-to-be ].

Second, in the Transform Type Values registry also on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

https://www.iana.org/assignments/ikev2-parameters/

the existing registration for:

Type: 4
Description: Diffie-Hellman Group (D-H)
Used In: (IKE, optional in AH & ESP)

will have it's description changed to Key Exchange Method (KE)
and its reference changed to: [RFC7296][ RFC-to-be ]

Third, in the registry named "Transform Type 4 - Diffie-Hellman Group Transform IDs" also on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

https://www.iana.org/assignments/ikev2-parameters/

the registry will be renamed to: "Transform Type 4 - Key Exchange Method Transform IDs"

Fourth, also in Transform Type Values registry also on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

https://www.iana.org/assignments/ikev2-parameters/

seven existing registrations will have their references changed to [ RFC-to-be ]:

Type Description Used In
-----------------------------------------------------------------
6 Additional Key Exchange 1 (optional in IKE, AH, ESP)
7 Additional Key Exchange 2 (optional in IKE, AH, ESP)
8 Additional Key Exchange 3 (optional in IKE, AH, ESP)
9 Additional Key Exchange 4 (optional in IKE, AH, ESP)
10 Additional Key Exchange 5 (optional in IKE, AH, ESP)
11 Additional Key Exchange 6 (optional in IKE, AH, ESP)
12 Additional Key Exchange 7 (optional in IKE, AH, ESP)

Fifth, in the IKEv2 Notify Message Types - Status Types registry also on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

https://www.iana.org/assignments/ikev2-parameters/

a single, existing registration will have its reference changed to [ RFC-to-be ]:

Value: 16441
NOTIFY MESSAGES - STATUS TYPES: ADDITIONAL_KEY_EXCHANGE

Sixth, in the IKEv2 Notify Message Types - Error Types registry also on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

https://www.iana.org/assignments/ikev2-parameters/

a single, existing registration will be made permanent and have its reference changed to [ RFC-to-be ]:

Value: 47
NOTIFY MESSAGES - ERROR TYPES: STATE_NOT_FOUND

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

(END IANA COMMENTS)
2022-10-19
07 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2022-10-19
07 David Dong
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ipsecme-ikev2-multiple-ke-07. If any part of this review is inaccurate, please let …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-ipsecme-ikev2-multiple-ke-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are six actions which we must complete.

Note: The last paragraph in Section 4 appears to be instructions for designated experts. If this is correct, we recommend including this paragraph in a sub-section for instructions to designated experts of the relevant registries.

First, in the IKEv2 Exchange Types registry on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

https://www.iana.org/assignments/ikev2-parameters/

the existing registration for:

Value: 44
Exchange Type: IKE_FOLLOWUP_KE

will have it's reference changed to [ RFC-to-be ].

Second, in the Transform Type Values registry also on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

https://www.iana.org/assignments/ikev2-parameters/

the existing registration for:

Type: 4
Description: Diffie-Hellman Group (D-H)
Used In: (IKE, optional in AH & ESP)

will have it's description changed to Key Exchange Method (KE)
and its reference changed to: [RFC7296][ RFC-to-be ]

Third, in the registry named "Transform Type 4 - Diffie-Hellman Group Transform IDs" also on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

https://www.iana.org/assignments/ikev2-parameters/

the registry will be renamed to: "Transform Type 4 - Key Exchange Method Transform IDs"

Fourth, also in Transform Type Values registry also on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

https://www.iana.org/assignments/ikev2-parameters/

seven existing registrations will have their references changed to [ RFC-to-be ]:

Type Description Used In
-----------------------------------------------------------------
6 Additional Key Exchange 1 (optional in IKE, AH, ESP)
7 Additional Key Exchange 2 (optional in IKE, AH, ESP)
8 Additional Key Exchange 3 (optional in IKE, AH, ESP)
9 Additional Key Exchange 4 (optional in IKE, AH, ESP)
10 Additional Key Exchange 5 (optional in IKE, AH, ESP)
11 Additional Key Exchange 6 (optional in IKE, AH, ESP)
12 Additional Key Exchange 7 (optional in IKE, AH, ESP)

Fifth, in the IKEv2 Notify Message Types - Status Types registry also on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

https://www.iana.org/assignments/ikev2-parameters/

a single, existing registration will have its reference changed to [ RFC-to-be ]:

Value: 16441
NOTIFY MESSAGES - STATUS TYPES: ADDITIONAL_KEY_EXCHANGE

Sixth, in the IKEv2 Notify Message Types - Error Types registry also on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

https://www.iana.org/assignments/ikev2-parameters/

a single, existing registration will be made permanent and have its reference changed to [ RFC-to-be ]:

Value: 47
NOTIFY MESSAGES - ERROR TYPES: STATE_NOT_FOUND

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist
2022-10-17
07 Barry Leiba Request for Last Call review by ARTART is assigned to Russ Housley
2022-10-17
07 Barry Leiba Request for Last Call review by ARTART is assigned to Russ Housley
2022-10-17
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2022-10-17
07 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2022-10-14
07 Russ Housley Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Russ Housley. Sent review to list.
2022-10-13
07 Dave Thaler Assignment of request for Last Call review by SECDIR to Dave Thaler was rejected
2022-10-13
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dave Thaler
2022-10-13
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dave Thaler
2022-10-13
07 Jean Mahoney Request for Last Call review by GENART is assigned to Russ Housley
2022-10-13
07 Jean Mahoney Request for Last Call review by GENART is assigned to Russ Housley
2022-10-10
07 Geoff Huston Request for Last Call review by DNSDIR Completed: Ready. Reviewer: Geoff Huston. Sent review to list.
2022-10-10
07 Jim Reid Request for Last Call review by DNSDIR is assigned to Geoff Huston
2022-10-10
07 Jim Reid Request for Last Call review by DNSDIR is assigned to Geoff Huston
2022-10-10
07 Cindy Morgan IANA Review state changed to IANA - Review Needed
2022-10-10
07 Cindy Morgan
The following Last Call announcement was sent out (ends 2022-10-24):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ipsecme-ikev2-multiple-ke@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, kivinen@iki.fi, rdd@cert.org …
The following Last Call announcement was sent out (ends 2022-10-24):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ipsecme-ikev2-multiple-ke@ietf.org, ipsec@ietf.org, ipsecme-chairs@ietf.org, kivinen@iki.fi, rdd@cert.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Multiple Key Exchanges in IKEv2) to Proposed Standard


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document: - 'Multiple Key
Exchanges in IKEv2'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-10-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes how to extend the Internet Key Exchange
  Protocol Version 2 (IKEv2) to allow multiple key exchanges to take
  place while computing a shared secret during a Security Association
  (SA) setup.  The primary application of this feature in IKEv2 is the
  ability to perform one or more post-quantum key exchanges in
  conjunction with the classical (Elliptic Curve) Diffie-Hellman key
  exchange, so that the resulting shared key is resistant against
  quantum computer attacks.  Another possible application is the
  ability to combine several key exchanges in situations when no single
  key exchange algorithm is trusted by both initiator and responder.

  This document updates RFC7296 by renaming a transform type 4 from
  "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and
  renaming a field in the Key Exchange Payload from "Diffie-Hellman
  Group Num" to "Key Exchange Method".  It also renames an IANA
  registry for this transform type from "Transform Type 4 - Diffie-
  Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange
  Method Transform IDs".  These changes generalize key exchange
  algorithms that can be used in IKEv2.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3220/





2022-10-10
07 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2022-10-10
07 Roman Danyliw
# Document Shepherd Writeup

*This version is dated 10 October 2022.*
(+additions from the AD)

Thank you for your service as a document shepherd. Among …
# Document Shepherd Writeup

*This version is dated 10 October 2022.*
(+additions from the AD)

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus is solid.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Several implementors have been integral in developing this document, thus
implementors have indicated interest in implementing this. There is already
at least two interoperable implementations of this specification:

* strongSwan, https://github.com/strongswan/strongswan/tree/ikev2-qske-multi-ke
* ELVIS-PLUS, http://ipsec.elvis.ru/en.html

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

No. The document has already been reviewed by security area people, and
the cryptographic algorithms are not part of this document, but are documented
separately. In addition reviews from cryptographers have already been received
to the basic protocol.

[Added by AD]
The protocol mechanism has been subject to peer-reviewed, formal verification:
*  DOI: https://dl.acm.org/doi/10.1145/3485832.3485885
*  Pre-print: https://www.mnm-team.org/pub/Publikationen/gggh21b/PDF-Version/gggh21b.pdf

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None are applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document contains no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks are applicable.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

No.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

Proposed Standard as indicated on the title page header and in the datatracker.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

There is one IPR already submitted, and authors have indicated there is no
other known IPRs to them.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Authors have indicated willingness to be listed as such. There are 7 authors
listed, this document is work of group of authors working on different areas,
i.e., some of the authors are experts on the IKEv2, some are concentrated
on the cryptographic primitives, and some more to the post quantum in general.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

Idnits reports few false positive warnings.

15. Should any informative references be normative or vice-versa?

References are split properly to normative and informative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are now RFCs.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

No.

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document will update RFC7296 (changes some IANA registry names, and some
fields names to more generic form).

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

IANA allocations are ok. Note, that one of the authors and shepherd are
IANA experts associated with the registries to be modified.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This does not create any new registries, it will rename one old registry
and will change name of items in one registry. In addition to that it
adds new values to 4 different ikev2 registry.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

2022-10-10
07 Roman Danyliw Last call was requested
2022-10-10
07 Roman Danyliw Last call announcement was generated
2022-10-10
07 Roman Danyliw Ballot approval text was generated
2022-10-10
07 Roman Danyliw Ballot writeup was generated
2022-10-10
07 Roman Danyliw IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2022-10-06
07 (System) Changed action holders to Roman Danyliw (IESG state changed)
2022-10-06
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-10-06
07 C. Tjhai New version available: draft-ietf-ipsecme-ikev2-multiple-ke-07.txt
2022-10-06
07 (System) New version approved
2022-10-06
07 (System)
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott …
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott Fluhrer , Valery Smyslov
2022-10-06
07 C. Tjhai Uploaded new revision
2022-10-04
06 Roman Danyliw
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering …
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus is solid.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Several implementors have been integral in developing this document, thus
implementors have indicated interest in implementing this. There is already
at least two interoperable implementations of this specification:

* strongSwan, https://github.com/strongswan/strongswan/tree/ikev2-qske-multi-ke
* ELVIS-PLUS, http://ipsec.elvis.ru/en.html

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

No. The document has already been reviewed by security area people, and
the cryptographic algorithms are not part of this document, but are documented
separately. In addition reviews from cryptographers have already been received
to the basic protocol.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None are applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document contains no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks are applicable.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

No.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

Proposed Standard as indicated on the title page header and in the datatracker.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

There is one IPR already submitted, and authors have indicated there is no
other known IPRs to them.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Authors have indicated willingness to be listed as such. There are 7 authors
listed, this document is work of group of authors working on different areas,
i.e., some of the authors are experts on the IKEv2, some are concentrated
on the cryptographic primitives, and some more to the post quantum in general.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

Idnits reports few false positive warnings.

15. Should any informative references be normative or vice-versa?

References are split properly to normative and informative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are now RFCs.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

No.

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document will update RFC7296 (changes some IANA registry names, and some
fields names to more generic form).

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

IANA allocations are ok. Note, that one of the authors and shepherd are
IANA experts associated with the registries to be modified.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This does not create any new registries, it will rename one old registry
and will change name of items in one registry. In addition to that it
adds new values to 4 different ikev2 registry.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

2022-10-03
06 Roman Danyliw
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering …
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus is solid.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Several implementors have been integral in developing this document, thus
implementors have indicated interest in implementing this. There is already
at least two interoperable implementations of this specification:

* strongSwan, https://github.com/strongswan/strongswan/tree/ikev2-qske-multi-ke
* ELVIS, http://ipsec.elvis.ru/en.html

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

No. The document has already been reviewed by security area people, and
the cryptographic algorithms are not part of this document, but are documented
separately. In addition reviews from cryptographers have already been received
to the basic protocol.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None are applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document contains no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks are applicable.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

No.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

Proposed Standard as indicated on the title page header and in the datatracker.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

There is one IPR already submitted, and authors have indicated there is no
other known IPRs to them.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Authors have indicated willingness to be listed as such. There are 7 authors
listed, this document is work of group of authors working on different areas,
i.e., some of the authors are experts on the IKEv2, some are concentrated
on the cryptographic primitives, and some more to the post quantum in general.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

Idnits reports few false positive warnings.

15. Should any informative references be normative or vice-versa?

References are split properly to normative and informative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are now RFCs.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

No.

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document will update RFC7296 (changes some IANA registry names, and some
fields names to more generic form).

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

IANA allocations are ok. Note, that one of the authors and shepherd are
IANA experts associated with the registries to be modified.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This does not create any new registries, it will rename one old registry
and will change name of items in one registry. In addition to that it
adds new values to 4 different ikev2 registry.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

2022-09-30
06 Roman Danyliw AD Review: https://mailarchive.ietf.org/arch/msg/ipsec/3taFVdgJ2xEwqoQEA1ExzsuXrGM/
2022-09-30
06 (System) Changed action holders to Valery Smyslov, Scott Fluhrer, Roman Danyliw, Oscar Garcia-Morchon, C. Tjhai, M. Tomlinson, G. Bartlett, Daniel Van Geest (IESG state changed)
2022-09-30
06 Roman Danyliw IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2022-06-21
06 Tero Kivinen
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering …
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus is solid.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Several implementors have been integral in developing this document, thus
implementors have indicated interest in implementing this. There is already
at least two interoperable implementations of this specification.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

No. The document has already been reviewed by security area people, and
the cryptographic algorithms are not part of this document, but are documented
separately. In addition reviews from cryptographers have already been received
to the basic protocol.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None are applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document contains no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks are applicable.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

No.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

Proposed Standard as indicated on the title page header and in the datatracker.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

There is one IPR already submitted, and authors have indicated there is no
other known IPRs to them.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Authors have indicated willingness to be listed as such. There are 7 authors
listed, this document is work of group of authors working on different areas,
i.e., some of the authors are experts on the IKEv2, some are concentrated
on the cryptographic primitives, and some more to the post quantum in general.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

Idnits reports few false positive warnings.

15. Should any informative references be normative or vice-versa?

References are split properly to normative and informative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are now RFCs.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

No.

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document will update RFC7296 (changes some IANA registry names, and some
fields names to more generic form).

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

IANA allocations are ok. Note, that one of the authors and shepherd are
IANA experts associated with the registries to be modified.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This does not create any new registries, it will rename one old registry
and will change name of items in one registry. In addition to that it
adds new values to 4 different ikev2 registry.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

2022-06-21
06 Tero Kivinen Responsible AD changed to Roman Danyliw
2022-06-21
06 Tero Kivinen IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2022-06-21
06 Tero Kivinen IESG state changed to Publication Requested from I-D Exists
2022-06-21
06 Tero Kivinen IESG process started in state Publication Requested
2022-06-21
06 Tero Kivinen Tag Revised I-D Needed - Issue raised by WGLC cleared.
2022-06-21
06 Tero Kivinen
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering …
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus is solid.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Several implementors have been integral in developing this document, thus
implementors have indicated interest in implementing this. There is already
at least two interoperable implementations of this specification.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

No. The document has already been reviewed by security area people, and
the cryptographic algorithms are not part of this document, but are documented
separately. In addition reviews from cryptographers have already been received
to the basic protocol.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None are applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document contains no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks are applicable.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

No.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

Proposed Standard as indicated on the title page header and in the datatracker.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

There is one IPR already submitted, and authors have indicated there is no
other known IPRs to them.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Authors have indicated willingness to be listed as such. There are 7 authors
listed, this document is work of group of authors working on different areas,
i.e., some of the authors are experts on the IKEv2, some are concentrated
on the cryptographic primitives, and some more to the post quantum in general.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

Idnits reports few false positive warnings.

15. Should any informative references be normative or vice-versa?

References are split properly to normative and informative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are now RFCs.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

No.

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document will update RFC7296 (changes some IANA registry names, and some
fields names to more generic form).

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

IANA allocations are ok. Note, that one of the authors and shepherd are
IANA experts associated with the registries to be modified.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This does not create any new registries, it will rename one old registry
and will change name of items in one registry. In addition to that it
adds new values to 4 different ikev2 registry.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

2022-06-13
06 C. Tjhai New version available: draft-ietf-ipsecme-ikev2-multiple-ke-06.txt
2022-06-13
06 (System) New version approved
2022-06-13
06 (System)
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott …
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott Fluhrer , Valery Smyslov
2022-06-13
06 C. Tjhai Uploaded new revision
2022-06-07
05 Tero Kivinen
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering …
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus is solid.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Several implementors have been integral in developing this document, thus
implementors have indicated interest in implementing this. There is already
at least two interoperable implementations of this specification.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

No. The document has already been reviewed by security area people, and
the cryptographic algorithms are not part of this document, but are documented
separately. In addition reviews from cryptographers have already been received
to the basic protocol.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None are applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document contains no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks are applicable.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. There are some nits which have already been sent to the authors, but the
basic protocol specification is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

No.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

Proposed Standard as indicated on the title page header and in the datatracker.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

There is one IPR already submitted, and authors have indicated there is no
other known IPRs to them.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Authors have indicated willingness to be listed as such. There are 7 authors
listed, this document is work of group of authors working on different areas,
i.e., some of the authors are experts on the IKEv2, some are concentrated
on the cryptographic primitives, and some more to the post quantum in general.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

Idnits reports few false positive warnings.

15. Should any informative references be normative or vice-versa?

References are split properly to normative and informative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are now RFCs.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

No.

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document will update RFC7296 (changes some IANA registry names, and some
fields names to more generic form).

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

IANA allocations are ok. Note, that one of the authors and shepherd are
IANA experts associated with the registries to be modified.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This does not create any new registries, it will rename one old registry
and will change name of items in one registry. In addition to that it
adds new values to 4 different ikev2 registry.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

2022-06-04
05 Tero Kivinen
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering …
# Document Shepherd Writeup

*This version is dated 8 April 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this writeup to give helpful context to Last Call and
Internet Engineering Steering Group ([IESG][1]) reviewers, and your diligence in
completing it, is appreciated. The full role of the shepherd is further
described in [RFC 4858][2], and informally. You will need the cooperation of
authors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The WG consensus is solid.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Several implementors have been integral in developing this document, thus
implementors have indicated interest in implementing this.

### Additional Reviews

5. Does this document need review from other IETF working groups or external
  organizations? Have those reviews occurred?

No. The document has already been reviewed by security area people, and
the cryptographic algorithms are not part of this document, but are documented
separately. In addition reviews from cryptographers have already been received
to the basic protocol.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

None are applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The document contains no YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

No automated checks are applicable.

### Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

Yes. There are some nits which have already been sent to the authors, but the
basic protocol specification is ready.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. Do any such issues remain that would merit specific
    attention from subsequent reviews?

No.

11. What type of RFC publication is being requested on the IETF stream (Best
    Current Practice, Proposed Standard, Internet Standard, Informational,
    Experimental, or Historic)? Why is this the proper type of RFC? Do all
    Datatracker state attributes correctly reflect this intent?

Proposed Standard as indicated on the title page header and in the datatracker.

12. Has the interested community confirmed that any and all appropriate IPR
    disclosures required by [BCP 78][7] and [BCP 79][8] have been filed? If not,
    explain why. If yes, summarize any discussion and conclusion regarding the
    intellectual property rights (IPR) disclosures, including links to relevant
    emails.

There is one IPR already submitted, and authors have indicated there is no
other known IPRs to them.

13. Has each Author or Contributor confirmed their willingness to be listed as
    such? If the number of Authors/Editors on the front page is greater than 5,
    please provide a justification.

Authors have indicated willingness to be listed as such. There are 7 authors
listed, this document is work of group of authors working on different areas,
i.e., some of the authors are experts on the IKEv2, some are concentrated
on the cryptographic primitives, and some more to the post quantum in general.

14. Identify any remaining I-D nits in this document. (See [the idnits tool][9]
    and the checkbox items found in Guidelines to Authors of Internet-Drafts).
    Simply running the idnits tool is not enough; please review the entire
    guidelines document.

Idnits reports few false positive warnings.

15. Should any informative references be normative or vice-versa?

References are split properly to normative and informative.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

All normative references are now RFCs.

17. Are there any normative downward references (see [RFC 3967][10],
    [BCP 97][11])? If so, list them.

No.

18. Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If they exist, what is the
    plan for their completion?

No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document will update RFC7296 (changes some IANA registry names, and some
fields names to more generic form).

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][12]).

IANA allocations are ok. Note, that one of the authors and shepherd are
IANA experts associated with the registries to be modified.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

This does not create any new registries, it will rename one old registry
and will change name of items in one registry. In addition to that it
adds new values to 4 different ikev2 registry.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp78
[8]: https://www.rfc-editor.org/info/bcp79
[9]: https://www.ietf.org/tools/idnits/
[10]: https://www.rfc-editor.org/rfc/rfc3967.html
[11]: https://www.rfc-editor.org/info/bcp97
[12]: https://www.rfc-editor.org/rfc/rfc8126.html

2022-06-04
05 Tero Kivinen Changed consensus to Yes from Unknown
2022-06-04
05 Tero Kivinen Intended Status changed to Proposed Standard from None
2022-03-28
05 C. Tjhai New version available: draft-ietf-ipsecme-ikev2-multiple-ke-05.txt
2022-03-28
05 (System) New version approved
2022-03-28
05 (System)
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott …
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott Fluhrer , Valery Smyslov
2022-03-28
05 C. Tjhai Uploaded new revision
2022-02-04
04 Tero Kivinen Notification list changed to kivinen@iki.fi because the document shepherd was set
2022-02-04
04 Tero Kivinen Document shepherd changed to Tero Kivinen
2021-09-30
04 C. Tjhai New version available: draft-ietf-ipsecme-ikev2-multiple-ke-04.txt
2021-09-30
04 (System) New version approved
2021-09-30
04 (System)
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott …
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott Fluhrer , Valery Smyslov
2021-09-30
04 C. Tjhai Uploaded new revision
2021-08-16
03 Tero Kivinen Tag Revised I-D Needed - Issue raised by WGLC set.
2021-08-16
03 Tero Kivinen IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-07-26
03 Tero Kivinen IETF WG state changed to In WG Last Call from WG Document
2021-07-26
03 Tero Kivinen Added to session: IETF-111: ipsecme  Mon-1430
2021-07-06
03 C. Tjhai New version available: draft-ietf-ipsecme-ikev2-multiple-ke-03.txt
2021-07-06
03 (System) New version approved
2021-07-06
03 (System)
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott …
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott Fluhrer , Valery Smyslov
2021-07-06
03 C. Tjhai Uploaded new revision
2021-01-10
02 C. Tjhai New version available: draft-ietf-ipsecme-ikev2-multiple-ke-02.txt
2021-01-10
02 (System) New version approved
2021-01-10
02 (System)
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott …
Request for posting confirmation emailed to previous authors: "C. Tjhai" , "G. Bartlett" , "M. Tomlinson" , Daniel Van Geest , Oscar Garcia-Morchon , Scott Fluhrer , Valery Smyslov
2021-01-10
02 C. Tjhai Uploaded new revision
2020-07-10
01 C. Tjhai New version available: draft-ietf-ipsecme-ikev2-multiple-ke-01.txt
2020-07-10
01 (System) New version approved
2020-07-10
01 (System)
Request for posting confirmation emailed to previous authors: Scott Fluhrer , ipsecme-chairs@ietf.org, Daniel Van Geest , "M. Tomlinson" , " grbartle@cisco.com" , "C. …
Request for posting confirmation emailed to previous authors: Scott Fluhrer , ipsecme-chairs@ietf.org, Daniel Van Geest , "M. Tomlinson" , " grbartle@cisco.com" , "C. Tjhai" , Valery Smyslov , Oscar Garcia-Morchon
2020-07-10
01 C. Tjhai Uploaded new revision
2020-01-10
00 Yoav Nir This document now replaces draft-tjhai-ipsecme-hybrid-qske-ikev2 instead of None
2020-01-10
00 C. Tjhai New version available: draft-ietf-ipsecme-ikev2-multiple-ke-00.txt
2020-01-10
00 (System) WG -00 approved
2020-01-08
00 C. Tjhai Set submitter to ""C. Tjhai" ", replaces to draft-tjhai-ipsecme-hybrid-qske-ikev2 and sent approval email to group chairs: ipsecme-chairs@ietf.org
2020-01-08
00 C. Tjhai Uploaded new revision