Re: [TLS] Question on Stateless TLS Session Resumption

Lakshminath Dondeti <ldondeti@qualcomm.com> writes:

> Eric Rescorla wrote:
>
>> Well, there are two separate issues here. There's no technical
>> reason why a new TLS handshake between a client/server pair
>> needs to invalidate and old session between them. Indeed,
>> I don't know of any server which enforces this before and it
>> would even in principle be rather difficult to do in the
>> absence of client authentication, which is fairly rare.
>
> The issue is that of revocation.  If a client's credentials are
> revoked, a full exchange will ensure that the client gets service only
> after it acquires/renews its certificate or whatever.  If there is an
> old ticket that the client can use to get service then it  is able to
> get around having to reauthenticate with new credentials.

Yes, as I said there are *two* issues. One issue is about what
happens when a client simply initiates a full handshake. In
that case there is no general need to invalidate an old ticket.
TLS is quite capable of having two parallel sessions between any
pair of communicating parties.

However, as you indicate, you might want to explicitly terminate
a session. As Vidya indicated, this requires server side state,
though less than a session cache would require.

> Right, that's as per 4346.  However, 4507 says "When presenting a
> ticket, the client MAY generate and include a Session ID in the TLS
> ClientHello."  Given that the client can change the session id, it
> becomes difficult (not impossible as I initially thought) for the
> server to track and invalidate old tickets.

It's not difficult at all. You invalidate the ticket, not the
session ID. The details are described in the SBR04 reference
cited below.

> But, perhaps as you say,
> this is generally not an issue in practice.  If the ticket lifetime is
> generally short enough, it is probably not a big deal (although it
> would have been nice to have stated it in 4507).

Well, here's what 4507 says:

5.1.  Invalidating Sessions

   The TLS specification requires that TLS sessions be invalidated when
   errors occur.  [CSSC] discusses the security implications of this in
   detail.  In the analysis in this paper, failure to invalidate
   sessions does not pose a security risk.  This is because the TLS
   handshake uses a non-reversible function to derive keys for a session
   so information about one session does not provide an advantage to
   attack the master secret or a different session.  If a session
   invalidation scheme is used, the implementation should verify the
   integrity of the ticket before using the contents to invalidate a
   session to ensure that an attacker cannot invalidate a chosen
   session.

[CSSC] is a reference to SBR04, which provides a fairly detailed
analysis of a variety of different ticket revocation schemes.

-Ekr

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls