[IPsec] Potential issue with draft-ietf-ipsecme-ikev2-intermediate

Tero Kivinen <kivinen@iki.fi> Thu, 11 November 2021 14:31 UTC

Return-Path: <kivinen@iki.fi>
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 D28493A03EA for <ipsec@ietfa.amsl.com>; Thu, 11 Nov 2021 06:31:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi
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 MbBmdHpegoYF for <ipsec@ietfa.amsl.com>; Thu, 11 Nov 2021 06:31:34 -0800 (PST)
Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (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 B480A3A033F for <ipsec@ietf.org>; Thu, 11 Nov 2021 06:31:34 -0800 (PST)
Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by meesny.iki.fi (Postfix) with ESMTPSA id 78C3A2004E; Thu, 11 Nov 2021 16:31:26 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1636641086; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UIv7/nWHYq35GaMpNm9fkcyZTuxvaAr43aBibZutbII=; b=wq37zh1D0VX0oWWsaGqMiSsfFOXcxGoJvCw5cT47+fMLQmUv8izmZCUwuwPOAanQFhUD5b 5ASRT9vlI+n3P18TxXKv6U8vHmGEFty+dG249xFc3ZBsHhEH2fHSn28WJis5fy+blG6EAu UXVt9/t0jngT86D62lrdCPKUG4z1F7I=
Received: by fireball.acr.fi (Postfix, from userid 15204) id D342F25C12DB; Thu, 11 Nov 2021 16:31:25 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24973.10557.573056.191679@fireball.acr.fi>
Date: Thu, 11 Nov 2021 16:31:25 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Valery Smyslov <smyslov.ietf@gmail.com>
Cc: IPsecME WG <ipsec@ietf.org>, 'Tobias Brunner' <tobias@strongswan.org>
In-Reply-To: <105001d7d6ce$e76f7f50$b64e7df0$@gmail.com>
References: <105001d7d6ce$e76f7f50$b64e7df0$@gmail.com>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 25 min
X-Total-Time: 27 min
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi
ARC-Seal: i=1; s=meesny; d=iki.fi; t=1636641086; a=rsa-sha256; cv=none; b=r29E4Iuk63kNMSMAOTnbvil3NqoX/I2T7CO9G/uG6Y9M7t9zzGwhl+ryMNlbIDFqv+7urn 2v7K21IpB554kurVMuJ8DiD2A+Dg8stlS4jnA+vyNuTKxPJCSaPIK6tCmS6is7Tp/dT3B4 baf+kfoRuQqXdeVDPygcfyf7rdyLzGk=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1636641086; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UIv7/nWHYq35GaMpNm9fkcyZTuxvaAr43aBibZutbII=; b=aoe0r35Pbb9GtStp6BMWzaK2YCq8r0oQKAXJKke04GYZPpxS8Hbu+sH0qcQoGa9jl/QuKH fXjTFAMss1ExwyOK/fsQpXb5eSKpKOKVLiBUK8O6DNGlWShPX4AkKrqQsXzarso8oJw9lg MydGRNqftt5MKI+OgpWHBIvrTr82Kzs=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/TYp4yI662qSgLX0nP8LJyCsM7nI>
Subject: [IPsec] Potential issue with draft-ietf-ipsecme-ikev2-intermediate
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Nov 2021 14:31:37 -0000

Valery Smyslov writes:
> So, the question to the WG is - what should we do with this:
> 
> 1. Re-define calculation of IntAuth to make it constant in size.
>      This will most probably require another WGLC and will break
>      interoperablity of existing products. The latter seems not so 
>      important (no product has been released yet), but the former 
>      may delay publication process.
> 
> 2. Leave calculation of IntAuth as is and add some text to the
>     Security Considerations section that describes potential 
>     problems and makes advise to the responder (e.g.
>     limit the number of accepted IKE_INTERMEDIATE exchanges).
>     This will not change bits on the wire and hopefully 
>     will not require another WGLC.

My suggestion (as an individual not as a chair) is to add text to
security considerations section where we point out that
implementations should limit the number of IKE_INTERMEDIATE exchanges
they allow to something sensible, like 10 or so.

These are exchanges we are doing before authentication so limiting the
number of them is something we want to do anyways.
-- 
kivinen@iki.fi