[
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)
