[IPsec] Do we want to address IKEv2 flaw with cookie processing?

Valery Smyslov <smyslov.ietf@gmail.com> Fri, 11 November 2022 14:53 UTC

Return-Path: <smyslov.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045DEC14CE38 for <ipsec@ietfa.amsl.com>; Fri, 11 Nov 2022 06:53:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61k34ImWMEkB for <ipsec@ietfa.amsl.com>; Fri, 11 Nov 2022 06:53:04 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50A55C14F727 for <ipsec@ietf.org>; Fri, 11 Nov 2022 06:53:04 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id g7so8676959lfv.5 for <ipsec@ietf.org>; Fri, 11 Nov 2022 06:53:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=3PcbZ5ulml1xWN8t0VsCHE0JP7GwS/o/gSB9SDfbEVo=; b=V8KtgmODgcDGaw47YozKJS8CzS2SHJKM4LyKyWx8tGwuMZdCH2ZexKpL7Qu/h8NxL6 Sz8COf0EtIqj2ALsamB80TTbYz4eW4FTIaM7YqQSXbmLX+dEY9OApPBPfArsX7NuGQWI nqs0s0TXwY/7HRzjumrIv2VDUZjAptNzeuXTkUItYilUCXqSJ85FlGFgpcYEhL+EYGaM oqmcIzkTe8TnqYVAUv70WnJ94vefH/GmTIuXcBa2uV0PASFPGe3pIq8i/tcuCgjShQAQ c7eJDHZk5Pn3Ak6Mp6uLl4VNwcaG1DLO++bysm/fqfkWcv1bXfZXqnZGWhq/zaeTf8+G 1t7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3PcbZ5ulml1xWN8t0VsCHE0JP7GwS/o/gSB9SDfbEVo=; b=S0795SQC0twtUiqeILSgqF+6VJP9w9/ug2v8owVmDBZj9L0FOSeNhp9yX0k6TDJ++C EPtmDKQAmIObd0Y05+c4LPm4dIGQzosNVXKEsEvJtu9Y0BkcSYf/RcfXFcTNnpNFZaKZ +n75NgKAKn8KWYjz9P7E9JGoC8pIQuIA/WqucWyyoDYvon5Z4HfibvJesn8KXKPWdfNE nJKlYlY3TzInTVLwLzoJ0pReY8iAUFL0zVuwGadGd7g7LrkzXxNShr68q3ATXRhUL/t+ 801Bac0ncOXB5eP9+YtILEkH+S/Xke9TpighWVbKqBJClGGdvKQFbbn04I0Of9A/fRQf CDGA==
X-Gm-Message-State: ANoB5pl0wYmEpexj786X10Y1bl+fhaxktKox6MLXqUvaaa430KWYqj6V W3IJ4qOC8vl6rCx+Pmj/n0acSrRACFDOZQ==
X-Google-Smtp-Source: AA0mqf6unSUqyyjyoQZ/e82HH/GnqeKOcXEI0RC0K+TUFiSY62AUvO0d3a4goGwXjEuJpz2czMKz1Q==
X-Received: by 2002:ac2:4d59:0:b0:4af:a588:e8bd with SMTP id 25-20020ac24d59000000b004afa588e8bdmr809289lfp.173.1668178381470; Fri, 11 Nov 2022 06:53:01 -0800 (PST)
Received: from buildpc ([93.188.44.204]) by smtp.gmail.com with ESMTPSA id s17-20020a056512315100b004aa95889063sm366708lfi.43.2022.11.11.06.53.00 for <ipsec@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Nov 2022 06:53:01 -0800 (PST)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: IPsecME WG <ipsec@ietf.org>
Date: Fri, 11 Nov 2022 17:52:59 +0300
Message-ID: <08ed01d8f5dd$4af9c4d0$e0ed4e70$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Adj12yT2DVoofbzfS1+mbuCHNerjsg==
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/G5vNaG--_y7KsE3qHR2_yNqNDHA>
Subject: [IPsec] Do we want to address IKEv2 flaw with cookie processing?
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 11 Nov 2022 14:53:08 -0000

Hi,

at the IPSECME@IETF115 I made a presentation (which is actually
was also presented at IETF109) about a minor flaw in IKEv2
which is concerned with cookie processing.

The flaw becomes noticeable in situation when there is high risk
of packet loss and reordering and when the responder either frequently
changes the secret used for cookie generation or frequently changes
its mind whether it needs to request a cookie or not (is it under attack or not).
In this situation there is a risk that the peers erroneously 
fail to authenticate each other.

The details are in the presentation
https://datatracker.ietf.org/meeting/115/materials/slides-115-ipsecme-revised-cookie-processing-in-ikev2-00

The possible solution is proposed in the draft
https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-cookie-revised/

As directed by the chairs I'd like to initiate a discussion 
whether we need to address this flaw and if yes,
then whether the proposed approach is reasonable.

Opinions?

Regards,
Valery.