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

David Lloyd (JIRA) issues at jboss.org
Fri Nov 20 10:21:00 EST 2015


David Lloyd created ELY-375:
-------------------------------

             Summary: 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.1.0.Final


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, use the ChannelBindingCallback to acquire the binding data for the already-selected channel binding type.
# 
# 



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)


More information about the jboss-jira mailing list