Re: [IPsec] New method to resist replay attack in ikev2
"ramaswamy" <ramaswamy.bm@globaledgesoft.com> Mon, 19 September 2011 14:25 UTC
Return-Path: <ramaswamy.bm@globaledgesoft.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 5559721F8C3F for <ipsec@ietfa.amsl.com>; Mon, 19 Sep 2011 07:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.152
X-Spam-Level:
X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_20=-0.74, MSGID_MULTIPLE_AT=1.449]
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 qmIkGw+f2gvz for <ipsec@ietfa.amsl.com>; Mon, 19 Sep 2011 07:25:26 -0700 (PDT)
Received: from gesmail.globaledgesoft.com (gesmail.globaledgesoft.com [119.82.106.22]) by ietfa.amsl.com (Postfix) with ESMTP id 60DBE21F8C39 for <ipsec@ietf.org>; Mon, 19 Sep 2011 07:25:26 -0700 (PDT)
Received: from RamaswamySM (ramaswamy_sm.globaledgesoft.com [172.16.8.54]) by gesmail.globaledgesoft.com (Postfix) with ESMTP id ED90F588225; Mon, 19 Sep 2011 20:00:40 +0530 (IST)
From: ramaswamy <ramaswamy.bm@globaledgesoft.com>
To: 'Tero Kivinen' <kivinen@iki.fi>
References: <20013.29623.491247.654466@fireball.kivinen.iki.fi> <B97B134FACB2024DB45F524AB0A7B7F203ED2B05@XMB-BGL-419.cisco.com> <90AEF529-7273-4695-BA31-4F221A4ACF45@checkpoint.com> <4E2EA248.70708@gmail.com> <B97B134FACB2024DB45F524AB0A7B7F203ED2CEA@XMB-BGL-419.cisco.com> <A2354B6A9F807641B21EEABD666ECEEA0130A752@XMB-BGL-416.cisco.com> <EE0C2F9E065E634B84FC3BE36CF8A4B2079C046C@xmb-sjc-23e.amer.cisco.com> <A2354B6A9F807641B21EEABD666ECEEA0130A7D8@XMB-BGL-416.cisco.com> <008901cc63b8$e5c9c640$b15d52c0$@bm@globaledgesoft.com> <20060.43306.157789.942917@fireball.kivinen.iki.fi>
In-Reply-To: <20060.43306.157789.942917@fireball.kivinen.iki.fi>
Date: Mon, 19 Sep 2011 19:57:32 +0530
Message-ID: <00e301cc76d8$44b0e940$ce12bbc0$@bm>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acxm9RwEPTnFAoxnTfyMsDhIPElU8gP4yXSA
Content-Language: en-us
Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net, ipsec-tools-users@lists.sourceforge.net, ikev2-devel@lists.sourceforge.net
Subject: Re: [IPsec] New method to resist replay attack in ikev2
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, 19 Sep 2011 14:25:27 -0000
Thanks for the response, I agree with your comments, I think we can use certificates to avoid man in the middle attacks and error message flooding in the INIT phase only, as certificates are signed by trusted certificate authorities authenticity is ensured. If certificates are used in INIT message exchanges [mutual authentication], we can effectively avoid afore said attacks as it avoids huge computation of IKE-keys before the client OR server is authenticated. To avoid Replay attacks: By using RSA private key of certificate to encrypt the nonce (Ni) in INIT_REQUEST message we can avoid replay attacks, at the receiving end, first certificate is verified using root CA and nonce is decrypted using public key of the received certificate which ensures that sender holds the valid private key of the certificate and not an attacker. By using nonce we can avoid Replay attacks[Packets can be rejected if the same nonce is received within a particular session]. Please assert and also let us know if any related drafts/rfc to avoid these attacks. Best Regards , Ram -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Tuesday, August 30, 2011 2:41 PM To: ramaswamy Cc: ipsec@ietf.org; ipsec-tools-devel@lists.sourceforge.net; ipsec-tools-users@lists.sourceforge.net; ikev2-devel@lists.sourceforge.net Subject: [IPsec] New method to resist replay attack in ikev2 ramaswamy writes: > Proposed new negotiations > > Before initial exchange begins initiator looks up to the pre shared > secret with the intended responder and does the hash value on first > half of pre shared secret, nonce of the initiator. Once the > responder receives the request it looks up the correspondence pre > shared key in its table and it takes the nonce form initiator > request message then it does a hash value to authenticate the > initiator. This is bit like how IKEv1 did it, and it has same problem than IKEv1 had with that, meaning it does not provide ANY identity protection at all. The responder needs to find the pre-shared key for the initiator based only with the information that are in the first IKE_SA_INIT packet. This DOES NOT include identity of the initiator, and SAi1, KEi, and Ni does not help at all in this process. The only information that responder has which it can use is the source IP-address of the IKE_SA_INIT packet. This has the effect that the pre-shared key will be tied to the source IP-address of the initiator, which mean every passive listener will also see that same IP-address and will know the identity of the initiator. The method in IKEv2 where the PSK is not tied to the IP-address of the initiator offers much better identity protection, as now the responder identity is only releaved to the active attacker. -- kivinen@iki.fi
- [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