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

[Toerless Eckert <[e-mail]>]

On Tue, Jul 21, 2020 at 10:54:25AM -0400, Michael Richardson wrote:
>     > 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.

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.

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

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.

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

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

> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



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


-- 
---
[e-mail]