From nobody Mon Sep 2 05:18:41 2019 Return-Path: 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 E4E8C120119 for ; Mon, 2 Sep 2019 05:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlY04255_Y7Y for ; Mon, 2 Sep 2019 05:18:37 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75CA1120073 for ; Mon, 2 Sep 2019 05:18:37 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id j16so6497853ljg.6 for ; Mon, 02 Sep 2019 05:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=+AHb/Uofw52vAN24Ou8I3t532F7/wECgGeaTekT6dek=; b=HF/HxkG4Y2KRszR+abbC5n80x0eKAjp/ObZId2IHFy1YGNK2njTUXMPUBlho3CXlhY Sc7vt7iAntJIUdHOlQyAgLFL0yQeD1Hp3bXQB9Mq++r1D0LW1E/NVXGWcB2EHm55TZj4 IQwjkGUCjkpEBrtpGf6vGdJJsMp+udDmZVPQldzmpnXTyCAw9trsVlfj0UzUzWMmyQyi P43I3P4Zfh4nmKWsanrr+/x2YCKzC6LSxWkb0FqNywK4XzfgFN0169WtTWKMyUk/nDSw r+UqSfKabFI2d83pOnFUQTH8KzZVMsGSftdSxi7xbrXUm0LkGZhKHUbNkP/bU9ouQT7R IymQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=+AHb/Uofw52vAN24Ou8I3t532F7/wECgGeaTekT6dek=; b=JIDrv605BlgAfWqGKFeAUuq2bfPPqVD0xau6kXRmVn4OHTtEAHClKl5hvCcThI2iBs 9uCLsEUsFmdtFUfPtkkPgsk8VXrIWyjPhe1zCBEWeGqdqFIvm4MLQcxzhkOVW0H4MCS/ vl2XCZuuyq5QCuQuZhbbNogyk6J9lnAcCCcziQD4Wzcg7ZTwZAI+ivPOwe3WVtj4ohzO +s/cbmIXGRcYrFznXBB7DOE3TDLUX+o3Wca85oZn9VoZlsDT7JyHewLqqjMYtFE8ILar 9EYsGb3VcTDEjVDpGn26X3mNQB4uebVIWtT5td7fDlIiV8qmHAQkP8JNnmdxVZkfu1rE /89g== X-Gm-Message-State: APjAAAV7QMTbiCHNA8sUgtkHnQ3Fe8bmbGZH4EgPL5CI1TGqwI8mDpGo JBDiFwV5iQspo0XoraAmlYg= X-Google-Smtp-Source: APXvYqwBb8jPvI6rdO4XPAi1L8XpFBMuge7ITkK/3+SEmdyjMEn/Np7z7wdv4pmju+4PQ0JEkRYiSg== X-Received: by 2002:a2e:5418:: with SMTP id i24mr3811585ljb.126.1567426715843; Mon, 02 Sep 2019 05:18:35 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id f22sm2348498ljh.22.2019.09.02.05.18.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 02 Sep 2019 05:18:35 -0700 (PDT) From: "Valery Smyslov" To: "'Dan Harkins'" , "'Paul Wouters'" Cc: , "'Tero Kivinen'" References: <7538495e-258d-1927-cbba-eb783675c83f@lounge.org> <23912.27054.796487.391930@fireball.acr.fi> <58d82a8c-d789-17ee-12b0-f935d7d2037e@lounge.org> <23912.60438.716153.761077@fireball.acr.fi> In-Reply-To: Date: Mon, 2 Sep 2019 15:18:34 +0300 Message-ID: <019a01d56188$8aeef3e0$a0ccdba0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKemzOesuU/tD3DsDoaNotpDYDw0QICH7oDAPL5BM4B5T6xKgKH0CBqAqW2A8wBf+7rcwIITlNfAa99XCwBt8NaxaT+G8gQ Content-Language: ru Archived-At: Subject: Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Sep 2019 12:18:40 -0000 Hi Dan, > > I did not add killing PSKs to that draft, precisely because some > > objected because strong PSK's are stronger than PAKEs. > > Strong PSKs are not stronger than PAKEs. A PAKE will offer you the added > protection of resistance to dictionary attack against the symmetric > credential > (which could, in fact, be a PSK). That's true. > The definition of dictionary attack is one in which the adversary > gains an > advantage through computation and not interaction. So even with a strong PSK > you are still susceptible to a dictionary attack since it is the > protocol that > is susceptible to attack and not the credential. With a strong PSK it just > makes the dictionary attack use much more time to be successful (and yes the > "true random strong PSK" that's 256 bits could make the attack > computationally > infeasible but then managing such a credential is similarly infeasible). It's a double edged sword. PAKE provides protection against passive attacks, so that easy manageable low entropy secrets can be used as PSKs. But if people get accustomed to use easily memorable low entropy secrets (because we say them that it's secure), then the protocol becomes susceptible to active attacks, and there is no an easy defense against them. Eventually you need to change the secrets frequently, thus making them even less manageable than traditional strong PSKs. Regards, Valery. [...] > regards, > > Dan. > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Sep 10 01:34:05 2019 Return-Path: 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 1287812009E; Tue, 10 Sep 2019 01:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3i3OlMcDTu5; Tue, 10 Sep 2019 01:34:02 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3713F120045; Tue, 10 Sep 2019 01:34:02 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id l20so15545235ljj.3; Tue, 10 Sep 2019 01:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=inZ+Qar2CR2XEeE9fAn7qC7W5f7Dm87E1nSOpiHAAjo=; b=dr/wvmn+C32DV7slPmmZi2zNBOniDbI15MEpDqvwPvc6NErrmODFaipEo/vQfaHX/Z AqRkSgajDQ7u2AM8E2hx4EoW3VYQHXenFbSaS2H/k9qnSEZBgaPXZy8IkwFepFUvou2O TBwhGyOre60Jta70RD7PGgoEqqKqxzESizUSgn3kBv0xQtE4jeJILeWnaTSTGzgXiyXv akNwjVybUv3EVn01yVpNSn+rPilm6FY6A+DYt7d3tqN6Y1gsRLA/1JlkK29iQLL1wngj TgOpag4YfVfJtLjaTn+rPZkEkZFi/NeWustSp1Zo6Wvzdxhj5wvFzoaaWdQW13tsj8aD 4Wmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=inZ+Qar2CR2XEeE9fAn7qC7W5f7Dm87E1nSOpiHAAjo=; b=Hyk0VOtNDxrHIZ8Ztq8pfl1ujgFzNKFD5rxP2Y/BQKGO1oWSptWN2OHIcj7dcrS59O rgP8zrMK/4r83dLXStKD8lwIK18VJb7YBiZu8OdNvHe7eAx61uznP/3868urgwl6HBr3 PmfZPgKS6XxrP3uZ0mdhV4lKlRdS9WqiwCez6ifNlUUUoSRuwCCajy1mtmBBXVFXnSuo BGgl9VzAIF8OicvS+hUBz2DmtutYDR2R+eGio2i0d38BBUsKHsAPePT4oXdGOOl4AjAs Q1AYiBY0cbYATk92UUyIU/vgMBA3bxZ9Mf188DgDZeMl/QDBzU+92KdzIQ29jeHg+TZC lT+Q== X-Gm-Message-State: APjAAAXiD+JCl3SztObt13eIBDW2pSwOlW89jR5Pec+4426JkMqHnHTL b0HUu/yXpAOXpAXRRDuHdy15LEB1 X-Google-Smtp-Source: APXvYqy5O4IAOJFP3w8DtslvtxtQg5uhzjAHDfJPiUfo3Xr8FST9IYAk5m83tdeYJN0si17n3+AbOg== X-Received: by 2002:a2e:3a0e:: with SMTP id h14mr8912614lja.161.1568104440486; Tue, 10 Sep 2019 01:34:00 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id p9sm3674446lji.107.2019.09.10.01.33.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 10 Sep 2019 01:33:59 -0700 (PDT) From: "Valery Smyslov" To: "cfrg@irtf.org" , "IPsecME WG" Cc: Date: Tue, 10 Sep 2019 11:34:00 +0300 Message-ID: <070e01d567b2$7f796740$7e6c35c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdVnsPt51vgTIv/KT7mOGOoTfkhs/g== Content-Language: ru Archived-At: Subject: [IPsec] PAKE selection process - review how PAKEs fit to IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2019 08:34:04 -0000 (sorry for cross-posting) Hi, on CFRG secretary request I volunteered to prepare a review of how each of the eight PAKE candidates can be integrated into the IKEv2. The review is in the form of I-D (see below). Conclusion: IKEv2 is flexible enough to accommodate any of the PAKE candidates. There is already a framework for integrating PAKE protocols into IKEv2, defined in RFC6467. Unfortunately, it has an "Experimental" status and is not widely supported, but I still think using it is a good way to go. The draft also discusses some alternative approaches. Comments are appreciated. Regards, Valery Smyslov. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Tuesday, September 10, 2019 11:11 AM To: Valery Smyslov Subject: New Version Notification for draft-smyslov-ikev2-pake-00.txt A new version of I-D, draft-smyslov-ikev2-pake-00.txt has been successfully submitted by Valery Smyslov and posted to the IETF repository. Name: draft-smyslov-ikev2-pake Revision: 00 Title: Usage of PAKE Protocols with IKEv2 Document date: 2019-09-09 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-smyslov-ikev2-pake-00.txt Status: https://datatracker.ietf.org/doc/draft-smyslov-ikev2-pake/ Htmlized: https://tools.ietf.org/html/draft-smyslov-ikev2-pake-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-smyslov-ikev2-pake Abstract: This memo discusses how PAKE (Password Authenticated Key Exchange) protocols can be integrated into the IKEv2 (Internet Key Exchange) protocol. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sat Sep 21 10:22:28 2019 Return-Path: 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 71965120071 for ; Sat, 21 Sep 2019 10:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZ-UacN_Ga5t for ; Sat, 21 Sep 2019 10:22:22 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1291012004C for ; Sat, 21 Sep 2019 10:22:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.64,532,1559512800"; d="scan'208,217";a="320189898" X-MGA-submission: =?us-ascii?q?MDHTuv9yjz6IPQmyaxg6Shsn+SXkWIl9RFCl5x?= =?us-ascii?q?/kccpPp47Dyon4EoA5oSB3uLhXbJ9OIlSR6gYZFno42FyT1B340ubQYj?= =?us-ascii?q?yDHbScUArzDbvO5GuO4PPd1eRLzPaLJtx/Wb1maPsrV+vgYu63jJAZj7?= =?us-ascii?q?bxFAzUmHrkZwiLr2EdgtxS2w=3D=3D?= Received: from zcs-store1.inria.fr ([128.93.142.28]) by mail3-relais-sop.national.inria.fr with ESMTP; 21 Sep 2019 19:22:19 +0200 Date: Sat, 21 Sep 2019 19:22:19 +0200 (CEST) From: Tristan Ninet To: Paul Wouters Cc: "ipsec@ietf.org WG" , Olivier Zendra , romaric maillard Message-ID: <94576796.2706392.1569086539715.JavaMail.zimbra@inria.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_84d42a1a-e2b6-4f90-a3a3-30fcf375e823" X-Originating-IP: [92.184.116.248] X-Mailer: Zimbra 8.7.11_GA_3800 (ZimbraWebClient - FF69 (Linux)/8.7.11_GA_3800) Thread-Index: MZ5jtk/0ggJ19ZcaM0YjCtR4eGPdkg== Thread-Topic: A Novel Denial-of-Service Attack Against IKEv2 - HAL-Inria Archived-At: Subject: Re: [IPsec] FYI: A Novel Denial-of-Service Attack Against IKEv2 - HAL-Inria X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2019 17:22:27 -0000 --=_84d42a1a-e2b6-4f90-a3a3-30fcf375e823 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Mr. Wouters, Thank you for your interest in our work. > I've read through the paper, and I believe is very much misrepresents what it > deems is a DoS attack against the IKEv2 protocol. > > The DoS attack described seems to think it can change the IP address and cause > Initiator to be authenticated by a different peer than intended (ignoring all of > IDi / IDr payloads it is relaying). Then the different peer is happy, but the > last IKE_AUTH reply to the initiator would signify a failure. Then when the > initiator sends an Informational message with a Delete payload and > AUTHENTICATION_FAILED notify, the attacker drops the message. Now the different > peer has "lost resources" since its IKE SA (and possibly IPsec SA) is up. A > proper implementation would send a Liveness probe if its IPsec SA counters > remain zero. It would also put an idle limit on an childless SA that resulted > from a TS_UNAVAILABLE (as opposed to a by design childless IKE SA) Let us denote Initiator by A, Responder by B, Victim by C, IKE_SA_INIT request by m1, IKE_SA_INIT response by m2, IKE_AUTH request by m3, and IKE_AUTH response by m4. I understand you are saying that authentication of A to C would fail because of IDi and IDr payloads. However, we put as a requirement to the attack that C trusts A, i.e. C has some configuration entry with the ID of A. In this case, authentication will succeed. Regarding the IDr payload, this payload is optional in m3. In fact libreswan does not send this payload in m3 by default. Furhermore, even if IDr is sent in m3, as explained in Section V-C-a) ("Vulnerability of strongSwan") in our paper, the RFC does not mandate to cancel the IKE SA setup if the IDr of m3 does not match C's identity. The RFC says: "If the IDr proposed by the initiator is not acceptable to the responder, the responder might use some other IDr to finish the exchange". This actually suggests that completing the IKE SA setup even if IDr is wrong is OK. So depending on the implementation, even if IDr is sent in m3, an IKE SA could be set up, and the attack could succeed. Therefore, with our requirements, authentication of A to C succeeds, and at least an IKE SA per deviation is up in C. You then say that a proper implementation would send a Liveness probe if its IPsec SA sequence numbers remain zero. The RFC does say that Liveness checks are needed. In this regard, strongswan and libreswan do not follow the RFC since in both implementations, Dead Peer Detection (DPD) is disabled by default. However, DPD does not deter the attack. A classic flooding DoS attack can only set up half-open SAs. An IKEv2 implementation should remove half-open SAs after some short time. In strongswan by default half-open SAs are removed after 30s. Therefore a high-rate of m1 messages is needed to achieve memory exhaustion using classic flooding against IKEv2. However, the Deviation attack sets up full IKE SAs (if not Child SAs as well) in C. We measured that a full connection (one IKE SA + one Child SA) is 23kB in strongswan, whereas a half-open SA is 1kB. This divides by 23 the minimum throughput of m1 messages to deviate in order to exhaust the memory of C. In strongswan, when DPD is enabled, by default, connections with a dead peer (such as in the Deviation Attack) are removed after dpdtimeout + total retransmission timeout = 30s + 165s = 195s. It does not make sense to go much lower, and some implementations might want to set this timeout higher so that bandwidth is not overwhelmed. This longer stay of undesirable connections in C's memory divides by 6 the minimum throughput of m1 messages to deviate in order to exhaust the memory of C. In total the Deviation Attack thus divides the required throughput by 140. In consequence the DA is much harder to detect using intrusion detection systems than classic DoS attacks, in particular when DPD timeout is high. In strongswan, when DPD is disabled, connections with a dead peer are removed at the time of rekeying, i.e. by default 3h. A DoS with a throughput 8000 times lower than classic DoS techniques is then possible. On the other hand, the requirements for the attack are quite strong. Firstly, the attacker needs to have some control over the connection between A and B. Secondly, all Initiator parties authenticate themselves using signature mode and are trusted by Victim. Thirdly, the attacker needs to find enough m1 messages to deviate. In addition, each m1 message must come from a different IKEv2 peer. Otherwise connections will simply replace current connections with the same peer. In fact I did not see this behavior in the RFC, but strongswan behaves this way by default. The contribution of the paper is to point out that when the above requirements are satisfied, then an attacker may perform a DoS attack with a significantly lower throughput than expected from classic flooding techniques. Note in addition that the vulnerability described in our paper is very much not specific to IKEv2. The vulnerability may appear in any stateful protocol that performs authentication and does not satisfy the weak agreement property. I admit however that we do not sufficiently detail the difference between the DA and classic DoS attacks in the paper. Also the version of the paper you read is quite old. It is a version that we submitted to a conference some time ago. We are currently publishing a more recent version at another conference. You also say that a proper implementation would put an idle limit on an childless SA that resulted from a TS_UNAVAILABLE (as opposed to a by design childless IKE SA). I think you mean TS_UNACCEPTABLE. I cannot find this behavior anywhere in the RFC. But even if it is true, the point I made above stays valid. > > It makes more wrong assumptions like "(TS negotiation will fail in most cases)" > which I guess they think would fail because the different peer's have different > IPsec SA configurations, but really if they are that different, they will also > have different IDi/IDr payloads because a peer's configuration with many other > peers for specific subnets would be configured with local/remote IDs as to not > tie these to hardcoded IP addresses. Without explicit ID, the ID used is > normally the ID_IPvx, and if that is used, using an IP address X with ID_IPv4 Y > will also cause an IKE failure of the victim peer because for IP address X it > would then expect ID_IPv4 X. You say that our assumption that TS negotiation will fail in most cases is wrong. Even if this assumption is wrong it only makes the attack stronger, as an even heavier connection is installed in C. You say that authentication using ID_IPvx will fail because A would be using different IP addresses in its IDi and in the source address of the m3 packet. However, in the attack the deviation only changes the destination address, not the source address. Thus no such failure would occur. > > It then "proves" this by using the strongswan/libreswan option uniqueids=no, > which is an non-standard override used to allow multiple IDs to establish more > than one connection. Obviously, such connections MUST use liveness/dpd to kick > out idle connections, because you cannot detect a reconnect from behind NAT from > a different user behind the same NAT, and you would accumulate a lot of > connections from restarting clients that you wouldn't be able to cleanup > otherwise. In our demonstration we decided, for practical reasons, not to create the N Initiator machines of the generic scenario, but instead to only create `N_{demo}` Initiator VMs, with each of them sending `N/N_{demo}` m1 messages to Responder machines. We are using fully virtualized machines (Virtualbox) in our demo, so it would not have been possible to create that many VMs. However, by default in strongSwan, a party requires an IKE ID to be unique among the IKE SAs it manages. That is, when that party receives an m3 message with an IDi payload that is equal to the peer ID of an existing IKE SA in its SAD, it will delete the old IKE SA and replace it with the new one. Because of this in our experiment, the Deviation Attack would add only `N_{demo}` unintended connections in Victim. To stay faithful to the generic scenario, we tell Victim not to delete the old IKE SA in this situation, and instead, to set up the new one alongside. This is done using the "uniqueids=never" option. However, as I said above, the attack does assume that each m1 message comes from a different IKEv2 peer. It is obvious that if the attack works with Ndemo Initiators and the "uniqueids=never" option set in Victim, then it works in the same setup but with N Initiators and without the "uniqueids=never" option in Victim. The above explanation is in appendix E of the version of the paper you read. It is also in the README of the demo. > > Assuming all peers are on dynamic IPs, so no ACL's kick in between the peers > (which would really only happen on a mesh cloud encryption, where an attacker > would be extremely unlikely able to selectively NAT or DROP packets), the DoS > attack would still fail. If peer A tries to talk to peer B and ends up talking > to peer C, then the attack would fail if peer A sends the IDr payload. If it > does not send an IDr payload, then it likely expects the ID_IPv4 later which > wouldn't match when it got redirected to a different peer, using a different > ID_IPv4. But even we assume all of this is true, and the attacker can block the > packets from peer A's delete request to peer C, then yes peer C uses one > connection resource. If peer A attempts a new connection because its connection > failed, the attacker can try this again, but peer C will replace the existing > IKE/IPsec SA in the normal case. So doing the attack twice from the same peer > (who is still trying to connect) will still only lead to one extra unused > connection of peer C. So you would need many peers to get any real amount of > memory wasted on peer C. But if peer C is expecting to be part of a mesh with > _many_ peers, it will have the resources to setup connections with a large > number of peers. Deflecting a few peers through other peers isn't going to > present a different scale level. You say that authentication will fail if A sends IDr. We already discussed this point above. Note that sending an IDr payload in the IKE_AUTH request might be indeed a potential countermeasure to the deviation attack, assuming that the implementation actually rejects incoming IKE_AUTH messages with improper IDr when acting as a responder (behavior that one might expect but once again is not mandated by the RFC). You say that A likely expects the ID_IPv4 later which wouldn't match when it got redirected to a different peer, using a different ID_IPv4. Well of course, and that will make the authentication of C to A fail, but the harm is already done since an SA was set up in C. You say that the attack has strong requirements. We already discussed this point above. It is true that the deviation attack is only successful in very specific conditions but I think that our paper is rather explicit on this point. > > In the case where repeated attempts would not replace the existing connection > (which they emulate using the strongswan/libreswan uniqueids=no option on peer > C), peer C would indeed end up using another one connection of memory. Peer A > would do some kind of back-off on the failures, so maybe you get a one > connection per minute rate. You would still need a lot of peers to DoS peer C, > which again means that peer C is already expected to talk to a lot of peers. At > best you could double the load by sending each peer configured through another > peer. As said above, we do not consider the case where repeated attempts would not replace the existing connection. > > And all this assumes peer C does not remove idle IKE/IPsec SA's, and does not > use liveness/DPD. Which in a mesh peer to peer enterprise network encryption you > would use. In a remote access VPN scenario, there is no "redirect to a different > peer" as all peers only connect to the one security gateway (or a set of > gateways with identical credentials) so 'redirecting' a peer is not possible. As said above, the Deviation Attack works even if C uses DPD, even if less efficient. > > It goes on to say the attack is not possible with PSKs, which I don't > understand. They also then mumbled about asymmetric authentication, which I > don't understand, but regardless is basically only employed with EAPTLS and > Remote Access VPNs, so it does not apply to this attack. When we said that the attack is not possible with PSKs, we assumed that the PSK between A and B is different than the PSK between A and C. In this case, authentication of A to C will fail and the attack does not work because no SA in installed in C. We were not talking about asymmetric encryption. Maybe it was bad phrasing. We were just considering the somehow "asymmetric" (i.e. not the same on both sides) situation where A authenticates himself using signature and C authenticates himself using PSK (in fact we switched A and C in the paper, this is a typo). What we said is that in this situation the attack still works, which is true. As a side note, the above situation is mentioned in the RFC: "There is no requirement that the initiator and responder sign with the same cryptographic algorithms. [...] In particular, the initiator may be using a shared key while the responder may have a public signature key and certificate". I am not sure whether this is a common situation. > > When using PSK with a Group-ID, this "attack" is in fact the actual normal > deployment that implementations already handle. A groupID plus PSK, at least on > libreswan, implies uniqueids=no for free because otherwise each client would > kick of the next client. Now imagine a client on flaky wifi that keeps dropping > and reconnecting. It would actually set up duplicate connections faster than > this entire peer redirection attack. Those configurations better better use > liveness/dpd already to ensure an often reconnecting client is not generating > hundreds of new IKE/IPsec SA's without cleaning up the old ones. (initial > contact cannot be used when using groupID with PSK as all different clients > identify the same). As I said, we only considered the case where the PSK between A and B is different than the PSK between A and C. > > They link to proof of concept code at gitlab.com/deviation/demo but I cannot > access this - it is a private repository. But from the description in the paper, > they only show 3 VMs and one of these connection tricks - and don't show any of > this at scale using containers to see how the target would respond when this > happens at a scale of which this becomes an actual attack. As I said above, the version of the paper you read is quite old. The gitlab repo that this version refers to was an anonymized repo. As later we did not need anonymisation anymore, we switched this repo to private and moved its content to a new public repo at gitlab.inria.fr/tninet/demo. Feel free to check it out. We refer to the above repo in the version of the paper that will soon be published. I agree however that because the version you read is public, we should have kept gitlab.com/deviation/demo public. To this end, we recently set the latter back to public and mirrored it to gitlab.inria.fr/tninet/demo. We actually use Ndemo + 3 VMs (Ndemo Initiators + Victim + Intruder + Probe), which by default in our demo amounts to 6 VMs since we use Ndemo = 3 by default. I already explained above why we do not used all N Initiators and why it does not affect our proof. > > In conclusion, I wish the authors of the paper would have contacted the IPsec > community at IETF or the opensource vendors of strongswan or libreswan before > publication. It also shows the limitations of formal proofs in the absence of > understanding operational deployments and implementation details. And that one > should never describe one's own inventions as "novel". Leave that praise to > others. We should indeed have contacted the IPsec community at IETF and the vendors of strongswan and libreswan. It would have been interesting to discuss the attack with you prior to publication. We hope that the answers and explanations we provided above remove (at least some of) your concerns with this paper. Best Regards, Tristan Ninet --=_84d42a1a-e2b6-4f90-a3a3-30fcf375e823 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear Mr. Wo= uters,

Thank you for your interest in our work.

> I've rea= d through the paper, and I believe is very much misrepresents what it
&g= t; deems is a DoS attack against the IKEv2 protocol.
>
> The D= oS attack described seems to think it can change the IP address and cause> Initiator to be authenticated by a different peer than intended (ign= oring all of
> IDi / IDr payloads it is relaying). Then the different= peer is happy, but the
> last IKE_AUTH reply to the initiator would = signify a failure. Then when the
> initiator sends an Informational m= essage with a Delete payload and
> AUTHENTICATION_FAILED notify, the = attacker drops the message. Now the different
> peer has "lost resour= ces" since its IKE SA (and possibly IPsec SA) is up. A
> proper imple= mentation would send a Liveness probe if its IPsec SA counters
> rema= in zero. It would also put an idle limit on an childless SA that resulted> from a TS_UNAVAILABLE (as opposed to a by design childless IKE SA)
Let us denote Initiator by A, Responder by B, Victim by C, IKE_SA_INI= T request
by m1, IKE_SA_INIT response by m2, IKE_AUTH request by m3, and= IKE_AUTH response
by m4.

I understand you are saying that authen= tication of A to C would fail because of
IDi and IDr payloads.

Ho= wever, we put as a requirement to the attack that C trusts A, i.e. C has so= me
configuration entry with the ID of A. In this case, authentication wi= ll succeed.

Regarding the IDr payload, this payload is optional in m= 3. In fact libreswan
does not send this payload in m3 by default.
Furhermore, even if IDr is sent in m3, as explained in Section V-C-a)
(= "Vulnerability of strongSwan") in our paper, the RFC does not mandate to ca= ncel
the IKE SA setup if the IDr of m3 does not match C's identity. The = RFC says: "If
the IDr proposed by the initiator is not acceptable to the= responder, the
responder might use some other IDr to finish the exchang= e". This actually
suggests that completing the IKE SA setup even if IDr = is wrong is OK. So
depending on the implementation, even if IDr is sent = in m3, an IKE SA could be
set up, and the attack could succeed.

T= herefore, with our requirements, authentication of A to C succeeds, and at<= br>least an IKE SA per deviation is up in C.

You then say that a pro= per implementation would send a Liveness probe if its
IPsec SA sequence = numbers remain zero.

The RFC does say that Liveness checks are neede= d. In this regard, strongswan and
libreswan do not follow the RFC since = in both implementations, Dead Peer
Detection (DPD) is disabled by defaul= t.

However, DPD does not deter the attack. A classic flooding DoS at= tack can only
set up half-open SAs. An IKEv2 implementation should remov= e half-open SAs after
some short time. In strongswan by default half-ope= n SAs are removed after 30s.
Therefore a high-rate of m1 messages is nee= ded to achieve memory exhaustion
using classic flooding against IKEv2.
However, the Deviation attack sets up full IKE SAs (if not Child SAs = as well) in
C. We measured that a full connection (one IKE SA + one Chil= d SA) is 23kB in
strongswan, whereas a half-open SA is 1kB. This divides= by 23 the minimum
throughput of m1 messages to deviate in order to exha= ust the memory of C.

In strongswan, when DPD is enabled, by default,= connections with a dead peer
(such as in the Deviation Attack) are remo= ved after dpdtimeout + total
retransmission timeout =3D 30s + 165s =3D 1= 95s. It does not make sense to go much
lower, and some implementations m= ight want to set this timeout higher so that
bandwidth is not overwhelme= d. This longer stay of undesirable connections in C's
memory divides by = 6 the minimum throughput of m1 messages to deviate in order to
exhaust t= he memory of C.

In total the Deviation Attack thus divides the requi= red throughput by 140. In
consequence the DA is much harder to detect us= ing intrusion detection systems
than classic DoS attacks, in particular = when DPD timeout is high.

In strongswan, when DPD is disabled, conne= ctions with a dead peer are removed at
the time of rekeying, i.e. by def= ault 3h. A DoS with a throughput 8000 times
lower than classic DoS techn= iques is then possible.

On the other hand, the requirements for the = attack are quite strong. Firstly,
the attacker needs to have some contro= l over the connection between A and B.
Secondly, all Initiator parties a= uthenticate themselves using signature mode and
are trusted by Victim. T= hirdly, the attacker needs to find enough m1 messages to
deviate. In add= ition, each m1 message must come from a different IKEv2 peer.
Otherwise = connections will simply replace current connections with the same
peer. = In fact I did not see this behavior in the RFC, but strongswan behaves
t= his way by default.

The contribution of the paper is to point out th= at when the above requirements
are satisfied, then an attacker may perfo= rm a DoS attack with a significantly
lower throughput than expected from= classic flooding techniques.

Note in addition that the vulnerabilit= y described in our paper is very much not
specific to IKEv2. The vulnera= bility may appear in any stateful protocol that
performs authentication = and does not satisfy the weak agreement property.

I admit however th= at we do not sufficiently detail the difference between the DA
and class= ic DoS attacks in the paper. Also the version of the paper you read is
q= uite old. It is a version that we submitted to a conference some time ago. = We
are currently publishing a more recent version at another conference.=

You also say that a proper implementation would put an idle limit o= n an
childless SA that resulted from a TS_UNAVAILABLE (as opposed to a b= y design
childless IKE SA). I think you mean TS_UNACCEPTABLE. I cannot f= ind this behavior
anywhere in the RFC. But even if it is true, the point= I made above stays valid.

>
> It makes more wrong assumpt= ions like "(TS negotiation will fail in most cases)"
> which I guess = they think would fail because the different peer's have different
> I= Psec SA configurations, but really if they are that different, they will al= so
> have different IDi/IDr payloads because a peer's configuration w= ith many other
> peers for specific subnets would be configured with = local/remote IDs as to not
> tie these to hardcoded IP addresses. Wit= hout explicit ID, the ID used is
> normally the ID_IPvx, and if that = is used, using an IP address X with ID_IPv4 Y
> will also cause an IK= E failure of the victim peer because for IP address X it
> would then= expect ID_IPv4 X.

You say that our assumption that TS negotiation w= ill fail in most cases is
wrong. Even if this assumption is wrong it onl= y makes the attack stronger, as an
even heavier connection is installed = in C.

You say that authentication using ID_IPvx will fail because A = would be using
different IP addresses in its IDi and in the source addre= ss of the m3 packet.
However, in the attack the deviation only changes t= he destination address, not
the source address. Thus no such failure wou= ld occur.

>
> It then "proves" this by using the strongswa= n/libreswan option uniqueids=3Dno,
> which is an non-standard overrid= e used to allow multiple IDs to establish more
> than one connection.= Obviously, such connections MUST use liveness/dpd to kick
> out idle= connections, because you cannot detect a reconnect from behind NAT from> a different user behind the same NAT, and you would accumulate a lot = of
> connections from restarting clients that you wouldn't be able to= cleanup
> otherwise.

In our demonstration we decided, for pra= ctical reasons, not to create the N
Initiator machines of the generic sc= enario, but instead to only create
`N_{demo}` Initiator VMs, with each o= f them sending `N/N_{demo}` m1 messages to
Responder machines. We are us= ing fully virtualized machines (Virtualbox) in our
demo, so it would not= have been possible to create that many VMs.

However, by default in = strongSwan, a party requires an IKE ID to be unique among
the IKE SAs it= manages. That is, when that party receives an m3 message with an
IDi pa= yload that is equal to the peer ID of an existing IKE SA in its SAD, it
= will delete the old IKE SA and replace it with the new one. Because of this= in
our experiment, the Deviation Attack would add only `N_{demo}` unint= ended
connections in Victim. To stay faithful to the generic scenario, w= e tell Victim
not to delete the old IKE SA in this situation, and instea= d, to set up the new
one alongside. This is done using the "uniqueids=3D= never" option.

However, as I said above, the attack does assume that= each m1 message comes
from a different IKEv2 peer. It is obvious that i= f the attack works with Ndemo
Initiators and the "uniqueids=3Dnever" opt= ion set in Victim, then it works in the
same setup but with N Initiators= and without the "uniqueids=3Dnever" option in
Victim.

The above = explanation is in appendix E of the version of the paper you read. It
is= also in the README of the demo.

>
> Assuming all peers ar= e on dynamic IPs, so no ACL's kick in between the peers
> (which woul= d really only happen on a mesh cloud encryption, where an attacker
> = would be extremely unlikely able to selectively NAT or DROP packets), the D= oS
> attack would still fail. If peer A tries to talk to peer B and e= nds up talking
> to peer C, then the attack would fail if peer A send= s the IDr payload. If it
> does not send an IDr payload, then it like= ly expects the ID_IPv4 later which
> wouldn't match when it got redir= ected to a different peer, using a different
> ID_IPv4. But even we a= ssume all of this is true, and the attacker can block the
> packets f= rom peer A's delete request to peer C, then yes peer C uses one
> con= nection resource. If peer A attempts a new connection because its connectio= n
> failed, the attacker can try this again, but peer C will replace = the existing
> IKE/IPsec SA in the normal case. So doing the attack t= wice from the same peer
> (who is still trying to connect) will still= only lead to one extra unused
> connection of peer C. So you would n= eed many peers to get any real amount of
> memory wasted on peer C. B= ut if peer C is expecting to be part of a mesh with
> _many_ peers, i= t will have the resources to setup connections with a large
> number = of peers. Deflecting a few peers through other peers isn't going to
>= present a different scale level.

You say that authentication will f= ail if A sends IDr. We already discussed this
point above. Note that sen= ding an IDr payload in the IKE_AUTH request might be
indeed a potential = countermeasure to the deviation attack, assuming that the
implementation= actually rejects incoming IKE_AUTH messages with improper IDr
when acti= ng as a responder (behavior that one might expect but once again is not
= mandated by the RFC).

You say that A likely expects the ID_IPv4 late= r which wouldn't match when it got
redirected to a different peer, using= a different ID_IPv4. Well of course, and
that will make the authenticat= ion of C to A fail, but the harm is already done
since an SA was set up = in C.

You say that the attack has strong requirements. We already di= scussed this point
above. It is true that the deviation attack is only s= uccessful in very specific
conditions but I think that our paper is rath= er explicit on this point.

>
> In the case where repeated = attempts would not replace the existing connection
> (which they emul= ate using the strongswan/libreswan uniqueids=3Dno option on peer
> C)= , peer C would indeed end up using another one connection of memory. Peer A=
> would do some kind of back-off on the failures, so maybe you get a= one
> connection per minute rate. You would still need a lot of peer= s to DoS peer C,
> which again means that peer C is already expected = to talk to a lot of peers. At
> best you could double the load by sen= ding each peer configured through another
> peer.

As said abov= e, we do not consider the case where repeated attempts would not
replace= the existing connection.

>
> And all this assumes peer C = does not remove idle IKE/IPsec SA's, and does not
> use liveness/DPD.= Which in a mesh peer to peer enterprise network encryption you
> wou= ld use. In a remote access VPN scenario, there is no "redirect to a differe= nt
> peer" as all peers only connect to the one security gateway (or = a set of
> gateways with identical credentials) so 'redirecting' a pe= er is not possible.

