Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 31 Mar 2016 17:44:25 +0000 (UTC)
From: "Sam Tunnicliffe (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12955032.1459445134000.103027.1459446265701@Atlassian.JIRA>
In-Reply-To: <JIRA.12955032.1459445134000@Atlassian.JIRA>
References: <JIRA.12955032.1459445134000@Atlassian.JIRA>
 <JIRA.12955032.1459445134078@arcas>
Subject: [jira] [Updated] (CASSANDRA-11471) Add SASL mechanism negotiation
 to the native protocol
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sam Tunnicliffe updated CASSANDRA-11471:
----------------------------------------
    Description: 
Introducing an additional message exchange into the authentication sequence would allow us to support multiple authentication schemes and [negotiation of SASL mechanisms|https://tools.ietf.org/html/rfc4422#section-3.2]. 

The current {{AUTHENTICATE}} message sent from Client to Server includes the java classname of the configured {{IAuthenticator}}. This could be superceded by a new message which lists the SASL mechanisms supported by the server. The client would then respond with a new message which indicates it's choice of mechanism.  This would allow the server to support multiple mechanisms, for example enabling both {{PLAIN}} for username/password authentication and {{EXTERNAL}} for a mechanism for extracting credentials from SSL certificates\* (see the example in [RFC-4422|https://tools.ietf.org/html/rfc4422#appendix-A]). Furthermore, the server could tailor the list of supported mechanisms on a per-connection basis, e.g. only offering certificate based auth to encrypted clients. 

The client's response should include the selected mechanism and any initial response data. This is mechanism-specific; the {{PLAIN}} mechanism consists of a single round in which the client sends encoded credentials as the initial response data and the server response indicates either success or failure with no futher challenges required.

>From a protocol perspective, after the mechanism negotiation the exchange would continue as in protocol v4, with one or more rounds of {{AUTH_CHALLENGE}} and {{AUTH_RESPONSE}} messages, terminated by an {{AUTH_SUCCESS}} sent from Server to Client upon successful authentication or an {{ERROR}} on auth failure. 

XMPP performs mechanism negotiation in this way, [RFC-3920|http://tools.ietf.org/html/rfc3920#section-6] includes a good overview.

\* Note: this would require some a priori agreement between client and server over the implementation of the {{EXTERNAL}} mechanism.


  was:
Introducing an additional message exchange into the authentication sequence would allow us to support multiple authentication schemes and [negotiation of SASL mechanisms|https://tools.ietf.org/html/rfc4422#section-3.2]. 

The current {{AUTHENTICATE}} message sent from Client to Server includes the java classname of the configured {{IAuthenticator}}. This could be superceded by a new message which lists the SASL mechanisms supported by the server. The client would then respond with a new message which indicates it's choice of mechanism.  This would allow the server to support multiple mechanisms, for example enabling both {{PLAIN}} for username/password authentication and {{EXTERNAL}} for a mechanism for extracting credentials from SSL certificates\* (see the example in [RFC-4422|https://tools.ietf.org/html/rfc4422#appendix-A]). Furthermore, the server could tailor the list of supported mechanisms on a per-connection basis, e.g. only offering certificate based auth to encrypted clients. 

The client's response should include the selected mechanism and any initial response data. This is mechanism-specific; the {{PLAIN}} mechanism consists of a single round in which the client sends encoded credentials as the initial response data and the server response indicates either success or failure with no futher challenges required.

>From a protocol perspective, after the mechanism negotiation the exchange would continue as in protocol v4, with one or more rounds of {{AUTH_CHALLENGE}} and {{AUTH_RESPONSE}} messages, terminated by an {{AUTH_SUCCESS}} sent from Client to Server upon successful authentication or an {{ERROR}} on auth failure. 

XMPP performs mechanism negotiation in this way, [RFC-3920|http://tools.ietf.org/html/rfc3920#section-6] includes a good overview.

\* Note: this would require some a priori agreement between client and server over the implementation of the {{EXTERNAL}} mechanism.


> Add SASL mechanism negotiation to the native protocol
> -----------------------------------------------------
>
>                 Key: CASSANDRA-11471
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11471
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL
>            Reporter: Sam Tunnicliffe
>              Labels: client-impacting
>
> Introducing an additional message exchange into the authentication sequence would allow us to support multiple authentication schemes and [negotiation of SASL mechanisms|https://tools.ietf.org/html/rfc4422#section-3.2]. 
> The current {{AUTHENTICATE}} message sent from Client to Server includes the java classname of the configured {{IAuthenticator}}. This could be superceded by a new message which lists the SASL mechanisms supported by the server. The client would then respond with a new message which indicates it's choice of mechanism.  This would allow the server to support multiple mechanisms, for example enabling both {{PLAIN}} for username/password authentication and {{EXTERNAL}} for a mechanism for extracting credentials from SSL certificates\* (see the example in [RFC-4422|https://tools.ietf.org/html/rfc4422#appendix-A]). Furthermore, the server could tailor the list of supported mechanisms on a per-connection basis, e.g. only offering certificate based auth to encrypted clients. 
> The client's response should include the selected mechanism and any initial response data. This is mechanism-specific; the {{PLAIN}} mechanism consists of a single round in which the client sends encoded credentials as the initial response data and the server response indicates either success or failure with no futher challenges required.
> From a protocol perspective, after the mechanism negotiation the exchange would continue as in protocol v4, with one or more rounds of {{AUTH_CHALLENGE}} and {{AUTH_RESPONSE}} messages, terminated by an {{AUTH_SUCCESS}} sent from Server to Client upon successful authentication or an {{ERROR}} on auth failure. 
> XMPP performs mechanism negotiation in this way, [RFC-3920|http://tools.ietf.org/html/rfc3920#section-6] includes a good overview.
> \* Note: this would require some a priori agreement between client and server over the implementation of the {{EXTERNAL}} mechanism.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)