[IPsec] What's the most reasonable way for the responder to handle the request containing unknown Key Exchange methods

Tero Kivinen <kivinen@iki.fi> Mon, 05 February 2024 18:51 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 CB872C14EB19 for <ipsec@ietfa.amsl.com>; Mon, 5 Feb 2024 10:51:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIPDAU0UK2i9 for <ipsec@ietfa.amsl.com>; Mon, 5 Feb 2024 10:51:51 -0800 (PST)
Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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) by ietfa.amsl.com (Postfix) with ESMTPS id 4B330C14F616 for <ipsec@ietf.org>; Mon, 5 Feb 2024 10:51:41 -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 4TTFpf2c3FzyRb; Mon, 5 Feb 2024 20:51:38 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1707159098; 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=rY56/8IU/bJl8XQtUb0b/11oo4h24wrQ3dsowz4CF9k=; b=k5dYfEXBlNVq4T3v5TYwJSmX60F1PwfSxtjP9jAhrpenCpU4dlwfMrsNWi1qfwoAZS9ZWl +9YMk0Ka3g6VaJlCl0LhkaOP14FI3bKb67XWycAaichnlbvVqJOPb/Yv7P8GbP89+ar+CQ dpprHQsQmznYelzGDAyUSWfOrDcbKOo=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1707159098; 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=rY56/8IU/bJl8XQtUb0b/11oo4h24wrQ3dsowz4CF9k=; b=Ou5K0worOAzp1QrZ8QpmgXU1t/yHQ+cC112eRJy5vT746gs+6VX/uhZYkYJoSbR8Px0DEm YkJGuBtbPpqh6OalEKBSeg7VCYXRkIfMMA/Oee4G3cqN57sp9y1Oa9Cop8Jjm4QqNgAgmw gS+V2EEmQnV6tBJQYoJIlfhq1xlXGPg=
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=1707159098; a=rsa-sha256; cv=none; b=gr4VbyoYl2016cup4KtSkQeYl+CeQFxwf1SVRGf3SG0YunzY+kBlhbjV07qHLKgUAJk5Q5 QRreiXxp72i2cElOb+bLbCoCnQc/EBOzXfPL4Oy/bweddJpt8UcrupdY5mS49G/d7rUGLf BedGEzlEWzSvN37nw/XSuwmZVWp6xzY=
Received: by fireball.acr.fi (Postfix, from userid 15204) id AE1D025C12C2; Mon, 5 Feb 2024 20:51:37 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <26049.11833.624551.934540@fireball.acr.fi>
Date: Mon, 05 Feb 2024 20:51:37 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: "Panwei (William)" <william.panwei=40huawei.com@dmarc.ietf.org>
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
In-Reply-To: <5e48af661d63445794b649649519ea65@huawei.com>
References: <5e48af661d63445794b649649519ea65@huawei.com>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 10 min
X-Total-Time: 10 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/gt5GaVgt48_vj8d3uuEDNZTvwT4>
Subject: [IPsec] What's the most reasonable way for the responder to handle the request containing unknown Key Exchange methods
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: Mon, 05 Feb 2024 18:51:53 -0000

Panwei \(William\) writes:
> The handling I suggest is as follows:
> 
>     1) if all KE methods proposed by the initiator are unknown to the
> responder, i.e., no KE method is acceptable, then the responder replies
> NO_PROPOSAL_CHOSEN, no matter what KE method is used in the KE payload.
> 
>     2) if at least one acceptable KE method is included in the initiator’s
> proposals, the responder can select one acceptable KE method, ignore the
> unknown KE methods, and perform the next step of KE Payload processing.
> 
>        2.1) if the KE method used in the KE payload happens to be the same as
> this selected KE method, then the responder normally replies with this
> selected KE method and the corresponding KE payload.
> 
>        2.2) if the KE method used in the KE payload is different from this
> selected KE method, then the responder replies INVALID_KE_PAYLOAD with this
> selected KE method, regardless of whether the KE method used in the KE payload
> is known or unknown to the responder.

This is correct processing.

Note, that any unknown KE method cannot be accaptable for the policy,
thus they are not allowed by the policy, and if there are any KE
methods which are acceptable to policy we use that, and if the KE
payload is not using that you send INVALID_KE_PAYLOAD and indicate the
KE method you want to use. 

This processing is same for the known and unknown KE methods, there is
no difference there.

Of course the initiator will include the exactly same SA payload
listing all those unknown KE methods when it retries with the KE
method listed in the INVALID_KE_PAYLOAD.

> However, others suggest that the responder should terminate the IKE
> exchange without reply, when the KE method used in the KE payload is
> unknown to the responder, even if there are other acceptable KE
> methods proposed in the SA payload.

If there is anything in the RFC7296 that would suggest that kind of
processing is valid, we need to fix that. The RFC7296 tries to be
extendable, thus it tries to ignore unknown values, and process things
without them.

For example in implementation I was familiar with there were not
unknown algorithms, all values for algorithms or methods were valid
from IKEv2 point of view, and those values were then matched against
policy, but of course policy only allowed values that implementation
actually recognized... 

> Because they feel the unknown KE method in the KE payload means that
> the whole packet is an invalid packet, and discarding this packet is
> the thing to do.

I have no idea where they think RFC7296 says anything like that. 
-- 
kivinen@iki.fi