As said above, the Deviation Attack works even i= f C uses DPD, even if less
efficient.

>
> It goes on to= say the attack is not possible with PSKs, which I don't
> understand= . They also then mumbled about asymmetric authentication, which I
> d= on't understand, but regardless is basically only employed with EAPTLS and<= br>> Remote Access VPNs, so it does not apply to this attack.

Whe= n we said that the attack is not possible with PSKs, we assumed that the PS= K
between A and B is different than the PSK between A and C. In this cas= e,
authentication of A to C will fail and the attack does not work becau= se no SA in
installed in C.

We were not talking about asymmetric = encryption. Maybe it was bad phrasing. We
were just considering the some= how "asymmetric" (i.e. not the same on both sides)
situation where A aut= henticates himself using signature and C authenticates
himself using PSK= (in fact we switched A and C in the paper, this is a typo).
What we sai= d is that in this situation the attack still works, which is true.

A= s a side note, the above situation is mentioned in the RFC: "There is norequirement that the initiator and responder sign with the same cryptograp= hic
algorithms. [...] In particular, the initiator may be using a shared= key while
the responder may have a public signature key and certificate= ". I am not sure
whether this is a common situation.

>
>= ; When using PSK with a Group-ID, this "attack" is in fact the actual norma= l
> deployment that implementations already handle. A groupID plus PS= K, at least on
> libreswan, implies uniqueids=3Dno for free because o= therwise each client would
> kick of the next client. Now imagine a c= lient on flaky wifi that keeps dropping
> and reconnecting. It would = actually set up duplicate connections faster than
> this entire peer = redirection attack. Those configurations better better use
> liveness= /dpd already to ensure an often reconnecting client is not generating
&g= t; hundreds of new IKE/IPsec SA's without cleaning up the old ones. (initia= l
> contact cannot be used when using groupID with PSK as all differe= nt clients
> identify the same).

