Re: [TLS] the use cases for GSS-based TLS and the plea for integrating

[Chris Newman <Chris.Newman at Sun.COM>]

For my IESG review of draft-ietf-tls-srp-14.txt, I voted to abstain with the 
following comment:

------
This a matter of application software architecture that applies to any
user-based authentication mechanism embedded in TLS that involves
or may involve unspecified server storage of per-user credential
information.

TLS stacks and the APIs to TLS stacks have started to ossify into
operating systems, mobile devices and shipping application software.
Such stacks are absolutely critical to application security, and are
already so complex that they are the cause of a significant number of
software defects and security updates.  I am very concerned about
adding unnecessary complexity to such a critical software component.
There is already a great deal of flux upgrading the cipher suites,
cipher modes and hash functions in these stacks.

Meanwhile, all the software infrastructure in applications surrounding
user identity, server credential repositories for users, and identity
federation is highly complex and in a great deal of flux.  If one looks
at the amount of complexity in the GSSAPI or deployed general
purpose SASL APIs and imagines the complexity of a software stack
including all those APIs blended with a TLS API, I find the prospect
daunting.  Indeed the complexity is sufficiently great that I consider
it bad architecture.

Meanwhile, there's a viable alternative.  If TLS and an authentication
framework such as GSSAPI, EAP or SASL are loosely bound using a
mechanism such as TLS channel bindings (TLS negotiates the security
layer which is subsequently bound to a completely separate user
authentication), then there is a very simple and clean boundary
between the two software stacks, leading to a much more pragmatic
real-world architecture.
------

I have subsequently spoken to other implementers in the applications area who 
integrate TLS and identity stacks into their application server software.  They 
all shared this concern to varying degrees.

This issue clearly also applies to a mechanism that embeds GSS in TLS.  As a 
measure of IETF consensus in support of such a mechanism, I want to see 
evidence there are real-world consumers of this technology sufficient that it 
might deploy.  Specifically, is this likely to be implemented in multiple TLS 
stacks?  Are applications that consume TLS stacks interested in using this 
instead of their present identity APIs and models?

               - Chris Newman
               Applications Area Director


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