[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    RE: [TLS] Question on Stateless TLS Session Resumption
From:       "Narayanan, Vidya" <vidyan () qualcomm ! com>
Date:       2007-01-17 3:52:02
Message-ID: C24CB51D5AA800449982D9BCB90325133C9C62 () NAEX13 ! na ! qualcomm ! com
[Download RAW message or body]

 
> 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
> 

I don't believe the above text captures all of what has been discussed
in this thread. Let's separate the issues of invalidating sessions and
subsequent ticket replays. The above text is referring to the fact that
the hash functions used are not reversible and hence, failure to
invalidate sessions is not a major problem. That is one aspect. However,
as your paper documents, in order to prevent repeated use of invalidated
tickets, the server must maintain a "black list" of sessions. The paper
refers to this in the context of timing analysis of the master secret,
which would involve an attacker different from the client. This also
seems true when the client has been revoked priveleges, for instance -
if the server invalidated a session because the client must no longer be
allowed to access it, the client may continue to replay an unexpired
ticket (essentially, the client becomes the attacker here) and without a
black list on the server, it is impossible to keep track of that. That
does not seem to be captured in the RFC. I think it would have been
useful to explicitly state the need for some minimal state at the server
in order to thwart these attacks. 

Vidya

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



[prev in list] [next in list] [prev in thread] [next in thread]