Subject: [IPsec] FW: Quantum Resistance Requirements

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 28 Oct 2016 14:25:45 +0000

Here is an update on the voting for the list of potential requirements for a short term Quantum Resistance solution; and a summary of the recent update to our draft (which reflects the stated requirements)

The votes so far (omitting the "no opinion" votes); I've listed the voters chiefly so that if I mischaracterized their votes, they can correct me.

- Simplicity; how large of a change to IKE (and IKE implementations) are we willing to contemplate?
Scott Fluhrer: very important
Michael Richardson: very important
Tommy Pauly: very important
Valery Smyslov: not as important as other issues
Oscar Garcia-Morchon: very important.

- Preserving existing IKE security properties?
Scott Fluhrer: very important
Michael Richardson: very important
Tommy Pauly: very important
Valery Smyslov: important
Oscar Garcia-Morchon: very important. 

- What do we feel needs to protected from someone with a Quantum Computer?  Do we feel  the need to protect only the IPsec traffic, or do we need to protect the IKE traffic as well.
Tommy Pauly: not clear if IKE traffic needs to be protected.
Valery Smylsov: important
Oscar Garcia-Morchon: IPsec traffic must be protected, IKE traffic would be a nice-to-have. 

- What level of identity protection do we need to provide?  If two different IKE negotiations use the same shared secret, do we mind if someone can deduce that?
Scott Fluhrer: not important
Michael Richardson: very important
Tommy Pauly: not important
Valery Smylsov: this is a nice to have, but not critical
Oscar Garcia-Morchon: this is less important
Russ Houseley: this is a nice to have, but only if it is cheap

-  PPK management; how much support do we provide for automatically managing the secrets?
Scott Fluhrer: not important
Tommy Pauly: not important
Oscar Garcia-Morchon: not important

- How much support do we provide for nonstatic secrets, for example, by QKD, or via something like HIMMO (a key distribution mechanism that appears to be post quantum)?
Scott Fluhrer: not important
Michael Richardson: not important
Tommy Pauly: not important
Oscar Garcia-Morchon: not important now, but will become important in the future

- Authentication; if someone with a Quantum Computer can break the DH in real time, do we care if he can act as a man-in-the-middle?
Scott Fluhrer: not important
Michael Richardson: important, provided that we don't run into the same issues that IKEv1 PSKs ran into
Tommy Pauly: not important
Valery Smylsov: this would be nice to have
Oscar Garcia-Morchon: this would be nice to have

- Algorithm agility; how important is it that we negotiate any cryptoprimitives involved?
Scott Fluhrer: not important
Tommy Pauly: not important
Valery Smylsov: important
Oscar Garcia-Morchon: less important.

My tentative summary of the votes:

- Simplicity and preserving existing security properties are the most important
- Protecting IKE traffic was considered less important.

We have updated our draft to reflect these requirements; it is much simpler than the previous draft, but does not provide anonymity.  It is based on a suggestion by Tero (which was to do the initial IKE SA establishment as normal, and then stir in the PPK into the IPsec KEYMAT generation process); this makes it much simpler than trying to exchange identities before doing the initial key derivation.  We did add a modification to how the child SA SKEYSEED was computed (by stirring in the PPK there as well); the advantage of this is that this means that any child IKE SAs were also quantum resistant.  This implies that an implementation that did insist on protecting the IKE traffic could immediately generate a child SA after negotiation, and then use that child SA to do all the real negotiation.  We thought that this flexibility justified the extra complication of modifying the SKEYSEED computation.  Such an implementation would leak the identities to a Quantum adversary, but everything else would be protected.

Here is how the draft scores against the given criteria:

- Simplicity; it is fairly simple
- Preserving existing IKE security properties?  It preserves all IKE security properties against an adversary with a conventional computer 
- What is protected from someone with a Quantum Computer?  It protects the IPsec traffic; it also allows an implementation (with more exchanges) to protect the IKE traffic (apart from the identities)
- What level of identity protection do we need to provide?  This doesn't provide any identity protection against someone with a Quantum Computer
-  PPK management; not addressed
- How much support do we provide for nonstatic secrets?  Not addressed, however it would not be difficult to add in the future.
- Authentication; can an attacker with Quantum Computer act as a man-in-the-middle?  No, not if both sides have PPK mandatory
- Algorithm agility; yes, the only algorithms used are the ones negotiated

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 Oct 2016 12:15:49 -0400

Scott Fluhrer (sfluhrer) <[email-masked]> wrote:
    > - What level of identity protection do we need to provide?  If two
    > different IKE negotiations use the same shared secret, do we mind if
    > someone can deduce that?

I think that this depends greatly upon the deployment scenario.

    > - Authentication; if someone with a Quantum Computer can break the DH
    > in real time, do we care if he can act as a man-in-the-middle?  Scott
    > Fluhrer: not important Michael Richardson: important, provided that we
    > don't run into the same issues that IKEv1 PSKs ran into Tommy Pauly:
    > not important Valery Smylsov: this would be nice to have Oscar
    > Garcia-Morchon: this would be nice to have

I'm very concerned that we don't wind up with insecure Group PSKs as we had
with IKEv1.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 31 Oct 2016 17:20:30 +0200

> I'm very concerned that we don't wind up with insecure Group PSKs as we had

As this document is written (or how I think it is written, as I have
not yet had time to read the latest version), the PPK used to provide
to quantum resistance is not used in the authentication, there is
still normal IKEv2 authentication step using normal IKEv2 shared
secret, or certificates. So even if the people would be using group
PPK, that would not allow similar issues than what happend with IKEv1.

Of course everybody sharing the same PPK will be able to attack other
users of the same group by just breaking the Diffie-Hellman :-)

On the other hand even if you know the PPK, you cannot do anything
without breaking the Diffie-Hellman, as it does not allow you do to
man-in-the-middle without breaking the normal authentication.

So, yes, there is some dangerous things that can happen, but I do not
think it will be reducing IKEv2 security even if such insecure
practices are used (except than it will reduce the quantum resistance
provided by PPK, if everybody knows PPK). 
-- 
[email-masked]

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 31 Oct 2016 16:50:43 +0000

> -----Original Message-----
> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Monday, October 31, 2016 11:20 AM
> To: Michael Richardson
> Cc: Scott Fluhrer (sfluhrer); IPsecme WG ([email-masked])
> Subject: Re: [IPsec] FW: Quantum Resistance Requirements
> 
> > I'm very concerned that we don't wind up with insecure Group PSKs as
> > we had with IKEv1.
> 
> As this document is written (or how I think it is written, as I have not yet had
> time to read the latest version), the PPK used to provide to quantum
> resistance is not used in the authentication, there is still normal IKEv2
> authentication step using normal IKEv2 shared secret, or certificates. So even
> if the people would be using group PPK, that would not allow similar issues
> than what happend with IKEv1.

That is correct; we do not replace the existing privacy and authentication features; instead, we supplement them by adding the PPK; this PPK is designed to add Quantum Resistance; however at the worse (e.g. you use the 'MakeMeTastyGoat' PPK), you still have the privacy/authentication security found that IKE provides.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Oct 2016 14:24:33 -0400

Scott Fluhrer (sfluhrer) <[email-masked]> wrote:
    >> Michael Richardson writes: > > - Authentication; if someone with a
    >> Quantum Computer can break the DH > > in real time, do we care if he
    >> can act as a man-in-the-middle?  Scott > > Fluhrer: not important
    >> Michael Richardson: important, provided that we > > don't run into the
    >> same issues that IKEv1 PSKs ran into Tommy Pauly: > > not important
    >> Valery Smylsov: this would be nice to have Oscar > > Garcia-Morchon:
    >> this would be nice to have
    >> >

    > That is correct; we do not replace the existing privacy and
    > authentication features; instead, we supplement them by adding the PPK;
    > this PPK is designed to add Quantum Resistance; however at the worse
    > (e.g. you use the 'MakeMeTastyGoat' PPK), you still have the
    > privacy/authentication security found that IKE provides.

Thank you for this clarification.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Garcia Morchon O, Oscar" <[email-masked]>
Date: Tue, 1 Nov 2016 01:28:46 +0000

> I'm very concerned that we don't wind up with insecure Group PSKs as

This description does not reduce IKEv2 security - the PPK is used next to IKEv2 security.
Furthermore, the description can also support pairwise keys.

I had a look at the description, and a later addition of a scheme such as HIMMO is straightforward and such scheme can generate all those pairwise keys very easily.
Instead of exchanging a PPK identity, you exchange the HIMMO identity that is used to generate the pairwise PPKs.
Since the generated keys depend on the exchanged identities, the scheme could also provide authentication.
The communication overhead is very small (a few tens of bytes).

-----Original Message-----
From: IPsec [mailto:[email-masked]] On Behalf Of Tero Kivinen
Sent: Monday, October 31, 2016 11:21 AM
To: Michael Richardson
Cc: IPsecme WG ([email-masked]); Scott Fluhrer (sfluhrer)
Subject: Re: [IPsec] FW: Quantum Resistance Requirements

> I'm very concerned that we don't wind up with insecure Group PSKs as

As this document is written (or how I think it is written, as I have not yet had time to read the latest version), the PPK used to provide to quantum resistance is not used in the authentication, there is still normal IKEv2 authentication step using normal IKEv2 shared secret, or certificates. So even if the people would be using group PPK, that would not allow similar issues than what happend with IKEv1.

Of course everybody sharing the same PPK will be able to attack other users of the same group by just breaking the Diffie-Hellman :-)

On the other hand even if you know the PPK, you cannot do anything without breaking the Diffie-Hellman, as it does not allow you do to man-in-the-middle without breaking the normal authentication.

So, yes, there is some dangerous things that can happen, but I do not think it will be reducing IKEv2 security even if such insecure practices are used (except than it will reduce the quantum resistance provided by PPK, if everybody knows PPK).
--
[email-masked]

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.