Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Wed, 24 Apr 2013 17:47:19 +0000 (UTC)
From: "Daryn Sharp (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: <JIRA.12638070.1363810059559.217548.1366825639079@arcas>
In-Reply-To: <JIRA.12638070.1363810059559@arcas>
References: <JIRA.12638070.1363810059559@arcas>
Subject: [jira] [Commented] (HADOOP-9421) Add full length to SASL response
 to allow non-blocking readers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

bq. Only if there is only one kind of tokens, which will not be true.

Valid point, but I'm interested in your vision/use-case for multiple tokens?  Could this be hidden behind the secret manager?

bq. Benoy: An alternative approach in choosing a mechanism is to model after the SSL protocol. Here Client does "ClientHello" to server with a list of mechanisms it supports.

Exploring that approach, why not return the mechanisms in response to the connection header?

bq. In terms of complexity. Sasl-next proposal actually seems more complex by intertwine sasl handshakes with mechanism/protocol selection/negotiation.

I'm open to ideas, but I'm not sure I understand this.  How is "do you do this mech?", "no?", "how about this mech?", "yes? ok, let's do it!" being complex?

bq. This is a generalization of the client initiation mechanism. If we implement my proposal, this can be added later in a backward compatible manner, as we can send the client capabilities in an optional field.

In your example, you're again assuming the client is in a position to intelligently _propose_ a mechanism - it's not.  The client can't make a determination until he knows the server id for a mechanism.  

The server can't _chose_ a mech based client capabilities either.  Just because the client and server support DIGEST-MD5/dtoken doesn't mean the client actually has the right token.  The server can't guess what the client has, nor would be desirable for the client to send all his token services so the server can chose.

The client is the one that must chose a mech but it needs server hints to do so.  I think a middle ground is the server advertises all its mechs at once, instead of one at a time as I proposed.
{noformat}
C -> S [ connection-header: ... ]
S -> C [ sasl-mechs: [mech1, proto1, id1], [mech2, proto2, id2], ... ]
C -> S [ sasl-start: mech?, proto? ]
...
{noformat}

Having only one side (in this case client) start the negotiation is much simpler.  If we say the client gets one shot, instead of willy-nilly choosing multiple mechs and the server keeping track of what's been attempted, then it will be a lot easier.  

The one downside I see to the client initiating the exchange, instead of the server, is if the server wants to do a second mech based on success of another mech.  Ex. using some special mech with a secret requires a followup sasl negotiation with say kerberos.  If the server always initiates, and the dumb client does what it's told, that's easy to do in a trivial fashion.  IMHO, dumb clients are always good, but I'm willing to compromise.
                
> Add full length to SASL response to allow non-blocking readers
> --------------------------------------------------------------
>
>                 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: Junping Du
>         Attachments: HADOOP-9421.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