EAP-TLS, session resumption and OCSP

[Alan DeKok]

On Mar 7, 2017, at 2:45 AM, Stefan Winter <stefan.winter at restena.lu> wrote:
> So, as long as the user keeps re-authing in intervals < cache duration,
> he will have *perpetual* access? No CRL, OCSP or cert expiry would have
> an effect on the TLS session resumption?

  Revoking the certificate while the user is online arguably shouldn't affect the users status.  Something similar applies to session resumption.

  The *default* configuration is to do this.  As always, it's possible to add local policies which force full re-authentication after a time.

  For certificate expiry, yes, that should be fixed.

> I would consider that a bug really.

  For most of it, yes.

> TLS 1.2 has a Security Considerations text on session resumption
> (RFC5246 section F.1.4):
> 
> "Sessions cannot be resumed unless both the client and server agree.
>   If either party suspects that the session may have been compromised,
>   or that certificates may have expired or been revoked, it should
>   force a full handshake.  An upper limit of 24 hours is suggested for
>   session ID lifetimes, [...]"

  Sure.  You can set session lifetimes via policies.  It's easier in v4 than v3 tho.

> The text leaves *slight* amounts of room for interpretation, but I for
> one read those 24 hours as an *absolute* time limit and not a sliding
> window since last use.

  It's also a suggestion.

> However, I somehow think that security-relevant software should have
> higher amibitions and take a more active role in developing such
> suspicions about stale state over time.

  Sure.   I've taken a look, and put a patch into v3.0.x:

https://github.com/FreeRADIUS/freeradius-server/commit/f98df357af120ee515963a820bdd16c68b41a41a

> At the very least, the cache could continue to work in non-verify mode
> until the TTL of the *original* cache entry expires. As soon as that
> time expires, maybe it's okay to still resume the session as always, but
> do a one-off OCSP + expiration check (and then keep going until the next
> original TTL period is over again). That way, the revocation and expiry
> states would get checked at least every 24h (default config value).
> Alternatively, a second config param absolute_max_lifetime could control
> when to kill the cache even if it's kept updated.

  Sure.  As always, patches are welcome. :)

  I'd suggest adding a "Session Expiry" attribute.  That way the session can be expired at a particular time.

> For me, I tend to think that the current risk of perpetual users is too
> high; I'd rather disable session caches completely to avoid that risk.
> Even if that means more crypto workload for the server :-/ That's
> because 3.1.x or 4 is not currently an option.

  Please try the v3.0.x branch with my recent patches.  If that solves the problem, it's a minor update over 3.0.13.

  Alan DeKok.