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

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jul 2020 18:10:36 -0400

Tero Kivinen <[email-masked]> wrote:
    Tero> Note, that initiator might not have any certificate from CA1 or CA2,
    Tero> it might actually use completely different CAs, i.e., the list of
    Tero> certificate authorities can be asymmetric.

    Toerless> Good explanation. So, whats the most simple example for this ?
    Toerless> I have a single VPN but multiple geographic headends and
    Toerless> there is an obfuscated logic what certs each headends accepts,
    Toerless> so i do have multiple and certreq helps me to choose ?

    > I would assume most common case will be when certificates are being
    > renewed in non-compatible way. I.e., you initially have rsa certs for
    > both client and server, then someone decides rsa is weak, and we must
    > move to ecdsa in the future. They will first install new TA certs on
    > the some servers (lets say they have 1000 of those, and they do not
    > want to do all of them immediately). Now some of the servers do have
    > TA1, and some have both TA1, and TA2.

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

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)

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.

    > Next clients needs to get new certificates from TA2. This process can
    > m^Htake months, as it is possible that some of the clients are not
    > connecting to the server for long time.

That's true in general, particularly for remote access situations, but ACP
nodes are mostly always reachable.  If they get turned off and put in a box,
then when they return, they have a valid certificate, or they have to
bootstrap again, and that's okay.

    > If you have client which has only TA1, there is no problem, it can
    > connect to any server which still supports TA1. If you have client
    > which has both TA1, and TA2, and it connects to old server which only
    > supports TA1, it needs to recognize this and use TA1 in that case. If
    > it connects to server using both TA1, and TA2, it most likely wants to
    > prefer TA2, as that is the direction the transition is going, so TA2
    > should be preferred if both are supported.

    > When all servers have been updated to support both TA1, and TA2, then
    > there is no longer issues, as now all clients which do have TA2, use
    > it for all servers, and those which have not yet updated to TA1, still
    > use that.

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?

    > So the idea is to allow iterative updating of the system, without the
    > need of flag days or configuration settings to specify things. I.e.,
    > IKEv2 will automatically detect which TA is supposed to be used, and
    > use it.

Agreed.

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

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 21 Jul 2020 14:00:30 +0300

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

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

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

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

> 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.
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 10:54:25 -0400

> CERTREQs might not be needed, but saying that they should/must not be

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.

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

    > devices which support both and get the "coolness" factor of not using

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.

    > correct certificate one when talking to one or another device.

Yes, this is an important case.

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

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 23 Jul 2020 13:53:36 +0200

> and in which case, you can't switch the keys at all.

I don't think this issue applies to ACP because both RSA and ECC / ECDSA
certificates are mandatory. Please check draft-ietf-anima-autonomic-control-plane-27,
section 6.1.1. I hope this should be sufficient, if not, then any text
fixes welcome.

Remember that ACP is not only summetric (no dedicated client/servers), but
also greenfield: aka: no need to think about IN THIS REVISION OF ACP about
legacy compatibility. IF/WHEN in the future we do provide update/extensions
to ACP, THEN we may get into considerations for two generations of nodes
talking to each other.

> Yes, this is an important case.

Right now, draft-ietf-anima-autonomic-control-plane-27 does only specify to still
send a certificate, even if a CERTREQ was received from the peer, and no certificate
would match the TA in the CERTREQ. We discussed how this was for diagnostics.
See section 6.7.3.1.2.

There is nothing in the current ACP text to say whether or not to send CERTREQ
right now. Given how the ACP just provides a refinement profile in section
6.7.3.1.2. on top of RFC8247, and given how RFC8247 does not mention CERTREQ,
that leaves is with a "MAY send CERTREQ" (i paraphrase) from RFC7296 section
3.8.

The domain merge is also of interest in ACP, so we could add a stronger
requirement against CERTREQ, but given how the documents we reference
(RFC8247/RFC7296), i am a bit suspicious about doing so. If CERTREQ is
so useful in non-ACP use caes, why is there no stronger than MAY in RFC7296
or RFC8247 ? Oversight in those IKEv2 RFCs ? Or are there some downsides
coming with it ?

I don't think i will add suc a requirement in this ACP spec because it
may be necessary to make the merge case work, but it is not sufficient,
and the set of components sufficient to support that use case is is
beyond the scope of this ACP base spec.

To give a hint: We only mandate use of EST, and if i wanted to support
a merge, or in general any use case where CERTREQ was useful, then i would
need to have nodes that would have two or more certs and CERTREQ is a
way to pick one of those multiple certs. And EST to the best of my
understandig does not allow to hand out more than one cert to a single
node. At least thats what i remember from having asked the quesrtion a few
times over the last 5 years.

We can still make merge work through extension documents, even without
fixing that EST limitation itself through other extensions of ACP, but
i think we would want a discuss first whether to rater do that or fix EST.

Or someone comes around and tells me this time that EST can be somehow
tricked to provide multiple certs to a single node.

> But, that that's what IKEv2 will have to deal with.

Actually, the ACP text currently says to use ID_IPV6_ADDR, but given how
the name of the ACP node is now an otherName, we _could_ signal it
via ID_DER_ASN1_GN, but IMHO ID_IPV6_ADDR is better.

Cheers
    Toerless

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

-- 
---
[email-masked]