As I said, we only considered= the case where the PSK between A and B is
different than the PSK betwee= n A and C.

>
> They link to proof of concept code at gitla= b.com/deviation/demo but I cannot
> access this - it is a private rep= ository. But from the description in the paper,
> they only show 3 VM= s and one of these connection tricks - and don't show any of
> this a= t scale using containers to see how the target would respond when this
&= gt; happens at a scale of which this becomes an actual attack.

As I = said above, the version of the paper you read is quite old. The gitlab repo=
that this version refers to was an anonymized repo. As later we did not= need
anonymisation anymore, we switched this repo to private and moved = its content to
a new public repo at gitlab.inria.fr/tninet/demo. Feel fr= ee to check
it out.

We refer to the above repo in the version of = the paper that will soon be
published. I agree however that because the = version you read is public, we
should have kept gitlab.com/deviation/dem= o public. To this end, we recently set
the latter back to public and mir= rored it to gitlab.inria.fr/tninet/demo.

We actually use Ndemo + 3 V= Ms (Ndemo Initiators + Victim + Intruder + Probe),
which by default in o= ur demo amounts to 6 VMs since we use Ndemo =3D 3 by default.
I already = explained above why we do not used all N Initiators and why it does
not = affect our proof.

>
> In conclusion, I wish the authors of= the paper would have contacted the IPsec
> community at IETF or the = opensource vendors of strongswan or libreswan before
> publication. I= t also shows the limitations of formal proofs in the absence of
> und= erstanding operational deployments and implementation details. And that one=
> should never describe one's own inventions as "novel". Leave that = praise to
> others.

We should indeed have contacted the IPsec = community at IETF and the vendors of
strongswan and libreswan. It would = have been interesting to discuss the attack
with you prior to publicatio= n. We hope that the answers and explanations we
provided above remove (a= t least some of) your concerns with this paper.

Best Regards,
Tri= stan Ninet

--=_84d42a1a-e2b6-4f90-a3a3-30fcf375e823-- From nobody Mon Sep 23 00:16:05 2019 Return-Path: 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 B7D9D120114 for ; Mon, 23 Sep 2019 00:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ccf2NBgBkzAj for ; Mon, 23 Sep 2019 00:15:58 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4815612004F for ; Mon, 23 Sep 2019 00:15:58 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id 5so8562841wmg.0 for ; Mon, 23 Sep 2019 00:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=Xs/6y2LlCnhhcbfEK3Gd19xnvGpEVfSUS7fxLCLinZE=; b=L4ho2AdId0qKSqC7mDPgDIEdx6L4vmbGDxKPjZjzqAxnyorGpYt5kwhJ+smj5fdbxt 7UkP8suW8XU0bkY8n9VB1Z62LceiHhqw/YVoIwOZDB64b7KEgJDi2BSJL9/w4nLxDEB4 9gv81QbaJ/IosI7ngiIb+J7bvx6GQtMY97nB/M19b/iVsrhmyzssLbeVonvTCU4vX41p KCVOapr490BxxXZ/1YA1LN20RMkGuSWc+tDt9Y6gb7/bD3c/092u6BL1RUDBSYiCFIdA /YhPIAweoN2pjEagXgEmIUY1eEG+YNEih74QRSDEzag8NOLtc5Feg6OXVvhCrCANDjjr ngUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=Xs/6y2LlCnhhcbfEK3Gd19xnvGpEVfSUS7fxLCLinZE=; b=q6m3ggUdmJaZYBoyJ5ilDuSXgywHoD2EKMXNfl6MwpQOtXyc+REJ+hbY6laGo9j6HV PN2Ety6bO3c8dmMJ7eMo/aOHJt8AoidrBRD3j48fRGe4qBawGaE69iAs5NFvUweLaAin e8tAhIYEvqaww5LUa3v04eMIdLQSiGQMn1DMSemF1s2vEr0c3iO16SCHDd+TVqmgQHEk Bws1pDlAwO4qJwu+pl0g7oAPQ+uUwBBsaouxy/JNyDZ3u4GuM9/L3leUVuyV9kAVwq8i ZnnsnTPE9hLVUKV7MPNreIC7M30zyGk1UqdJ5XMsSsbRJBaH7bUnutAItpIniA7tXiDt UrKw== X-Gm-Message-State: APjAAAX5+yWFm/L3rBCVwTowVHSBev7gnT3r1Hay0b8z4FPpxvARgXWb oJZqZDI7mew00se5hmMtmBGnNISa X-Google-Smtp-Source: APXvYqx5zZhB+JRev99Pr/aKxbXzaW3BeBoGKOK/KtNBoPGyX7vZdM9ztK/bbnPxwCoDCWkTlaO+Qg== X-Received: by 2002:a1c:c1cc:: with SMTP id r195mr13367206wmf.50.1569222956389; Mon, 23 Sep 2019 00:15:56 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id r2sm8583993wrm.3.2019.09.23.00.15.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 23 Sep 2019 00:15:55 -0700 (PDT) From: "Valery Smyslov" To: "'Tristan Ninet'" , "'Paul Wouters'" Cc: , "'Olivier Zendra'" , "'romaric maillard'" References: <94576796.2706392.1569086539715.JavaMail.zimbra@inria.fr> In-Reply-To: <94576796.2706392.1569086539715.JavaMail.zimbra@inria.fr> Date: Mon, 23 Sep 2019 10:15:52 +0300 Message-ID: <023901d571de$bdbbd660$39338320$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_023A_01D571F7.E30B7F60" X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQF7ZKmfV8khvYPhz36pVztOWKzhBafs8DKA Archived-At: Subject: Re: [IPsec] FYI: A Novel Denial-of-Service Attack Against IKEv2 - HAL-Inria X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 07:16:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_023A_01D571F7.E30B7F60 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, I think that the key assumption for this attack to happen is an ability for the attacker to drop packets in the network. Note, that this is quite strong assumption, because it's easier for an attacker to inject packets then to remove them, unless he/she controls some parts of network infrastructure. If attacker is able to drop packets, then a lot of DoS attacks are possible. And I agree with Paul that wise responder should initiate liveness check if case he/she sees no traffic on the just created SA, because AUTHENTICATION_FAILED notification might not reach he/she even without attacker's efforts. It's not in the RFC? but it's just a wise safeguard. At least our implementation does this. Regards, Valery. From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tristan Ninet Sent: Saturday, September 21, 2019 8:22 PM To: Paul Wouters Cc: ipsec@ietf.org WG; Olivier Zendra; romaric maillard Subject: Re: [IPsec] FYI: A Novel Denial-of-Service Attack Against IKEv2 - HAL-Inria Dear Mr. Wouters, Thank you for your interest in our work. > I've read through the paper, and I believe is very much misrepresents what it > deems is a DoS attack against the IKEv2 protocol. > > The DoS attack described seems to think it can change the IP address and cause > Initiator to be authenticated by a different peer than intended (ignoring all of > IDi / IDr payloads it is relaying). Then the different peer is happy, but the > last IKE_AUTH reply to the initiator would signify a failure. Then when the > initiator sends an Informational message with a Delete payload and > AUTHENTICATION_FAILED notify, the attacker drops the message. Now the different > peer has "lost resources" since its IKE SA (and possibly IPsec SA) is up. A > proper implementation would send a Liveness probe if its IPsec SA counters > remain zero. It would also put an idle limit on an childless SA that resulted > from a TS_UNAVAILABLE (as opposed to a by design childless IKE SA) Let us denote Initiator by A, Responder by B, Victim by C, IKE_SA_INIT request by m1, IKE_SA_INIT response by m2, IKE_AUTH request by m3, and IKE_AUTH response by m4. I understand you are saying that authentication of A to C would fail because of IDi and IDr payloads. However, we put as a requirement to the attack that C trusts A, i.e. C has some configuration entry with the ID of A. In this case, authentication will succeed. Regarding the IDr payload, this payload is optional in m3. In fact libreswan does not send this payload in m3 by default. Furhermore, even if IDr is sent in m3, as explained in Section V-C-a) ("Vulnerability of strongSwan") in our paper, the RFC does not mandate to cancel the IKE SA setup if the IDr of m3 does not match C's identity. The RFC says: "If the IDr proposed by the initiator is not acceptable to the responder, the responder might use some other IDr to finish the exchange". This actually suggests that completing the IKE SA setup even if IDr is wrong is OK. So depending on the implementation, even if IDr is sent in m3, an IKE SA could be set up, and the attack could succeed. Therefore, with our requirements, authentication of A to C succeeds, and at least an IKE SA per deviation is up in C. You then say that a proper implementation would send a Liveness probe if its IPsec SA sequence numbers remain zero. The RFC does say that Liveness checks are needed. In this regard, strongswan and libreswan do not follow the RFC since in both implementations, Dead Peer Detection (DPD) is disabled by default. However, DPD does not deter the attack. A classic flooding DoS attack can only set up half-open SAs. An IKEv2 implementation should remove half-open SAs after some short time. In strongswan by default half-open SAs are removed after 30s. Therefore a high-rate of m1 messages is needed to achieve memory exhaustion using classic flooding against IKEv2. However, the Deviation attack sets up full IKE SAs (if not Child SAs as well) in C. We measured that a full connection (one IKE SA + one Child SA) is 23kB in strongswan, whereas a half-open SA is 1kB. This divides by 23 the minimum throughput of m1 messages to deviate in order to exhaust the memory of C. In strongswan, when DPD is enabled, by default, connections with a dead peer (such as in the Deviation Attack) are removed after dpdtimeout + total retransmission timeout = 30s + 165s = 195s. It does not make sense to go much lower, and some implementations might want to set this timeout higher so that bandwidth is not overwhelmed. This longer stay of undesirable connections in C's memory divides by 6 the minimum throughput of m1 messages to deviate in order to exhaust the memory of C. In total the Deviation Attack thus divides the required throughput by 140. In consequence the DA is much harder to detect using intrusion detection systems than classic DoS attacks, in particular when DPD timeout is high. In strongswan, when DPD is disabled, connections with a dead peer are removed at the time of rekeying, i.e. by default 3h. A DoS with a throughput 8000 times lower than classic DoS techniques is then possible. On the other hand, the requirements for the attack are quite strong. Firstly, the attacker needs to have some control over the connection between A and B. Secondly, all Initiator parties authenticate themselves using signature mode and are trusted by Victim. Thirdly, the attacker needs to find enough m1 messages to deviate. In addition, each m1 message must come from a different IKEv2 peer. Otherwise connections will simply replace current connections with the same peer. In fact I did not see this behavior in the RFC, but strongswan behaves this way by default. The contribution of the paper is to point out that when the above requirements are satisfied, then an attacker may perform a DoS attack with a significantly lower throughput than expected from classic flooding techniques. Note in addition that the vulnerability described in our paper is very much not specific to IKEv2. The vulnerability may appear in any stateful protocol that performs authentication and does not satisfy the weak agreement property. I admit however that we do not sufficiently detail the difference between the DA and classic DoS attacks in the paper. Also the version of the paper you read is quite old. It is a version that we submitted to a conference some time ago. We are currently publishing a more recent version at another conference. You also say that a proper implementation would put an idle limit on an childless SA that resulted from a TS_UNAVAILABLE (as opposed to a by design childless IKE SA). I think you mean TS_UNACCEPTABLE. I cannot find this behavior anywhere in the RFC. But even if it is true, the point I made above stays valid. > > It makes more wrong assumptions like "(TS negotiation will fail in most cases)" > which I guess they think would fail because the different peer's have different > IPsec SA configurations, but really if they are that different, they will also > have different IDi/IDr payloads because a peer's configuration with many other > peers for specific subnets would be configured with local/remote IDs as to not > tie these to hardcoded IP addresses. Without explicit ID, the ID used is > normally the ID_IPvx, and if that is used, using an IP address X with ID_IPv4 Y > will also cause an IKE failure of the victim peer because for IP address X it > would then expect ID_IPv4 X. You say that our assumption that TS negotiation will fail in most cases is wrong. Even if this assumption is wrong it only makes the attack stronger, as an even heavier connection is installed in C. You say that authentication using ID_IPvx will fail because A would be using different IP addresses in its IDi and in the source address of the m3 packet. However, in the attack the deviation only changes the destination address, not the source address. Thus no such failure would occur. > > It then "proves" this by using the strongswan/libreswan option uniqueids=no, > which is an non-standard override used to allow multiple IDs to establish more > than one connection. Obviously, such connections MUST use liveness/dpd to kick > out idle connections, because you cannot detect a reconnect from behind NAT from > a different user behind the same NAT, and you would accumulate a lot of > connections from restarting clients that you wouldn't be able to cleanup > otherwise. In our demonstration we decided, for practical reasons, not to create the N Initiator machines of the generic scenario, but instead to only create `N_{demo}` Initiator VMs, with each of them sending `N/N_{demo}` m1 messages to Responder machines. We are using fully virtualized machines (Virtualbox) in our demo, so it would not have been possible to create that many VMs. However, by default in strongSwan, a party requires an IKE ID to be unique among the IKE SAs it manages. That is, when that party receives an m3 message with an IDi payload that is equal to the peer ID of an existing IKE SA in its SAD, it will delete the old IKE SA and replace it with the new one. Because of this in our experiment, the Deviation Attack would add only `N_{demo}` unintended connections in Victim. To stay faithful to the generic scenario, we tell Victim not to delete the old IKE SA in this situation, and instead, to set up the new one alongside. This is done using the "uniqueids=never" option. However, as I said above, the attack does assume that each m1 message comes from a different IKEv2 peer. It is obvious that if the attack works with Ndemo Initiators and the "uniqueids=never" option set in Victim, then it works in the same setup but with N Initiators and without the "uniqueids=never" option in Victim. The above explanation is in appendix E of the version of the paper you read. It is also in the README of the demo. > > Assuming all peers are on dynamic IPs, so no ACL's kick in between the peers > (which would really only happen on a mesh cloud encryption, where an attacker > would be extremely unlikely able to selectively NAT or DROP packets), the DoS > attack would still fail. If peer A tries to talk to peer B and ends up talking > to peer C, then the attack would fail if peer A sends the IDr payload. If it > does not send an IDr payload, then it likely expects the ID_IPv4 later which > wouldn't match when it got redirected to a different peer, using a different > ID_IPv4. But even we assume all of this is true, and the attacker can block the > packets from peer A's delete request to peer C, then yes peer C uses one > connection resource. If peer A attempts a new connection because its connection > failed, the attacker can try this again, but peer C will replace the existing > IKE/IPsec SA in the normal case. So doing the attack twice from the same peer > (who is still trying to connect) will still only lead to one extra unused > connection of peer C. So you would need many peers to get any real amount of > memory wasted on peer C. But if peer C is expecting to be part of a mesh with > _many_ peers, it will have the resources to setup connections with a large > number of peers. Deflecting a few peers through other peers isn't going to > present a different scale level. You say that authentication will fail if A sends IDr. We already discussed this point above. Note that sending an IDr payload in the IKE_AUTH request might be indeed a potential countermeasure to the deviation attack, assuming that the implementation actually rejects incoming IKE_AUTH messages with improper IDr when acting as a responder (behavior that one might expect but once again is not mandated by the RFC). You say that A likely expects the ID_IPv4 later which wouldn't match when it got redirected to a different peer, using a different ID_IPv4. Well of course, and that will make the authentication of C to A fail, but the harm is already done since an SA was set up in C. You say that the attack has strong requirements. We already discussed this point above. It is true that the deviation attack is only successful in very specific conditions but I think that our paper is rather explicit on this point. > > In the case where repeated attempts would not replace the existing connection > (which they emulate using the strongswan/libreswan uniqueids=no option on peer > C), peer C would indeed end up using another one connection of memory. Peer A > would do some kind of back-off on the failures, so maybe you get a one > connection per minute rate. You would still need a lot of peers to DoS peer C, > which again means that peer C is already expected to talk to a lot of peers. At > best you could double the load by sending each peer configured through another > peer. As said above, we do not consider the case where repeated attempts would not replace the existing connection. > > And all this assumes peer C does not remove idle IKE/IPsec SA's, and does not > use liveness/DPD. Which in a mesh peer to peer enterprise network encryption you > would use. In a remote access VPN scenario, there is no "redirect to a different > peer" as all peers only connect to the one security gateway (or a set of > gateways with identical credentials) so 'redirecting' a peer is not possible. As said above, the Deviation Attack works even if C uses DPD, even if less efficient. > > It goes on to say the attack is not possible with PSKs, which I don't > understand.. They also then mumbled about asymmetric authentication, which I > don't understand, but regardless is basically only employed with EAPTLS and > Remote Access VPNs, so it does not apply to this attack. When we said that the attack is not possible with PSKs, we assumed that the PSK between A and B is different than the PSK between A and C. In this case, authentication of A to C will fail and the attack does not work because no SA in installed in C. We were not talking about asymmetric encryption. Maybe it was bad phrasing. We were just considering the somehow "asymmetric" (i.e. not the same on both sides) situation where A authenticates himself using signature and C authenticates himself using PSK (in fact we switched A and C in the paper, this is a typo). What we said is that in this situation the attack still works, which is true. As a side note, the above situation is mentioned in the RFC: "There is no requirement that the initiator and responder sign with the same cryptographic algorithms. [...] In particular, the initiator may be using a shared key while the responder may have a public signature key and certificate". I am not sure whether this is a common situation. > > When using PSK with a Group-ID, this "attack" is in fact the actual normal > deployment that implementations already handle. A groupID plus PSK, at least on > libreswan, implies uniqueids=no for free because otherwise each client would > kick of the next client. Now imagine a client on flaky wifi that keeps dropping > and reconnecting. It would actually set up duplicate connections faster than > this entire peer redirection attack. Those configurations better better use > liveness/dpd already to ensure an often reconnecting client is not generating > hundreds of new IKE/IPsec SA's without cleaning up the old ones. (initial > contact cannot be used when using groupID with PSK as all different clients > identify the same). As I said, we only considered the case where the PSK between A and B is different than the PSK between A and C. > > They link to proof of concept code at gitlab.com/deviation/demo but I cannot > access this - it is a private repository. But from the description in the paper, > they only show 3 VMs and one of these connection tricks - and don't show any of > this at scale using containers to see how the target would respond when this > happens at a scale of which this becomes an actual attack. As I said above, the version of the paper you read is quite old. The gitlab repo that this version refers to was an anonymized repo. As later we did not need anonymisation anymore, we switched this repo to private and moved its content to a new public repo at gitlab.inria.fr/tninet/demo. Feel free to check it out. We refer to the above repo in the version of the paper that will soon be published. I agree however that because the version you read is public, we should have kept gitlab.com/deviation/demo public. To this end, we recently set the latter back to public and mirrored it to gitlab.inria.fr/tninet/demo. We actually use Ndemo + 3 VMs (Ndemo Initiators + Victim + Intruder + Probe), which by default in our demo amounts to 6 VMs since we use Ndemo = 3 by default. I already explained above why we do not used all N Initiators and why it does not affect our proof. > > In conclusion, I wish the authors of the paper would have contacted the IPsec > community at IETF or the opensource vendors of strongswan or libreswan before > publication. It also shows the limitations of formal proofs in the absence of > understanding operational deployments and implementation details. And that one > should never describe one's own inventions as "novel". Leave that praise to > others. We should indeed have contacted the IPsec community at IETF and the vendors of strongswan and libreswan. It would have been interesting to discuss the attack with you prior to publication. We hope that the answers and explanations we provided above remove (at least some of) your concerns with this paper. Best Regards, Tristan Ninet ------=_NextPart_000_023A_01D571F7.E30B7F60 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi,

 

I think that the key assumption for this attack to happen is an = ability

for the attacker to drop packets in the network. Note, that this is =

quite strong assumption, because it’s easier for an attacker to = inject packets

then to remove them, unless he/she controls some parts of network = infrastructure.

 

If attacker is able to drop packets, then a lot of DoS attacks = are possible.

 

And I agree with Paul that wise responder should initiate liveness = check

if case he/she sees no traffic on the just created SA, because =

AUTHENTICATION_FAILED notification might not reach = he/she

even without attacker’s efforts. It’s not in the RFC? but = it’s

just a wise safeguard. At least our implementation does = this.

 

Regards,

Valery.

 

From:= IPsec = [mailto:ipsec-bounces@ietf.org] On Behalf Of Tristan = Ninet
Sent: Saturday, September 21, 2019 8:22 PM
To: = Paul Wouters
Cc: ipsec@ietf.org WG; Olivier Zendra; romaric = maillard
Subject: Re: [IPsec] FYI: A Novel Denial-of-Service = Attack Against IKEv2 - HAL-Inria

 

Dear Mr. = Wouters,

Thank you for your interest in our work.

> = I've read through the paper, and I believe is very much misrepresents = what it
> deems is a DoS attack against the IKEv2 = protocol.
>
> The DoS attack described seems to think it = can change the IP address and cause
> Initiator to be = authenticated by a different peer than intended (ignoring all of
> = IDi / IDr payloads it is relaying). Then the different peer is happy, = but the
> last IKE_AUTH reply to the initiator would signify a = failure. Then when the
> initiator sends an Informational message = with a Delete payload and
> AUTHENTICATION_FAILED notify, the = attacker drops the message. Now the different
> peer has = "lost resources" since its IKE SA (and possibly IPsec SA) is = up. A
> proper implementation would send a Liveness probe if its = IPsec SA counters
> remain zero. It would also put an idle limit = on an childless SA that resulted
> from a TS_UNAVAILABLE (as = opposed to a by design childless IKE SA)

