[Ipsec] RE: OCSP in IKEv2

["Michael Myers" <mmyers@fastq.com>]

Charlie,

Per very recent discussions with the ADs, I believe we have a
more tractable path forward than that I originally proposed.
Based on a separate document defining an IANA-allocated
extension to the CERT payload content, which extension would
define "OCSP Response", this path would enable public discussion
of the issues, such as you raise, but would in no way impact
forward progress of the IKEv2 I-D.

Mike

-----Original Message-----
From: Charlie Kaufman [mailto:charliek@microsoft.com]
Sent: Friday, May 21, 2004 10:38 AM
To: ipsec@ietf.org
Cc: Michael Myers
Subject: RE: OCSP in IKEv2


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