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 ? > > > > > And from what i read in rfc7296, CERTREQ is optional, > > so we can mandate NOT to use it. > > This is going to be the same discussion we had with transport mode. You > should not try to modify the IKE protocol. > > The protocol allows you to send it and allows you to ignore the contents of > it. That should be fine for your use case. > > > > 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)
It's not quite "you know who you are talking to based on IP", but more of "under this precondition, you know that the peer should be part of the same ACP domain, and thus using the same TA as you". But you don't know exactly which peer in the domain, and thus which EE cert, you're going to get. The case that (IIUC) triggered this subthread is when things are wired badly and you end up actually talking to someone in a different ACP domain, i.e., with a different TA. We want to be able to report what that "unexpected" TA is, so that the mis-wiring can be diagnosed more readily. -Ben _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
