ipsec October 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: [IPsec] #119: Which certificate types can be mixed in one

[IPsec] #119: Which certificate types can be mixed in one exchange?

From: Tero Kivinen <kivinen_at_nospam>
Date: Fri Oct 30 2009 - 14:06:43 GMT
To: Yaron Sheffer <yaronf@checkpoint.com>


Yaron Sheffer writes:
> Should be added to Sec. 3.6, probably as a new subsection.
>
> One Hash & URL (H&U) bundle only. Or...
>
> One Raw RSA key, or...
>
> One or more cert payloads of either type 4 or H&U (type 12)
>
> Can have one or more CRLs and/or OCSP content (RFC
> 4806<http://tools.ietf.org/html/rfc4806>) added to any of the above,
> except for Raw RSA.

I think the answer to question which types can be mixed in one exchange is: Any.

As recipient should be able to ignore the formats it does not support easily, and if that results to case where recipient does not have enough information to validate the certificate then the authentication cannot succeed. The sender should include certificates in the format that they were requested by certificate request payload, but if it cannot, then it might as well include the certificate in some other format, just in case that will help the recipient. If that does not help the recipient, then those two peers cannot authenticate each other.

I do not see any problem when some implementation which needs to present certificate for peer, which didn't send any certificate request payload, decides to send same certiface using format 11 and 4 and also provides intermediate certificates for the X.509 certificate as hash and url of X.509 certificates and even includes CRL in format 7 if all that can be fit to the packet without causing fragmentation (i.e. if all that fits to packet less than 1280 bytes, then there is no reason not to include all that helpful information if that was readily available).

Then if the initiator was very limited IPsec garage door remote controller implementation which required public key as raw rsa key (format 11), it can take it from there, and ignore rest, and if it happened to be real VPN client using preper CA, it can then verify the certificates and CRLs etc.

Limiting the number of certificate types which can be mixed in one exchange will limit the scenarios we can use with IPsec. I.e. if we limit there can be only one type then we need to add more configuration to the recipient, i.e. it needs to know from somewhere that this incoming connection is now from this limited IPsec garage door remote controller so only raw RSA key is presented, and if it is this VPN client (laptop) then it need to give certificates etc.

I do not think this really affects interoperability as we already have fixed list of mandatory to implement methods, this mostly affect how much configuration each implementation needs to fill in, compared to using more optimistic approach that fill in everything we have and hope the other end has enough data to finish the authentication (if we really gave everything we had, and that was not enough for the other end, then we clearly cannot communicate regardless what format we would have used). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec