[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Ipsec] OCSP in IKEv2
I have no issue with reducing the normative strength of this clause (1)
so long as we directly address the case. The question is what does a
IKEv2 responder send back should it be unable to comply with an
initiator's request for in-band OCSP?
To your second point (2), it has been established that IKEv2 is too far
along in its consensus formation for the degree of reset direct
inclusion of this proposal would cause. Russ' direction is equally
unambiguous regarding PKI4IPSEC: OCSP for IKEv2 will be an individual
submission I-D gated onto the Standards Track, subject to comments.
Which brings us back to the first point: improving the I-D based on
comments. These days making PKI work translates in part to knob
reduction. I interpret this into a reduction of optional protocol
elements and crisp SHALL/SHALL NOT requirements instead of SHOULD or
That said, it is useful in some instances to be accommodative. I am not
yet convinced this is such an instance. Failing to include an OCSP
Response is not an all-out failure as you cite from IKEv2. The
responder may simply be unable to provide the requested service. That
does not mean it has failed in some fundamental way.
But neither am I expert in IPSEC's current state of deployment. I
remain open to debate on this point but as I see it today, a responder
unable to satisfy an initiator's request for in-band OCSP should say so,
if only in an error message. The initiator can then retry with a
reduced level of assurance if it so chooses.
From: William Dixon
Sent: Saturday, August 07, 2004 3:46 PM
(1) . . . I'm wondering why there is a "MUST not ignore the OCSP
response payload" statement in the draft. I don't think an error message
MUST be sent [because IKEv2 says] "An endpoint MUST conclude that the
other endpoint has failed only when repeated attempts to contact it have
gone unanswered for a timeout period or when a cryptographically
protected INITIAL_CONTACT notification is received on a different IKE_SA
to the same authenticated identity."
(2) . . . do we adopt OCSP support in IKEv2 at this point, advance this
draft as an addendum, or maybe incorporate it into the PKI4IPsec work
Ipsec mailing list