[jboss-jira] [JBoss JIRA] (ELY-375) Server-side channel binding can cause mismatches

Server-side channel binding can cause mismatches ------------------------------------------------ Key: ELY-375 URL: https://issues.jboss.org/browse/ELY-375 Project: WildFly Elytron Issue Type: Bug Components: Authentication Mechanisms, Callbacks Reporter: David Lloyd Fix For: 1.2.0.Beta1 At present, the client and the server both locally query their connection situation to determine whether channel binding aware mechanisms should be made available for authentication. This is done by handling a {{ChannelBindingCallback}} and letting the callback handler determine what type of channel binding should be used, and what the data is. However, this strategy fails if the client and server choose a different channel binding type, which is very likely to happen if at any point JSSE begins support for acquisition of the tls-unique channel binding data. A newer JDK would have tls-unique data, but an older JDK might only have tls-server-end-point available, resulting in a channel-binding-mismatch type error. SCRAM allows the client to specify one channel binding type. So if the client supports multiple types, it has to guess at the type most likely to be supported by the server. SCRAM allows the server to read the client's channel binding type. Ideally, the server would then select the matching channel binding type if it is available, instead of querying for it ahead of time. So I propose the following: # On the SCRAM client, continue to use the ChannelBindingCallback to choose the binding type and data. # Introduce a callback type which allows a mechanism participant to provide a list of available channel binding types. # On the SCRAM server, instead of using ChannelBindingCallback to select a binding type *and* acquire the binding data, use this channel binding types callback to acquire the set of available channel bindings within the server factory. # On the SCRAM server, validate the client's selected binding type against the set of available channel bindings. # Change the ChannelBindingCallback contract, so that if a binding type name is already provided, the corresponding binding data should be provided (or an exception thrown). If no channel binding type name is given, then the callback continues to function as it does today, where a type is chosen and provided along with its data. # On the SCRAM server, use the modified ChannelBindingCallback contract to acquire the binding data for a pre-selected channel binding type.