Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME WG document

From: David McGrew <[email-masked]>
Date: Fri, 1 Jul 2016 08:34:05 -0400

Hi Dave,

> On Jun 28, 2016, at 2:12 PM, Waltermire, David A. (Fed) <[email-masked]> wrote:
> 
> This has been a good discussion so far. There is work to be done to address the issues raised.
> 
> Getting back to the call for adoption, I'd like to see feedback on the following questions to better understand where consensus is on this issue.
> 

thanks for framing the questions; let me chime in with some specific responses, speaking as a WG member.  

> 1) Previous WG discussions have indicated interest in this problem. Does the working group think that there is a problem here that we need to address?

Yes; the problem is that IKEv2 does not have the same postquantum security as IKEv1.  This is an immediate practical need, because the difference between versions has motivated some users to have a preference for the obsolete version, and on the flip side, users of the current version cannot benefit from postquantum security of preshared keys.  

> 2) Should we do this work in the IPsecME working group? If not, where?

Yes, the problem being addressed is an important one for the IKEv2 standard, and the solution should be broadly available to the IPSec community.  

> 3) Can we use draft-fluhrer-qr-ikev2 as a starting point for developing a WG solution to this problem? If not, what is a suitable starting point instead?
> 

Yes; that draft is a good starting point.  The goal should be to develop an RFC that updates RFC 7383 and specifies how Postquantum Preshared Keys (PPKs) can be used, in a manner that is operationally similar to IKE preshared keys, to achieve postquantum security.   The WG should decide whether identity protection is needed, or whether it can be traded for simplicity.

Other approaches, such as QKD or using a long stream of shared secret key material obtained from an arbitrary source, should be addressed through separate documents, because they are not needed to address the above problem, and because they do not meet the requirement of operational similarity with current practice.   A sequence of key material intended for one-time use is not the same as a PPK, and the logic needed to handle indexing and sequencing should not be imposed on the RFC that addresses the immediate need.   

Going a little further off topic, with any technology (like QKD or a one-time pad) that is predicated on the idea that computational cryptography cannot be fully trusted, there should be a detailed security analysis of how it is integrated into IPsec/IKE, which shows how to use the technology along with other IPSec mechanisms in a way that is consistent with its security assumptions.   In short, the usage of technologies that are only interesting in scenarios that include major advances in cryptanalysis should be specifically crafted to minimize the risk of those advances.  No such analysis has yet been put forward.  The analysis of key renewal rates in the SECOQC White Paper on Quantum Key Distribution and Cryptography [Section 3.2 of http://www.secoqc.net/downloads/secoqc_crypto_wp.pdf], for instance, neglects to consider the risk of a key collision attack, and does not attempt any formal/provable security framework.   The IPSec WG should expect this analysis before any standards are developed that support these new technologies, and those standards should clearly state what advantages the new technologies have, and in what scenarios they should be used, and what sort of other IPSec algorithms and options are consistent with good security.    Please note that I am not objecting to the IPSec WG taking up this work; I am pointing out that there is a lot of work involved, which underscores the importance of dealing with it in a way that is separate from the immediate need of parity between IKE versions.

best,

David

> Regards,
> Dave
> 
>> -----Original Message-----
>> From: Scott Fluhrer (sfluhrer) [mailto:[email-masked]]
>> Sent: Friday, June 24, 2016 11:26 AM
>> To: [email-masked]; David McGrew <[email-masked]>
>> Cc: Waltermire, David A. (Fed) <[email-masked]>; IPsecME WG
>> <[email-masked]>; Panos Kampanakis (pkampana) <[email-masked]>
>> Subject: RE: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME
>> WG document
>> 
>> 
>>> -----Original Message-----
>>> From: Paul Wouters [mailto:[email-masked]]
>>> Sent: Friday, June 24, 2016 9:43 AM
>>> To: David McGrew (mcgrew)
>>> Cc: Waltermire, David A. (Fed); IPsecME WG; Scott Fluhrer (sfluhrer);
>>> Panos Kampanakis (pkampana)
>>> Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an
>>> IPSecME WG document
>>> 
>>> On Fri, 24 Jun 2016, David McGrew wrote:
>>> 
>>> Hi David,
>>> 
>>>> Because QKD is not a practical system for Internet security.   It has serious
>>> security issues/challenges and operational limitations on bitrate, range, and
>>> physical media.   It requires a point to point optical link, which is typically
>>> dedicated fiber, which must be shorter than 60 miles.  There are
>>> security issues with QKD because it relies on a physical interaction
>>> across the line between the encrypter and decrypter, thus giving an
>>> attacker the opportunity to perform an attack on the physical process
>> anywhere on that
>>> line.   See for instance Brassard et. al. Security Aspects of Practical Quantum
>>> Cryptography, Lydersen et. al., Hacking commercial quantum
>>> cryptography systems by tailored bright illumination, or Gerhardt et.
>>> al., Full-field implementation of a perfect eavesdropper on a quantum
>> cryptography
>>> system.   Another major security problem is the range limitation; it has
>> been
>>> proposed to extend the range of QKD by using a chain of trusted
>>> repeaters, each connected by a QKD sy  stem.  These repeaters would
>>> greatly increase the attack surface, and require the end user to trust
>>> the infrastructure provider(s); in contrast, the Internet community
>>> wants end to end encryption, as described in RFC3365 and RFC7624.
>>>> 
>>>> In contrast, QR-IKEv2 can be used to add postquantum security
>>>> between
>>> any two points on the globe, without requiring dedicated fiber, and
>> without
>>> requiring physical layer security assumptions.   It has *fewer* security
>>> assumptions than draft-nagayama-ipsecme-ipsec-with-qkd, as that draft
>>> relies on the security of symmetric cryptography and the physical
>>> layer, whereas QR-IKEv2 relies only on the former.
>>> 
>>> For a postquantum IKEv2 extension, does it matter which underlying
>>> mechanism is used to provide the extra bits to mix into the SKEYSEED?
>>> 
>>> I think what is needed is:
>>> 
>>> - A NOTIFY message that signals an identifier of where the extra bits
>>>   should be taken/generated from. Both endpoints have previous
>>> knowledge
>>>   of what tjos identifier refers to. Be it a hardware device or an
>>>   offset in a onetime pad, etc, etc.
>> 
>> One possible concern is whether such a notify message would compromise
>> the anonymity properties of IKE; if someone in the middle sees the same
>> identifier in multiple exchanges, would they be able to conclude that those
>> are the same individuals negotiating?  If the NOTIFY messages are
>> anonymized, how is that done?
>> 
>> Now, it might be that the WG would decide to compromise on such
>> anonymization concerns; this would simplify things a lot, however it's very
>> much something we need WG agreement on.
>> 
>>> 
>>> - A specification on how to mix in these extra bits into SKEYSEED generation
>>>   to gain postquantum security.
>> 
>> The reason we specify modifying the public nonces (rather than doing a more
>> fundamental change to the skeyseed computation) was to minimize changes
>> to the IKE implementation itself (and in particular, the crypto parts).  Is there
>> a reason why we wouldn't continue with this approach?
>> 
>>> 
>>> - Any additional counter meassures (such as increased minimum
>>> keysizes)
>> 
>> And what algorithms are suggested (e.g. XCBC and CMAC both don't work, as
>> the standard IKE versions are fixed to 128 bit keys)
>> 
>>> 
>>> Do we need to know if these bits came from a QKD link, a QR link, or a
>>> mutually shared onetime pad? If not, then these specifics should not
>>> go into such an ikev2 extension.
>>> 
>>> Paul

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 1 Jul 2016 17:53:45 +0300

[This replies to emails other people also sent to list, but I just
picked the last email to list some points, and I am talking here as an
implementor not as a chair].

David McGrew writes:
> Yes; that draft is a good starting point.  The goal should be to
> develop an RFC that updates RFC 7383 and specifies how Postquantum
> Preshared Keys (PPKs) can be used, in a manner that is operationally
> similar to IKE preshared keys, to achieve postquantum security.
> The WG should decide whether identity protection is needed, or
> whether it can be traded for simplicity.

One note you should remember that IKEv1 does not have any identity
protection when using shared keys with main mode. The responder MUST
know from the IP address alone who the other end is, thus the whole
world will know that this identity is same identity than the last one
coming from the same IP...

I.e. as the shared key is used to derive the encryption key for the
IKE message protecting the ID payload you need to know the shared key
before you can decrypt the message containing ID to find who the other
is, thus the ID you get is useless for you as you must have already
picked up one shared key before getting that far.

People who say that IKEv1 is quantum computing resistant because it
does exactly this (i.e. the pre shared key is used to derive keys)
clearly do not care about identity protection.

Because of that I think the limited identity protection should be ok,
i.e., identity protection for the initiator can be broken by active
attacker (like in IKEv2 now), and it should be ok even if it broken
for both parties if Diffie-Hellman done in the IKE is broken.

The identity protection against the responder has always been bit
vague, as normally responders identity is always known because he has
fixed ip-address or that ip-address is advertised somewhere etc.

We had long discussions about these when we were doing IKEv2, and we
ended up with the current compromise, i.e. IKEv2 identity protection
protects identities against passive attacker provided attacker cannot
break Diffie-Hellman, but does not protect identity protection against
active attacker.

Also note that the way shared keys were used in the IKEv1 also caused
the fact that main mode with pre shared keys cannot really be used for
mobile users, or devices coming from behind nat, etc. This has really
limited the identity protection offered by IKEv1 in real use as users
use aggressive mode which do not have identity protection at all.

Also even if the IP-numbers are static it caused all kind of wierd
errors, as mistyped shared key caused decryption errors in the IKE
packet handling, causing the detecting such situation hard (usually
when you have decryption error you simply silently ignore the message,
but for authentication failures, it would be nicer to return the error
saying authentication failed so the user experience would be better,
IKEv1 cannot do that).

Because of this I think it is better to just stick with the current
identity protection method, i.e., do not derive IKE SA encryption keys
from the shared secret, i.e., active attacker can still get the IDi...

> Other approaches, such as QKD or using a long stream of shared
> secret key material obtained from an arbitrary source, should be
> addressed through separate documents, because they are not needed to
> address the above problem, and because they do not meet the
> requirement of operational similarity with current practice.   A
> sequence of key material intended for one-time use is not the same
> as a PPK, and the logic needed to handle indexing and sequencing
> should not be imposed on the RFC that addresses the immediate need.

Earlier I have proposed very simple method where the IKE_SA_INIT
contains just some kind of notification messages identifying the
"oob-key" to be use. This identification information is completely
opaque, and fully depends on the implementation.

It could be fixed random string, which would immediately leak out the
identity of the users, just like IKEv1 IP-address did. It could just
random identifier, which identifies the one-time-use shared secret
from big table (which is shared between the end nodes), it could be
some kind of encrypted blob, which is encrypted with some kind of
system wide group shared key (i.e., everybody in the group know it,
but outsiders do not, so it protects identities for outsiders, but not
for insiders), or it could be something more complicated like what
current draft proposes.

For the IKEv2 protocol point of view it is just opaque binary object
which is given to the subsystem which will then return a shared key to
be used for him.

In all cases both ends must share the same shared key or table of
shared keys or access to the QKD subsystem, so this code that knows
how this blob is interpreted can be left to the implementations. We do
not need to standardize it, we can leave it open, just like we leave
cookie or the IKEv2 session resumption ticket format. We could include
some proposals in the appendix, and we might want to add 16-bit
"format identifier" in the beginning just in case people want mix
multiple methods in same implementations.

This means that the level of shared key identity protection is left to
implementation and to it depends on the policy settings.

When IKEv2 then has the shared secret then it needs to mix that to
some parts of the cryptographic protection to provide quantum
resistant IKEv2.

There are multiple levels on that:

1) Include it only in KEYMAT. This will protect all IPsec SAs, i.e.
   the actual traffic transmitted over IPsec is protected from
   attackers able to break the Diffie-Hellman of the IKEv2. I.e.,
   replace SK_d in there with (SK_d | OOB_secret). Note, this have
   also the side effect that after the first IKEv2 rekey also the
   IKEv2 SA traffic is protected, as new keying material after the
   IKEv2 rekey depends on the SK_d.

2) In addition to the 1, include it also in the SK_pi and SK_pr. This
   will mean that even if the attacker is able to break Diffie-Hellman
   and the Signature method, he will not be able to authenticate as
   user, as he cannot calculate the MACedIDforI/MACedIDforR for
   authentication. I.e. replace SK_pi and SK_pr with (SK_pi |
   OOB_secret) and (SK_pr | OOB_secret). 

3) Include it in the SKEYSEED calculation. This will has the side
   effect that we are no longer able to get meaningfull error messages
   in case something goes wrong in the OOB key identification process,
   i.e., in case the OOB_secrets do not matchi, we just drop the frame
   and wait for next one, thus we cause timeout if OOB_secret is
   wrong. This is bad for user experience, but this will also protect
   the IKEv2 SA traffic with the OOB_secret.

And, no please do not propose that we make this negotiated... Lets
pick one and use it. I am in favor of 2, because it offers most, but
does not cause problems. And if someone wants to protect traffic
selectors and future traffic in IKEv2, they can simply do IKE_SA_INIT
+ IKE_AUTH with childless initiation, and then immediately do IKE SA
rekey, and then CREATE_CHILD_SA to create Child SAs. 

> Going a little further off topic, with any technology (like QKD or a
> one-time pad) that is predicated on the idea that computational
> cryptography cannot be fully trusted, there should be a detailed
> security analysis of how it is integrated into IPsec/IKE, which
> shows how to use the technology along with other IPSec mechanisms in
> a way that is consistent with its security assumptions. In short,
> the usage of technologies that are only interesting in scenarios
> that include major advances in cryptanalysis should be specifically
> crafted to minimize the risk of those advances. No such analysis has
> yet been put forward. The analysis of key renewal rates in the
> SECOQC White Paper on Quantum Key Distribution and Cryptography
> [Section 3.2 of
> http://www.secoqc.net/downloads/secoqc_crypto_wp.pdf], for instance,
> neglects to consider the risk of a key collision attack, and does
> not attempt any formal/provable security framework. The IPSec WG
> should expect this analysis before any standards are developed that
> support these new technologies, and those standards should clearly
> state what advantages the new technologies have, and in what
> scenarios they should be used, and what sort of other IPSec
> algorithms and options are consistent with good security. Please
> note that I am not objecting to the IPSec WG taking up this work; I
> am pointing out that there is a lot of work involved, which
> underscores the importance of dealing with it in a way that is
> separate from the immediate need of parity between IKE versions.

I do not think that is reasonable for the IPsecME WG. We do not have
security analysis on the use of ChaCha20/Poly1305 on IPsec/IKE. We do
not have security analysis on most of the other things either.

We should simply provide requirements for the OOB_secret provided by
the subsystem and that should be enough. I.e., it should be enough to
say that OOB_secret MUST be longer than 16 octets, and MUST NOT be
longer than 64 octets, and to provide protection against attackers
able to break Diffe-Hellman in IKEv2 it must be something that
attackers cannot guess or know...

That should be enough to make it secure for IKEv2 use. That was one of
the reasons why I was so much against the QKD draft originally getting
rid of the whole Diffie-Hellman in IKEv2, and only using the
OOB_secret. I want the failure model of the OOB_secret to be so that
the IKEv2 still as safe as it is now (yes, there might be some leak on
the ID part in the OOB key identification process, but the IPsec
traffic is still safe).

Anyways, either one of those draft is good starting point for this
work. It does not really matter which one we pick, we then just need
to change it to what WG things is approriate for this protocol (i.e.,
which compromizes we take, and which we do not take).

Ps. And now back to my vacation, so I most likely will not reply back
until I get back from my last week of vacation.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 5 Jul 2016 12:16:10 +0300

Hi Tero,

I think it is a bit early to discuss particular approaches,
before the WG makes a decision to adopt the document.

However, just for the record (see below).

>   the IKEv2 SA traffic with the OOB_secret.

Not necessary. In particular, the current draft allows to detect 
OOB key mismatch and to act gracefully in this situation.
And I don't think it is far too complicated.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 5 Jul 2016 12:20:02 +0300

Hi,

> problem here that we need to address?

Yes.

> 2) Should we do this work in the IPsecME working group? If not, where?

