"James A. Donald" <jam...@echeque.com> writes: > > [In order to implement strong password based > > encryption and authentication] on the server side, > > we need a request object in the script language that > > tells the script that this request comes from an > > entity that established a secure connection using > > shared secrets associated with such and such a > > database record entered in response to such and such > > a web page
Peter Gutmann wrote: > Ah, that is a good point, you now need the credential > information present at the TLS level rather than the > tunneled-protocol level (and a variation of this, > although I think one that way overcomplicates things > because it starts diverting into protocol redesign, is > the channel binding problem (see RFC 5056 and, > specific to TLS, > draft-altman-tls-channel-bindings-05.txt)). On the > other hand is this really such an insurmountable > obstable? Consider what would be involved in building the UI into the Google browser, and also building the necessary scripting support into Web2Py on Google App Engine. It is not a small job. > I don't really see why you'd need complex scripting > interfaces though, just "return the shared-secret > value associated with this ID" in response to a > request from the TLS layer. This request is issued when the connection is being established, before the URL is specified. So it is impossible to service that request from the script that generates the web page. So where are we servicing that request? Presumably, need to service it somewhere within the Web Application Framework, for example within Mod PHP or Web2Py. Further, some applications, for example banks and share registries, typically have several different ID tables at a single domain, and several different kinds of shared human memorable secret information associated with each ID. And, having established that association, then when the URL is specified, and the script associated that URL is finally invoked by the Web Application Framework, then that script needs to be invoked with the relevant ID, or better, the script then needs to be provided with a database cursor pointing at the relevant ID. Further, if we do the SRP dance every single page, it is a huge performance hit, with many additional round trips. One loses about 20 percent of one's market share for each additional round trip. So we only want to do the SRP dance on session establishment, only want to do it once per human session, once per logon, not once per TLS session. Which means that the TLS layer has to cache the the transient strong shared secret constructed from the weak durable human memorable secret for the duration of the Web Application Framework's logon and logoff and provide the cached database cursor to the web page script at every page request during a single logon session, which requires a higher level of integration between TLS and the Web Application Framework than either one was originally designed for. Which means a significant amount of work integrating this stuff with any given web application framework. Further, suppose, as is typical with banks, a given domain name hosts multiple ID tables each with different kinds of shared secret information. In that case, we can obtain multiple different kinds of SRP logons, each relevant to certain web pages but not others, each with different privilege levels, and the framework has to enforce that, has to provide to each web page information about the logon type, and ensure that inappropriate web pages are never invoked at all, but are 403ed when the user attempts to access a url through a logon of inappropriate type. We cannot rely on the server side web page script to 403 itself in response to inappropriate logon type, since when a new kind of logon was introduced, no one would ever go back and make sure that all the old web pages correctly checked the logon type. If the web page script contains a line of code that says "If such and such, then do a 403", then sooner or later someone will delete that code and say "Hey, it still works just fine.". This is starting to sound depressingly like a great deal of work rewriting lots of complex, bugridden stuff in web application frameworks that are already designed to handle logons in a quite different way. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com