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

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 21 July 2020 14:54 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 6AD573A09DE; Tue, 21 Jul 2020 07:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 AqdsqLpbuG_g; Tue, 21 Jul 2020 07:54:28 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0653A09DD; Tue, 21 Jul 2020 07:54:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id B0B1938A1E; Tue, 21 Jul 2020 10:34:01 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id S53sxJWtEzh0; Tue, 21 Jul 2020 10:34:00 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2AF0E38A1A; Tue, 21 Jul 2020 10:34:00 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6C3C03F; Tue, 21 Jul 2020 10:54:25 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Tero Kivinen <kivinen@iki.fi>, ipsec@ietf.org, anima@ietf.org
In-Reply-To: <24342.51918.664855.708819@fireball.acr.fi>
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> <24342.51918.664855.708819@fireball.acr.fi>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Tue, 21 Jul 2020 10:54:25 -0400
Message-ID: <21070.1595343265@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/4W3jtX2Wg0blm9xXkJLKLmX53p8>
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 14:54:31 -0000

Tero Kivinen <kivinen@iki.fi> wrote:
    >> 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.

I hope that at no point do we forbid the use of anything.
A peer might not expect it/do anything.
The important part is that we say what pieces we *do* require.
There is one more revision of ACP coming out on Monday, and I hope that is
the last one that the IESG will approve on the next telechat.

    >> 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 think that proper management will probably not be in revision 1 of products.
However, a killer-use-case for the ACP is for SDN control channels, so I
could be wrong.

    >> 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 :-)

I think that we say that we will tolerate RSA :-)
So you are right: there could be devices which do not do ECDSA on day one,
and in which case, you can't switch the keys 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.

Yes, this is an important case.

    >> 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

No, the ACP document has been forced to use otherName in it's
certificates. That's nothing to do with IPsec/IKEv2.
But, that that's what IKEv2 will have to deal with.


--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-