[
https://issues.apache.org/jira/browse/TINKERPOP-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15245667#comment-15245667
]
ASF GitHub Bot commented on TINKERPOP-1263:
-------------------------------------------
Github user PommeVerte commented on the pull request:
https://github.com/apache/incubator-tinkerpop/pull/291#issuecomment-211383008
Hey @mike-tr-adamson .
I had a look at [`RFC 4422 section
3.2`](https://tools.ietf.org/html/rfc4422#section-3.2) and it seems to imply
that `mechanism` negotiation implementations are essentially our choice. I was
wondering why you decided to prepend it to the payload, rather than say, add it
to the payload, or negotiate it after authentication as pointed out in the RFC
(to avoid downgrade attacks for users who want to extend the server
capabilities here)
> Pass SASL mechanism name through with initial SASL response
> -----------------------------------------------------------
>
> Key: TINKERPOP-1263
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1263
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
> Affects Versions: 3.1.2-incubating
> Reporter: Mike Adamson
> Assignee: stephen mallette
> Fix For: 3.1.3, 3.2.1
>
>
> Support was added to the client driver to allow either plain text or GSSAPI
> SASL authentication. This improvement is for the client to pass the name of
> the mechanism as part of the initial SASL response. This gives the server
> side SASL handler the option to negotiate whether it will allow the specific
> mechanism.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
