Re: [IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

Valery Smyslov <svan@elvis.ru> Thu, 18 April 2024 13:02 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 ECFB7C1CAF2C; Thu, 18 Apr 2024 06:02:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, 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 I31oWjT1nq_N; Thu, 18 Apr 2024 06:02:35 -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 466DFC14F689; Thu, 18 Apr 2024 06:02:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=elvis.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: Date:Subject:In-Reply-To:References:CC:To:From:Sender:Reply-To: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=Vtx6PBXUl9YQvtCxBezd5J8lfh9ixOih0vA5vtvtK0w=; b=ndzjwXENWDtgTtebbWzoQUg5N6 T/7zpxb/UWLYgJsY7cufNHv9WZ2DlR2gr8pBcEdeuUKnxXD2ZUB8AmP+kx1h4q9YZ+020gxk5KjuN H0jMO4C7ZoYBH9CSqHpFYy/bnT0YKKTsBYMeBzshW84B9gAC84LSVKuH39Nz/cetlUMA=;
Received: from kmail2.elvis.ru ([93.188.44.210]) by dpmail.elvis.ru with esmtp (Exim 4.89) (envelope-from <svan@elvis.ru>) id 1rxROn-0007n2-Ml; Thu, 18 Apr 2024 16:02:00 +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 1rxROn-00EgE0-FP; Thu, 18 Apr 2024 16:01:57 +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; Thu, 18 Apr 2024 16:01:57 +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; Thu, 18 Apr 2024 16:01:57 +0300
From: Valery Smyslov <svan@elvis.ru>
To: 'Paul Wouters' <paul@nohats.ca>
CC: 'Paul Wouters' <paul.wouters@aiven.io>, 'The IESG' <iesg@ietf.org>, draft-ietf-ipsecme-ikev2-auth-announce@ietf.org, ipsecme-chairs@ietf.org, ipsec@ietf.org, kivinen@iki.fi
References: <000c01da9167$b202adf0$160809d0$@elvis.ru> <CF1A94F8-CAC8-4906-81BF-58E2BFDF4F8A@nohats.ca>
In-Reply-To: <CF1A94F8-CAC8-4906-81BF-58E2BFDF4F8A@nohats.ca>
Date: Thu, 18 Apr 2024 16:01:57 +0300
Message-ID: <002501da9190$980e67d0$c82b3770$@elvis.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGSiNaAh9YuwNlSkUq8VwkCsnZedwJpgVxRserCncA=
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/4ZeZLBE2-GbaTmktmSJoT6W0sYc>
Subject: Re: [IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)
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: Thu, 18 Apr 2024 13:02:42 -0000

Hi Paul,

> >> Note that the IANA registry involved here was renamed since the
> >> latest draft was written :)
> >>
> >> Notify Message Type  -> Notify Message Status Type
> >>
> >> "IKEv2 Notify Message Types - Status Types" -> IKEv2 Notify Message
> >> Status Type
> >
> > This is already fixed in my local copy (the IANA was so kind to remind
> > me about this change in a personal message :-))
> 
> Good :)
> 
> >
> >> I wonder if it would make sense to somewhere explain that the
> >> authentication method refers to the AUTH payload,
> >
> > Hmm... I'm not sure where to put this clarification and in which form.
> > I think that there is a chance of over-specification, that might add confusion.
> > You are talking only about signature authentication, and besides that
> > we have PSK. In addition, IKEv2 doesn't require peer ID to match
> > X.509 identity, since they are linked via the local security policy
> > (i.e., it is the policy, which specify which IDs are acceptable and
> > which X.509 identities they correspond to, so the strict matching of
> > them is just a one particular case).
> >
> > If think that this is a real concern, then do you have any concrete text in mind?
> 
> Maybe somewhere say it is the “authentication method used for the AUTH
> payload”.

OK, then how about (Section 3):

CURRENT:
   The receiving party may take this
   information into consideration when selecting an algorithm for its
   authentication if several alternatives are available.

NEW:
   The receiving party may take this
   information into consideration when selecting an algorithm for its
   authentication (i.e., the algorithm used for calculation of the AUTH
   payload) if several alternatives are available.

Does this help?

Regards,
Valery.

> Paul=