Here.

> a suitable starting point instead?

We can.

Regards,
Valery.

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 5 Jul 2016 15:44:11 +0300

[chair hat off]

> before the WG makes a decision to adopt the document.

Yes and no.

It is too early to think about actual protocol decisions, but we need
to know whether current draft is suitable for protocol selections we
are going to be doing, and we need to think about what kind of
compromizes we want to do.

I.e., I think it is important to think even in this phase, whether we
care about the identity hiding against passive attackers who can break
Diffie-Hellman or not. And do we care about identity protection
against active attackers. If we do want to protect against one of
those kinds of attackers, our solutions are going to be more
complicated.

If we do not care (i.e., keep the current level of protection in IKEv2
meaning no identity protection against active attackers or attackers
who can break Diffie-Hellman) then our solutions are simplier.

These requirements and compromizes are the important things we need to
decide on the WG before we can make decisions on the actual protocol
solutions. 

> And I don't think it is far too complicated.

Current draft does, but there has been other proposals which did not.

The current draft is also very costly and allows very easy denial of
service attacks, as responder needs to linear search of all possible
configured PPKs. If we for example use some kind of one time password
system, where each user has 1000 pre-distributed PPKs and we have 1000
users, responder needs to do million operations every time someone
sends him a packet or same thing if we have million users configured
and each have one PPK. Thats why I do not like the current approach
and I think trying to hide the identity for the active attacker is
just opening other attacks which are worse than the attack where
attactive attacker can learn the ID of the initiator...

