Subject: [Emu] EAP-TLS and OCSP

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 14 Feb 2007 15:08:43 -0800

Currently EAP-TLS does not require OCSP.  Ryan has requested that we
make support for the OCSP TLS (RFC4366 - section 3.6) extension a SHOULD
implement in EAP-TLS.  

The benefit of this is that it allows the peer to check for certificate
revocation before it has access to the network.  Without this if the
peer does not have an up to date CRL it must defer revocation checking
until it has network access and can receive an up to date CRL.  The peer
must limit its trust of the security of its network connection until it
can access the CRL.  

The downside of this is that it places a new requirement on EAP-TLS
implementations.  Even though it is a SHOULD and not a MUST it is
important to realize that a SHOULD is a requirement to implement unless
there are circumstances which make this requirement not apply to a
particular situation.  

I would like to here views from the working group on this topic.

Joe

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: Badra <[email-masked]>
Date: Thu, 15 Feb 2007 00:25:35 +0100

Hi Joe,

IMO, it is nice to have a SHOULD or MAY regarding EAP-TLS with OCSP.

The particular situation in which this requirement does not apply may be
related the interoperability issues described
indraft-ietf-tls-interoperability-00.

Best regards,
Badra

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 14 Feb 2007 15:41:30 -0800

Since I am new to this list and don't know the PKI background here I
thought I would provide a few links to help with this discussion:

OCSP - http://www.ietf.org/rfc/rfc2560.txt
TLS Extensions - http://www.ietf.org/rfc/rfc4366.txt

Additionally I wanted to talk about the rationale behind this (although
it has some coverage in the other thread), X.509 certificates are long
lived assertions that are made by their issuers that bind entitlements
and constraints to a key (no surprise here).

The thing is that as a long lived assertion the older it is the less
likely it is trustworthy, this is especially true for server
certificates that are typically just used in software cryptographic
implementations where these keys can be stolen from memory, or disk
(this is especially true in datacenters where key material needs to be
distributed broadly).

I guess this brings us to why certificates get revoked, there are lots
of reasons they most common being key compromise (which I describe
above) others include issuance errors, ca compromise, affiliation
change, suspension of roles, etc.

NIST has a nice paper by David Cooper on the topic available here:
http://csrc.nist.gov/nissc/1998/proceedings/paperG2.pdf

As a practical matter revocation happens allot, just take a look at the
many VeriSign CRLs associated with their public SSL issuance (several
have CRLs approaching 1MB) and the multi-megabyte CRLs in the DoD.

There are other reliability and performance benefits as well, with CRLs
commonly being very large it can take a long time over high latency
links to download and validate which negatively effects the user (often
times downloads actually fail due to timeouts).

As for doing the check after the fact, this can certainly be done
however this means that you may have already exchanged confidential
information with a hostile entity and the damage is done.

As for my logic associated with this being a SHOULD, RFC2119
(http://www.ietf.org/rfc/rfc2119.txt) defines SHOULD as follows:

   SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

This seems appropriate given the issues at hand, this label allows the
implementer to ignore this requirement if appropriate for their
particular situation thus providing appropriate guidance but enabling
implementers to do what's right for their given situation.

OK, that's my 2 bits :)

Ryan

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 3:09 PM
To: [email-masked]
Subject: [Emu] EAP-TLS and OCSP

Joe