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
