Subject: [TLS] The "other means" of controlling sessionids, master_secrets

From: <[email-masked]>
Date: Sun, 14 Jan 2007 13:33:02 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: <[email-masked]>
Date: Sun, 14 Jan 2007 22:52:05 -0800

The following describes where I'm going one thought train, 
on this topic. In what follows, I may or may not be making a 
conforming usage of the ticket standard. This interpretation 
is a useful test of the spec, as from my reading I believe 
what I'm doing is (a) correct (b) intended. If folks think 
it's not, the RFC needs some work. Whilst I'm definitely not 
exploiting the ticketing mechanism for its stated raison 
d'etre, I do believe I'm 100% conforming in what follows:-

Assume the "other means" noted in the standard is: a SAML2 
protocol flow. The client http browser cooperates with an 
IDP saml-endpoint (at his/her favorite portal (google.com, 
live.com, enterprise.com, society.org ...)), and the target 
website in the server farm cooperates with an SP 
saml-endpoint (a service appliance adjacent to the load 
balancer). Lets assume the saml-endpoints on IDP and SP 
participate in federated identity sharing, and use XML 
Encryption to share attributes (including a master_secret) 
defined in an attribute contract. Also assume that, 
incidentally, the XML DigSigs used in SAML flow achieve 
webSSO, per the SAML POST profile and metadata (certs, trust 
anchors etc) are all set up via the controlling trust model.

Now, lets assume that upon finally being redirected to the 
the app server using an https URL (where said server is deep 
in data center's access layer), said site now cooperates 
"locally" with the "ticket-enabled" SSL-offloading load 
balancer in the aggregation layer of its data center. 
Cooperation includes at least...delegating control of the 
master_secret retrieved from the SAML messages to the load 
balancer, so it can wrap it, and share it henceforth - using 
the ticket regime.

Another cooperation could reverse the relationship between 
load balancer and app server, in which certain state 
information from the SSL session could be relayed to the app 
server (as an inserted HTTP header, for example). Using the 
SAML2 Attribute Query now, this state information could be 
communicated to the IDP site in a custom query type (using 
signed XML messages). In this way, the SP and IDP endpoints 
could both share certain information from the SSL stream 
that their SAML trust model calls for mutual rights to 
audit.

I think I can do all this today, just exploiting the 
architecture of TLS1.0 and tickets.