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