On May 29, 2009, at 3:02 PM, Jeffrey Hutzelman wrote:
So, you'd rather pick YAP and then discover that only tls-unique is supported but you can't use a unique binding for your TLS session (and thus authentication fails) than be able to detect this situation in advannce and fall back to SCRAM?
I see this situation to be the same as that caused by your proposal.If a server administrator desires to offer tls-unique with SCRAM but not tls-x-unique, yet the server desires to offer tls-x-unique for some other mechanism, your approach has the server advertising both tls-unique and tls-x-unique. The client hence might choose to use tls- x-unique with SCRAM, only to have a failure. Obviously, your proposal was not designed to accommodate this situation.
I argue that not only should mechanism designers consider the applicability of each channel binding type with the mechanism, application protocol developers need to consider the applicability of each mechanism/channel bind type combination when implementing (as mechanisms are specified in a application-neutral manner and channel binding types are specified (typically) in a mechanism specific manner, the developer cannot assume the application protocol, mechanism and channel binding type designers have not considered all of the issues the developer needs to consider). And deployers will consider the applicability of a mechanism/channel binding type to each application protocol system they deploy. Just as we've seen deployers demand methods, especially server side methods, for restricting which mechanisms are used in application protocol deployments, I believe we'll see deployers demand methods for restricting use of channeling binding types on a per mechanism basis.
Hence, when I consider your proposal with a in-the-mechanism exchange approach, I conclude they will fail in similar ways in face of administrative-set/implementor-set per-mechanism channel binding restrictions. When I consider other aspects of these solutions, I find that that in-the-mechanism sucks less.
I continue to think negotiating channel binding type using the mechanism name, as we do for hash algorithms, as we done for channel binding on/off, is the best approach.
Simon said:
I believe there is some point in having a manual process to register each and every SCRAM-IPSEC-FOO,SCRAM-TLS-BAR combination: it makes us have to think about the securityproperties of each particular combination of mechanism with channel binding.
+1. -- Kurt