IETF Logo Mail Archive

Re: [IPsec] WG adoption call for draft-smyslov-ipsecme-ikev2-auth-announce

Paul Wouters <paul@nohats.ca> Mon, 08 November 2021 15:29 UTC

Return-Path: <paul@nohats.ca>
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 EEE503A0D72 for <ipsec@ietfa.amsl.com>; Mon, 8 Nov 2021 07:29:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 L-p0bWiZ1P8a for <ipsec@ietfa.amsl.com>; Mon, 8 Nov 2021 07:29:04 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::85]) (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 67BDB3A0F3A for <ipsec@ietf.org>; Mon, 8 Nov 2021 07:29:04 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Hnw4n3s0Kz3M9; Mon, 8 Nov 2021 16:28:57 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1636385337; bh=1CvTsBVOIS3H1rriZ5DlzUCAdLL5joJ76q6unGx3370=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fKQlA6H37WNGQHbTdrIkntWm0jpraV26DR6Bern8FB3eRbarB7wFEidkOXqnj/+zz l4DqPUvctXNCMA9LNDrx6XjrqFuWriIwBArhWzYzFd8DWghbOKd0AcHuOOKsbJzXrH wYQq5EVcTCdLeDRTOmawb1IxeLYLDnL8xqzzUB48=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id SVNsL73x0dvL; Mon, 8 Nov 2021 16:28:55 +0100 (CET)
Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 8 Nov 2021 16:28:55 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id AD4EA1321A5; Mon, 8 Nov 2021 10:28:54 -0500 (EST)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AA1851321A4; Mon, 8 Nov 2021 10:28:54 -0500 (EST)
Date: Mon, 08 Nov 2021 10:28:54 -0500
From: Paul Wouters <paul@nohats.ca>
To: Tero Kivinen <kivinen@iki.fi>
cc: ipsec@ietf.org
In-Reply-To: <24969.12694.458121.62453@fireball.acr.fi>
Message-ID: <b4daaaf-4547-b0f9-2b6b-7b6793ac7460@nohats.ca>
References: <24969.12694.458121.62453@fireball.acr.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/Pz3A7BZdXIbr_clNX0AAYWZt71w>
Subject: Re: [IPsec] WG adoption call for draft-smyslov-ipsecme-ikev2-auth-announce
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: Mon, 08 Nov 2021 15:29:09 -0000

On Mon, 8 Nov 2021, Tero Kivinen wrote:

>     draft-smyslov-ipsecme-ikev2-auth-announce
> 
> This is the start of 2 week WG adoption call for this document, ending
> 2021-11-22. Please send your reply about whether you support adopting
> this document as WG document or not.

I support working on the idea. I am not sure if this document in its
current form, properly conveys the differences between supported,
accepted and unsupported, rejected. This is especially tricky in the
responder side that does not yet know the ID of the peer and cannot
lookup configuration details yet.

Also, as we have been merging authentication methods into RFC 7427
digital signature format, it is unclear to me how we can convey some
of these parameters using existing IANA registries, since the whole
point here was that we didnt need to create and maintain one. Eg if we
support or allow EDDSA or some new signature algorithm, we might not
have any IANA registry for it, and just stating "we support RFC 7427"
does not solve the actual problem.

Paul

v2.23.0 | Report a Bug | By Email