Re: [IPsec] Avoid multiple authentication's
"Naveen B N (nbn)" <nbn@cisco.com> Mon, 29 August 2011 10:18 UTC
Return-Path: <nbn@cisco.com>
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 0F60B21F886A for <ipsec@ietfa.amsl.com>; Mon, 29 Aug 2011 03:18:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 20UGlaesTzkA for <ipsec@ietfa.amsl.com>; Mon, 29 Aug 2011 03:18:16 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 822E821F8ACE for <ipsec@ietf.org>; Mon, 29 Aug 2011 03:18:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nbn@cisco.com; l=17247; q=dns/txt; s=iport; t=1314613178; x=1315822778; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=E24nGvrCvSgLmlK9R6A+BHcb3sYs5a9r0J9W0KaFcBU=; b=eMCyKRIq3Lz6c6NG3UxqwQ2RAuV0xz9fAjKKRG0p6M//3a9WWCHOKYvL DAI08uAVpaKn+9dowQvGzyxKT4eZn9QxmAWMEq6OeJM2kCSYvornM17v1 1A+kYYlbZtkS4ibb6mTBJPWzbpcAplTNVOEyKE1KgD7uEaO04/q4kxGak A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AroAAINmW05Io8US/2dsb2JhbABCmCePWHeBQAEBAQEDAQEBDwEdCjQLDAQCAQgOAwQBAQEKBhcBBgEgBgEeCQgBAQQBCggIEQIHh1SYUgGeGYVsYASHYokshyiEYocT
X-IronPort-AV: E=Sophos;i="4.68,296,1312156800"; d="scan'208";a="112948733"
Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 29 Aug 2011 10:19:35 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7TAJZiv031847; Mon, 29 Aug 2011 10:19:35 GMT
Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 29 Aug 2011 15:49:35 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 29 Aug 2011 15:49:34 +0530
Message-ID: <A2354B6A9F807641B21EEABD666ECEEA0130ACEB@XMB-BGL-416.cisco.com>
In-Reply-To: <A2354B6A9F807641B21EEABD666ECEEA0130AC9E@XMB-BGL-416.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [IPsec] Avoid multiple authentication's
thread-index: AcxmFT7HSJrT7ZNdSCu10vugR9oW1QAD1XkgAAQSDlA=
References: <CA81055B.598C%ynir@checkpoint.com><4c91facfa314f3e37144479dc92d1855.squirrel@www.trepanning.net> <A2354B6A9F807641B21EEABD666ECEEA0130AC9E@XMB-BGL-416.cisco.com>
From: "Naveen B N (nbn)" <nbn@cisco.com>
To: Dan Harkins <dharkins@lounge.org>, Yoav Nir <ynir@checkpoint.com>
X-OriginalArrivalTime: 29 Aug 2011 10:19:35.0373 (UTC) FILETIME=[26987FD0:01CC6635]
Cc: ipsec@ietf.org, "Saravana Ravindran (sarravin)" <sarravin@cisco.com>, "Sastry SK (sassk)" <sassk@cisco.com>, "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Subject: Re: [IPsec] Avoid multiple authentication's
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 10:18:18 -0000
Hi Dan and Yoav Nir, Thank you and appreciate for the timely comments on my view and sharing the drafts for the same. I was thinking to bring a Token concept in Ikev2 which will be Given by the responder, so that the session keys is bound to a life time and If the Key is still valid IKE_INIT can be skipped and IKE_AUTH is directly used even in the next sessions. Tokens= Session key + Life time. The above will save DH computation and key negotiation in case the session was aborted for some reason and if the client has multiple make break of sessions. The above will save multiple times of authentication of client who was already authenticated. Kindly share your views on token to be used has authenticators For multiple sessions. Thanks and Regards Naveen -----Original Message----- From: Dan Harkins [mailto:dharkins@lounge.org] Sent: Monday, August 29, 2011 12:01 PM To: Yoav Nir Cc: Naveen B N (nbn); Scott Fluhrer (sfluhrer); Yaron Sheffer; Rajeshwar Singh Jenwar (rsj); ipsec@ietf.org Subject: Re: [IPsec] Perfect Forward secrecy 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 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