[Ipsec] RE: OCSP in IKEv2

["Charlie Kaufman" <charliek@microsoft.com>]

I agree there will be problems with sizes if people try to pass CRLs as
part of the IKE negotiation because CRLs tend to be large and IKE runs
over UDP. Adding support to IKEv2 for OCSP is plausible, though I
believe it is too late in the process for this big a change in this
version. Support for OCSP would likely change the number of messages in
the IKEv2 exchange.

Longer term I also believe this is a bad idea, but for a different
reason. Passing certificates 'in band' in IKE makes sense because they
are not reliably accessible by any standardized protocol. Both CRL
fetching and OCSP are designed to run over IP (not embedded in another
protocol), and so I believe it would be better to use those protocols
directly rather than taking them apart and reassembling them inside
IPsec. There will be occasions when either the CRL or the OCSP server
will only be accessible to an endpoint over an IPsec SA, which
introduces a chicken and egg problem. In my opinion, the lesser hack
would be allow an IPsec SA to come up with limited connectivity without
the CRL or OCSP verification, where the connectivity is limited to that
required to fetch the CRL or talk to the OCSP server. I'm sure others
would violently disagree with my taste on this matter. But in any case,
it seems like a debate better conducted in the PKI4IPSEC working group.

	--Charlie Kaufman

-----Original Message-----
From: Michael Myers [mailto:mmyers@fastq.com]
Sent: Wednesday, May 19, 2004 1:24 PM
To: ipsec@ietf.org
Subject: OCSP in IKEv2


Charlie,

Recent discussions in the PKI4IPSEC working group exposed a
disconnect between IKE's specification of CRLs and their utility
given likely CRL size.  Towards in-band alternatives, OCSP as
developed by PKIX and defined by RFC 2560 is a viable option for
IKE in-band signaling of certificate revocation status.

OCSP did not exist as an RFC when IKE was originally drafted; it
was still an I-D at that stage of IKE's development. Its absence
in IKE's original specification is thus understandable.  But
OCSP does now exist as an alternative to CRLs.  Per a recent
PKIX poll, there are something like eight independent
implementations of OCSP.

I strongly encourage amendment of IKEv2 to accommodate OCSP.
TLS has already done so, as has the OWA community.  Why not
IPSEC?  I realize this notice is probably too late for -13 but
might consensus could be formed for inclusion in -14 of IKEv2?

Michael Myers



_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec