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

Michael Richardson <mcr+ietf-SWp7JaYWvAQV+D8aMU/[email protected]> Tue, 21 Jul 2020 10:54:25 -0400
Newsgroups	gmane.ietf.anima,gmane.ietf.ipsec
Message-ID	<21070.1595343265@localhost>
Tero Kivinen <[email protected]> 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-SWp7JaYWvAQV+D8aMU/[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
signature.asc (application/pgp-signature, 487 B)