Re: [IPsec] Perfect Forward secrecy

[Yoav Nir <[e-mail]>]

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)" <[e-mail]> 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: '[e-mail]'
>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: '[e-mail]'
>> 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'; '[e-mail]'
>> Cc: '[e-mail]'; Prashant Batra (prbatra); 'ipsec-tools-
>> [e-mail]'; '[e-mail]';
>> '[e-mail]'
>> 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';
>> > [e-mail]
>> > Cc: '[e-mail]'; Prashant Batra (prbatra); ipsec-tools-
>> > [e-mail]; [e-mail];
>> ipsec-
>> > [e-mail]
>> > 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: [e-mail]; Prashant Batra (prbatra)
>> > Subject: RE: [IPsec] DH keys calculation performance
>> >
>> >
>> >
>> > > -----Original Message-----
>> > > From: [e-mail] [mailto:[e-mail]] On
>> > Behalf
>> > > Of Naveen B N (nbn)
>> > > Sent: Thursday, August 25, 2011 6:48 AM
>> > > To: Yaron Sheffer; Yoav Nir
>> > > Cc: [e-mail]; 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: [e-mail] [mailto:[e-mail]] On
>> > Behalf
>> > > Of Prashant Batra (prbatra)
>> > > Sent: Tuesday, July 26, 2011 6:33 PM
>> > > To: Yaron Sheffer; Yoav Nir
>> > > Cc: [e-mail]
>> > > 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:[e-mail]]
>> > > Sent: Tuesday, July 26, 2011 4:47 PM
>> > > To: Yoav Nir
>> > > Cc: Prashant Batra (prbatra); [e-mail]
>> > > 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
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/ipsec
>> > > _______________________________________________
>> > > IPsec mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/ipsec
>
>Scanned by Check Point Total Security Gateway.