On Mon, Jun 22, 2020 at 05:42:00PM +0300, Valery Smyslov wrote:
> 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.
Yepp, figured that from Pauls response.
> > 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?
Yepp.
> Why Issuer DN from the last certificate in the chain before the TA is not
> sufficient?
See other mail.
> > 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.
Ok, thanks. I think ACP can deal with this. Need to heck the
text we have and see whas missing...
Cheers
Toerless
> 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
> > > > > [email protected]
> > > > > https://www.ietf.org/mailman/listinfo/ipsec
> > >
> > > _______________________________________________
> > > IPsec mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/ipsec
> >
> > --
> > ---
> > [email protected]
--
---
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
