[
https://issues.apache.org/jira/browse/HBASE-26666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17552344#comment-17552344
]
Bryan Beaudreault commented on HBASE-26666:
-------------------------------------------
[~andor] any chance we can clean up this Jira summary/description or make sure
we're on the same page? My understanding is you were originally working on SASL
bearer token, but pivoted to implement native TLS as a pre-requisite. I
mentioned this issue in HBASE-26708 and was met with some (reasonable)
confusion as to the state of things from [~apurtell]:
{quote}[~bbeaudreault] I was/am confused by that because HBASE-26666 is a
child of HBASE-26553 which describes itself as "OAuth Bearer authentication
mech plugin for SASL". Can you or someone clean this up so we can clearly see
what is going on? Is it really a full TLS RPC stack? Because it looks to me
like some TLS fiddling to get a token that then sets up the usual wrapped SASL
connection, possibly why I am confused. That would not be native TLS support in
the sense I mean and the sense that is really required, possibly why it has not
gotten enough attention.
{quote}
So the question at hand is whether the implementation you have in
[https://github.com/apache/hbase/pull/4125] is actually native TLS support that
can stand on its own, or whether it's tied the token stuff you're working on.
It would be beneficial to clarify the Jira, because it might drive more
interest in getting people to code review so we can push across the finish line.
> Address bearer token being sent over wire before RPC encryption is enabled
> --------------------------------------------------------------------------
>
> Key: HBASE-26666
> URL: https://issues.apache.org/jira/browse/HBASE-26666
> Project: HBase
> Issue Type: Sub-task
> Reporter: Josh Elser
> Assignee: Andor Molnar
> Priority: Major
> Fix For: HBASE-26553
>
>
> Today, HBase must complete the SASL handshake (saslClient.complete()) prior
> to turning on any RPC encryption (hbase.rpc.protection=privacy,
> sasl.QOP=auth-conf).
> This is a problem because we have to transmit the bearer token to the server
> before we can complete the sasl handshake. This would mean that we would
> insecurely transmit the bearer token (which is equivalent to any other
> password) which is a bad smell.
> Ideally, if we can solve this problem for the oauth bearer mechanism, we
> could also apply it to our delegation token interface for digest-md5 (which,
> I believe, suffers the same problem).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
