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

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/

Thank you - I also found this an interesting read, but must admit that I’m somewhat shaky on the math / security properties.

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

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.

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.

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.

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.

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

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.

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...?