Hi Toerless,
> 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.
>
> The responder can also know that it must use the ACP certificate from the
> transport address that it listens to: This are link-local scope IPv6
> addresses with a UDP port number that is signalled in a discovery protocol.
> That way a responder can bind an IKEv2 instance that has only the ACP
> certificate available.
>
> 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. And from what i read in rfc7296, CERTREQ is optional,
> so we can mandate NOT to use it.
And I think that prohibiting sending CERTREQ is really bad idea for the profile.
The better idea is to require ignoring CERTREQ content on receipt if you think
it's not useful in your use case, but not banning sending it.
> 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 I understand you correctly, you just want to include TA
in CERT payload only for diagnostic purposes, right?
Why Issuer DN from the last certificate in the chain before the TA is not
sufficient?
> I do not fully understand the sequence of events, e.g.: if this approach
> only works for one side (for the responder learning the TA of the
> initiator), or if it would only work for the other side.
Only responder will learn the TA of the initiator.
In case of misconfiguration the responder will receive
the IKE_AUTH request that it will not be able to verify
(because it doesn't have the right TA). In this case
the responder must send back AUTHENTICATION_FAILED
notify, and this is the only information the initiator will obtain.
The reason why authentication failed and the TA the responder
would use will remain unknown for the initiator in this case.
Regards,
Valery.
> Pls. let me know, i can accordingly adjust the text.
>
> > More general thought: each side performs validation of peer's cert by his
> > own,
> > using his own trust assumptions. If peer sends you his TA that he will be
> > using while validating your
> > identity, then it sounds strange to me, because it's his trust anchor, not
> > yours.
> > You even cannot check whether it's expired, because peer's clock may skew
> > from yours...
>
> The signaling of TA is meant to help (human) diagnostics of authentication
> failure,
> not to make authentication successful. The candidate text for rev -25 has 4
> examples.
> Lots of options for misconfigurations in large enterprises, no other way to
> get to the TA of a device trying to connect to you, etc. pp.
>
> Cheers
> Toerless
>
> > Regards,
> > Valery.
> >
> > > > > > 3. IKEv2 authentication MUST use authentication method 14
> > > > > > ("Digital
> > > > > > Signature") for ACP certificates; this authentication method can
> > > > > > be
> > > > > > used with both RSA and ECDSA certificates, as indicated by a
> > > > > > PKIX-
> > > > > > style OID.
> > > > > >
> > > > > > I think it???s better to rephrase this more accurately:
> > > > > > ???indicated by an ASN.1 object
> > > > > > AlgorithmIdentifier???
> > > > >
> > > > > Wouldn't it be more correct to say "indicated by a
> > > > > SubjectPublicKeyInfo
> > > > > (SPKI) ASN.1 object" ?
> > > >
> > > > No, as far as I understand the text, it tells that the particular
> > > > signing algorithm is indicated in the AUTH payload by inclusion its OID.
> > > > That's partially true, it is indicated by inclusion AlgorithmIdentifier
> > > > ASN.1 object
> > > > (and not SubjectPublicKeyInfo or pure OID).
> > > >
> > > > It's probably better to just delete the text in the last sentence "as
> > > > indicated by a PKIX-style OID".
> > >
> > > ;-) Going once, going twice ? ... If not, i'll follow this advice
> > >
> > > Thanks!
> > > Toerless
> > >
> > > > Regards,
> > > > Valery.
> > > >
> > > > > Paul
> > > >
> > > > _______________________________________________
> > > > IPsec mailing list
> > > > IPsec@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/ipsec
> >
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
>
> --
> ---
> t...@cs.fau.de
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
