Subject: [IPsec] draft-fluhrer-qr-ikev2-01

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Fri, 19 Feb 2016 22:03:39 +0000

Last year, NSA made an announcement about how to deal with the potentiality of someone developing a Quantum Computer; (https://www.nsa.gov/ia/programs/suiteb_cryptography/).  Among their recommendations was the advice that:

"CSfC deployments involving an IKE/IPsec layer may use RFC 2409-conformant implementations of the IKE standard (IKEv1) together with large, high-entropy, pre-shared keys and the AES-256 encryption algorithm. RFC 2409 is the only version of the IKE standard that leverages symmetric pre-shared keys in a manner that may achieve quantum resistant confidentiality.

The reason they gave this advise was the IKEv1, unlike IKEv2, stirred in the preshared key into the KDF function (along with the (EC)DH shared secret); hence if the preshared key was strong, then Shor's algorithm (which can recover the (EC)DH shared secret) is not enough to recover the negotiated keys.

Now, we don't want people to migrate back to an obsolete version of the protocol; hence we've devised a way to strengthen IKEv2 the same way.

It was considered important to minimize the changes made to IKEv2.  From a cryptographical prespective, the only change we make is that we modify the nonces that we present to the KDF.  By keeping the cryptographical changes minimal, we reduce the risk of accidentally introducing a weakness.

Like IKEv1, this solution assumes that the initiator and the responder share a secret string (called a PPK in the draft).  However, unlike IKEv1, that is not the only authentication that's in the system.  We leave the existing authentication methods in place, and add this in addition.

One thing that was a source of complexity was that we did not want to assume that every system had the same PPK; that instead that systems would want a pairwise PPK.  However, if a responder configured its PPK on a per-peer basis, and didn't learn the peer until after an IKEv2 tunnel has been established, that would mean that the responder would need to know the PPK before it officially learned the peer.  To solve this, we added the PPK_REQUEST/PPK_ENCODE notifications to give the responder a hint about which PPK to use (without leaking the identity to third parties).

Would anyone be willing to review this draft?  I believe that we have a need for such a solution.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 19 Feb 2016 19:21:29 -0500 (EST)

On Fri, 19 Feb 2016, Scott Fluhrer (sfluhrer) wrote:

> “CSfC deployments involving an IKE/IPsec layer may use RFC 2409-conformant implementations of the IKE standard (IKEv1) together with large, high-entropy, pre-shared keys and the AES-256
> encryption algorithm. RFC 2409 is the only version of the IKE standard that leverages symmetric pre-shared keys in a manner that may achieve quantum resistant confidentiality.
> 
> The reason they gave this advise was the IKEv1, unlike IKEv2, stirred in the preshared key into the KDF function (along with the (EC)DH shared secret); hence if the preshared key was
> strong, then Shor’s algorithm (which can recover the (EC)DH shared secret) is not enough to recover the negotiated keys.

> Now, we don’t want people to migrate back to an obsolete version of the protocol; hence we’ve devised a way to strengthen IKEv2 the same way.

> Would anyone be willing to review this draft?  I believe that we have a need for such a solution.

Yes, I am happy to review. I also think this might make a good topic to
discuss face to face at the next meeting.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 20 Feb 2016 11:12:01 +0300

Hi Scott,

thank you for issuing a new version of the draft that addresses most of my comments on -00 version.

However I still have some concerns. I'm not happy with the way algorithm agility support is added
into the draft. 

Currently the draft specifies PPK Indicator Algorithm as a 4 bytes long integer with a single
defined value of 1 (AES256_SHA256). This definition does imply the need for new
registry since more algorithms would be specified. I don't see any compelling reason to add a new registry,
since the existing registries can be reused. 

I'd propose the following way to support algorithm agility.

When the responder receives the initial request with PPK_REQUEST notification, it parses
SA payload collecting all PRF type transforms. The result is the list of PRFs the initiator
supports. The responder picks the most preferred PRF from the list and returns 
its value (as defined in the IKEv2 registry "Transform Type 2 - Pseudo-random Function Transform IDs") 
as PPK Indicator algorithm in PPK_ENCODE notification. The PPK indicator is computed
using this PRF as foolws:

ppk_indicator = PRF(PRF(ppk, "A"), ppk_indicator_input)

This proposal has the following advantages.
1. Reusing existing IKEv2 registry
2. Better interoperability, since the PRF transform is mandatory in the SA payload
    in IKEv2 and the responder can always be sure that the chosen PRF is supported
    by the initiator. With the current proposal the situation is possible when 
    the initiator includes, for example, only AEAD transforms in SA payload.
    In this case even AEAD transform is (for example) AES based, there is no guarantee
    that plain AES encryption is also supported by the initiator.
3. The current PPK Indicator Algorithm field combines 2 algorithms - encryption
    and prf. Once more algorithms are supported as PPK indicator the size
    of the registry will be grown quickly since every new prf will be combined
    with every new cipher (yes, it can be limited by combining only
    selected prfs with only selected ciphers, but that would reduce interoperability).
    This would make the idea of precomputing ppk indicators on responder
    less efficient (you may easily precompute the whole ppk database using few
    popular PRFs, but if these PRFs are combined with ciphers - 
    the resulting number of their combinations could become too big).

I see the only disadvantage of this proposal. As you wrote you specifically
used combination of encryption and PRF since AES is supported in hardware 
on some CPUs and thus gives some performance advantages over PRF-only
scheme. I don't think it is a compelling argument. It reflects only the current
situation in the industry and may change over time. I don't think the protocol
should be based on such shaky grounds. Am I missing something?

Few editorial issues:

1. Abstract
    No point at the end of the abstract.

2. Section 1
   [The general idea is that we add an additional secret that is shared
   between the initiator and the responder; this secret is in addition
   to the authentication method that is already provided within IKEv2.]

    s/in addition/an addition ? 

3. IANA Considerations section is missing.

Regards,
Valery Smyslov.

  It was considered important to minimize the changes made to IKEv2.  >From a cryptographical prespective, the only change we make is that we modify the nonces that we present to the KDF.  By keeping the cryptographical changes minimal, we reduce the risk of accidentally introducing a weakness.

   

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

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

---

From: "Paul Hoffman" <[email-masked]>
Date: Sat, 20 Feb 2016 07:12:53 -0800

<no hat>

Your proposal of using heuristics from the SA payload instead of using a 
new registry seems like a bad tradeoff. It costs nothing to create a new 
registry. Further, the code that implementers need to write to use the 
new registered value is smaller *and more definitive* than the code 
needed to use your proposed heuristics.

As for your prediction that AES support might be removed from some CPUs 
in the future: that seems particularly unlikely. Basically, you never 
see CPU features removed from a product line. You sometimes see new 
families of low-end CPUs designed without all the features of current 
CPUs, but even that would not be a negative here. Further, if we need 
algorithms beyond AES in the future, it seems really likely that a 
competition for a replacement would favor one that could re-use the AES 
support in current chips.

I think a small registry for the (hopefully) few developers who care 
about QR a decade before anyone thinks there is any possibility of its 
use is a reasonable way forward.

--Paul Hoffman

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 20 Feb 2016 19:42:42 +0300

Hi Paul,

there is no heuristics in my proposal. The initiator's SA payload contains
all PRFs it supports. The responder can pick up any of them and be sure that
the chosen PRF is supported by initiator. It is a native negotiation mechanism of IKEv2.
And note that DDoS protection draft uses exactly the same mechanism.

And I never said that support for AES will be removed. I meant that there are
some alternatives for AES (like Chacha20), which are not supported in hardware.
Moreover, if (for example) SHA2 is supported in hardware tomorrow, then
there will be no perfirmance advantages in using AES.

What about the registries - I just follow Occam's razor principle.

Regards,
Valery.

-----Original Message----- 
From: Paul Hoffman
Date: 20 февраля 2016 г. 18:12
To: Valery Smyslov
Cc: [email-masked]
Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01

<no hat>

--Paul Hoffman

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Feb 2016 18:53:05 +0200

Scott Fluhrer (sfluhrer) writes:
> The reason they gave this advise was the IKEv1, unlike IKEv2,
> stirred in the preshared key into the KDF function (along with the
> (EC)DH shared secret); hence if the preshared key was strong, then
> Shor’s algorithm (which can recover the (EC)DH shared secret) is not
> enough to recover the negotiated keys.

The fact that IKEv1 stirred the preshared keys when generating the
keying material for the IKE SA encryption etc keys was the reason that
Main mode of the IKEv1 cannot be used in general case.

I.e. as in IKEv1 when using main mode and preshared keys the responder
needs to know the identity of the initiator based solely on the
IP-address, as it cannot decrypt the Identity payload before it knows
the pre shared keys.

This "feature" of the protocol is really bad, and we should not copy
anything like that to the IKEv2. 

> Now, we don’t want people to migrate back to an obsolete version of
> the protocol; hence we’ve devised a way to strengthen IKEv2 the same
> way.

Agree.

> It was considered important to minimize the changes made to IKEv2.
> From a cryptographical prespective, the only change we make is that
> we modify the nonces that we present to the KDF. By keeping the
> cryptographical changes minimal, we reduce the risk of accidentally
> introducing a weakness.

I think you are doing this wrong. There is no need to change the
SKEYSEED calculation. That only prototects the IKE SA encryption,
authentication keys. It would be much better to change the KEYMAT
calculation only, and keep the SKEYSEED calculation as it is now.

SKEYSEED is used to authenticate the other end and to attack that do
require online attacks done during the IKE SA lifetime. Even if the
attacker can break the encryption and MAC keys used for the IKE SA
that will leak out the actual traffic transmitted over the IPsec SA.
It does leak out the identities of the peers, but using active attacks
those are visible anyways.

To make IPsec quantum computing safe, i.e. so that saved IPsec SA
flows cannot be decrypted later when QC computers are available and
which can break Diffie-Hellman used now, we just need to add the
strong shared secret to the KEYMAT calculations.

I.e. in addition to the g^ir (new) and nonces, we can add the PPK
there:

KEYMAT = prf+(SK_d, PPK | Ni | Nr)

KEYMAT = prf+(SK_d, PPK | g^ir (new) | Ni | Nr)

This way even if the attacker stores all the IKE and IPsec flows, and
can then later break the DH used to protect the SKEYSEED, they will be
able to decrypt the IKE SA, but the actual traffic is still protected
as KEYMAT used to generate traffic keys contains PPK.

This also gets rid of the complicated PPK_REQUEST and PPK_ACK from the
IKE_SA_INIT.

In this case the initiator just needs to indicate which PPK it will be
using (especially with the OOB PPK keys there might be one-time pad of
them or they might be generated using some external method like
QKD).

As the identification of the PPK can be just random octet string which
interpretation is left to the implementation. Both end needs to have
same PPK anyways, so in addition the PPK they might have ID string for
it. The full exchange would be something like this:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SAi1, KEi, Ni  -->

                                <--  HDR, SAr1, KEr, Nr, [CERTREQ]

   HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,],
   	N(PPK_ID, x1), N(PPK_ID, x2), ...,
        AUTH, SAi2, TSi, TSr}  -->

                                <--  HDR, SK {IDr, [CERT,]
 				     	  N(PPK_ID, x1), AUTH, 
 					  SAr2, TSi, TSr}

