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.
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
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
