ipsec September 2009 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: [IPsec] CRL checking when selecting a certifcate

[IPsec] CRL checking when selecting a certifcate

From: Tero Kivinen <kivinen_at_nospam>
Date: Thu Sep 03 2009 - 09:01:27 GMT
To: David Wierbowski <wierbows@us.ibm.com>

David Wierbowski writes:
> In a recent append Tero said:
> >Then the responder is already going against the RFC4306 which says
> >"Certificate revocation checking must be considered during the
> >chaining process used to select a certificate. " meaning the responder
> >cannot send certifiate which itself considers revoced. Only case when
> >this can happen is when responder thinks he has valid certificate but
> >initiator then checks it against certificate authority's system (for
> >example OCSP) and finds out it is not valid anymore. This is not
> >common case, thus it can lead to timeouts.
> This is a lower case must.

Which does not say you can ignore it. It just says it is not protocol specific "MUST" which affect interoperability, it is behavior "must" meaning you still need to do that, but even if you don't you will most likely are still interoperable (altought the connection will/can fail).

> I'm not sure it is safe to assume that
> implementations adhere to a lower case must.

I expect that that implementations do follow such text. If implementations ignore this kind of text with no upper case MUST then I am sure the implementation doing that is completely broken.

If we take other example from section 1.2 which says:

   The initial exchanges are as follows: Initiator Responder -------------------------------------------------------------------    HDR, SAi1, KEi, Ni -->

   HDR contains the Security Parameter Indexes (SPIs), version numbers,    and flags of various sorts. The SAi1 payload states the    cryptographic algorithms the initiator supports for the IKE SA. The    KE payload sends the initiator's Diffie-Hellman value. Ni is the    initiator's nonce.

There is no "MUST/SHOULD/MAY"s in there but if implementation does not follow the text explaining how initial exchange packet is generated the implementation does not work.

So implementations cannot just search uppercase "MUST/SHOULD/MAY" texts and assume it is enough to make sure those are correct. It also needs to do what the text says...

> CRL checking is not cheap and
> performing CRL checking when selecting a certificate seems like an optional
> usability feature to me.

The you probably want to make change to the current text which says you must do it...

On the other hand usually you are using certificates from the same CA, thus when you checking other ends certificate you already fetch the CRL from the CA and revoke those certificates which are revoked by it. If that happens yo revoke your own certificate you should notice that too. That means in normal case the CRL checking is free operation as you need to do it anyways for the other ends certificate (the most expensive operation usually is the fetching of the CRL and verifying its signature, looping through the revoked certificates after that is very cheap).

Only case where it actually do cost you extra is when you are using different CRL for your own certificate than what the other end is using.

> From the sender's point of view the worst thing
> that is going to happen is the receiver will fail the authentication
> because the certificate is revoked. The only advantage to doing the check
> on the sender's side is there is a chance the sender can find a non-revoked
> certificate, but I think the decision to perform that optimization is
> implementation specific.

Partially agree on that. Especially as the recipient of your certificate might have information that you do not (for example the garage door opener remote controller might not have connection to the CA to fetch CRLs, but the server to which it connects to can have, and can check CRLs and can also send CRLs inband to the remote).

But with current text that is not possible. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec