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
