Re: [IPsec] Comments on draft-smyslov-ipsecme-ikev2-auth-announce

Tero Kivinen <kivinen@iki.fi> Tue, 09 November 2021 09:39 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 9E07A3A0D43 for <ipsec@ietfa.amsl.com>; Tue, 9 Nov 2021 01:39:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.43
X-Spam-Level:
X-Spam-Status: No, score=-5.43 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, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi
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 Dj7IN3E128ms for <ipsec@ietfa.amsl.com>; Tue, 9 Nov 2021 01:39:00 -0800 (PST)
Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (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 5F1E33A0D41 for <ipsec@ietf.org>; Tue, 9 Nov 2021 01:38:59 -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 B0BB62004E; Tue, 9 Nov 2021 11:38:54 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1636450734; 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=Imlghb/hUVMrp0mkbiVVi9Hp0dW9kWyAd+Kxu8o0cSU=; b=X4JZupRUjRxRAv6pC7JP1OT2bI1G6ZE02w9lElg0xcJPrArYsOG6aItiU2BrJC81423AUH gaBKhVr12FSjuGoE4+PvdvSAkK1TkKK5YJX0xMxdWU5jU6CTJ3EQeQyMrhwgz7OZTWKiXH jV2b/n4to/BGOquunBZn/oJcJgST1bA=
Received: by fireball.acr.fi (Postfix, from userid 15204) id 3420825C10BB; Tue, 9 Nov 2021 11:38:54 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <24970.16813.881128.590975@fireball.acr.fi>
Date: Tue, 09 Nov 2021 11:38:53 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Paul Wouters <paul.wouters@aiven.io>
Cc: "Scott Fluhrer (sfluhrer)" <sfluhrer=40cisco.com@dmarc.ietf.org>, "ipsec@ietf.org" <ipsec@ietf.org>
In-Reply-To: <2fe9aba6-6ac5-5af4-5439-867c5ad6f053@nohats.ca>
References: <BL3PR11MB5682B8216D3A393B4D1771DBC1919@BL3PR11MB5682.namprd11.prod.outlook.com> <24969.37073.626018.820410@fireball.acr.fi> <2fe9aba6-6ac5-5af4-5439-867c5ad6f053@nohats.ca>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 4 min
X-Total-Time: 4 min
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=1636450734; a=rsa-sha256; cv=none; b=Yg3Vi+O9hU6hvCx5fWxrilgQS1o1/AK+uYvqoh9r7Af9BRTR5axeHRPDOEJyNqVd5F7UUB WBXB2pUHmuGRc3JwfrGq52VTuJuWgyXsnO9vbzpx3JiX8e4SJ+D3yYFeJ7TMmbqJT9uWdy zeh0yq72AXwGhT/CA4ilSJ/QVO4V5Ak=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1636450734; 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=Imlghb/hUVMrp0mkbiVVi9Hp0dW9kWyAd+Kxu8o0cSU=; b=I0fjYYJniIOiZSzgQQb9TAP0BGHha7fqIqyaPDM8dhphGIpn0/nuDt9ChMXrIyXAYcnVYu gwIWxA9euCQ54rSkKSebI9lJZxMkCE1qTzCOHz1+ublV63q0pi9rYqqeURvFQF1q2vPq/z KyG0/HiRODfwFsE7x6ib/B5UmuwtLsI=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/yrSfRPR8Hz-DEKlYPBkTDFrhHlY>
Subject: Re: [IPsec] Comments on 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: Tue, 09 Nov 2021 09:39:06 -0000

Paul Wouters writes:
> On Mon, 8 Nov 2021, Tero Kivinen wrote:
> 
> >> Does the AuthMethod apply to the algorithms within the certificate
> >> as well? The RFC should clarify this.
> >
> > The reason for this notify is that if the peer has multiple key pairs
> > (i.e., private keys) it needs to pick one private key to sign the AUTH
> > payload with. If one of those private keys is using EC and another is
> > using RSA, then without this notification there is no way of knowing
> > which one to pick (except perhaps by prior configuration or by
> > heuristics based on the CERTREQ etc).
> 
> What will be in the notification then? Since the authenticaion method
> for both is "RFC 7425 Digital Signatures" as per existing IANA registry
> for IKEv2 Authentication Methods.

>From the draft:

----------------------------------------------------------------------
   The following format is currently used only with the "Digital
   Signature" (14) authentication method.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Length (>3)  |  Auth Method  |   Cert Link   |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
   |                                                               |
   ~                AlgorithmIdentifier ASN.1 object               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
----------------------------------------------------------------------

I.e., for RFC7425 Digital Signatures, there is also the ASN.1
algorithm identifier to tell which algorithm(s) is/are supported.

> We would still need a new registry or we need to identify auth algorithms
> by their SPKI similar to how we can signature supported hash algorithms.
> But we would prob end up with seeing lots of duplicate entries with
> slightly different SPKI prefixes.

If the Cert Link is zero then the algorithms can be used with any CA,
otherwise they are only to specific CA listed in the CERTREQ, so in
most cases you simply list method 14 few times with the
AlgorithmIdentifiers you support. 

> The RSS-v1.5 vs RSS-PSS is a major pain right now, and implementations
> using 7425 and specifying RSA-v1.5 SHA1 are a double pain as the RFCs
> clearly doesn't allow that. We run into frequent interop issues with
> these.

My understanding is that the one of the reasons for this draft is to
try to solve that issue...
-- 
kivinen@iki.fi