Hi Naveen,
please take a look at RFC 5723, which is very similar to your idea.
Thanks,
Yaron
On 29.8.2011 13:19, Naveen B N (nbn) wrote:
Hi Dan and Yoav Nir,
Thank you and appreciate for the timely comments on my view and
sharing the drafts for the same.
I was thinking to bring a Token concept in Ikev2 which will be
Given by the responder, so that the session keys is bound to a
life time and If the Key is still valid IKE_INIT can be skipped
and IKE_AUTH is directly used even in the next sessions.
Tokens= Session key + Life time.
The above will save DH computation and key negotiation in case
the session was aborted for some reason and if the client has
multiple make break of sessions.
The above will save multiple times of authentication of client
who was already authenticated.
Kindly share your views on token to be used has authenticators
For multiple sessions.
Thanks and Regards
Naveen
-----Original Message-----
From: Dan Harkins [mailto:[email protected]]
Sent: Monday, August 29, 2011 12:01 PM
To: Yoav Nir
Cc: Naveen B N (nbn); Scott Fluhrer (sfluhrer); Yaron Sheffer; Rajeshwar
Singh Jenwar (rsj); [email protected]
Subject: Re: [IPsec] Perfect Forward secrecy
Hi Naveen,
Yoav is right that increasing the size of the secret, and ensuring it
is uniformly random, will mitigate this sort of dictionary attack. And
the 3 drafts he mentions will basically foil it entirely.
But the attack you mention does not affect "perfect forward secrecy".
That is the property that even with the loss of a long term credential
(like the pre-shared secret learned by dictionary attack) the adversary
is unable to determine the session key from a different run of the
protocol. This property still holds even with a successful dictionary
attack against a pre-shared key.
regards,
Dan.
On Sun, August 28, 2011 11:04 pm, Yoav Nir wrote:
Hi Naveen
If you use a 128-bit or 256-bit truly random shared secret (like you
should, although probably nobody does), brute force will never work.
If
you use a weaker shared secret, such as something with 20-40 bits of
entropy, then your offline dictionary attack becomes practical.
For suggested ways of counteracting this, take a look at these:
http://tools.ietf.org/html/draft-harkins-ipsecme-spsk-aut
http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2
http://tools.ietf.org/html/draft-shin-augmented-pake
On 8/29/11 8:54 AM, "Naveen B N (nbn)"<[email protected]> wrote:
Hi Scott,
Even with the Pre-shared secret, the protocol can't keep up the
property
of " perfect Forward secrecy".
I have assumed the both the server and client use pre-shared secret,
same
below methods applies to Certificate based
Authentication has well.
Below steps show why.
Subject: Intruder X acts has server only to get the access of auth
payload.
1)A send IKE_INIT to indented server.
2) X[ intruder ] receives the INIT and process just has the protocol
and
replies with the generated
public value for DH. IKE_INT response is from Intruder instead of
Server
by creating the packet using
a raw socket using [ IP spoofing].
3)A and X now generate the Sk key which is used to encrypt the next
IKE_AUTH message.
4)A sends IKE_AUTH and intruder receives the same and he is able to
decrypt the message and get access to IDR and Auth payload.
5)Intrudes gets hold of the AUTH data and work on it to derive the
Pre-shared Secret { eg. Brute force}.
6) Since The Pre-shared secret is not changes the Intruder can now
behave
has the Initiator to server[IDR]
And complete the Ikev2 flow.
Kindly share your view on the above .
Thanks and Regards
Naveen
-----Original Message-----
From: Scott Fluhrer (sfluhrer)
Sent: Friday, August 26, 2011 7:27 PM
To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir'
Cc: '[email protected]'
Subject: RE: [IPsec] DH keys calculation performance
-----Original Message-----
From: Naveen B N (nbn)
Sent: Friday, August 26, 2011 1:37 AM
To: Naveen B N (nbn); Scott Fluhrer (sfluhrer); 'Yaron Sheffer';
'Yoav
Nir'
Cc: '[email protected]'
Subject: RE: [IPsec] DH keys calculation performance
Hi Scott,
if we can take care of the "Forward Secrecy",
When using Asymetric keys from certificates
To negotiate symmetric keys, then certificate
Can be used in place of DH Computation.
"TO maintain "Forward Secrecy", we have to change the keys from
time to time based on the key length, which can be achieved by re-
negotiating"
No, you'd have the change the asymmetric keys all well; with the
private
key, the attacker can still recover the session (symmetric) keys.
Now, it's not impossible to change the public keys; however, it does
involve generating a fresh private/public key pair. With RSA, at
least,
that's a lot more expensive than doing a single exchange (or, for that
matter, several dozen simple exchanges), and so if the point of this
is
to reduce the total amount of computation, well, that rather misses
the
point.
If this is possible then I can present a draft for the same.
Thanks& Regards
Naveen
-----Original Message-----
From: Scott Fluhrer (sfluhrer)
Sent: Thursday, August 25, 2011 10:18 PM
To: Naveen B N (nbn); 'Yaron Sheffer'; 'Yoav Nir';
'[email protected]'
Cc: '[email protected]'; Prashant Batra (prbatra); 'ipsec-tools-
[email protected]'; '[email protected]';
'[email protected]'
Subject: RE: [IPsec] DH keys calculation performance
-----Original Message-----
From: Naveen B N (nbn)
Sent: Thursday, August 25, 2011 12:34 PM
To: Scott Fluhrer (sfluhrer); 'Yaron Sheffer'; 'Yoav Nir';
[email protected]
Cc: '[email protected]'; Prashant Batra (prbatra); ipsec-tools-
[email protected]; [email protected];
ipsec-
[email protected]
Subject: RE: [IPsec] DH keys calculation performance
Hi Scott,
Please find the queries and comments inline ..
Scott>- Transporting keying material lacks forward secrecy.
"Forward
secrecy" is the property that, if some actually recovers the
entire
state of one (or both) of the sides, they still won't be able to
decrypt a transcript of a session that had happened earlier
(because
the state needed to decrypt it was zeroized when the session was
closed). With key transport, it is impractical to zeroize the
private
key used during the exchange, and with that, the attacker can
decrypt
the keying material, and from there, rederive the session keys.
In
contrast, with DH, as long as both sides zeroize the private
exponents
and shared secrets (along with the session state), the attacker
does
not have enough information.
Naveen>> TO maintain "Forward Secrecy", we have to change the keys
from
time to time based on the key length, which can be achieved by re-
negotiating
new keys with the communicated Symmetric key.
But if you say that the first session used is to derive the
private key of the peer, then Asymmetric key should never be used
for
deriving symmetric keys
Or to protect data. If Certificate are still used in TLS
for
negotiation of Symmetric keys, this is a major issue because they
are
used in important places.
I believe you misunderstand; we're not using the asymmetric key to
"derive" the symmetric keys, but instead just to transport it.
Here's the scenario:
- Side A picks some keying material ("premaster secret" is TLS's
terminology for it)
- Side A encrypts it with Side B's public key, and sends it to B
- Side B decrypts it with his own private key
- Both side A and side B use that keying material (and possibly
other
information that has been exchanged) to derive the real session keys
The problem I was discussing: what if, after the session has been
shut
down, the attacker recovers side B's private key? This private key
is
unlikely to be zeroized along with the session (at least, with the
current CA infrastructure); using this private key, the attacker
could
decrypt the encrypted keying material (just like B did), and
rederive
the session keys (again, just like B did).
Naveen>>So, Certificates should only be used for authentication in
a
protected environment is it.
What could be the life time of the RSA keys then, how long
will
it take to derive a private key from a public key with the best
available resources.
Then it comes down to DH method being the best secured
available solution for negotiating Symmetric key on the fly,
without
having shared keying material with the peer.
Scott>- IKEv2 allows other types of authentication beyond
certificates;
using public key encryption as a step in generating keying
material
would imply that we would need a different mechanism to generate
keying
material for other types of authentication. This is certainly not
impossible (in fact, IKEv1 did have different mechanisms based on
authentication type, although for different reasons); the IKEv2
designers decided to unify that.
Naveen>>May be Ikev2 designers feel that the intruder may selects
a
week authentication type if exposed in plan message, But I think
we
are
authenticating the INIT_MESSAGE in IKE_AUTH
Message, so they could have provided a authentication
method
in
IKE_INIT message.
Thanks and Regards
Naveen
-----Original Message-----
From: Scott Fluhrer (sfluhrer)
Sent: Thursday, August 25, 2011 6:57 PM
To: Naveen B N (nbn); Yaron Sheffer; Yoav Nir
Cc: [email protected]; Prashant Batra (prbatra)
Subject: RE: [IPsec] DH keys calculation performance
-----Original Message-----
From: [email protected] [mailto:[email protected]] On
Behalf
Of Naveen B N (nbn)
Sent: Thursday, August 25, 2011 6:48 AM
To: Yaron Sheffer; Yoav Nir
Cc: [email protected]; Prashant Batra (prbatra)
Subject: Re: [IPsec] DH keys calculation performance
Hi ,
Can we not use the existing RSA keys to get the shared secret
without
using the DH computation
Because of the calculation that are involved.
Let's say A wants to initiate a session with B.
Let A get the Public key of B from CA by sending a protected
message
using public key of CA.
Use the obtained public key for sending the shared secret to B
and
same
from the other
End has well, this will ensure authentication and avoiding DH
computation.
I feel that certificate can be used for authentication and as
well
has
negotiated Symmetric key using the
Concept of Asymmetric cryptography which is one of the good
features
of certificate.
Why in Ikev2, certificates are just used for authentication and
why
they are not used for
negotiating Symmetric key instead in place of DH computation. Is
it
to
avoid use of Trusted CA negotiation.
Well, you certainly can use certificates (with public key
encryption
keys) to transport keying material; indeed, the ciphersuite of TLS
that
is in general use does exactly that.
However, it does have a few drawbacks. Here are some of the
reasons
that the IKEv2 designers may have chosen not to use it:
- Transporting keying material lacks forward secrecy. "Forward
secrecy" is the property that, if some actually recovers the
entire
state of one (or both) of the sides, they still won't be able to
decrypt a transcript of a session that had happened earlier
(because
the state needed to decrypt it was zeroized when the session was
closed). With key transport, it is impractical to zeroize the
private
key used during the exchange, and with that, the attacker can
decrypt
the keying material, and from there, rederive the session keys.
In
contrast, with DH, as long as both sides zeroize the private
exponents
and shared secrets (along with the session state), the attacker
does
not have enough information.
- IKEv2 allows other types of authentication beyond certificates;
using
public key encryption as a step in generating keying material
would
imply that we would need a different mechanism to generate keying
material for other types of authentication. This is certainly not
impossible (in fact, IKEv1 did have different mechanisms based on
authentication type, although for different reasons); the IKEv2
designers decided to unify that.
Thanks and Regards
Naveen
From: [email protected] [mailto:[email protected]] On
Behalf
Of Prashant Batra (prbatra)
Sent: Tuesday, July 26, 2011 6:33 PM
To: Yaron Sheffer; Yoav Nir
Cc: [email protected]
Subject: Re: [IPsec] DH keys calculation performance
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 protected]]
Sent: Tuesday, July 26, 2011 4:47 PM
To: Yoav Nir
Cc: Prashant Batra (prbatra); [email protected]
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
On 07/26/2011 01:40 PM, Yoav Nir wrote:
On Jul 25, 2011, at 11:29 PM, Prashant Batra (prbatra) wrote:
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.
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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
