[
https://issues.apache.org/jira/browse/HDFS-13617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16524793#comment-16524793
]
Erik Krogen edited comment on HDFS-13617 at 6/27/18 9:16 AM:
-------------------------------------------------------------
Hey [~vagarychen], I just tried to apply this on trunk and the patch failed to
apply. Can you try rebasing again?
Looking at the patch makes me feel that we need to reduce the attack surface
for replay attacks. For example, instead of just generating a secret of the
QOP, can we generate a secret of the QOP + clientUserName (which can't be faked
due to Kerberos auth)? I think ideally it would contain some combination of the
QOP, client user name, client IP, and block ID.
Some smaller comments:
* {{PBHelperClient}} L357 is checking if {{builder}} has a handshake secret; it
should be checking {{tok}}
* For {{DFS_QOP_WRAP_HMAC_ALGORITHM_DEFAULT}}, it looks like other similar
usages hard-code this. Does this need to be configurable? Is it required to
match the HMAC algorithm for the {{BlockTokenSecretManager}}, or can you
mix-and-match a {{SecretKey}} and {{Mac}} with different algorithms? If they
need to match, we should use a shared constant.
* Is {{IOException}} really the right exception to throw for the two
misconfiguration cases within the {{NameNodeRpcServer}} constructor? I think a
{{Precondition}} or {{IllegalArgumentException}} or something would be more
suitable.
* The {{Mac}} instance needs to be {{ThreadLocal}}. It could also use a more
descriptive name.
Just for my reference, this patch *only* adds the NameNode side of things; the
client / DataNode handling is in HDFS-13699.
was (Author: xkrogen):
Hey [~vagarychen], I just tried to apply this on trunk and the patch failed to
apply. Can you try rebasing again?
Some initial thoughts:
* {{PBHelperClient}} L357 is checking if {{builder}} has a handshake secret; it
should be checking {{tok}}
* For {{DFS_QOP_WRAP_HMAC_ALGORITHM_DEFAULT}}, it looks like other similar
usages hard-code this. Does this need to be configurable? Is it required to
match the HMAC algorithm for the {{BlockTokenSecretManager}}, or can you
mix-and-match a {{SecretKey}} and {{Mac}} with different algorithms? If they
need to match, we should use a shared constant.
* Is {{IOException}} really the right exception to throw for the two
misconfiguration cases within the {{NameNodeRpcServer}} constructor? I think a
{{Precondition}} or {{IllegalArgumentException}} or something would be more
suitable.
* The {{Mac}} instance needs to be {{ThreadLocal}}. It could also use a more
descriptive name.
* Looking at the patch makes me feel that we need to reduce the attack surface
for replay attacks. For example, instead of just generating a secret of the
QOP, can we generate a secret of the QOP + clientUserName (which can't be faked
due to Kerberos auth)? I think ideally it would contain some combination of the
QOP, client user name, client IP, and block ID.
Just for my reference, this patch *only* adds the NameNode side of things; the
client / DataNode handling is in HDFS-13699.
> Allow wrapping NN QOP into token in encrypted message
> -----------------------------------------------------
>
> Key: HDFS-13617
> URL: https://issues.apache.org/jira/browse/HDFS-13617
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Reporter: Chen Liang
> Assignee: Chen Liang
> Priority: Major
> Attachments: HDFS-13617.001.patch, HDFS-13617.002.patch
>
>
> This Jira allows NN to configurably wrap the QOP it has established with the
> client into the token message sent back to the client. The QOP is sent back
> in encrypted message, using BlockAccessToken encryption key as the key.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