SKEYSEED is calculated normally, but the based on the agreed PPK_ID
both ends fetch the real PPK to be used for the KEYMAT calculations.
Initiator can send multiple PPK_IDs, as there might be cases where
initiator and responder might be out of sync when using one time pad
keys, and responder replies with one PPK_ID which is the selected
PPK_ID.

As the contents of the PPK_ID is completely implementation dependent,
it might also contain some other structure, for example the initiator
might send largest offset in its one-time pad in PPK_ID, and responder
will pick any offset that is larger than that in response. Also as it
is not needed until the IPsec SA is created, there is no need to put
them in the unencrypted IKE_SA_INIT, we can put them in the IKE_AUTH
payload. 

The PPK is then fetched from database or whatever, and used in the
KEYMAT calculation as specified above.

The same PPK_ID payloads can be used also in the CREATE_CHILD_SA
exchanges in similar ways as we can do another Diffie-Hellman there.

I gave about same comments when we were checking this last time, i.e.
when we were talking about the
draft-nagayama-ipsecme-ipsec-with-qkd-01.txt draft.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Feb 2016 12:05:23 -0500 (EST)

> anything like that to the IKEv2.

It was solved in for instant the GSSAPI drafts, by sending the ID in
the first packet exchange, and mixing it into the SKEYSEED to avoid
MITM token/id passing. So it _can_ be done but it does reveal the
ID's in the clear unless this is done in an AUTH roundtrip to add
protection against passive attackers at the expense of one roundtrip.

> KEYMAT = prf+(SK_d, PPK | g^ir (new) | Ni | Nr)

So devil's advocate here. Haven't we just reduced all of IKE to a
convoluted one time pad scheme?

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 23 Feb 2016 20:10:19 +0200

> protection against passive attackers at the expense of one roundtrip.

Main mode of IKEv1 is supposed to protect identity. It is described in
the section 4.5 Identity Protection Exchange in the RFC 2408.

So anything which leaks out the identities in main mode is not really
main mode, but some other exchange. Don't remember what GSSAPI draft
did for the exchange type, i.e. did they have separate exchange type,
or did they reuse the number 2 Identity Protection...

IKEv2 the only exchange we have is something that will protect
identities for passive attackers.

> convoluted one time pad scheme?

Yes and no. If the method of getting the PPK based on the PPK_ID is an
offset to the one time pad, then yes, we are using one time pad to
generate keys, but it is not one time pad scheme, as we only use the
PPK to generate the keys for the encryption and the encryption is not
using one time pad.

If the PPK is for example just static 256-bit random shared secret
between peers, then there is no one time pad property there at all,
but the IPsec SA traffic is still protected against enemies using
quantum computer to break the Diffie-Hellman. Unless the enemy also
gets the PPK he will not be able to decrypt the IPsec SA traffic.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 23 Feb 2016 13:25:17 -0500 (EST)

> or did they reuse the number 2 Identity Protection...

The gssapi draft used the same private number as the XAUTH draft leading
to more alcohol consumption for implementors :)

> identities for passive attackers.

So we can send IDs in a dedicated IKE_AUTH round trip.

> Yes and no.

> gets the PPK he will not be able to decrypt the IPsec SA traffic.

If you have a static 256 bit random shared secret, why not use it
as PRF for KEYMAT and skip IKE altogether :P

Paul

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 23 Feb 2016 18:55:09 +0000

> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Tuesday, February 23, 2016 11:53 AM
> To: Scott Fluhrer (sfluhrer)
> Cc: IPsecme WG ([email-masked])
> Subject: [IPsec] draft-fluhrer-qr-ikev2-01
> 
> Scott Fluhrer (sfluhrer) writes:> 
> > From a cryptographical prespective, the only change we make is that we
> > modify the nonces that we present to the KDF. By keeping the
> I think you are doing this wrong. There is no need to change the SKEYSEED
> calculation. That only prototects the IKE SA encryption, authentication keys.
> It would be much better to change the KEYMAT calculation only, and keep
> the SKEYSEED calculation as it is now.

Why would it be much better?

By keeping SK_e, etc unprotected, you are allowing an attacker with a Quantum Computer to decrypt the IKE protocol traffic.  That means that he gets things like the traffic selectors.

That is a reduction in the security model that IKEv2 presents; yes, an active attacker can get the identities, but we can't get the rest of the IKEv2 traffic.  I would wonder if the WG would agree to that, given that there is an alternative that doesn't do that.

> This also gets rid of the complicated PPK_REQUEST and PPK_ACK from the

Is that the sole reason it is "much better"?  The notification exchange really isn't that hard...

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 24 Feb 2016 14:44:28 +0300

Hi Tero,

> those are visible anyways.

Only one party's identity is visible, not both. 
And active attacks are more complex and easier to detect.

> as KEYMAT used to generate traffic keys contains PPK.

I think this proposal is worse than presented in the draft.
It leaves information in the IKE SA vulnerable to QC-based attacks. 
Thus it completely eliminates the IKEv2 property of protecting
identities against passive attackers.  

Moreover, the way PPK is used in the draft is more clear and 
easier to implement. Note, that the only difference between the crypto
formulas from RFC7296 and the draft is that every use of Nx (where x = [ir]) 
is replaced with PRF(PPK | Nx). It is simple and modular from 
implementer's point of view. Moreover, in this case the PPK is used as the key
for PRF, while in your proposal the PPK is used as additional data
fetched into PRF. Using secret material (PPK) as a data is always a pain
for the products that maintain "security core", while using secret as a key 
is simple and natural.

> This also gets rid of the complicated PPK_REQUEST and PPK_ACK from the

I don't think it's prohibitevly complex.

Regards,
Valery.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Feb 2016 09:27:47 -0500

I like Tero's approach.

> As the contents of the PPK_ID is completely implementation dependent, it
> might also contain some other structure, for example the initiator might
> send largest offset in its one-time pad in PPK_ID, and responder will pick
> any offset that is larger than that in response. Also as it is not needed
> until the IPsec SA is created, there is no need to put them in the
> unencrypted IKE_SA_INIT, we can put them in the IKE_AUTH payload.

I was thinking that an offset into some *broadcasted* one-time pad would be
attractive if it permitted one to avoid pre-distribution of the pad, but as
long as the attacker can record that, and eventually break the encryption
protecting sending the offset, then it fails.

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

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 24 Feb 2016 20:26:27 +0200

> as PRF for KEYMAT and skip IKE altogether :P

That would generate same key for each IPsec SA, which would be really
bad especially if you are using any of the modern modes (GCM, CCM,
CTR).

Static traffic keys are bad. Static authentication keys are ok. Static
shared secret used to derive the traffic keys in such way that it will
be unique and allows rekeying traffic keys it also ok.

You do need at least nonce exchange in IKE to make sure keys are
different every time.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 24 Feb 2016 20:44:57 +0200

> Why would it be much better?

Simplier, and less error prone. No issues with fixed ciphers used in
negotiation. Keeps the IKE_SA_INIT smaller, which makes it better for
DoS attack protection. Makes error handling easier, as you can
actually decrypt the IKE_AUTH always and can see that something goes
wrong. One of the issues with IKEv1 with wrong pre shared keys was
that you decrypted the frame and got some garbage out, and you did not
know whether that was attacker, or wheter other end had wrong pre
shared key.

> By keeping SK_e, etc unprotected, you are allowing an attacker with
> a Quantum Computer to decrypt the IKE protocol traffic.  That means
> that he gets things like the traffic selectors.

Yes. On VPN uses this might actually matter, but in most likely it
does not matter even in there, as the traffic selectors is from one
IP-address assigned temporarely for that user to all other addresses,
i.e., they do not actually leak anything.

It would be bigger issue if it would actually leak the addresses used
in the traffic, but when using tunnel mode those addresses are still
protected.

For non-VPN cases, i.e., when using transport mode, traffic selectors
are visible from the IPsec frames anyways.

> That is a reduction in the security model that IKEv2 presents; yes,
> an active attacker can get the identities, but we can't get the rest
> of the IKEv2 traffic.  

Active attacker can also get the Traffic selectors the initiator
offers, he will also get the certificate used, and the CAs the
initiator has configured to.

> I would wonder if the WG would agree to that, given that there is an
> alternative that doesn't do that.

I think it is more useful to get this deployed than to get complicated
alternative that nobody implements.

Adding the PPK to the KEYMAT when generating IPsec SA keys from the
notify payload sent in the IKE_AUTH would be change that is only few
lines. In addition to that you need the code to fetch the PPK based on
the PPK_ID, and how complicated that is depends on the method you are
using. If you are using static PPK_ID and PPK, that is most likely
also very small change.

> > This also gets rid of the complicated PPK_REQUEST and PPK_ACK from
> > the IKE_SA_INIT.
> 

Yes. Simplicity makes things much better. I have checked your draft
few times, but usually noticed that there is some AES+SHA operations,
and even using algorithms which are not implemented on the IoT
devices. Actually just trying to understand what those AES+SHA
operations does, takes more time than I have now available, so I
cannot say whether the method works or not.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 24 Feb 2016 21:40:26 +0200

> And active attacks are more complex and easier to detect.

The responder identity is usually quite static, as responders
IP-address is usually static... If there are multiple responder IDs in
the same IP-address, then initiator usually needs to tell which one of
them he wants to connect using both IDi, and IDr in his IKE_AUTH
request, and in that case the active attacker do get both identities.

> It leaves information in the IKE SA vulnerable to QC-based attacks.

And what information do you think is there that is really worth of
protecting?

My understanding is that when there really are attackers using
QC-based attacks in real, we need to change the IKEv2 again, to make
the authentication methods also protected against QC-based attacks.

What we are solving now is the fact that someone can save all the
IKEv2 / IPsec traffic now, and when they do get the quantum computers,
they can break the Diffie-Hellman and then get the traffic keys used
to protect the IPsec traffic.

I.e. the saving of traffic happens now and breaking of the traffic
happens much later.

What information there are in the IKEv2 SA which is important to
protect for that kind of attacks?

> identities against passive attackers.

Yes. I think protecting the actual IPsec traffic is much more
important than protecting the identities, especially as they are
already vulnerable to the active attackers.

Detecting active attackers is easier, but I still assume that quite a
lot of implementations do retry silently if they do not get reply back
to the IKE_AUTH, i.e., there is no big alerts at that time warning
user that there might be active attacker on link, who just stole your
ID.

> implementer's point of view.

The draft had all kind of talks about AES and SHA256, so I just assume
that was there to confuse people and it is not needed?

> Moreover, in this case the PPK is used as the key for PRF, while in
> your proposal the PPK is used as additional data fetched into PRF.

The reason I used that is that cryptographers who designed the IKEv2
did that same thing with the share secret output from the
Diffie-Hellman, i.e., the g^ir. So I do assume that is safe, and if it
not then we need some proper cryptographer to tell me why not.

Also using the PPK as key to the PRF will limit the size of the PPK to
match you PRF key length. Using it as a data is supposed to be better
if I remember right why this method was selected for the IKEv2.

Anyways I am not cryptographer, I just assume that the people who are
and who said it is ok to do 

KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr)

know what they were doing.

> Using secret material (PPK) as a data is always a pain for the
> products that maintain "security core", while using secret as a key
> is simple and natural.

But this what we do in IKEv2 for all cases, also the SKEYSEED is
calculated in same way:

SKEYSEED = prf(Ni | Nr, g^ir)

I.e. the public values Ni and Nr are used as key, and the shared
secret g^ir is used as data.

If you think that is unsafe, I would like to get more information
about that, as that would mean that we need to change the
cryptographic protocol used in the IKEv2...
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 25 Feb 2016 10:38:13 +0300

Hi Tero,

> And what information do you think is there that is really worth of

If we are talking about the original IKEv2 as specified in the RFC 7296,
then there are not much sensitive data inside the IKE SA - mostly identities,
traffic selectors and configuration attributes (althouth I think all these items 
must still receive due protection).

However, I've been always thinking that IKE SA can be used as a transport 
for low volume data (for example using Transaction exchange). I'm sure there are 
propriatory extensions out there and I wonder why nobody try to standardize it yet.

There is also a draft describing IKEv2 based protocol for group key 
management (draft-yeung-g-ikev2) and it does tramsmit sensitive
information (including session keys) inside IKE SA.

It is a pity if QC protection mechanism won't work for these IKEv2 variants
(as in your proposal).

> the authentication methods also protected against QC-based attacks.

Note, that the proposed solution also protects authentication
(since SK_px are used in calculation of the AUTH payload content).

> protect for that kind of attacks?

See above. For some derivation of IKEv2 (like G-IKEv2)
there are a lot of sensitive information to protect.

> that was there to confuse people and it is not needed?

Please, re-read the draft. In the last version it is not tied with any
particular algorithms (AES, SHA256) and uses the negotiated 
PRF for SKEYSEED calculation.

> if I remember right why this method was selected for the IKEv2.

Most PRFs accept key of arbitrary length. And if some PRF
is defined with a fixed length key, that there will be a problem
with this PRF in IKEv2 anyway - with calculation of SKEYSEED,
where key is a concatenation of the nonces. That's why
an ugly hack for AES-XCBC-PRF-128 and AES-CMAC-PRF-128 
is included in the protocol.

> know what they were doing.

I'm not a cryptographer either, but I think that from cryptography
point of view your construction is sound. The problem resides
in implementation, not in mathematics. See below.

> cryptographic protocol used in the IKEv2...

I never meant that it is unsafe. I meant that sometimes it causes 
a headache for implementers when long-term secret is used
as a data in cryptographic formulas. Consider the situation when
you have a dedicated hardware (HSM, token) where long-term
secrets reside. Very often this hardware has an API that 
never allows the secrets to be exposed and allows them to be used 
only as keys in cryptographic primitives (i.e. you can encrypt
some data using these key). If you need to use these keys
as data in cryptographic primitives then you must either contact
the hardware manufacturer and ask him for a new API function
specific for your needs or to find some workarounds, that
are often based on undocumented features.

Note that g^xy is a different beast - it is not a long-term
secret, and usually APIs allow using session keys
as a data in key derivation functions. 

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 25 Feb 2016 14:43:17 +0200

Valery Smyslov writes:
> If we are talking about the original IKEv2 as specified in the RFC
> 7296, then there are not much sensitive data inside the IKE SA -
> mostly identities, traffic selectors and configuration attributes

And most of that information is derived from the configuration, which
is usually static for the host. I.e. initiator most likely always
offers same ID, traffic selectors and config attribute requests to
responder. I.e. most of this data do not need protection.

> (althouth I think all these items must still receive due
> protection).

They still will, but they will not receive full protection against the
QC based attacks.

Even when attackers have quantum computers, the attacks against the
Diffie-Hellman most likely still will require time, so are they
willing to use the machine to break Diffie-Hellmans of the QC
resistant IKEv2 SAs just to get that information, when they still
cannot get the actual traffic? 

> However, I've been always thinking that IKE SA can be used as a
> transport for low volume data (for example using Transaction
> exchange). I'm sure there are propriatory extensions out there and I
> wonder why nobody try to standardize it yet.

I think that is bad idea. IKEv2 is key exchange protocol. It is not
meant to be data transfer protocol. The message flow system is not
really suitable for the data transfers, for example the common window
size is 1, so you can have only one request outstanding, i.e. each
transfer takes full round trip before you can continue. Each request
requires ACK, and you can not combine multiple ACKs to different
requests to one reply. If you do make window size larger, the only way
to lower it again is to rekey IKE SA. There is no congestion control
for the IKE messages etc.

So do not use IKEv2 SA to transfer data. Use it only to things which
it is meant to, i.e., key exchange and key management.

If you want to transfer data, create IPsec SA, and run TCP (or UDP)
over it.

> information (including session keys) inside IKE SA.

That is not IKEv2, it is separate protocol using same framing than
IKEv2. It does not run on the same port than IKEv2 (500 vs 848).
Things we define for IKEv2 do not automatically transfer to that
anyways, thus if they want to use whatever method we define there,
they do require to specify how it affects their protocol. For example
they do not use IKE_AUTH exchange at all, they use GSA_AUTH exchange,
which have different payloads than IKE_AUTH has.

Also if they want to make that protocol QC resistant, they just need
to define new key download type. This can be done in multiple
different ways (either use PPK to encrypt the key transmitted, or use
PPK and the key transmitted to derive actual traffic keys etc). 

> It is a pity if QC protection mechanism won't work for these IKEv2
> variants (as in your proposal).

It wont. They are separate protocols, and they need to specify how
they are going to make their protocol QC resistant. 

> (since SK_px are used in calculation of the AUTH payload content).

True, but when our whole certificate hierarchy is broken because
signatures are broken we should still replace the authentication
methods with something that is fully resistant to the QC. 

> there are a lot of sensitive information to protect.

Which has nothing to do with this discussion, as G-IKEv2 is not IKEv2,
nor it is work that is done in the IPsecME Wg at all. There used to be
separate working group (Msec) working on those protocols, and their
protocols were based on the IKE, but not really IKE. If they want to
use things we define here they need to incorporate them to their
protocols separately. 

>From the draft:

...
   The PPK Indicator Algorithm is a 4 byte word that states which PPK
   indicator to use.  That is, it gives the encoding format for the PPK
   that should be used is given to the responder.  At present, the only
   assigned encoding is 0x00000001, which indicates that AES256_SHA256
   will be used (as explained below).
...

And unfortunately I do not really have time to read the draft now as
the mechanism looks too complicated to me with little gain, and will
most likely not go forward, thus there is no point of me to waste my
time on it now.

> is included in the protocol.

Most PRFs accept arbitrary length key, but they will convert it to
suitable for the algorithm by hashing it first. For example
AES-XCBC-PRF-128 will take the key and calculate the AES-XCBC-PRF-128
with zero key and will get 128 bit key out from that which is then
used as the key to PRF.

If the key contained 256 bits of entropy after that it will only
contain 128-bits of entropy and if the rest of the inputs to the PRF
is just (public) nonces, then the final keying material will have 128
bits of entropy.

I think this was the reason why the KEYMAT and SKEYSEED in IKEv2 is
calculated as how they are in the IKEv2.

> in implementation, not in mathematics. See below.

That is not my construction, that is construction we currently have in
the IKEv2.

> are often based on undocumented features.

That is actual real reason to do things differently. I.e. perhaps the
KEYMAT generation then should be

   KEYMAT = prf+(SK_d, g^ir (new) | prf(PPK, Ni) | prf(PPK, Nr))

instead?

Or something similar where we use PPK as key to PRF. 
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 25 Feb 2016 18:04:12 +0300

> use things we define here they need to incorporate them to their

We disagree on this. I think that if some solution can be re-used in 
a similar protocol, then it saves a lot of unnecessary work. 
G-IKEv2 is based on IKEv2 and they are very similar. Not only framing, 
but also the core crypto formulas are the same.

>   will be used (as explained below).

This text is not concerned with SKEYSEED calculation, where the negotiated 
PRF is used.

>   KEYMAT = prf+(SK_d, g^ir (new) | prf(PPK, Ni) | prf(PPK, Nr))

That's exactly how PPK is used in the draft (except that
it is used there for SKEYSEED calculation).

Regards,
Valery.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 25 Feb 2016 22:33:50 +0000

> Sent: Thursday, February 25, 2016 7:43 AM
> To: Valery Smyslov
> Cc: Scott Fluhrer (sfluhrer); [email-masked]
> > Most PRFs accept key of arbitrary length. And if some PRF is defined
> > with a fixed length key, that there will be a problem with this PRF in
> > IKEv2 anyway - with calculation of SKEYSEED, where key is a
> > concatenation of the nonces. That's why an ugly hack for
> > AES-XCBC-PRF-128 and AES-CMAC-PRF-128 is included in the protocol.
> 
> Most PRFs accept arbitrary length key, but they will convert it to suitable for
> the algorithm by hashing it first. For example
> AES-XCBC-PRF-128 will take the key and calculate the AES-XCBC-PRF-128 with
> zero key and will get 128 bit key out from that which is then used as the key
> to PRF.

XCBC is already excluded by the guidance that recommends to use AES-256.  However, I would agree that the guidance needs to be more complete.

> 
> That is actual real reason to do things differently. I.e. perhaps the KEYMAT
> generation then should be
> 

That would certainly be a more implementable suggestion, if the WG is OK with the idea that the IKE SAs not being protected.  It would make like living with an HSM easier to deal with, while making the process of deciding which PPK to use simpler.  We may end up including a simple notification scheme (to help with a brownfield scenario, where the peer may or may not be upgraded to use PPK yet), but we might also decide to omit that as well.

So, is the protection of the IKE SA important?  I would personally vote that it is, but if the WG decides otherwise, then this is clearly a better proposal.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 26 Feb 2016 12:14:56 +0200

> but also the core crypto formulas are the same.

But as you pointed out key distribution and generation are not same.
Yes, the method we define here should be easily re-used in there, but
it still do require some work, and that is something thta the G-IKEv2
people needs to do.

> This text is not concerned with SKEYSEED calculation, where the negotiated 

True, but unless you do that you never get to the SKEYSEED
calculation, so the above system is needed, to know which PPK is to be
used and this is the complication caused by the fact that SK_e depends
on the PPK.

Of course you can do the same stupid thing that was done on IKEv1, and
say that you just use the source IP-address and fetch PPK based on
that, but that method simply does not work well.

> it is used there for SKEYSEED calculation).

And because it is used in the SKEYSEED it means we need to know which
PPK is used BEFORE we can decrypt IKE_AUTH, which means that we cannot
use identity to pick it. And because of that we need to make
complicated method of telling which PPK is used in the IKE_SA_INIT
using fixed ciphers that are not implemented on all devices (for
example IoT).

All this limits the use of this quite a much, which mostly makes this
only usable in special cases. I instead want to get good enough
protection for current IKEv2 which is very widely usable even when it
does leak out identities, traffic selectors and configuration
payloads to attacker who can break Diffie-Hellman (or anybody who is
willing to do active attack). 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 26 Feb 2016 13:49:05 +0200

Scott Fluhrer (sfluhrer) writes:
> That would certainly be a more implementable suggestion, if the WG
> is OK with the idea that the IKE SAs not being protected.  It would
> make like living with an HSM easier to deal with, while making the
> process of deciding which PPK to use simpler.  We may end up
> including a simple notification scheme (to help with a brownfield
> scenario, where the peer may or may not be upgraded to use PPK yet),
> but we might also decide to omit that as well. 
> 
> So, is the protection of the IKE SA important?  I would personally
> vote that it is, but if the WG decides otherwise, then this is
> clearly a better proposal. 

I agree that having protection of the IKE SA would be nice to have,
but I am scared that the complication of deciding which PPK to use
will cause issues, and not protecting IKE SA is good compromize, i.e.
provides the most important thing (protectiong to the actual IPsec
traffic against the QC attacks), while still being so easy to
implement and use that everybody can start using it (even the smallest
IoT device can do this provided it has PPK somehow available).
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 26 Feb 2016 16:00:40 +0300

> it still do require some work, and that is something thta the G-IKEv2

As far as I understand, the method from the draft can be reused in G-IKEv2 as-is.
And if we choose not to protect IKE SA, then they will need to reinvent the wheel.

> using fixed ciphers that are not implemented on all devices (for

The ciphers are not really fixed. There is a kind of negotiation
during cookie exchanhe. Abd the draft can be easily modified 
to re-use existing IKEv2 registries for the crypto primitives - see
https://mailarchive.ietf.org/arch/msg/ipsec/r4I5SCIEt4BmXsROCDXZXTbVuIc

The support for the cookie exchange is mandatory in the IKEv2,
adding a couple notification to it doesn't add much complexity.

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 26 Feb 2016 16:14:55 +0300

> That would certainly be a more implementable suggestion, if the WG is OK with the idea 
> that the IKE SAs not being protected.  It would make like living with an HSM easier to deal with, 
> while making the process of deciding which PPK to use simpler.  We may end up including a simple 
> notification scheme (to help with a brownfield scenario, where the peer may or may not be upgraded 
> to use PPK yet), but we might also decide to omit that as well.
>
> So, is the protection of the IKE SA important?  I would personally vote that it is, 
> but if the WG decides otherwise, then this is clearly a better proposal.

I think that the protection of IKE SA is important. This would preserve IKEv2
security properties (like protecting identities against passive attacker) 
and would allow to re-use the solution in G-IKEv2 and other IKEv2 derivations 
that do transfer sensitive information within IKE SA. 

Otherwise we'll end up with a solution that is very limited to use while still
sustantially modifying the IKEv2 (for example core crypto calculations
must be changed in any case).

Regards,
Valery.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 26 Feb 2016 09:05:33 -0500

Valery Smyslov <[email-masked]> wrote:
    > I think that the protection of IKE SA is important. This would preserve
    > IKEv2 security properties (like protecting identities against passive
    > attacker) and would allow to re-use the solution in G-IKEv2 and other
    > IKEv2 derivations that do transfer sensitive information within IKE SA.

If the protection of the IKE SA means that we wind up in an IKEv1-like
situation with Main Mode and group PSKs, then the result will be that IKE is
not used.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 26 Feb 2016 17:19:26 +0300

Hi Michael,

> situation with Main Mode and group PSKs, then the result will be that IKE is

Agree. But it is my understanding of the draft that it doesn't imply any 
IKEv1 like group PSKs. It allows proper selection of pair-wise PSK.

Regards,
Valery.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Mon, 29 Feb 2016 12:59:13 +0000

> From: Valery Smyslov [mailto:[email-masked]]
> Sent: Friday, February 26, 2016 9:19 AM
> To: Michael Richardson
> Cc: Scott Fluhrer (sfluhrer); Tero Kivinen; [email-masked]
> > situation with Main Mode and group PSKs, then the result will be that
> > IKE is not used.
> 

Yes, the intention is to allow someone to set up pairwise PPK's.