[
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
