On Mar 7, 2017, at 2:45 AM, Stefan Winter <stefan.winter@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/f98df357af120ee515963...
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.