Subject: [IPsec] New Version Notification for draft-kivinen-ipsecme-secure-password-framework-01.txt

From: Tero Kivinen <[email-masked]>
Date: Mon, 25 Jul 2011 16:46:31 +0300

Subject: New Version Notification for draft-kivinen-ipsecme-secure-password-framework-01.txt
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Mon, 25 Jul 2011 06:29:50 -0700

A new version of I-D, draft-kivinen-ipsecme-secure-password-framework-01.txt has been successfully submitted by Tero Kivinen and posted to the IETF repository.

Filename:	 draft-kivinen-ipsecme-secure-password-framework
Revision:	 01
Title:		 Secure Password Framework for IKEv2
Creation date:	 2011-07-25
WG ID:		 Individual Submission
Number of pages: 14

Abstract:
   This document creates a generic way for Internet Key Exchange (IKEv2)
   to use any of the symmetric secure password authentication methods.
   There are multiple methods already specified in other documents and
   this document does not add new one.  This document specifies a common
   way so those methods can agree on which method is to be used in
   current connection.  This document also provides a common way to
   transmit secure password authentication method specific payloads
   between peers.

The IETF Secretariat

---

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Tue, 26 Jul 2011 08:59:38 +0530

Hello,

The DH exchange (Calculation of Public/Private key and the Secret) in
IKEV2 Initial exchange 
seems to be very expensive. This is slowing down the overall IKEv2
tunnel establishment.
Is there a way to optimize it?

Regards,
Prashant

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 25 Jul 2011 21:37:38 -0700

Hi Prashant,

Back in the days we had some acceleration of DH in the hardware
http://www.wipo.int/patentscope/search/en/WO2005008999.

Other things you can do is put in more CPU or use a lower DH group.

Thanks,
Vishwas

On Mon, Jul 25, 2011 at 8:29 PM, Prashant Batra (prbatra) <[email-masked]
> wrote:

---

From: Yoav Nir <[email-masked]>
Date: Tue, 26 Jul 2011 13:40:19 +0300

> Is there a way to optimize it?

Hi Prashant.

I know of three ways to optimize the D-H exchange.

First, note that each peer has to perform two operations: 
 1. Generate: create a random x and calculate X=2^x mod p
 2. Derive: calculate the shared secret S=Y^x mod p
The "Derive" operation has to be done during the exchange, but the "Generate" operation can be done long before the exchange. If your problem is degraded performance at some peak, you can pre-generate some values. This has a high cost in memory, but can be useful for dealing with peaks.

Second, note that 2^73 mod p = ((2^64 mod p) * (2^8 mod p) * (2^1 mod p)) mod p
If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod p for 0<=x<=2048 and store these values. After that, both the generate and derive operations become simple multiplications of the resulting values. This has a fixed cost in memory, but can accelerate things.

Third, you may want to look at the EC groups. The EC operations require less computation.

Hope this helps

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 26 Jul 2011 14:17:28 +0300

You might want to review http://tools.ietf.org/html/rfc5996#section-2.12.

Also, session resumption (http://tools.ietf.org/html/rfc5723)
reduces the computational costs of renewing an IKE SA when a client
needs to reconnect to a gateway a second time after some failure.

Thanks,

Yaron

On 07/26/2011 01:40 PM, Yoav Nir wrote:

Hello,

Hi Prashant.

Hope this helps

Yoav

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

---

From: "Prashant Batra (prbatra)" <[email-masked]>
Date: Tue, 26 Jul 2011 18:33:23 +0530

Thanks Yoav and Yaron  for the suggestions.

Even I was thinking and tried generating and storing the key pair  well
in the beginning,.  This helped to some extent.

The secret calculation is also very expensive, but this has to be done
in midst of the exchange only.

Regards,

Prashant 

From: Yaron Sheffer [mailto:[email-masked]] 
Sent: Tuesday, July 26, 2011 4:47 PM
To: Yoav Nir
Cc: Prashant Batra (prbatra); [email-masked]
Subject: Re: [IPsec] DH keys calculation performance

You might want to review
http://tools.ietf.org/html/rfc5996#section-2.12.

Also, session resumption (http://tools.ietf.org/html/rfc5723) reduces
the computational costs of renewing an IKE SA when a client needs to
reconnect to a gateway a second time after some failure.

Thanks,
    Yaron

	Hello,
	 
	The DH exchange (Calculation of Public/Private key and the
Secret) in
	IKEV2 Initial exchange 
	seems to be very expensive. This is slowing down the overall
IKEv2
	tunnel establishment.
	Is there a way to optimize it?

Hi Prashant.

First, note that each peer has to perform two operations: 
 1. Generate: create a random x and calculate X=2^x mod p
 2. Derive: calculate the shared secret S=Y^x mod p
The "Derive" operation has to be done during the exchange, but the
"Generate" operation can be done long before the exchange. If your
problem is degraded performance at some peak, you can pre-generate some
values. This has a high cost in memory, but can be useful for dealing
with peaks.
 
Second, note that 2^73 mod p = ((2^64 mod p) * (2^8 mod p) * (2^1 mod
p)) mod p
If you're using a 2048-bit D-H group, you can pre-calculate 2^x mod p
for 0<=x<=2048 and store these values. After that, both the generate and
derive operations become simple multiplications of the resulting values.
This has a fixed cost in memory, but can accelerate things.
 
Third, you may want to look at the EC groups. The EC operations require
less computation.
 
Hope this helps
 
Yoav

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 26 Jul 2011 07:55:54 -0700 (PDT)

Hello,

> in midst of the exchange only.

  You could pick one secret x and then for IKE exchanges do this:

0th exchange: y = g^x mod p
1st exchange: y = g^(x+1) mod p
2nd exchange: y = g^(x+2) mod p
.
.
.
nth exchange: y = g^(x+n) mod p

Getting from exchange i to exchange i+1, then, is just a single modular
multiply, which should be "cheaper" for you.

  Knowing n, y, g and p and that y = g^(x+n) mod p does not really give
an advantage (above the discrete logarithm problem) in finding x. That
said, I still would not suggest doing many more than a few of these (and
I am not qualified to quantify that statement) but for a few-- i.e. keep
n small and after n choose a new x and repeat-- it should be OK.

  Maybe this technique will allow you to "cheapen" your exchange a bit.
I think throwing hardware at this problem is your best bet though.

  regards,

  Dan.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 26 Jul 2011 08:13:33 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yoav Nir
> Sent: Tuesday, July 26, 2011 6:40 AM
> To: Prashant Batra (prbatra)
> Cc: [email-masked]
> p)) mod p If you're using a 2048-bit D-H group, you can pre-calculate
> 2^x mod p for 0<=x<=2048 and store these values.

Surely, you mean something like 0<=x<320 or so.  When you create a DH
shared secret for a MODP group, it is pointless to create a secret as
big as the prime.  Against DH, there are two known types of attacks:
	(A) Attacks that take time based on the modulus (and don't
depend on the value of the exponent at all)
	(B) Attacks that take time based on the exponent (and don't
depend that much on the value of the modulus)
What you want to do is pick your exponent just large enough that (B)
attacks take about as long as (A) attacks; making the exponent any
larger than that will make it more expensive for you without making it
any more secure (because an attacker can just go ahead with an (A)
attack); while making it smaller will make it less secure (because a (B)
attack becomes easier).

So, what's the size of such an exponent?  Well, that's a difficult
question; however, the RFC's do give guidance.  If you're using a 2048
bit exponent for 2048 bit MODP group, that's an obvious thing to fix.
If we look at RFC3526, we see that it suggests an exponent of length of
between 220 and 320 bits (it's a range because experts have different
estimates of how difficult type (A) attacks are).

Also, if you're doing groups 22-24, then it's easy; use an exponent of
the same size as 'q' (that'd be 160, 224 and 256 bits); a larger
exponent is pointless.
And, for completeness, for a ECDH group, it's also easy; use an exponent
of the same size as the curve (e.g. 256 bits for the P256 curve).

---

From: Yoav Nir <[email-masked]>
Date: Tue, 26 Jul 2011 18:38:13 +0300

> attack); while making it smaller will make it less secure (because a (B)

Yes. My bad.

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 26 Jul 2011 11:59:14 -0400

Regarding Dan's suggestion (*) of using g^x, g^{x+1}, etc as successive DH
values, I would like to note the following.

This would lead to situations where two parties exchange successive keys of
the form g^{xy} and g^{(x+1)(y+1)}=g^{xy}*g^x*g^y*g.
In this case, if an attacker learns the key g^{xy} it also learns the next
key, something that violates key-exchange security (i.e. security against
"known key attacks"). However, if one models the key derivation function
applied to g^{xy} as a random oracle then this usage is probably ok (I did
not prove it), assuming the attacker does not have access to g^{xy} before
hashing. This is a weaker security property than the one achieved by always
choosing x and y afresh (in which case we have proof of security without
resorting to random oracle assumptions and without assuming that the
attacker never gets to see g^{xy}).

In a performance-vs-security tradeoff one may choose to use this method, but
one should be aware that there is a trade-off here.

Hugo

(*) I am not blaming Dan. I actually suggested that trick in my 1995 SKEME
paper as a way to improve over the suggestion of re-using the same exponent
in multiple exchanges as proposed at the time in the Photuris protocol. It
indeed improved over Photuris but today I would be more careful about
suggesting that.