Re: [IPsec] vendor support of RFC7427

Paul Wouters <paul@nohats.ca> Tue, 20 June 2017 17:33 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 471E91315C3 for <ipsec@ietfa.amsl.com>; Tue, 20 Jun 2017 10:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 f_paDzicX5ZL for <ipsec@ietfa.amsl.com>; Tue, 20 Jun 2017 10:33:34 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 7CE951315A2 for <ipsec@ietf.org>; Tue, 20 Jun 2017 10:33:29 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3wsZgq0nWXz1Kv; Tue, 20 Jun 2017 19:33:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1497980007; bh=j0NLpahI07pAYVACxeR8+XyX1ONbWidZKBCVgcDEVMY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=H0dJ/ke2PuGH/jzDbQ1js8uIbXkwoN93EcFtNYHNdxPufu3HgJE+NUpKyN4lZyMA3 BcYHc1eaQpDxA6TKE9DIiMMH9rensx4DwNoMNRz3DSn2nie/qRlMKsM5iyEDAV/EYq Ye6Ayt6uC8UbI/YkFmfsu0dg0yNvbEe9uQHQPFbY=
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 pnN0Pat2yq6C; Tue, 20 Jun 2017 19:33:25 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 20 Jun 2017 19:33:25 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6200D1255FC; Tue, 20 Jun 2017 13:33:24 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 6200D1255FC
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 58CD740D3592; Tue, 20 Jun 2017 13:33:24 -0400 (EDT)
Date: Tue, 20 Jun 2017 13:33:24 -0400
From: Paul Wouters <paul@nohats.ca>
To: Valery Smyslov <svanru@gmail.com>, Sahana Prasad <sahana.prasad07@gmail.com>
cc: IPsecME WG <ipsec@ietf.org>
In-Reply-To: <2FBB5ECC7B8043F2B4E1A6141B3D4FE1@buildpc>
Message-ID: <alpine.LRH.2.21.1706201321020.5686@bofh.nohats.ca>
References: <876523B00C3F9D47BFD2B654D63DBF92BEAA73FA@US70UWXCHMBA05.zam.alcatel-lucent.com> <2FBB5ECC7B8043F2B4E1A6141B3D4FE1@buildpc>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/H5nM-Dlz7E7rkAqNoct_Wp_J1mM>
Subject: Re: [IPsec] vendor support of RFC7427
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.22
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, 20 Jun 2017 17:33:36 -0000

On Mon, 10 Oct 2016, Valery Smyslov wrote:

Valery,

I forgot if we reached any consensus or ideas on the 7427 issue you
brought up in Seoul. Sahana has started work on implementing 7427
for libreswan and during this process we came up with a few questions.

Has there been any discussion about using a hash algorithm that
is different from the one used to sign the CERT (if certificates are
used) ? It seems to not make much sense and lead to false sense of
security if the signature uses SHA2 but the CERT is trusted based on
a SHA1 signature. So, in a way sending more then one hash algorithm
seems to only make sense for raw public keys, not with certificates?

Is it implied that when using SHA2, one twiches the RSA algorithm
variant? If so, how does one know that the old variant is supported?
(I guess that's the issue you brought up in the link below)

Another issue we have in our implementation, is that we don't know which
hash algorithms we allow when needing to send an IKE_INIT response. In
theory, our server could have two connections loaded, one using RSA-SHA1
and one using ECDSA-SHA2. These connections can only be selected
when we receive the IKE_AUTH packet. So our implementation picks one
(sort of randomly) and when processing IKE_AUTH it can "switch" to the
other connection. But we already have to commit to a hash algorithm
in the IKE_INIT reply. And if we are sending ALL the hash algorithms that
we support/implement, then we run the risk of the peer expecting to be
able to use some hash algorithm, but we don't allow it per configuration
for that specific connection (eg the SHA2 one on the RSA-SHA1 connection)
and there is no way to signal that other then AUTHENTICATION_FAILED.

Paul

> Subject: Re: [IPsec] vendor support of RFC7427

> Hi,
>  
> we (ELVIS-PLUS) support RFC7427 for over a year and we are interoperable with Strongswan.
>  
> However, see my message about some interoperability problems:
> https://www.ietf.org/mail-archive/web/ipsec/current/msg10840.html
>  
> This issue is scheduled for discussion on ipsecme meeting in Seoul.
>  
> Regards,
> Valery Smyslov.