Let us denote Initiator = by A, Responder by B, Victim by C, IKE_SA_INIT request
by m1, = IKE_SA_INIT response by m2, IKE_AUTH request by m3, and IKE_AUTH = response
by m4.

I understand you are saying that = authentication of A to C would fail because of
IDi and IDr = payloads.

However, we put as a requirement to the attack that C = trusts A, i.e. C has some
configuration entry with the ID of A. In = this case, authentication will succeed.

Regarding the IDr = payload, this payload is optional in m3. In fact libreswan
does not = send this payload in m3 by default.

Furhermore, even if IDr is = sent in m3, as explained in Section V-C-a)
("Vulnerability of = strongSwan") in our paper, the RFC does not mandate to = cancel
the IKE SA setup if the IDr of m3 does not match C's identity. = The RFC says: "If
the IDr proposed by the initiator is not = acceptable to the responder, the
responder might use some other IDr = to finish the exchange". This actually
suggests that completing = the IKE SA setup even if IDr is wrong is OK. So
depending on the = implementation, even if IDr is sent in m3, an IKE SA could be
set up, = and the attack could succeed.

Therefore, with our requirements, = authentication of A to C succeeds, and at
least an IKE SA per = deviation is up in C.

You then say that a proper implementation = would send a Liveness probe if its
IPsec SA sequence numbers remain = zero.

The RFC does say that Liveness checks are needed. In this = regard, strongswan and
libreswan do not follow the RFC since in both = implementations, Dead Peer
Detection (DPD) is disabled by = default.

However, DPD does not deter the attack. A classic = flooding DoS attack can only
set up half-open SAs. An IKEv2 = implementation should remove half-open SAs after
some short time. In = strongswan by default half-open SAs are removed after 30s.
Therefore = a high-rate of m1 messages is needed to achieve memory = exhaustion
using classic flooding against IKEv2.

However, the = Deviation attack sets up full IKE SAs (if not Child SAs as well) = in
C. We measured that a full connection (one IKE SA + one Child SA) = is 23kB in
strongswan, whereas a half-open SA is 1kB. This divides by = 23 the minimum
throughput of m1 messages to deviate in order to = exhaust the memory of C.

In strongswan, when DPD is enabled, by = default, connections with a dead peer
(such as in the Deviation = Attack) are removed after dpdtimeout + total
retransmission timeout = =3D 30s + 165s =3D 195s. It does not make sense to go much
lower, and = some implementations might want to set this timeout higher so = that
bandwidth is not overwhelmed. This longer stay of undesirable = connections in C's
memory divides by 6 the minimum throughput of m1 = messages to deviate in order to
exhaust the memory of C.

In = total the Deviation Attack thus divides the required throughput by 140. = In
consequence the DA is much harder to detect using intrusion = detection systems
than classic DoS attacks, in particular when DPD = timeout is high.

In strongswan, when DPD is disabled, connections = with a dead peer are removed at
the time of rekeying, i.e. by default = 3h. A DoS with a throughput 8000 times
lower than classic DoS = techniques is then possible.

On the other hand, the requirements = for the attack are quite strong. Firstly,
the attacker needs to have = some control over the connection between A and B.
Secondly, all = Initiator parties authenticate themselves using signature mode = and
are trusted by Victim. Thirdly, the attacker needs to find enough = m1 messages to
deviate. In addition, each m1 message must come from a = different IKEv2 peer.
Otherwise connections will simply replace = current connections with the same
peer. In fact I did not see this = behavior in the RFC, but strongswan behaves
this way by = default.

The contribution of the paper is to point out that when = the above requirements
are satisfied, then an attacker may perform a = DoS attack with a significantly
lower throughput than expected from = classic flooding techniques.

Note in addition that the = vulnerability described in our paper is very much not
specific to = IKEv2. The vulnerability may appear in any stateful protocol = that
performs authentication and does not satisfy the weak agreement = property.

I admit however that we do not sufficiently detail the = difference between the DA
and classic DoS attacks in the paper. Also = the version of the paper you read is
quite old. It is a version that = we submitted to a conference some time ago. We
are currently = publishing a more recent version at another conference.

You also = say that a proper implementation would put an idle limit on = an
childless SA that resulted from a TS_UNAVAILABLE (as opposed to a = by design
childless IKE SA). I think you mean TS_UNACCEPTABLE. I = cannot find this behavior
anywhere in the RFC. But even if it is = true, the point I made above stays valid.

>
> It makes = more wrong assumptions like "(TS negotiation will fail in most = cases)"
> which I guess they think would fail because the = different peer's have different
> IPsec SA configurations, but = really if they are that different, they will also
> have different = IDi/IDr payloads because a peer's configuration with many other
> = peers for specific subnets would be configured with local/remote IDs as = to not
> tie these to hardcoded IP addresses. Without explicit ID, = the ID used is
> normally the ID_IPvx, and if that is used, using = an IP address X with ID_IPv4 Y
> will also cause an IKE failure of = the victim peer because for IP address X it
> would then expect = ID_IPv4 X.

You say that our assumption that TS negotiation will = fail in most cases is
wrong. Even if this assumption is wrong it only = makes the attack stronger, as an
even heavier connection is installed = in C.

You say that authentication using ID_IPvx will fail because = A would be using
different IP addresses in its IDi and in the source = address of the m3 packet.
However, in the attack the deviation only = changes the destination address, not
the source address. Thus no such = failure would occur.

>
> It then "proves" = this by using the strongswan/libreswan option uniqueids=3Dno,
> = which is an non-standard override used to allow multiple IDs to = establish more
> than one connection. Obviously, such connections = MUST use liveness/dpd to kick
> out idle connections, because you = cannot detect a reconnect from behind NAT from
> a different user = behind the same NAT, and you would accumulate a lot of
> = connections from restarting clients that you wouldn't be able to = cleanup
> otherwise.

In our demonstration we decided, for = practical reasons, not to create the N
Initiator machines of the = generic scenario, but instead to only create
`N_{demo}` Initiator = VMs, with each of them sending `N/N_{demo}` m1 messages to
Responder = machines. We are using fully virtualized machines (Virtualbox) in = our
demo, so it would not have been possible to create that many = VMs.

However, by default in strongSwan, a party requires an IKE = ID to be unique among
the IKE SAs it manages. That is, when that = party receives an m3 message with an
IDi payload that is equal to the = peer ID of an existing IKE SA in its SAD, it
will delete the old IKE = SA and replace it with the new one. Because of this in
our = experiment, the Deviation Attack would add only `N_{demo}` = unintended
connections in Victim. To stay faithful to the generic = scenario, we tell Victim
not to delete the old IKE SA in this = situation, and instead, to set up the new
one alongside. This is done = using the "uniqueids=3Dnever" option.

However, as I = said above, the attack does assume that each m1 message comes
from a = different IKEv2 peer. It is obvious that if the attack works with = Ndemo
Initiators and the "uniqueids=3Dnever" option set in = Victim, then it works in the
same setup but with N Initiators and = without the "uniqueids=3Dnever" option = in
Victim.

The above explanation is in appendix E of the = version of the paper you read. It
is also in the README of the = demo.

>
> Assuming all peers are on dynamic IPs, so no = ACL's kick in between the peers
> (which would really only happen = on a mesh cloud encryption, where an attacker
> would be extremely = unlikely able to selectively NAT or DROP packets), the DoS
> = attack would still fail. If peer A tries to talk to peer B and ends up = talking
> to peer C, then the attack would fail if peer A sends = the IDr payload. If it
> does not send an IDr payload, then it = likely expects the ID_IPv4 later which
> wouldn't match when it = got redirected to a different peer, using a different
> ID_IPv4. = But even we assume all of this is true, and the attacker can block = the
> packets from peer A's delete request to peer C, then yes = peer C uses one
> connection resource. If peer A attempts a new = connection because its connection
> failed, the attacker can try = this again, but peer C will replace the existing
> IKE/IPsec SA in = the normal case. So doing the attack twice from the same peer
> = (who is still trying to connect) will still only lead to one extra = unused
> connection of peer C. So you would need many peers to get = any real amount of
> memory wasted on peer C. But if peer C is = expecting to be part of a mesh with
> _many_ peers, it will have = the resources to setup connections with a large
> number of peers. = Deflecting a few peers through other peers isn't going to
> = present a different scale level.

You say that authentication will = fail if A sends IDr. We already discussed this
point above. Note that = sending an IDr payload in the IKE_AUTH request might be
indeed a = potential countermeasure to the deviation attack, assuming that = the
implementation actually rejects incoming IKE_AUTH messages with = improper IDr
when acting as a responder (behavior that one might = expect but once again is not
mandated by the RFC).

You say = that A likely expects the ID_IPv4 later which wouldn't match when it = got
redirected to a different peer, using a different ID_IPv4. Well = of course, and
that will make the authentication of C to A fail, but = the harm is already done
since an SA was set up in C.

You say = that the attack has strong requirements. We already discussed this = point
above. It is true that the deviation attack is only successful = in very specific
conditions but I think that our paper is rather = explicit on this point.

>
> In the case where repeated = attempts would not replace the existing connection
> (which they = emulate using the strongswan/libreswan uniqueids=3Dno option on = peer
> C), peer C would indeed end up using another one connection = of memory. Peer A
> would do some kind of back-off on the = failures, so maybe you get a one
> connection per minute rate. You = would still need a lot of peers to DoS peer C,
> which again means = that peer C is already expected to talk to a lot of peers. At
> = best you could double the load by sending each peer configured through = another
> peer.

As said above, we do not consider the case = where repeated attempts would not
replace the existing = connection.

>
> And all this assumes peer C does not = remove idle IKE/IPsec SA's, and does not
> use liveness/DPD. Which = in a mesh peer to peer enterprise network encryption you
> would = use. In a remote access VPN scenario, there is no "redirect to a = different
> peer" as all peers only connect to the one = security gateway (or a set of
> gateways with identical = credentials) so 'redirecting' a peer is not possible.

As said = above, the Deviation Attack works even if C uses DPD, even if = less
efficient.

>
> It goes on to say the attack is = not possible with PSKs, which I don't
> understand.. They also = then mumbled about asymmetric authentication, which I
> don't = understand, but regardless is basically only employed with EAPTLS = and
> Remote Access VPNs, so it does not apply to this = attack.

When we said that the attack is not possible with PSKs, = we assumed that the PSK
between A and B is different than the PSK = between A and C. In this case,
authentication of A to C will fail and = the attack does not work because no SA in
installed in C.

We = were not talking about asymmetric encryption. Maybe it was bad phrasing. = We
were just considering the somehow "asymmetric" (i.e. not = the same on both sides)
situation where A authenticates himself using = signature and C authenticates
himself using PSK (in fact we switched = A and C in the paper, this is a typo).
What we said is that in this = situation the attack still works, which is true.

As a side note, = the above situation is mentioned in the RFC: "There is = no
requirement that the initiator and responder sign with the same = cryptographic
algorithms. [...] In particular, the initiator may be = using a shared key while
the responder may have a public signature = key and certificate". I am not sure
whether this is a common = situation.

>
> When using PSK with a Group-ID, this = "attack" is in fact the actual normal
> deployment that = implementations already handle. A groupID plus PSK, at least on
> = libreswan, implies uniqueids=3Dno for free because otherwise each client = would
> kick of the next client. Now imagine a client on flaky = wifi that keeps dropping
> and reconnecting. It would actually set = up duplicate connections faster than
> this entire peer = redirection attack. Those configurations better better use
> = liveness/dpd already to ensure an often reconnecting client is not = generating
> hundreds of new IKE/IPsec SA's without cleaning up = the old ones. (initial
> contact cannot be used when using groupID = with PSK as all different clients
> identify the same).

As = I said, we only considered the case where the PSK between A and B = is
different than the PSK between A and C.

>
> They = link to proof of concept code at gitlab.com/deviation/demo but I = cannot
> access this - it is a private repository. But from the = description in the paper,
> they only show 3 VMs and one of these = connection tricks - and don't show any of
> this at scale using = containers to see how the target would respond when this
> happens = at a scale of which this becomes an actual attack.

As I said = above, the version of the paper you read is quite old. The gitlab = repo
that this version refers to was an anonymized repo. As later we = did not need
anonymisation anymore, we switched this repo to private = and moved its content to
a new public repo at = gitlab.inria.fr/tninet/demo. Feel free to check
it out.

We = refer to the above repo in the version of the paper that will soon = be
published. I agree however that because the version you read is = public, we
should have kept gitlab.com/deviation/demo public. To this = end, we recently set
the latter back to public and mirrored it to = gitlab.inria.fr/tninet/demo.

We actually use Ndemo + 3 VMs (Ndemo = Initiators + Victim + Intruder + Probe),
which by default in our demo = amounts to 6 VMs since we use Ndemo =3D 3 by default.
I already = explained above why we do not used all N Initiators and why it = does
not affect our proof.

>
> In conclusion, I wish = the authors of the paper would have contacted the IPsec
> = community at IETF or the opensource vendors of strongswan or libreswan = before
> publication. It also shows the limitations of formal = proofs in the absence of
> understanding operational deployments = and implementation details. And that one
> should never describe = one's own inventions as "novel". Leave that praise to
> = others.

We should indeed have contacted the IPsec community at = IETF and the vendors of
strongswan and libreswan. It would have been = interesting to discuss the attack
with you prior to publication. We = hope that the answers and explanations we
provided above remove (at = least some of) your concerns with this paper.

Best = Regards,
Tristan Ninet

 <= /span>

