Subject: RE: [TLS] draft-housley-evidence-extns-00.txt

From: "Peter Williams" <[email-masked]>
Date: Fri, 1 Sep 2006 10:55:06 -0700

So, looking at recent work on adding saml authorization assertions to TLS protocols flows, and now the proposed addition of evidentiary deductions to TLS session/connections, we can think more widely at the architectural implications for TLS. Analytically, we can cast those implications in terms of (a) the original architecture, (b) EAP and WTLS variants that have come into being over the last 10 years (c) web2.0 async frameworks.
 
In the original netscape-platform's SSL architecture, SSL was a winsock provider (tho not in reality ever implemented as such - except by Microsoft for a while) - one of many sub-protocol hooks that a good application protocol designer might add to the stack atop IPX, TCP/IP, ISO RTSE, or (today) ws-reliablemessaging.
 
To contextualize the hooking, one defined the "s" protocols - ftps, https, pptps, and a hundred unregistered ones from Microsoft - e.g. frontpageS. Into each context, the app designer added custom semantics, being not limited to https semantics. Netcape and its browser centric model of the web1.0 hardly represented the entire space of web possibilities, after all.  We all know of course of the evolution of EAP_TTLS, which is another example of the pattern, in a different sphere that had little to do with the web. Simialrly, jabber has take on its own course applying TLS handshakes.
 
Thinking back to the modern web2.0, we all know of the flow of SAML1.1 assertion between claim-aware application -  between STSs, claimants and web resources, in the ws-federation pattern that extends ws-security channels for distributed interworking. 
 
And we know of the SAML-complying DerivedTokens from ws-secureConversation that represent security context information and entropy properties for STS to which we have delegated the responsiblity for security channel maintenance for dumb-device, or escrowed, apps. So, going beyond the semantics of https,ftps, pop3s, eap-ttls, TLS CAN INDEED AND PROPERLY SHOULD support the ws-federation binding for the ws-security framework.
 
I'm not sure the way the internet-drafts are fmorulated really *well* adapts TLS to the web2.0 world, for xml-signaling buses whose security contexts do not rely on the internet security architcture. But, its quite proper to think about linking the SAML1 assertions flowing end-end at the ws-trust and ws-federation's http-redirection layer to those used, now, by the TLS engine in an internet-based stack complying with the internet security architecture. This is parpticularly true when allowing those flows to now control from above how a given ws-addressed TLS layer entity should apply access controls when interacting with layer 4/5 boundary access points - or the protocol hooked "above", in the winsock-speak.
I find the very ideas of TLS auth and evidence extensions really quite exciting, particularly now we have an open security context signaling infrastructure from the ws-security and ws-secureconversation worlds to also work with, as hypermedia app designers. (1) Signed assertions as xml strings, (2) WS-Trust signed responses, and (3) metadata flow allowing learning and knowledge transfer by next generation internet/winsock stacks - these are all mechanism we did not have available as commodity components available to your average vis basic programmer, back in 1995/6. This is all quite cool!
 
Peter.

From: [email-masked]: [email-masked]: RE: [TLS] draft-housley-evidence-extns-00.txtDate: Fri, 1 Sep 2006 09:12:45 -0700CC: 

  A very, very, very long time ago, ssl-talk discussed for weeks whether SSL supported, could support, or even should support evidentiary services such as non-repudiation - i.e. whether some of its protocol exchanges might be used at the application level to support claims at layer 7, generated as a side-effect of using the comms. stack. We focused on applying the blurring to the problem of enforcing UK/US mandatory key escrow policies - a high-priority topic for IESG, at that time. For example: if one initiated a second SSL3 handshake mid-session without dropping the https session context, one inherently created evidence related to the data exchanged between the two SSL2/SSL3 message-layer handshakes. That second handshake was evidence of the data exchange pattern at the https level.  We even defined parallel handshakes, using the SSL3 message layer's allowance for defining custom handshake flows, that did things like mandatory key escrow deposit and then policy *Enforcement* (which was popular at the time and perhaps this is back to popularity in 2006 IETF?) to showoff applicability of one handshake to express control over the https session ongoings on the primary channel. (This would ensure the server that the mandatory rules had been enforced on the consumer https channel, otherwise the server would drop the https session to comply with govt policies etc). I even remember writing up an proof, using inductive logic, for the mandatory integrity properties. Now, the list seems to be badly failing to distinguish between https and its socket-layer security protocol support.  Another way of saying that is, however - perhaps time had come to revist what we were saying in 1995 when we even then wondering about blurring the distinctions, between the stack layers - as regard to evidence generation from a socket provider. Are we thus truly "failing", or are we simply changing the paradigm, finally! While there was always interplay in the SSL design world between what happened in the application (the https realm known to the Netscape 2 browser hypermedia platform) and the SSL layer (behind the socket in winsock), we were clear that app vs layer separation was to be clean. For example, certs chains were processed by the https-layer application process in accord with the hypermedia experience of sessions focusing on session identity(s)  and confidence policy(s) thereto, but core SSL handshakes and security context session resumption processes were handled by the kernel/winsock provider without regard to "secure interworking pattern" being sought by the application context applying a socket provider's enhanced transport features. Conclusion. I supported using SSL handshakes as evidence-generation purposes at the app layer in 1995. And, I therefore still do. It breaks all the design correctness rules, and lots of IETF dogma that motivated TLS's distinct conception of itself (vs SSL3). But.. so what! Dogma can always be rewritten.

> Date: Thu, 31 Aug 2006 11:39:36 -0400> To: [email-masked]> From: [email-masked]> Subject: Re: [TLS] draft-housley-evidence-extns-00.txt> CC: > > David:> > That is true, an application running on top of TLS could handle this > feature, but then every application would have to do so.  By putting > it into TLS, any application can easily be supported.  The alerts to > mark the beginning and end were intended to allow applications to > generate evidence for a portion of the application exchange, but > these can be sent at the beginning and the at end of the TLS session > to support arbitrary applications.> > Russ> > > At 09:01 PM 8/30/2006, David Hopwood wrote:> >Russ Housley wrote:> > > http://www.ietf.org/internet-drafts/draft-housley-evidence-extns-00.txt> > >> > > I would like the TLS WG to be aware of this document.  Review is> > > encouraged, and comments are welcome.> >> >What is the rationale for complicating TLS with this, when it seems as> >though it could just as easily be supported at the application protocol> >level?> >> >--> >David Hopwood <[email-masked]>> >> >> >> >_______________________________________________> >TLS mailing list> >[email-masked]> >https://www1.ietf.org/mailman/listinfo/tls> > > _______________________________________________> TLS mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls

Express yourself with gadgets on Windows Live Spaces Try it! 
_________________________________________________________________
Search from any Web page with powerful protection. Get the FREE Windows Live Toolbar Today!
http://get.live.com/toolbar/overview

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls