Inline
On Sun, Jun 21, 2020 at 11:37:58PM -0400, Paul Wouters wrote:
> On Jun 21, 2020, at 22:22, Toerless Eckert <t...@cs.fau.de> wrote:
> >
> > ???Thanks, Valery
> >
> > let me pick up the one point i have no clear text solution for yet.
> >
> >> On Fri, Feb 28, 2020 at 10:52:02AM +0300, Valery Smyslov wrote:
> >> Hi Toerless,
> > [...]
> >> Well, the example you provided doesn't work. In IKEv2 first
> >> the responder sends a list of TA (hashes) he has in a CERTREQ payload.
> >> When the initiator receives it, he checks the list trying to find
> >> a corresponding TA that signed his certificate (or a chain) and if he
> >> finds one, then he sends
> >> back a bunch of his certificates starting from EE and up to (but not
> >> including) this TA.
> >> If the initiator fails to find a proper TA, then the SA fails and no more
> >> exchanges take place.
> >> If he finds one, then there is absolutely no point to send it back
> >> to the responder, as the responder has indicated already that he has it.
> >> The same happens in the opposite direction.
> >
> >> So I still cannot buy this argument.
> >
> > Ok, so lets assume initiator and responder being routers may have multiple
> > certificates for diffent purposed. The initiator knows it needs to use
> > the ACP certificate because the IKEv2 was triggered for the purpose of ACP
>
> Yes.
>
>
> > The responder can also know that it must use the ACP certificate from the
> > transport address that it listens to:
>
> Yes
>
> > When we assume that initiator and responder can perfectly well constrain
> > themselves to their ACP certificates, it sounds almost as if we would
> > want to mandate to NOT USE CERTREQ, because that would cause
> > termination of the IKEv2 exchange before exchange of certificates
> > takes places.
>
> What is causing termination ?
Thats what i concluded from Valery's description to happen if the
CERTREQ sent does not contain any TA hash that the recipient can
match. If the functionality of CERTREQ is instead such that its
just advisory and the replying side would/could/should still sent
back a cert with a TA not in the CERTREQ , that would be good
to understand.
> > And from what i read in rfc7296, CERTREQ is optional,
> > so we can mandate NOT to use it.
>
> The protocol allows you to send it and allows you to ignore the contents of
> it. That should be fine for your use case.
so if the diagnostics we want would only be possible by ignoring the
CERTREQ, that seems to be an option then which should need to be
made clear in the ACP spec.
Cheers
Toerless
> > If i take our explanation, in the absence of CERTREQ, the initiator
> > would send the cert chain, including TA (additional requiremement from
> > ACP profile), and we would have the necessary informtion on the
> > responder side - even if the mutual authentication then fails.
>
> If you know who it is you are supposed to talking to based on an IP, why do
> you even need a CA chain? Seems two self signed certs configured on both ends
> work too. In that case, the IKE implementation would also not bother with
> CERTREQ (and maybe even CERT, but I???m pretty sure our implementation would
> still send it)
>
> Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
