Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security
draft-ietf-ipsecme-qr-ikev2-11

[Ballot comment]

Thanks for the work done on this protocol extension. I only have two
relatively minor comments.

---------------------------------------------------------------------------

§5.1:

>  It is anticipated
>  that later standards will extend this technique to allow dynamically
>  changing PPK values.

It's likely that future specifications will extend the technique even before
becoming standards. Consider changing "standards" to "specifications."

---------------------------------------------------------------------------

§5.1:

>    Not all implementations are
>    able to configure arbitrary octet strings; to improve the
>    potential interoperability, it is recommended that, in the
>    PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited
>    to the base64 character set, namely the 64 characters 0-9, A-Z,
>    a-z, + and /.

This is a little confusing, since the base64 character set has 65 characters
in it (the 64 cited, plus '='). If the omission of '=' is intentional,
please add a short statement indicating so -- otherwise, implementors may
assume that its omission is unintentional and include it in their IDs. To
the extent that the problem describes arises in the field, this has the
potential to cause cause similar issues.

[Ballot comment]
Hi,

It seems to me there are places where 2119/8174 keywords would make sense.
Few examples, with suggestions:
  If the initiator is configured to use a post-quantum preshared key
  with the responder (whether or not the use of the PPK is mandatory),
  then it will include a notification USE_PPK in the IKE_SA_INIT
  request message as follows:
>>MUST include

  If the initiator needs to resend this initial message with a cookie
  (because the responder response included a COOKIE notification), then
  the resend would include the USE_PPK notification if the original
  message did.
>>MUST (or SHOULD?) include
by the way, if it is a resend of the message described in the paragraph above, then "if the original message did" seems superfluous.

  Otherwise the responder replies with the IKE_SA_INIT message including a
  USE_PPK notification in the response:
>>MUST reply

      initiator and the responder.  The responder can use the PPK_ID to
      look up the corresponding PPK value.  Not all implementations are
      able to configure arbitrary octet strings; to improve the
      potential interoperability, it is recommended that, in the
      PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited
      to the base64 character set, namely the 64 characters 0-9, A-Z,
      a-z, + and /.
>>RECOMMENDED

  values 3-127 are reserved for IANA;
Maybe it's just because I'm not used to that wording, but why "reserved for IANA" ?  The table seems to qualify them as unassigned.

[Ballot comment]
Hi,

I would have expected more 2119/8174 keywords.

Few examples, with suggestions:
  If the initiator is configured to use a post-quantum preshared key
  with the responder (whether or not the use of the PPK is mandatory),
  then it will include a notification USE_PPK in the IKE_SA_INIT
  request message as follows:
>>MUST include

  If the initiator needs to resend this initial message with a cookie
  (because the responder response included a COOKIE notification), then
  the resend would include the USE_PPK notification if the original
  message did.
>>MUST (or SHOULD?) include
by the way, if it is a resend of the message described in the paragraph above, then "if the original message did" seems superfluous.

  Otherwise the responder replies with the IKE_SA_INIT message including a
  USE_PPK notification in the response:
>>MUST reply

      initiator and the responder.  The responder can use the PPK_ID to
      look up the corresponding PPK value.  Not all implementations are
      able to configure arbitrary octet strings; to improve the
      potential interoperability, it is recommended that, in the
      PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited
      to the base64 character set, namely the 64 characters 0-9, A-Z,
      a-z, + and /.
>>RECOMMENDED

  values 3-127 are reserved for IANA;
Maybe it's just because I'm not used to that wording, but why "reserved for IANA" ?  The table seems to qualify them as unassigned.

[Ballot comment]
These are all editorial.

** Section 1.  Per “Recent achievements in developing quantum computers …”, is there a citation?

** Section 1. Per:
  If the preshared key has
  sufficient entropy and the PRF, encryption and authentication
  transforms are quantum-secure, then the resulting system is believed
  to be quantum resistant, that is, invulnerable to an attacker with a
  quantum computer.

-- The definition of quantum resistant doesn’t seem exactly precise.  A quantum-resistant algorithm isn’t “invulnerable to an attacker with a quantum computer”, rather isn’t it instead no easier to attack than with known classical architectures?

-- The first clause says the underlying primitives are quantum-secure, but then says that this translated into something being quantum-resistant.  I found it confusing to mix both terms (which sometimes are used interchangeably)

** Section 1.  Per “This document describes a way to extend IKEv2 to have a similar property; assuming that the two end systems share a long secret key then the resulting exchange is quantum resistant.”, I stumbled over this language a bit because I wasn’t sure which property you were referencing – was it the list of things in the previous paragraph’s last sentence that made it “quantum-secure”?

** Section 3. Per the description of modified IKEv2 key derivation:

-- Recommend explicitly citing the relevant section:
OLD:
Then, it computes this modification of the standard IKEv2 key derivation:

NEW:
Then, it computes this modification of the standard IKEv2 key derivation from Section 2.14 of [RFC7296]:

-- Recommend explaining the notation/relationship between the “prime versions” of the sub-keys (i.e., SK_d’ and SK_pi’ and SK_pr’) in the this SKEYSEED formula with the SKEYSEED formula in Section 2.14 of [RFC72196].

** Editorial Nits:

-- Section 1.  Editorial. s/this note/this document/ -- trying to be consistent on how the I-D references itself.

-- Section 4.  Editorial.  Recommended clarity:

OLD:
This will not affect the strength against a
  passive attacker; it would mean that an attacker with a quantum
  computer (which is sufficiently fast to be able to break the (EC)DH
  in real time) would not be able to perform a downgrade attack.

NEW:
This will not alter the resistance to a passive attack as even an attacker with a quantum computer (which is sufficiently fast to be able to break the (EC)DH in real time) would not be able to perform a downgrade attack.

-- Section 5.2.3.  Typo. s/Addtionally/Additionally/

-- Section 6.  Typo. s/transmited/transmitted/

[Ballot comment]
Yes, an interesting document, and thanks for that.  A few editorial comments:

— Section 1 —

  to be quantum resistant, that is, invulnerable to an attacker with a
  quantum computer.

“Invulnerable” isn’t the same as “not vulnerable”: it has a stronger connotation.  You should probably use “not vulnerable” or “resistant” instead.

  By bringing post-
  quantum security to IKEv2, this note removes the need to use

Make it “this document”, please.

  This document does not replace the
  authentication checks that the protocol does; instead, it is done as
  a parallel check.

What’s the antecedent to “it”?  Should “it is” instead be “they are”?

— Section 3 —

  when the initiator believes it has a mandatory to use PPK

You need hyphens in “mandatory-to-use”.

—

I also find it interesting that Alexey thought you needed to add a normative reference for “ASCII”, bit not for “base64”.  Personally, I think both are sufficiently well known that you need neither.

[Ballot comment]
Interesting read. Agree with Alissa, was this considered as update of RFC7296? It would give it the appropriate visibility for readers of RFC7296.

[Ballot comment]
Thank you for this document. One small suggestion below:

5.1.  PPK_ID format

  o  PPK_ID_FIXED (2) - in this case the format of the PPK_ID and the
      PPK are fixed octet strings; the remaining bytes of the PPK_ID are
      a configured value.  We assume that there is a fixed mapping
      between PPK_ID and PPK, which is configured locally to both the
      initiator and the responder.  The responder can use the PPK_ID to
      look up the corresponding PPK value.  Not all implementations are
      able to configure arbitrary octet strings; to improve the
      potential interoperability, it is recommended that, in the
      PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited
      to the base64 character set, namely the 64 characters 0-9, A-Z,
      a-z, + and /.

In order to avoid any doubt, I suggest you make it clear that you mean ASCII encoding here. For this you should add a normative reference to RFC 20 in the last quoted sentence.

[Ballot comment]
1) One small question on section 3:
"if using PPKs for communication with this responder
  is optional for the initiator, then the initiator MAY include a
  notification NO_PPK_AUTH in the above message."
This does mean that NO_PPK_AUTH notification should not be sent when the mandatory_or_not flag indicates that PPK is mandatory, right? Or is that a separate configuration? Would be good to clarify in the doc!

2) Section 6 says:
"In this situation, it is RECOMMENDED
  that the initiator caches the negative result of the negotiation for
  some time and doesn't make attempts to create it again for some time,"
Would it be possible to give any hints about what "some time" means or at least the order of magnitude? Maybe it could be recommended to wait a couple of seconds? Or how long is it usually expected to take until the half-open connection will be expired?

3) Also here:
"then the initiator doesn't abort the
  exchange immediately, but instead waits some time for more responses
  (possibly retransmitting the request)."
How long should one wait? Probably 1-2 RTTs if the RTT is known or maybe there is some good max value like 500ms or 1s or more...?  Is there any risk in waiting too long?

3) And one high-level comment (without knowing to much details about IKEv2): Would it be possible do a downgrade detection, meaning when non-PKK encryption is established the initiator would tell the responser again that it was initially requesting PKK, just to double-check...?

[Ballot comment]
1) One small question on section 3:
"if using PPKs for communication with this responder
  is optional for the initiator, then the initiator MAY include a
  notification NO_PPK_AUTH in the above message."
This does mean that NO_PPK_AUTH notification should not be sent when the mandatory_or_not flag indicates that PPK is mandatory, right? Or is that a separate configuration? Would be good to clarify in the doc!

