Re: [IPsec] Perfect Forward secrecy
"Dan Harkins" <dharkins@lounge.org> Mon, 29 August 2011 06:29 UTC
Return-Path: <dharkins@lounge.org>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274E121F855B for <ipsec@ietfa.amsl.com>; Sun, 28 Aug 2011 23:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.223
X-Spam-Level:
X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfPBGI1lE-Dd for <ipsec@ietfa.amsl.com>; Sun, 28 Aug 2011 23:29:43 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A082F21F86EE for <ipsec@ietf.org>; Sun, 28 Aug 2011 23:29:43 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3FCDD1022404C; Sun, 28 Aug 2011 23:31:06 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 28 Aug 2011 23:31:06 -0700 (PDT)
Message-ID: <4c91facfa314f3e37144479dc92d1855.squirrel@www.trepanning.net>
In-Reply-To: <CA81055B.598C%ynir@checkpoint.com>
References: <CA81055B.598C%ynir@checkpoint.com>
Date: Sun, 28 Aug 2011 23:31:06 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Yoav Nir <ynir@checkpoint.com>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Naveen B N <nbn@cisco.com>, Rajeshwar Singh Jenwar <rsj@cisco.com>, Scott Fluhrer <sfluhrer@cisco.com>
Subject: Re: [IPsec] Perfect Forward secrecy
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Aug 2011 06:29:45 -0000
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)" <nbn@cisco.com> 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: 'ipsec@ietf.org' >>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: 'ipsec@ietf.org' >>> 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'; 'timo.teras@iki.fi' >>> Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); 'ipsec-tools- >>> users@lists.sourceforge.net'; 'ikev2-devel@lists.sourceforge.net'; >>> 'ipsec-tools-devel@lists.sourceforge.net' >>> 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'; >>> > timo.teras@iki.fi >>> > Cc: 'ipsec@ietf.org'; Prashant Batra (prbatra); ipsec-tools- >>> > users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net; >>> ipsec- >>> > tools-devel@lists.sourceforge.net >>> > 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: ipsec@ietf.org; Prashant Batra (prbatra) >>> > Subject: RE: [IPsec] DH keys calculation performance >>> > >>> > >>> > >>> > > -----Original Message----- >>> > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>> > Behalf >>> > > Of Naveen B N (nbn) >>> > > Sent: Thursday, August 25, 2011 6:48 AM >>> > > To: Yaron Sheffer; Yoav Nir >>> > > Cc: ipsec@ietf.org; 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: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >>> > Behalf >>> > > Of Prashant Batra (prbatra) >>> > > Sent: Tuesday, July 26, 2011 6:33 PM >>> > > To: Yaron Sheffer; Yoav Nir >>> > > Cc: ipsec@ietf.org >>> > > 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:yaronf.ietf@gmail.com] >>> > > Sent: Tuesday, July 26, 2011 4:47 PM >>> > > To: Yoav Nir >>> > > Cc: Prashant Batra (prbatra); ipsec@ietf.org >>> > > 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 >>> > > IPsec@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/ipsec >>> > > _______________________________________________ >>> > > IPsec mailing list >>> > > IPsec@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/ipsec >> >>Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >
- [IPsec] New Version Notification for draft-kivine… Tero Kivinen
- [IPsec] DH keys calculation performance Prashant Batra (prbatra)
- Re: [IPsec] DH keys calculation performance Vishwas Manral
- Re: [IPsec] DH keys calculation performance Yoav Nir
- Re: [IPsec] DH keys calculation performance Yaron Sheffer
- Re: [IPsec] DH keys calculation performance Prashant Batra (prbatra)
- Re: [IPsec] DH keys calculation performance Dan Harkins
- Re: [IPsec] DH keys calculation performance Scott Fluhrer (sfluhrer)
- Re: [IPsec] DH keys calculation performance Yoav Nir
- Re: [IPsec] DH keys calculation performance Hugo Krawczyk
- Re: [IPsec] DH keys calculation performance Scott Fluhrer (sfluhrer)
- [IPsec] IPSec implementation query. Prashant Batra (prbatra)
- Re: [IPsec] DH keys calculation performance Naveen B N (nbn)
- Re: [IPsec] DH keys calculation performance Naveen B N (nbn)
- Re: [IPsec] DH keys calculation performance Scott Fluhrer (sfluhrer)
- Re: [IPsec] DH keys calculation performance Naveen B N (nbn)
- [IPsec] New method to resist replay attack in ike… ramaswamy
- Re: [IPsec] DH keys calculation performance Scott Fluhrer (sfluhrer)
- Re: [IPsec] DH keys calculation performance Naveen B N (nbn)
- Re: [IPsec] Perfect Forward secrecy Naveen B N (nbn)
- Re: [IPsec] Perfect Forward secrecy Yoav Nir
- Re: [IPsec] Perfect Forward secrecy Dan Harkins
- Re: [IPsec] Tokes = Session key + lifetime Naveen B N (nbn)
- Re: [IPsec] Perfect Forward secrecy Stephen Kent
- Re: [IPsec] Avoid multiple authentication's Naveen B N (nbn)
- Re: [IPsec] Avoid multiple authentication's Yaron Sheffer
- Re: [IPsec] Avoid multiple authentication's Naveen B N (nbn)
- [IPsec] New method to resist replay attack in ike… Tero Kivinen
- Re: [IPsec] New method to resist replay attack in… ramaswamy
- Re: [IPsec] New method to resist replay attack in… Tero Kivinen
- Re: [IPsec] New method to resist replay attack in… ramaswamy
- Re: [IPsec] New method to resist replay attack in… ramaswamy
- Re: [IPsec] New method to resist replay attack in… ramaswamy