hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Thompson (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-2617) Replaced Kerberized SSL for image transfer and fsck with SPNEGO-based solution
Date Tue, 17 Jul 2012 17:31:36 GMT

    [ 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

        

Mime
View raw message