hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daryn Sharp (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-9421) Convert SASL to use ProtoBuf and add lengths for non-blocking processing
Date Thu, 20 Jun 2013 23:17:21 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13689823#comment-13689823
] 

Daryn Sharp commented on HADOOP-9421:
-------------------------------------

+Simple to insecure+
{noformat}
C -> S connectHeader(SIMPLE)
C -> S connectionContext
C -> S RPC request
{noformat}

No change/overhead.

+Simple to secure+
{noformat}
C -> S connectHeader(SIMPLE)
C -> S connectionContext
C -> S RPC request
C <- S RPC exception "SIMPLE not supported", close connection
{noformat}

No change/overhead.

Note: There's an existing race condition.  The server sent the exception in response to the
connect header, but the client already blasted the context and request.

+SASL to insecure server+
{noformat}
C -> S connectHeader(SASL)
C <- S SUCCESS
C -> S connectionContext
C -> S RPC request
{noformat}

Immediate success message replaces switch to simple.

+SASL to secure server+
{noformat}
C -> S connectHeader(SASL)
C <- S NEGOTIATE {
         [TOKEN, DIGEST-MD5, proto, realm, first-challenge-token]
         [KERBEROS, GSSAPI, user, host, null]
       }
C -> S INITIATE [ <Auth from NEGOTIATE> ] response-token
[... back and forth CHALLENGE/RESPONSE ...]
S <- C SUCCESS final-token
C -> S connectionContext
C -> S RPC request
{noformat}

The INITIATE for a token will use the first-challenge-token provided by the server to cut
out a roundtrip.  Since the client cannot initiate, the existing code wastes a round trip
soliciting the first DIGEST-MD5 challenge that I'm now immediately returning.

The INITIATE for kerberos cannot include a first challenge.  The GSSAPI mechanism cannot generate
a challenge w/o an initial response from the client.  This is fine and expected.

With this design, a follow on change can allow the client to pick the first auth type it supports
instead of guessing in advance what it should try.  It will use the fields as provided, of
course with safeguards to sanity check for malicious behavior.  Using the advertised fields
is how the client will support IP failover.

Walking the advertised auths will allow completely decoupling the auth type code from the
RPC client.  The auth types can be implemented as pluggable services that will be called on
demand if the server requests that auth type.  The pluggable services may use the protocol/serverId
fields to decide if they have the credentials to even attempt the auth.

The client should never attempt an auth unless it knows the server supports the auth, and
the client actually has the credentials to do the auth.

+Bad SASL client to secure+
{noformat}
C -> S connectHeader(SASL)
C <- S NEGOTIATE {
         [TOKEN, DIGEST-MD5, proto, realm, first-challenge-token]
         [KERBEROS, GSSAPI, user, host, null]
       }
C -> S INITIATE [ INVALID ] response-token
C <- S RPC Exception "INVALID not supported", connection closed
{noformat}

Well, you were supposed to reply with one of the advertised methods, not make a blind guess...
 Sorry, game over.

                
> 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.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

Mime
View raw message