EAP-TLS, session resumption and OCSP
Hello, we are curently testing a large-scale rollout of EAP-TLS for eduroam purposes. One of the things we observed is that if an authentication uses TLS session resumption, the server does not re-check the OCSP state of the client cert that was used to login initially. So, in a scenario where - cert is valid, user authenticates with a full EAP-TLS handshake - cert gets revoked - user re-authenticates with session resumption then the authentication does NOT fail but succeed. Looking at the TLS-Client-Cert-* attributes which get restored from session cache, it looks like it could be easy to do that though - the serial number of the cert is saved; and the OCSP responder URL maybe isn't but could be. And with both pieces of information, another OCSP check can be run even on a resumed session. A related question: how is the cache lifetime determined? When config sets it to 24 hours, is that 24 hours after the initial, full, authentication, or is that lifetime refreshed with every re-auth, meaning the cache expires after 24 hours of non-use? If the latter, a revoked user could perpetually prolong his account lifetime even if OCSP wouldn't want to let him. 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? 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
Dear FreeRadius users mailing list, We would like to acknowledge that we have received your request and a ticket has been created. A support representative will be reviewing your request and will send you a personal response.(usually within 24 hours). To view the status of the ticket or add comments, please visit https://trubrain.freshdesk.com/helpdesk/tickets/278 Thank you for your patience. Sincerely, TruBrain Support Team
On Mar 3, 2017, at 4:34 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
One of the things we observed is that if an authentication uses TLS session resumption, the server does not re-check the OCSP state of the client cert that was used to login initially.
Yes. The OCSP checks are done in an OpenSSL callback when the certificate is first received. During session resumption there's no certificate used, so no OpenSSL callback.
Looking at the TLS-Client-Cert-* attributes which get restored from session cache, it looks like it could be easy to do that though - the serial number of the cert is saved; and the OCSP responder URL maybe isn't but could be. And with both pieces of information, another OCSP check can be run even on a resumed session.
Yes.
A related question: how is the cache lifetime determined? When config sets it to 24 hours, is that 24 hours after the initial, full, authentication, or is that lifetime refreshed with every re-auth, meaning the cache expires after 24 hours of non-use?
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. Alan DeKok.
On Mar 3, 2017, at 7:12 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 3, 2017, at 4:34 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
One of the things we observed is that if an authentication uses TLS session resumption, the server does not re-check the OCSP state of the client cert that was used to login initially.
Yes. The OCSP checks are done in an OpenSSL callback when the certificate is first received. During session resumption there's no certificate used, so no OpenSSL callback.
It's fixed in >= v3.1.x. Although the client doesn't provide the certificate, the certificate is still available. Unfortunately the OpenSSL callback infrastructure doesn't allow re-checking the certificate chain, so something had to be hacked together to do that manually (see tls_validate_client_cert_chain).
Looking at the TLS-Client-Cert-* attributes which get restored from session cache, it looks like it could be easy to do that though - the serial number of the cert is saved; and the OCSP responder URL maybe isn't but could be. And with both pieces of information, another OCSP check can be run even on a resumed session.
Yes.
See above.
A related question: how is the cache lifetime determined? When config sets it to 24 hours, is that 24 hours after the initial, full, authentication, or is that lifetime refreshed with every re-auth, meaning the cache expires after 24 hours of non-use?
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.
Yes.
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.
Only in <= v3.0.x.
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.
In >= v3.1.x yes, in < v3.1.x probably maybe not. -Arran
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
On Mar 7, 2017, at 2:45 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
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.
Technically yes.
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.
Indeed. I think however, that there'd be more value in convincing OpenSSL that there current system of validation callbacks is inadequate, rather than attempting to backport the OCSP validation-on-resumption logic to v3.0.x.
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.
In v4.0.x the validity of the OCSP response is controlled by the nextUpdate field in the OCSP response. Or more precisely, the OCSP response can be cached, and the contents of the nextUpdate field is made available to control the lifetime of that cache entry. If the OCSP response isn't cached then a full OCSP validity check will take place on each resumption.
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.
Agreed. You're welcome to try and convince someone to backport the code to v3.0.x, but my backlog is already quite sizeable. -Arran Arran Cudbard-Bell FreeRADIUS Core Developer FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
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.
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Stefan Winter -
Team at TruBrain