Re: [IPsec] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06
Valery Smyslov <svan@elvis.ru> Tue, 02 April 2024 07:09 UTC
Return-Path: <svan@elvis.ru>
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 67E77C14F685; Tue, 2 Apr 2024 00:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 (1024-bit key) header.d=elvis.ru
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 eopGkLJGjNNf; Tue, 2 Apr 2024 00:09:37 -0700 (PDT)
Received: from dpmail.elvis.ru (dpmail.elvis.ru [93.188.44.211]) (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 6DDF5C14F684; Tue, 2 Apr 2024 00:09:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=elvis.ru; s=mail; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=LdIfetI1ZIciwo682COwkmqv6wQzzEXeSxBG9XDYJgg=; b=gUmjf8dz/t5lvAAeqa37vh/eLF aP+cC5bM8HT7Xu0nxCd00OzwvbICqUBQvuiPOILxUjS7ZeAIIBdHg2Kv9BE2YvoSr408OwKXDCn4/ 8qDvtbwG6B/sCmVx0MqXt64SppJo/J7OJBjWzC63qxwf3f0c+FUTtkx7qjNwfTIWOuPY=;
Received: from kmail2.elvis.ru ([93.188.44.210]) by dpmail.elvis.ru with esmtp (Exim 4.89) (envelope-from <svan@elvis.ru>) id 1rrYGj-0002UF-5r; Tue, 02 Apr 2024 10:09:17 +0300
Received: from mail.office.elvis.ru ([10.111.1.29]) by kmail2.elvis.ru with esmtp (Exim 4.94.2) (envelope-from <svan@elvis.ru>) id 1rrYGi-00AHxN-Uy; Tue, 02 Apr 2024 10:09:16 +0300
Received: from MAIL16.office.elvis.ru (10.111.1.29) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Tue, 2 Apr 2024 10:09:16 +0300
Received: from BuildPC (10.111.10.33) by MAIL16.office.elvis.ru (10.111.1.29) with Microsoft SMTP Server id 15.1.1779.2 via Frontend Transport; Tue, 2 Apr 2024 10:09:16 +0300
From: Valery Smyslov <svan@elvis.ru>
To: 'Paul Wouters' <paul.wouters@aiven.io>
CC: 'Reese Enghardt' <ietf@tenghardt.net>, gen-art@ietf.org, draft-ietf-ipsecme-ikev2-auth-announce.all@ietf.org, ipsec@ietf.org, last-call@ietf.org
References: <171173986283.29677.15166968196717624638@ietfa.amsl.com> <03f601da8435$abd224e0$03766ea0$@elvis.ru> <CAGL5yWbur5rKfL4yoK5JqcBy1cTSUtcJW-3MWdnw-7yGF-pTTQ@mail.gmail.com>
In-Reply-To: <CAGL5yWbur5rKfL4yoK5JqcBy1cTSUtcJW-3MWdnw-7yGF-pTTQ@mail.gmail.com>
Date: Tue, 02 Apr 2024 10:09:16 +0300
Message-ID: <047001da84cc$acc92870$065b7950$@elvis.ru>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0471_01DA84E5.D218D170"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQLaTwj89V31ruQgk1px0cbnvV3PaQE4tbRXAgEfsBOvOymB0A==
Content-Language: ru
X-CrossPremisesHeadersFilteredBySendConnector: MAIL16.office.elvis.ru
X-OrganizationHeadersPreserved: MAIL16.office.elvis.ru
X-Spam-Scanner: Rspamd work in kmail2.elvis.ru, WHITELIST
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Status: not scanned, disabled by settings
X-KLMS-AntiPhishing: Clean, bases: 2023/02/21 22:47:00
X-KLMS-AntiVirus: Kaspersky Security for Linux Mail Server, version 8.0.3.30, bases: 2023/02/21 21:02:00 #20887462
X-KLMS-AntiVirus-Status: Clean, skipped
X-Spam-Scanner: Rspamd work in dpmail.elvis.ru, WHITELIST
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/3nRs-bH2YPyTd9rGedY1aGJP00A>
Subject: Re: [IPsec] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06
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: Tue, 02 Apr 2024 07:09:41 -0000
Hi Paul, On Mon, Apr 1, 2024 at 9:08 AM Valery Smyslov < <mailto:svan@elvis.ru> svan@elvis.ru> wrote: I've added the following sentence to the Introduction: Since IKEv2 doesn't allow to use multiple authentication methods and doesn't provide means for peers to indicate to the other side which authentication methods they support, it is possible that in these situations the peer which supports wider range of authentication methods (or authentication token formats) improperly selects the method (or format) which is not supported by the other side. I wouldn't phrase it like it, since if we are talking about the peers using different authentication methods (eg client EAPTLS and server X.509 cert) then there are "multiple authentication methods". Also, the server could have multiple configurations for the same peer so a peer could come in using X509 or PSK. I think the core case is that the peers cannot dictate the auth method the peer must use. But this document allows them to inform the peer or what they are going to allow? Although a bit limited because in IKE_SA_INIT, one does not have the peer's identity yet, and different peers might only be allowed specific auth methods. I believe the issue Reese raised was: why we didn’t modify IKEv2 so that each peer was able to try to authenticate with all auth methods it had credentials for – with signature(s), PSK etc., and the SA would be established if at least one of these methods succeeded. I agree that the wording above is imperfect and imprecise. Perhaps: Since IKEv2 requires that each peer uses exactly one authentication method and doesn't provide means for peers to indicate to the other side which authentication methods they support, it is possible that in these situations the peer which supports wider range of authentication methods (or authentication token formats) improperly selects the method (or format) which is not supported by the other side. This is still imprecise since with EAP the server actually authenticates itself with two methods. But perhaps we can leave with this? Or can you propose a better wording? Regards, Valery. Paul
- [IPsec] Genart last call review of draft-ietf-ips… Reese Enghardt via Datatracker
- Re: [IPsec] Genart last call review of draft-ietf… Valery Smyslov
- Re: [IPsec] Genart last call review of draft-ietf… Paul Wouters
- Re: [IPsec] Genart last call review of draft-ietf… Valery Smyslov
- Re: [IPsec] Genart last call review of draft-ietf… Paul Wouters
- Re: [IPsec] Genart last call review of draft-ietf… Reese Enghardt
- Re: [IPsec] [***SPAM***] Re: Genart last call rev… Valery Smyslov
- Re: [IPsec] [***SPAM***] Re: Genart last call rev… Reese Enghardt