EAP-TLS, session resumption and OCSP

[Arran Cudbard-Bell]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20170307/e468d188/attachment.sig>