Re: [Anima] [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane)

Tero Kivinen <kivinen@iki.fi> Tue, 21 July 2020 11:00 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1506E3A0A4F; Tue, 21 Jul 2020 04:00:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 0uB6dn_Ow6is; Tue, 21 Jul 2020 04:00:38 -0700 (PDT)
Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC543A0A4D; Tue, 21 Jul 2020 04:00:36 -0700 (PDT)
Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id F27731B00093; Tue, 21 Jul 2020 14:00:30 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1595329233; 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=fW4MRMERSVmCRkP0QlaUl3AwOvRUTMqZYp34H7s3rGQ=; b=QflMue2Zz4S+qKMtI2JInlwLLvH8kVTwXLXfiIbHQW5bInPaVt+fHJLNfpw/ZDI6Vp1YUf cEIJEyZ0czwlu+ZiNpn7kIlFpKPFZYjmir3UsGayvqboJo/FDh+7ArC3fcTX//Hmgua5yh 5TEJUtHQ7eCAMJo4lP+kecpKcxY1wjKt80dLV3YjhoFTlt93nME1/AihlP1kZBPoO74Jkx UA5JLuFwWQKhp2/nI5jZDrmF9WIWG2WmRBe56/nT2tcr3y03B8ahZRDXwbWK5CGHmUKpgs ge8njqVom4niCRlUJ8P3zoGEqXCVICYTduAxrhk36lH4f0dj30jXQYpO2UUJiw==
Received: by fireball.acr.fi (Postfix, from userid 15204) id AEF5225C11CC; Tue, 21 Jul 2020 14:00:30 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24342.51918.664855.708819@fireball.acr.fi>
Date: Tue, 21 Jul 2020 14:00:30 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: ipsec@ietf.org, anima@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org
In-Reply-To: <6871.1595023836@localhost>
References: <7EDA9264-8007-4221-9A0D-D967C9AD8BD9@gmail.com> <0b8001d5ecad$79ce7ad0$6d6b7070$@gmail.com> <alpine.LRH.2.21.2002261504240.27113@bofh.nohats.ca> <0c9e01d5ed4c$2353f5a0$69fbe0e0$@gmail.com> <20200619145112.GA47906@faui48f.informatik.uni-erlangen.de> <alpine.LRH.2.22.394.2006191126200.32638@bofh.nohats.ca> <24142.1592760359@localhost> <24309.64229.308771.733097@fireball.acr.fi> <20200626161053.GQ41244@faui48f.informatik.uni-erlangen.de> <24315.37346.143409.46224@fireball.acr.fi> <20200630202812.GF13952@faui48f.informatik.uni-erlangen.de> <24336.33964.354779.953171@fireball.acr.fi> <6871.1595023836@localhost>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 13 min
X-Total-Time: 12 min
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1595329233; 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=fW4MRMERSVmCRkP0QlaUl3AwOvRUTMqZYp34H7s3rGQ=; b=S2KU7u3zyu+tSlBEG/8uLwKCJht9TbFIrNjqM31ygxCU6HqeR11N1ogHUaKxD/TNaMgevv 1lxX5BqFCDi3x0bpIqixgaeP86Zr62Cbr0r58JfsTbafd2GGml6uGxotdMmNj7B5t1ccN3 jtniKfOSEFHxTyjwaEw9z7ULmIe+osv+GsyljJSBKT58/+HE7S28ENGgIeiyxNkilecq3K 3FbRmxFwrbv8bKrCacDK+ndp94GSuJ1Kl+OVISkUt2ZHA4CMk5rQAWElVqKfx9FxbD4EJD UJ5d7FciR5ayc3Ne25NRKPRJ5Y7y9MSE8S5YTn6f42LamPsR18O4PG6pgrih4Q==
ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1595329233; a=rsa-sha256; cv=none; b=WzuPtvO3O+N/R/V81Ixka+crVTgUmqAuy9rgVvb42D8A4aFcIgLPSTv2uUTL+KyeNcveDd eJXxLtVhzxOeNIVHei2q9a7KtvqdWRAqs2IwaPQJf6q7WleTkI712p6TKE4HDUDvHz3WXG 6tlhMCdKBjaJtAI/xlf3wX5I1g/Vq2Hs4dVFb8HkwhCxRVK0PS+VOPFXqmCa4d+tnSt4Xf Thzzw0A+00Fr/mP2mpz05nX4q3aVg5g2MBB5RGS3uQiTszWzsClhoHYJW5gmn0TK43Xp5W T/QGle+HRzlFmgrj4Cs952rM8mTrAUCScf2D/jvITzzvtVOwZbTsTa6Znnq8tA==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/0wHc_0kGaCYmY7Aa98gOuDbfQSc>
Subject: Re: [Anima] [IPsec] Troubleshooting IPsec peer certs (was: Re: IPsec profile feedback wanted (draft autonomic control) plane)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jul 2020 11:00:41 -0000

Michael Richardson writes:
> I am not really following this discussion very well.
> I'm not sure if this is general advice or ACP specific advince.

This discussion was not ACP specific, this was just generic reasons
why CERTREQ etc are usuful in general. Anyways I think most ACP cases
do not need CERTREQ, but on the other hand there might be cases where
it is still useful there, and thats why I would hate to see profile
that forbits its use. I.e., it is fine to say in profile, that
CERTREQs might not be needed, but saying that they should/must not be
sent is bad idea. 

> In the case that you describe (RSA->ECDSA),  I think that we would sign TA1
> with TA2, or vice-versa. (probably one and then the other a month later).
> We can feed/update the trust anchors when certificates are renewed, or we can
> use draft-ietf-netconf-trust-anchors to change things (the advantages of
> having really good security for in-band management)

If you have proper management, then you can do almost instanteneous
changes, but CERTREQ allows you do do similar things even when you do
not have any kind of management system configuring devices, with much
longer overlaps in configuration. 

> I prefer relatively short expiries for certificates in the ACP
> because <STAR reasons>. I think that all systems have to support
> both RSA and ECDSA for a big overlapping period. I don't think this
> is a problem.
> 
> I think that there is not a problem having a RSA key (TA1) sign an
> ECDSA EE cert. I know that I've done it, but I know that some think
> it uncool.

Sometimes the problem is that there are devices there which do not
support ECDSA at all, which means you are stuck with RSA for both root
and EE for all devices. With CERTREQ some parts of the network can
start use full ECDSA TA and EE and still interoperate with those
devices which support both and get the "coolness" factor of not using
RSA at all :-)

Other similar cases comes when you merge authorization domains
together, i.e., two companies merge and they both had their own CAs
before, and not all devices support both CAs, so you need to pick
correct certificate one when talking to one or another device. 

> You are imagining a period of time where we are installing the trust anchors,
> and I don't see it has to be like that.
> 
> Have TA1 sign TA2 as a sub-CA, and then pass out TA1->TA2->EE(ecdsa)
> chain to the new nodes. Once this is done for all nodes, you can
> drop TA1. In reality, there are probably at least an extra level of
> CA, possibly two.
> 
> Do you think that I should include this situation into draft-richardson-registrar-operational-considerations?

The text I provided earlier was just general IPsec case, I have not
checked out situation in this specific case, so I cannot comment on
that before I read that document... 

>     >> The full name of a node was so far an rfc822Name, now i need to
>     >> fix it to become what i think is going to be a GeneralName,
>     >> and hence it might best be to signal IDi/IDr as ID_DER_ASN1_GN
> 
>     > Note, that the IDi and IDr are what is matched against the IPsec
>     > policy, i.e., nothing in the certificate will cause policy to be
>     > selected, only IDi and IDr does that. After IDi and IDr identifies the
>     > suitable policy, we can go and match the information in the policy
>     > against the certificate. That policy might include information like
>     > how to match the certificate subject alt name or subject name to
>     > identity or information in the policy.
> 
> So, we've been forced to use otherName, and this will cause new code in some
> of the IKEv2 daemon that we need to use :-(

No, you are not forced to use anything. Your ID could be KEY_ID with
just random 128-bit binary blob, and you could find your policy entry
based on that. Then in the policy entry there might be information
what should be present in the certificate, or even just hash of the
raw public key (which could be also be sent inside the certificate in
some cases).

IDi and IDr are used to find the policy, policy information is used to
verify that the authorization information provided are correct. That
information usually includes trust anchors, and information what
should be in the certificate signed by those trust anchors.
-- 
kivinen@iki.fi