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

List:       ietf-tls
Subject:    [TLS] The "other means" of controlling sessionids, master_secrets
From:       <home_pw () msn ! com>
Date:       2007-01-14 21:33:02
Message-ID: BAY126-DAV100103FD81B017F779146392B60 () phx ! gbl
[Download RAW message or body]

concerning RFC 4507.

The IESG appears to assert the following:-

 "SessionTicket TLS Extension

[...]
   If the client possesses a ticket that it wants to use to 
resume a
   session, then it includes the ticket in the SessionTicket 
extension
   in the ClientHello.  [...]

        [...]If the client is not prepared to receive a 
ticket in the
   NewSessionTicket handshake message then it MUST NOT 
include a
   SessionTicket extension unless it is sending a non-empty 
ticket it
   received through some other means from the server."

[http://www.rfc-archive.org/getrfc.php?rfc=4507]


So, I'm assuming (a) a ticket contains a wrapped 
master_secret (b) the last clause from above (other means), 
c) the TLS transport is EAP-TLS [rfc2716bis-06] cooperating 
with PPTP [RFC2637].

Lets now presume that there are 10 current TLS connection 
states in the client's cache, all duplicates of an active 
sessionid. Once a minute, they each perform a (keying 
material refresh) re-handshake citing their ticket generated 
by the server, and communicated on the n-1th handshake. 
(This "ticket" seems to be a variation of SSL3 fortezza_dms 
model for communicating (stateless) wrapped master_keys from 
the client endpoint to the loadbalancer)

Lets also presume that it is conforming for TLS endpoints to 
NEVER NEED TO DO a "full handshake", to establish a given 
sessionid. That is, we exploited assumption (b). The 
assumption means that the sessionid name and the wrapped 
master_secret value are managed by some proprietary key 
distribution protocol tuned to the nature of the TLS 
transport, in question. Presumably in TLS1.2 the ciphersuite 
designer specifes a suitable KDF, similarly, to generate 
suitable amounts of keying material for the nature of the 
fragment transport.

Presumably, a fatal alert on any one of those connections NO 
longer affects re-use of a sessionid on the others, given 
the sessionid is managed "by other means". All obligations 
for sessionid handling are borne by the client, AND these 
are set to comply with its (non-SSL) agreements with the 
server.



 


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