Anyways I think we should work on this problem, and I think we do want
to think about the requirements for the solution we are going to do
before we can start writing actual protocol specification. And the
protocol specification can be based on either one of the drafts, there
is not that big difference in them, and depending on the requirements
things needs to be added or removed from the drafts.
-- 
[email-masked]

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 5 Jul 2016 13:06:59 +0000

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Tuesday, July 05, 2016 8:44 AM
> To: Valery Smyslov
> Cc: David McGrew (mcgrew); IPsecME WG; Scott Fluhrer (sfluhrer);
> [email-masked]; Waltermire, David A. (Fed); Panos Kampanakis (pkampana)
> Subject: Re: [IPsec] Call for adoption on draft-fluhrer-qr-ikev2 as an IPSecME
> WG document
> 
> [chair hat off]
> 
> Valery Smyslov writes:
> > I think it is a bit early to discuss particular approaches, before the
> > WG makes a decision to adopt the document.
> 
> Yes and no.
> 
> It is too early to think about actual protocol decisions, but we need to know
> whether current draft is suitable for protocol selections we are going to be
> doing, and we need to think about what kind of compromizes we want to do.
> 
> I.e., I think it is important to think even in this phase, whether we care about
> the identity hiding against passive attackers who can break Diffie-Hellman or
> not. And do we care about identity protection against active attackers. If we
> do want to protect against one of those kinds of attackers, our solutions are
> going to be more complicated.
> 
> If we do not care (i.e., keep the current level of protection in IKEv2 meaning
> no identity protection against active attackers or attackers who can break
> Diffie-Hellman) then our solutions are simplier.
> 
> > Not necessary. In particular, the current draft allows to detect OOB
> > key mismatch and to act gracefully in this situation.
> The current draft is also very costly and allows very easy denial of service
> attacks, as responder needs to linear search of all possible configured PPKs. If
> we for example use some kind of one time password system, where each
> user has 1000 pre-distributed PPKs and we have 1000 users, responder
> needs to do million operations every time someone sends him a packet or
> same thing if we have million users configured and each have one PPK.

Actually, the current draft allows the responder to make a trade-off between identity protection and cost of lookup.

In the exchange, the responder selects a "PPK Indicator Input" and the initiator responds with a value that's a function of the PPK and the PPK Indicator input that the responder selected.  If the responder always selects a random PPK Indicator Input, you get identity hiding (at the cost of having the responder doing the search).  If the responder always selects a fixed value, then the initiator's response is a fixed function of the PPK (and so the responder can precompute all the PPK's he knows about, and then do a simple lookup at negotiation time), you get a fast negotiation (at the cost of identity hiding).

> Thats
> why I do not like the current approach and I think trying to hide the identity
> for the active attacker is just opening other attacks which are worse than the
> attack where attactive attacker can learn the ID of the initiator...

Actually, the identity weakness would be a passive attacker being able to deduce whether two negotiations used the same PPK (and if they did, they're likely from the same entity).

> 
> Anyways I think we should work on this problem, and I think we do want to
> think about the requirements for the solution we are going to do before we
> can start writing actual protocol specification. And the protocol specification
> can be based on either one of the drafts, there is not that big difference in
> them, and depending on the requirements things needs to be added or
> removed from the drafts.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 5 Jul 2016 16:08:17 +0300

Hi, 

> and each have one PPK. 

Not exactly true. The current draft allows the responder to balance
between initiator's identity hiding and responder's load.
For example, it can choose to always give to initiators the same
PPK Indicator Input and precalculate the results for all the keys it has.
In this case there is no identity hiding, however it will take a log2(n)
to find the key (literally nothing with million keys).

In the other corner case the responder can behave as you described, 
providing full identity hiding at the cost of additional resource consumption.

And the responder can always choose a proper balance between 
these extreme cases, even dynamically.