Hi Toerless,
> Thanks.
>
> I think ACP has no specific encoding preference for the
> exchanged certificates, but we do of course MUST support BRSKI
> enrolled certificate (chains), and i think PKS#7 is MTI there (Michael ?).
>
> Can PKS#7 certificate chains be converted locally into any potential
> other possible IKEv2 supported encoding format ? Then i think ACP
> is open to pick any encoding you could suggest to us. Othewise
> PKCS#7 is the safe ACP requirement.
I believe it's possible to convert. The encoding most widely used
is "X.509 Certificate - Signature", so it's just a certificate without
any envelopes. You may include as many CERT payloads as you wish,
each containing a single certificate. The is also an encoding
for CRLs ("Certificate Revocation List (CRL)").
But as others have already suggested, I'd rather remove all this
certificates stuff from the draft and just point to the RFC7296.
> More inline.
>
> On Thu, Feb 27, 2020 at 11:58:53AM +0300, Valery Smyslov wrote:
> > Hi Paul,
> >
> > > > 1. The
> > > > Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be
> > > > supported. See [IKEV2IANA] for this and other IANA IKEv2 parameter
> > > > names used in this text.
> > > >
> > > > ???PKCS #7 wrapped X.509 certificate??? certificate encoding is
> > > > deprecated and is not used in IKEv2
> > > > (see
> > > > https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-
> parameters-
> > > 11).
> > > > Generally, I see no need for the text that imposes requirements on
> > > > certificate encoding at all ???
> > > > we never run into the interoperability problems with this? as far
> > > > as I remember. I suggest to remove
> > > > this text.
> > >
> > > Actually we do. We had to add pkcs7 to ikev2 to be compatible with some
> > > windows deployments when intermediate certificates were being sent. On
> > > top of that, Microsoft did it wrong, as the format does not allow a
> > > chain but they added more than one anyway. So if anything, we DO NOT
> > > want to see more pkcs7 in IKEv2.
> >
> > We do support PKCS#7 too, but officially it's not specified for IKEv2 and
> > thus must not be specified in the profile.
>
> Ok. Great. I read this as you think this requirement is necessary
> to ensure peers can interoperate in exchaning their cert chains
> during IKEv2.
No, we just inherited this support from IKEv1 and didn't removed it from IKEv2
code,
thus slightly violating IKEv2 spec. It's just an implementation feature and I
object
if any IKEv2 based profile will allow it.
> > > > and including the locally provisioned trust anchor certificate MUST
> > > > be signaled. See Section 6.10.7 for the sub-CA example in which
> > > > certificate chains are used.
> > > >
> > > > This is confusing. I read this text as the ???MUST??? is imposed
> > > > only if
> > > > ???certificate chains are used???. Does it mean that implementations
> > > > may skip this ???MUST??? if EE certificate is directly signed by CA
> > > > certificate
> > > > and there is no intermediate certificates? Or is it still a chain
> > > > and ???if??? is relevant to the case when there is no CA and there
> > > > is a direct trust to EE certificates
> > > > (in which case PKI is not needed at all and you can use RAW public
> > > > keys)?
> > >
> > > I agree it should not try to dictate how certificate based IKE
> > > certification works, but just reference to IKEv2 and its updates for
> > > that.
> >
> > That was my point :-)
>
> There are two things here:
>
> -> Originally i wrote the text without need to include TA in the
> signaled cert chain. Reason: I worked with IPsc implementations
> that did not signal/verify cert chains, and i also think to remember
> that i discussed and was told that the specs do not mandate this,
> so that behavor was a valid option. If you can confirm, that
> compliance with IKEv2 MANDATES the need to signal cert chain
> (eg: through MUST in one of the MANDATORY normative PKI
> references), then i could remove the text if we wanted just to
> have "standard behavior".
>
> -> Michael wanted the additional signaling of the TA for diagnostic
> purposes. When this was added, the original text was not correctly
> adjusted, so now it sounds as if this all only applies IF there is
> more than the node cert and a root (no intermediate CA). That of
> course is wrong. We would always want to signal the cert chain
> including TA (remove "if..." condition).
Again, as Paul and others have suggested, I'd remove all
certificates-transfer-in-IKEv2 stuff
from the profile and just reference RFC7296. This part of IKEv2 never caused
interoperability problems (AFAIK), so I see no need to mandate IKEv2 behavior
here.
> > > > Another point: trust anchors certificates usually are not included
> > > > in CERT payload in IKEv2.
> > > > I see draft???s a reasoning that this inclusion would allow better
> > > > network debugging,
> > > > but I???m not sure I can buy this argument. Probably more detailed
> > > > explanation is needed.
> > >
> > > They could suggest that for easier debuggint a CERTREQ payload is
> > > included. That has the hash of the CA, which should be good enough.
> > > But again, IKEv2 already specifies this. Why is this document trying
> > > to change IKEv2 certificate processing?
> >
> > Agree.
>
> It seems to me as if standard cert processing is primarily concerned
> with the minimum mandatory signaling for security. Maybe there
> is even the thinking that its a possible security feature that if
> you don't know the TA hash, you can not learn the TA cert.
>
> In the case of ACP, we do not care about such possible strange
> TA cert hiding security feature.
>
> An ACP can potentially have a bunch of TAs, for example under
> mergers & aquisitions. And especially if BRSKI is not used, these
> may be provisioned by all type of flawed mechanisms, like broken
> SDN controllers. Or incorrectly refreshed. Just think of the
> simple local diagnostics when a peer fails to connect and it
> for example has the correct TA, but unfortunately an expired
> cert for it. TA cert hash mismatch, but easily diagnosed when the TA
> cert iss signaled. Without having to go to a possible non-existant
> archive of prior TE certs from a company just aquired 9 months ago,
> where ACPs where merged.
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.
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...
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
