Subject: Re: [IPsec] FW: Quantum Resistance Requirements

From: Valery Smyslov <[email-masked]>
Date: Mon, 14 Nov 2016 21:52:40 +0900

Hi Scott,

after reading the draft I have one question. The draft redefines both
KEYMAT and SKEYSEED for IKE SA rekey derivations for the case
when PPK is used. Did you consider variant when only SK_d derivation
is modified? Something like this:

No modification to SK_* calculation, SKEYSEED calculation and KEYMAT calculation.
However, for the PPK use case define SK_d`, that must be used instead of SK_d,
so that SK_d’ = prf+(SK_d, Ni’ | Nr’), where Ni’ = prf(PPK, Ni), Nr’ = prf(PPK, Nr).

This is an ad hoc construction, probably it can be improved, but the idea is clear:
Introduce a single point (SK_d’ derivation) where modifications to keys derivation algorithm
take place, instead of two points. It will make implementations modification easier, I think.

So, did you consider such variant? Are there any security disadvantages?

Regards,
Valery Smyslov.

From: Scott Fluhrer (sfluhrer)
Sent: 28 октября 2016 г. 23:25
To: IPsecme WG ([email-masked])
Subject: [IPsec] FW: Quantum Resistance Requirements

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

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

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 14 Nov 2016 14:07:13 +0000

No, we didn’t consider modifying things there.

The main reason we wouldn’t have considered that is a possible complication to crypto hardware; if we assume that we had hardware that did most of the crypto calculations internally, it might keep the SK_d value internally, and might not give us an easy way to modify it.  In contrast, the nonces are inputs to the hardware, and so that hardware is agnostic to whether we’re actually giving it the nonces that actually appeared in the packets, or whether we’re giving them modified versions of it.

I don’t expect there to be any security disadvantage; the differences would be entirely practical.

From: Valery Smyslov [mailto:[email-masked]]
Sent: Monday, November 14, 2016 7:53 AM
To: Scott Fluhrer (sfluhrer); IPsecme WG ([email-masked])
Subject: RE: [IPsec] FW: Quantum Resistance Requirements

Hi Scott,

Regards,
Valery Smyslov.

From: Scott Fluhrer (sfluhrer)<mailto:[email-masked]>
Sent: 28 октября 2016 г. 23:25
To: IPsecme WG ([email-masked])<mailto:[email-masked]>
Subject: [IPsec] FW: Quantum Resistance Requirements

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

---

From: Valery Smyslov <[email-masked]>
Date: Tue, 15 Nov 2016 06:50:08 +0900

That’s a double fold problem. You are changing nonces using PPK and
it seems that for HSM the PPK operations should also be done in hardware, shouldn’t them?
In this case it’s a bit unfair to say you keeps current hardware intact
(well, I think that different configurations are possible and I think
In some cases your considerations make sense).

However, if you need to modify hardware in any case, then my proposal looks
a bit simpler – you have a single point in the IKE key derivation
logic that needs modification (and the same is true for software).

From: Scott Fluhrer (sfluhrer)
Sent: 14 ноября 2016 г. 23:07
To: Valery Smyslov; IPsecme WG ([email-masked])
Subject: RE: [IPsec] FW: Quantum Resistance Requirements

Hi Scott,

Regards,
Valery Smyslov.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 15 Nov 2016 03:56:03 +0200

Scott Fluhrer (sfluhrer) writes:
> The main reason we wouldn’t have considered that is a possible
> complication to crypto hardware; if we assume that we had hardware
> that did most of the crypto calculations internally, it might keep
> the SK_d value internally, and might not give us an easy way to
> modify it. In contrast, the nonces are inputs to the hardware, and
> so that hardware is agnostic to whether we’re actually giving it the
> nonces that actually appeared in the packets, or whether we’re
> giving them modified versions of it.

One of the issues of using Ni' = PRF(PPK, Ni) instead of modifying the
SK_d calculation is that the system needs to keep the PPK in memory
permanently. I.e., if we only modify the SK_d calculation, i.e.,
define

SK_d' = PRF(PPK, SK_d)

or something like that, then we can clear the PPK in memory
immediately after that point, and we can drop permissions that allows
us access to PPK.

This will provide better security as attacks similar to the heartbleed
cannot read PPK from the memory.

Also it is clear that even if PPK is changed during the lifetime of
the IKE SA we do not enter the issue that whether we need to use old
or new PPK. Especially if some kind of HSM is used to keep PPK, it
might not allow access the old PPKs after they are expired.

I think the PPK is so important that when you are adding support for
the QR to your implementation you want to move the PPK handing in to
the hardware crypto module so PPK will be protected, and not add it as
addon to the crypto module.
-- 
[email-masked]