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

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. 

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