------=_NextPart_000_023A_01D571F7.E30B7F60-- From nobody Mon Sep 23 11:07:36 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A1E1200DB; Mon, 23 Sep 2019 11:07:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.102.0 Auto-Submitted: auto-generated Precedence: bulk Sender: CC: ipsecme-chairs@ietf.org, draft-ietf-ipsecme-implicit-iv@ietf.org, Tero Kivinen , kivinen@iki.fi, ipsec@ietf.org, alexey.melnikov@isode.com Content-Transfer-Encoding: 7bit Reply-To: ietf@ietf.org Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156926204805.17123.14844528696780230612.idtracker@ietfa.amsl.com> Date: Mon, 23 Sep 2019 11:07:28 -0700 Archived-At: Subject: [IPsec] Last Call: (Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP)) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 18:07:29 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Implicit IV for Counter-based Ciphers in Encapsulating Security Payload (ESP)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-10-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Encapsulating Security Payload (ESP) sends an initialization vector (IV) or nonce in each packet. The size of IV depends on the applied transform, being usually 8 or 16 octets for the transforms defined by the time this document is written. Some algorithms such as AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not require an unpredictable nonce. When using such algorithms the packet counter value can be used to generate a nonce. This avoids sending the nonce itself, and saves in the case of AES-GCM, AES-CCM, AES-CTR and ChaCha20-Poly1305 8 octets per packet. This document describes how to do this. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ipsecme-implicit-iv/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Sep 26 02:27:18 2019 Return-Path: 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 03C13120863 for ; Thu, 26 Sep 2019 02:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpRsmxa9P1RX for ; Thu, 26 Sep 2019 02:27:13 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CD6120859 for ; Thu, 26 Sep 2019 02:27:12 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTP id x8Q9R9m6015219; Thu, 26 Sep 2019 12:27:09 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x8Q9R83X019737; Thu, 26 Sep 2019 12:27:08 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23948.33900.216096.521743@fireball.acr.fi> Date: Thu, 26 Sep 2019 12:27:08 +0300 From: Tero Kivinen To: Tristan Ninet Cc: Paul Wouters , "ipsec\@ietf.org WG" , Olivier Zendra , romaric maillard In-Reply-To: <94576796.2706392.1569086539715.JavaMail.zimbra@inria.fr> References: <94576796.2706392.1569086539715.JavaMail.zimbra@inria.fr> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 50 min X-Total-Time: 54 min Archived-At: Subject: Re: [IPsec] FYI: A Novel Denial-of-Service Attack Against IKEv2 - HAL-Inria X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 09:27:16 -0000 Tristan Ninet writes: > Dear Mr. Wouters, > > Thank you for your interest in our work. > > > I've read through the paper, and I believe is very much misrepresents what it > > deems is a DoS attack against the IKEv2 protocol. > > > > The DoS attack described seems to think it can change the IP address and cause > > Initiator to be authenticated by a different peer than intended (ignoring all of > > IDi / IDr payloads it is relaying). Then the different peer is happy, but the > > last IKE_AUTH reply to the initiator would signify a failure. Then when the > > initiator sends an Informational message with a Delete payload and > > AUTHENTICATION_FAILED notify, the attacker drops the message. Now the different > > peer has "lost resources" since its IKE SA (and possibly IPsec SA) is up. A > > proper implementation would send a Liveness probe if its IPsec SA counters > > remain zero. It would also put an idle limit on an childless SA that resulted > > from a TS_UNAVAILABLE (as opposed to a by design childless IKE SA) > > Let us denote Initiator by A, Responder by B, Victim by C, IKE_SA_INIT request > by m1, IKE_SA_INIT response by m2, IKE_AUTH request by m3, and IKE_AUTH response > by m4. > > I understand you are saying that authentication of A to C would fail because of > IDi and IDr payloads. Normally authentication from A to C will fail because of different authentication information. I.e., if they are using pre-shared keys the pre-shared key for A to B is different than A to C (unless B and C are part of same infrastructure, i.e., load-sharing or high availaibility pairs). If A is using certificates then usually it has two different CA infrastructures one for B and one for C, so C will not accept certificate meant for B and will fail authentication. You can get this work if B and C are sharing configuration i.e., they are two different gateways in the same adminstrative domain. > However, we put as a requirement to the attack that C trusts A, i.e. C has some > configuration entry with the ID of A. In this case, authentication will succeed. You also put restriction that A shares exactly same authentication information for B and C both. This is not normal for cases where B and C are independent. > You then say that a proper implementation would send a Liveness probe if its > IPsec SA sequence numbers remain zero. > > The RFC does say that Liveness checks are needed. In this regard, strongswan and > libreswan do not follow the RFC since in both implementations, Dead Peer > Detection (DPD) is disabled by default. RFC says: If no cryptographically protected messages have been received on an IKE SA or any of its Child SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. Usually DPD will be have timeout of 10-30 seconds, i.e., after initial silence, i.e., if there is nothing happening in the IKEv2 SA after final IKE_AUTH in few tens of seconds C will send DPD message to A and will not get reply to that, and C will delete the IKE SA after few minutes. > However, DPD does not deter the attack. A classic flooding DoS attack can only > set up half-open SAs. An IKEv2 implementation should remove half-open SAs after > some short time. In strongswan by default half-open SAs are removed after 30s. > Therefore a high-rate of m1 messages is needed to achieve memory exhaustion > using classic flooding against IKEv2. > > However, the Deviation attack sets up full IKE SAs (if not Child SAs as well) in > C. We measured that a full connection (one IKE SA + one Child SA) is 23kB in > strongswan, whereas a half-open SA is 1kB. This divides by 23 the minimum > throughput of m1 messages to deviate in order to exhaust the memory of C. Note, that sending classic flooding attack packets requires no effort from the attacker. Settting up full IKEv2 SA do require Diffie-Hellmans, Certificate verifications etc, thus rate you can set them up is much more limited than classic case. The maximum number of IKEv2 SAs that can be set up each second is usually in order of hundreds or thousands, thus even if it uses 23kB for two minutes (until DPD kicks them out) that is only few gigabytes of memory. Older phones would run out of memory at that point, but newer ones have more memory than that... Also as you are relying for A to set initiate the connection you can only set up one connection per few minutes, as A will not immediately retry connection to B/C when it receives IKE_AUTH message failing authentication. The RFC does not provide instructions for this case, but authentication failure in IKE_AUTH means there is something wrong that most likely will not be automatically fixed, the clients usually wait for some time before retrying. I.e., if you are waiting for adminstrator of either end to go and fix the authentication information in configuration there is no point retrying every second. You can try every 30 seconds without any issues, and still almost immediately detect when other end fixes their configuration. > In strongswan, when DPD is enabled, by default, connections with a dead peer > (such as in the Deviation Attack) are removed after dpdtimeout + total > retransmission timeout = 30s + 165s = 195s. It does not make sense to go much > lower, and some implementations might want to set this timeout higher so that > bandwidth is not overwhelmed. This longer stay of undesirable connections in C's > memory divides by 6 the minimum throughput of m1 messages to deviate in order to > exhaust the memory of C. So if A tries every 30 seconds and C keeps it in memory for 200 seconds that still means we only have 6-7 of them active at one time. Not really proper attack. > In total the Deviation Attack thus divides the required throughput by 140. In > consequence the DA is much harder to detect using intrusion detection systems > than classic DoS attacks, in particular when DPD timeout is high. You seem to be assuming that A will retry immediately when it gets authentication failure? Even if it did that usually the setup time needed for one IKEv2 SA is in order of second or so, so getting more than one connection per second from the same host A is difficult (2 * RTT + Diffie-Hellman calculations + certificate calculations). Even with new connectiona attempt every second you only have few hundred extra IKEv2 SAs. > In strongswan, when DPD is disabled, connections with a dead peer are removed at > the time of rekeying, i.e. by default 3h. A DoS with a throughput 8000 times > lower than classic DoS techniques is then possible. Disabling DPD is bad idea, and if you do that, then you are asking for it... > On the other hand, the requirements for the attack are quite strong. Firstly, > the attacker needs to have some control over the connection between A and B. > Secondly, all Initiator parties authenticate themselves using signature mode and > are trusted by Victim. Thirdly, the attacker needs to find enough m1 messages to > deviate. In addition, each m1 message must come from a different IKEv2 peer. > Otherwise connections will simply replace current connections with the same > peer. In fact I did not see this behavior in the RFC, but strongswan behaves > this way by default. Normally each new connection has INITIAL_CONTACT notification which tells the responder that this replaces all previous connections with same authenticated peers. I assumed you had assumed that INITIAL_CONTACT notifications would have been disabled on A to get this attack working at all, as I assume you forced A to do multiple connections right after each other. On the other hand here you do assume that we simply take normal m1 messages going to B and redirect them to C also, which means that the load of C can at most be same than B, thus you do not really do Denial of Service attack, you just cause some extra load to C. I mean if B and C are required to be part of same authentication infrastructure, you can assume that they have about same amount of resources, thus C has no problem of handling the same load B is having. > The contribution of the paper is to point out that when the above requirements > are satisfied, then an attacker may perform a DoS attack with a significantly > lower throughput than expected from classic flooding techniques. I would say the throughput is much lower than normal operational case on the Monday morning problem. I.e., when gateways are assumed to be able to handle 100-1000 times of normal load every now and then and still process operations without major delays. This throughput seems to be lower than that. > You also say that a proper implementation would put an idle limit on an > childless SA that resulted from a TS_UNAVAILABLE (as opposed to a by design > childless IKE SA). I think you mean TS_UNACCEPTABLE. I cannot find this behavior > anywhere in the RFC. But even if it is true, the point I made above stays valid. Most implementations uses something like 30 second timer for that. If the initiator has some other Child SAs to be set up they will do it immediately after the IKE_AUTH finishes, thus you just need to wait for few tens of seconds for them. If they do not have any other Child SAs to create there is no point of keep extra IKE SA up. RFC do not provide all possible implementation detail, quite a lot of corner cases are left for implementors to solve. RFC8019 does have some discussion about these issues, even though it mostly concentrates on the half open SA problem, as that is hardest to protect against. > > It makes more wrong assumptions like "(TS negotiation will fail in most cases)" > > which I guess they think would fail because the different peer's have different > > IPsec SA configurations, but really if they are that different, they will also > > have different IDi/IDr payloads because a peer's configuration with many other > > peers for specific subnets would be configured with local/remote IDs as to not > > tie these to hardcoded IP addresses. Without explicit ID, the ID used is > > normally the ID_IPvx, and if that is used, using an IP address X with ID_IPv4 Y > > will also cause an IKE failure of the victim peer because for IP address X it > > would then expect ID_IPv4 X. > > You say that our assumption that TS negotiation will fail in most cases is > wrong. Even if this assumption is wrong it only makes the attack stronger, as an > even heavier connection is installed in C. > > You say that authentication using ID_IPvx will fail because A would be using > different IP addresses in its IDi and in the source address of the m3 packet. > However, in the attack the deviation only changes the destination address, not > the source address. Thus no such failure would occur. ID_IPvx and outer IP does not have anything common. It is completely possible and valid for node to send ID_IPv4 identity of 10.0.0.1 from completely different IP-address. From the RFC7296 section 3.5: When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. Also the most common road warrior setup would be any<->any traffic selectors, and leave the narrowing for the responder, so C will happily narrow that range down to something that is useful for him. > However, as I said above, the attack does assume that each m1 message comes > from a different IKEv2 peer. It is obvious that if the attack works with Ndemo > Initiators and the "uniqueids=never" option set in Victim, then it works in the > same setup but with N Initiators and without the "uniqueids=never" option in > Victim. If you assume that each m1 comes for differnet legitimite IKEv2 peer, you only provide work factor of 2, which is very very low... Especially when you compare that to Monday morning problem where work factor might suddenly be raised by 100 or 1000 times the normal load. If you can cause C to provide any kind of visibile change of behavior with work factor of 2 then C is completely misconfigured and underresourced and will fail in normal use every now and then anyways. > > It goes on to say the attack is not possible with PSKs, which I don't > > understand.. They also then mumbled about asymmetric authentication, which I > > don't understand, but regardless is basically only employed with EAPTLS and > > Remote Access VPNs, so it does not apply to this attack. > > When we said that the attack is not possible with PSKs, we assumed that the PSK > between A and B is different than the PSK between A and C. In this case, > authentication of A to C will fail and the attack does not work because no SA in > installed in C. Note, that it is also does not work for certificates, as CA trust anchors configured for B and C are different, thus C will not accept A's certificate as it is not signed by proper CA for C, it is signed with trust anchor used for B. Only time where B and C uses same certificate authorities is when they are part of same authentication domain. In IPsec we do not have similar common trusted CA list than we have in web. Each adminstrative domain will configure the CAs they trust separately, and quite often those CAs are separate CAs only for IPsec use for that specific gateway. -- kivinen@iki.fi From nobody Thu Sep 26 03:50:39 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD81120890; Thu, 26 Sep 2019 03:50:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, kaduk@mit.edu, kivinen@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 6.102.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156949503676.6134.13370406710555775779.idtracker@ietfa.amsl.com> Date: Thu, 26 Sep 2019 03:50:36 -0700 Archived-At: Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 106 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 10:50:37 -0000 A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: suit Technology Overlap: i2nsf curdle tls saag cfrg tcpm Key Participant Conflict: uta 6lo 6tisch lwig ace People who must be present: Tero Kivinen David Waltermire Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Sep 27 11:32:12 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B98B12093F; Fri, 27 Sep 2019 11:31:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern via Datatracker To: Cc: ipsec@ietf.org, ietf@ietf.org, draft-ietf-ipsecme-implicit-iv.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.103.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Joel Halpern Message-ID: <156960911643.12419.11856828548296442014@ietfa.amsl.com> Date: Fri, 27 Sep 2019 11:31:56 -0700 Archived-At: Subject: [IPsec] Genart last call review of draft-ietf-ipsecme-implicit-iv-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 18:31:57 -0000 Reviewer: Joel Halpern Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ipsecme-implicit-iv-07 Reviewer: Joel Halpern Review Date: 2019-09-27 IETF LC End Date: 2019-10-07 IESG Telechat date: Not scheduled for a telechat Summary: THis document is ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A