EAP-TLS, session resumption and OCSP

[Stefan Winter]

Hi,

>   The cached session information will expire after 24 hours.  When a session is resumed, the old information is deleted, and a new entry is created.
> 
>> If the latter, a revoked user could perpetually prolong his account
>> lifetime even if OCSP wouldn't want to let him.
> 
>   So long as you keep letting him in, yes.
> 
>> Also, something we didn't check but that just now comes to my mind: does
>> the server check the expiry time of the cert on a resumed session?
> 
>   Hmm... I'll have to check that.  I'm not sure.

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?

I would consider that a bug really.

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, [...]"

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.

(The RFCs reason for that time is the rather abstract risk of a third
party obtaining a master_secret in the meanwhile; the risk of perpetual
authentication is a much more concrete one IMHO).

Also, granted that if a software never checks for OCSP states / expiry
then it will never have the above "suspicion" that the certificate may
have been revoked or expired, and will keep letting the user in.

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.

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.

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.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20170307/f001601d/attachment.sig>