[
https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13688564#comment-13688564
]
Daryn Sharp commented on HADOOP-9421:
-------------------------------------
SASL just defines the format of the bytes used by mechanisms. It's left as an
exercise to the reader as to how to negotiate and wire encode the
challenge/response sequence. Per the SASL RFC
http://tools.ietf.org/html/rfc4422#section-4
{noformat}
4. Protocol Requirements
In order for a protocol to offer SASL services, its specification
MUST supply the following information:
1) A service name, to be selected from registry of "service" elements
for the Generic Security Service Application Program Interface
(GSSAPI) host-based service name form, as described in Section 4.1
of [RFC2743]. Note that this registry is shared by all GSSAPI and
SASL mechanisms.
2) Detail any mechanism negotiation facility that the protocol
provides (see Section 3.2).
A protocol SHOULD specify a facility through which the client may
discover, both before initiation of the SASL exchange and after
installing security layers negotiated by the exchange, the names
of the SASL mechanisms that the server makes available to the
client. The latter is important to allow the client to detect
downgrade attacks. This facility is typically provided through
the protocol's extensions or capabilities discovery facility.
3) Definition of the messages necessary for authentication exchange,
including the following:
a) A message to initiate the authentication exchange (see Section
3.3).
This message MUST contain a field for carrying the name of the
mechanism selected by the client.
This message SHOULD contain an optional field for carrying an
initial response. If the message is defined with this field,
the specification MUST describe how messages with an empty
initial response are distinguished from messages with no
initial response. This field MUST be capable of carrying
arbitrary sequences of octets (including zero-length sequences
and sequences containing zero-valued octets).
b) Messages to transfer server challenges and client responses
(see Section 3.4).
Each of these messages MUST be capable of carrying arbitrary
sequences of octets (including zero-length sequences and
sequences containing zero-valued octets).
c) A message to indicate the outcome of the authentication
exchange (see Section 3.6).
This message SHOULD contain an optional field for carrying
additional data with a successful outcome. If the message is
defined with this field, the specification MUST describe how
messages with an empty additional data are distinguished from
messages with no additional data. This field MUST be capable
of carrying arbitrary sequences of octets (including zero-
length sequences and sequences containing zero-valued octets).
{noformat}
> Convert SASL to use ProtoBuf and add lengths for non-blocking processing
> ------------------------------------------------------------------------
>
> Key: HADOOP-9421
> URL: https://issues.apache.org/jira/browse/HADOOP-9421
> Project: Hadoop Common
> Issue Type: Sub-task
> Affects Versions: 2.0.3-alpha
> Reporter: Sanjay Radia
> Assignee: Daryn Sharp
> Priority: Blocker
> Attachments: HADOOP-9421.patch, HADOOP-9421.patch, HADOOP-9421.patch,
> HADOOP-9421.patch, HADOOP-9421.patch, HADOOP-9421-v2-demo.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