2) Section 6 says:
"In this situation, it is RECOMMENDED
  that the initiator caches the negative result of the negotiation for
  some time and doesn't make attempts to create it again for some time,"
Would it be possible to give any hints about what "some time" means or at least the order of magnitude? Maybe it could be recommended to wait a couple of seconds? Or how long is it usually expected to take until the half-open connection will be expired?

3) Also here:
"then the initiator doesn't abort the
  exchange immediately, but instead waits some time for more responses
  (possibly retransmitting the request)."
How long should one wait? Probably 1-2 RTTs if the RTT is known or maybe there is some good max value like 500ms or 1s or more...?  Is there any risk in waiting too long?

3) And one high-level comment (without know to much details about IKEv2): Would it be possible to a downgrade detection, meaning even non-PKK encryption is established the initiator would tell the responser again that it was initially requesting PKK, just to double-check...?

[Ballot comment]
I think this document should formally update RFC 7296. Was that discussed in the WG?

I think the citation for [NISTPQCFP] should link to the actual call for proposals.

Section 6:

"In addition, the policy SHOULD be set to negotiate only quantum-
  resistant symmetric algorithms; while this RFC doesn't claim to give
  advice as to what algorithms are secure (as that may change based on
  future cryptographical results), below is a list of defined IKEv2 and
  IPsec algorithms that should not be used, as they are known to
  provide less than 128 bits of post-quantum security"

This paragraph mixes normative SHOULD with non-normative "should not" in the same paragraph. I was wondering if that is intentional.

[Ballot comment]
Thank you for the work put into this document. I found it very interesting to read BTW. I have only one minor non-blocking comment: please read RFC 8126 to have a correct IANA section about "type 16435" (and others). Same applies for section 5.1.

I hope that this helps to improve this document or any future one of yours,

Regards,

-éric

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

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

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

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

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

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

the following three early registrations will have their references changed to [ RFC-to-be ]:

16435 USE_PPK [draft-ietf-ipsecme-qr-ikev2]
16436 PPK_IDENTITY [draft-ietf-ipsecme-qr-ikev2]
16437 NO_PPK_AUTH [draft-ietf-ipsecme-qr-ikev2]

Second, a new registry is to be created.

IANA Question --> What should the name of the registry be?

IANA Question --> should the registry be located on the Internet Key Exchange Version 2 (IKEv2) Parameters registry page located at:

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

or, if not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry will be managed via Expert Review as defined in [ RFC 8126 ].

There are initial registrations in the new registry as follows:

PPK_ID Type Value Reference
----------- ----- ------------
Reserved 0
PPK_ID_OPAQUE 1 [ RFC-to-be ]
PPK_ID_FIXED 2 [ RFC-to-be ]
Unassigned 3-127
Reserved for private use 128-255

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.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-12-25):

From: The IESG
To: IETF-Announce
CC: David Waltermire , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-qr-ikev2@ietf.org, ipsec@ietf.org, david.waltermire@nist.gov, kaduk@mit.edu
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Postquantum Preshared Keys for IKEv2) to Proposed Standard


The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document: - 'Postquantum
Preshared Keys for 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 2019-12-25. 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


  The possibility of Quantum Computers poses a serious challenge to
  cryptographic algorithms deployed widely today.  IKEv2 is one example
  of a cryptosystem that could be broken; someone storing VPN
  communications today could decrypt them at a later time when a
  Quantum Computer is available.  It is anticipated that IKEv2 will be
  extended to support quantum-secure key exchange algorithms; however
  that is not likely to happen in the near term.  To address this
  problem before then, this document describes an extension of IKEv2 to
  allow it to be resistant to a Quantum Computer, by using preshared
  keys.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The intended status is Proposed Standard, which is listed in the title page header. The document defines a protocol and for interoperability the Internet Standard status is appropriated.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

The possibility of Quantum Computers pose a serious challenge to cryptography algorithms deployed widely today.  IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a Quantum Computer is available.  It is anticipated that IKEv2 will be extended to support quantum secure key exchange algorithms; however that is not likely to happen in the near term.  To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
 
The document has been highly reviewed and discussed and presented during multiple meetings and through the mailing list. The draft had no controversy. The draft has been discussed frequently on the mailing list and a lot of comments have been provided on list by people other than the authors, to include implementors. In addition to mailing list discussions, the draft has been presented and discussed during the 98 tru 102 IETF meetings. The draft has been supported by the participants in the room on various hums for the specific design decisions made in the document.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The document is supported by implementors, and authors also represent a subset of implementors. Interoperability has been confirmed by at least four independent implementations from Cisco, Apple, libreswan and ELVIS-PLUS. There likely additional implementations that the WG are not aware of at this time.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

David Waltermire is the document shepherd and Benjamin Kaduk is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has completely reviewed this draft to include
review of idnits, the references, and IANA considerations sections. No
issues have been found. The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The document has been heavily discussed and reviewed by the WG, and has
been presented during the IETF meetings. There has been a significant
number of comments on the draft, which have been sufficiently addressed
by the authors. The document represents the strong consensus of the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The idnits tool finds a single issue, which is an obsolete informational reference to RFC 2409. This is a false positive, since the draft is intentionally referencing IKEv1. No other issues were found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Three early assignments have been made in the IANA "IKEv2 Notify Message Types - Status Types" receiving the required expert review. The document does not need any additional external formal reviews.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

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

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) 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 protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section adds three new status types to the IANA "IKEv2 Notify Message Types - Status Types" registry. Both of these entries have been requested for early assignment, have passed expert review, and already appear in the registry.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is no need to proceed to further checks.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The intended status is Proposed Standard, which is listed in the title page header. The document defines a protocol and for interoperability the Internet Standard status is appropriated.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

The possibility of Quantum Computers pose a serious challenge to cryptography algorithms deployed widely today.  IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a Quantum Computer is available.  It is anticipated that IKEv2 will be extended to support quantum secure key exchange algorithms; however that is not likely to happen in the near term.  To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
 
The document has been highly reviewed and discussed and presented during multiple meetings and through the mailing list. The draft had no controversy. The draft has been discussed frequently on the mailing list and a lot of comments have been provided on list by people other than the authors, to include implementors. In addition to mailing list discussions, the draft has been presented and discussed during the 98 tru 102 IETF meetings. The draft has been supported by the participants in the room on various hums for the specific design decisions made in the document.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The document is supported by implementors, and authors also represent a subset of implementors. Interoperability has been confirmed by at least four independent implementations from Cisco, Apple, libreswan and ELVIS-PLUS. There likely additional implementations that the WG are not aware of at this time.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

David Waltermire is the document shepherd and Benjamin Kaduk is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has completely reviewed this draft to include
review of idnits, the references, and IANA considerations sections. No
issues have been found. The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The document has been heavily discussed and reviewed by the WG, and has
been presented during the IETF meetings. There has been a significant
number of comments on the draft, which have been sufficiently addressed
by the authors. The document represents the strong consensus of the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

The idnits tool finds a single issue, which is an obsolete informational reference to RFC 2409. This is a false positive, since the draft is intentionally referencing IKEv1. No other issues were found.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Three early assignments have been made in the IANA "IKEv2 Notify Message Types - Status Types" receiving the required expert review. The document does not need any additional external formal reviews.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

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

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) 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 protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section adds three new status types to the IANA "IKEv2 Notify Message Types - Status Types" registry. Both of these entries have been requested for early assignment, have passed expert review, and already appear in the registry.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is no need to proceed to further checks.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

The intended status is Proposed Standard, which is listed in the title page header. The document defines a protocol and for interoperability the Internet Standard status is appropriated.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

The possibility of Quantum Computers pose a serious challenge to cryptography algorithms deployed widely today.  IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a Quantum Computer is available.  It is anticipated that IKEv2 will be extended to support quantum secure key exchange algorithms; however that is not likely to happen in the near term.  To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?
 
The document has been highly reviewed and discussed and presented during multiple meetings and through the mailing list. The draft had no controversy. The draft has been discussed frequently on the mailing list and a lot of comments have been provided on list by people other than the authors, to include implementors. In addition to mailing list discussions, the draft has been presented and discussed during the 98 tru 102 IETF meetings. The draft has been supported by the participants in the room on various hums for the specific design decisions made in the document.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

The document is supported by implementors, and authors also represent a subset of implementors. Interoperability has been confirmed by at least four independent implementations from Cisco, Apple, libreswan and ELVIS-PLUS. There likely additional implementations that the WG are not aware of at this time.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

David Waltermire is the document shepherd and Benjamin Kaduk is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd has completely reviewed this draft to include
review of idnits, the references, and IANA considerations sections. No
issues have been found. The document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The document has been heavily discussed and reviewed by the WG, and has
been presented during the IETF meetings. There has been a significant
number of comments on the draft, which have been sufficiently addressed
by the authors. The document represents the strong consensus of the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Three early assignments have been made in the IANA "IKEv2 Notify Message Types - Status Types" receiving the required expert review. The document does not need any additional external formal reviews.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

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

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No.

(17) 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 protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

The IANA section adds three new status types to the IANA "IKEv2 Notify Message Types - Status Types" registry. Both of these entries have been requested for early assignment, have passed expert review, and already appear in the registry.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

There is no need to proceed to further checks.