[
https://issues.apache.org/jira/browse/HDFS-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13416380#comment-13416380
]
Dave Thompson commented on HDFS-2617:
-------------------------------------
Not weighing in either way. Just thought it might be helpful to point out some
details
relevant to some of the above comments.
1. SPNEGO is not a direct replacement for KSSL. SPNEGO as an authentication
method is only a subset of what SSL provides, which is a full transport layer
security mechanism (read as authentication and payload protection). Further,
with regards to authentication, KSSL provides client and server side
authentication. Kerberos SPNEGO (as in HTTP Negotiate) will mean that we will
lose server side authentication at the point of connection, though maintain
client side authentication.
2. Known WEP attacks are not applicable to SSL despite the fact that RC4 may be
a common streaming cipher between them. Pre-shared keys are effectively
non-existent in the SSL world.
3. DES and 3DES are very different block ciphers with regards to cipher
strength. 56 bit vs 168 bit ciphers.
4. Not clear what the concern is regarding the current hard coding of 3DES in
the code, though it may be worth pointing out that it's customary for a clients
to present a cipher suite of acceptable ciphers in SSL, meaning the current
implementation could be expanded on to include a set. A list of Kerberos
cipher suites is in RFC 2712, though one needs to cross reference which one's
are implemented in the client and server crypto libs. Quick list includes
RC4_128, RC2_128, 3DES(168). Haven't checked if there are further extensions.
This can be done asymmetrically (think upgradable), though of course it's not
effective until both client and server support the new ciphers.
5. Regarding RC4 streaming cipher with 128 bit keys, it's likely a vast
majority of one's credit card transactions are still occurring using this, as
this has been the defacto standard since the mid 90's.. though earlier with 88
bits of the key exposed making effective 40-bit to comply with old US
import/export restrictions.
> Replaced Kerberized SSL for image transfer and fsck with SPNEGO-based solution
> ------------------------------------------------------------------------------
>
> Key: HDFS-2617
> URL: https://issues.apache.org/jira/browse/HDFS-2617
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: security
> Reporter: Jakob Homan
> Assignee: Jakob Homan
> Fix For: 2.1.0-alpha
>
> Attachments: HDFS-2617-a.patch, HDFS-2617-b.patch,
> HDFS-2617-config.patch, HDFS-2617-trunk.patch, HDFS-2617-trunk.patch,
> HDFS-2617-trunk.patch, HDFS-2617-trunk.patch, hdfs-2617-1.1.patch
>
>
> The current approach to secure and authenticate nn web services is based on
> Kerberized SSL and was developed when a SPNEGO solution wasn't available. Now
> that we have one, we can get rid of the non-standard KSSL and use SPNEGO
> throughout. This will simplify setup and configuration. Also, Kerberized
> SSL is a non-standard approach with its own quirks and dark corners
> (HDFS-2386).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
