Subject: [nfsv4] Decoupling Transport Security from User Identity

From: David Noveck <[email-masked]>
Date: Thu, 6 Sep 2018 05:56:16 -0400

Chuck started a recent discussion of this issue that I'd like to follow up
on.   My impression is that most people think think decoupling these is a
useful direction for implementation but it isn't clear what specification
work in this area, if any, needs to be done.

People have cited a number of reasons why decoupling these would be helpful
(performance, encryption of data that might otherwise be the subject of
traffic analysis), but nobody has cited any reasons why using krb5p might
be better in some way, beyond the simple fact that this is the approach
assumed in the Security Considerations sections of RFCs 7530 and 5661.  In
light of he context of the current discussion, I can't assume that this
means there aren't any such reasons.

I think we need to be aware of any potential downsides of the decooupled
approach because we might want to revise the Security Considerations
sections of these RFCs.   Beyond the possible need to take a different
approach to transport security (perhaps giving at least equal billing to
the decoupled approach), there is a need to strengthen these sections as
previous IESG comments have shown.   In the Security directorate review of
RFC8275, which referred, in discussing security issues, to RFC7530, the
Security Considerartions section of RFC7530 was characterized as "woefully
inadequate" and "a collection of random thoughts jotted down in haphazard
fashion".  While RFC8275 was approved despite these concerns, we might want
to think about addressing the inadequacies in existing treatments of NFSv4
security.

If the working group does take on the work of revising the NFSv4 security
approach, then we need to be in agreement about how to characterize the
choice between the decoupled approach and the current approach, as I expect
both to exist for quite some time with neither being deprecated.   Clearly
AUTH_SYS will remain appropriately deprecated, at least when used in the
clear.

I'd like to hear people's opinions on whether the working group should take
on this work and any other comments about how we should address the
decoupling issue from a specification point of view.   I'm particularly
interested in the possible existence of arguments people might make to
support retention of  the primacy of the current (coupled) approach,
whether you think those arguments are valid or not. If we think the
decoupled approach is OK in general,  then we need to say so, properly deal
with cases where it isn't, and be prepared for any pushback.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 6 Sep 2018 15:27:29 -0400

> On Sep 6, 2018, at 5:56 AM, David Noveck <[email-masked]> wrote:
> 
> Chuck started a recent discussion of this issue that I'd like to follow up on.   My impression is that most people think think decoupling these is a useful direction for implementation but it isn't clear what specification work in this area, if any, needs to be done.
> 
> People have cited a number of reasons why decoupling these would be helpful (performance, encryption of data that might otherwise be the subject of traffic analysis), but nobody has cited any reasons why using krb5p might be better in some way, beyond the simple fact that this is the approach assumed in the Security Considerations sections of RFCs 7530 and 5661.  In light of he context of the current discussion, I can't assume that this means there aren't any such reasons.
> 
> I think we need to be aware of any potential downsides of the decooupled approach because we might want to revise the Security Considerations sections of these RFCs.   Beyond the possible need to take a different approach to transport security (perhaps giving at least equal billing to the decoupled approach), there is a need to strengthen these sections as previous IESG comments have shown.   In the Security directorate review of RFC8275, which referred, in discussing security issues, to RFC7530, the Security Considerartions section of RFC7530 was characterized as "woefully inadequate" and "a collection of random thoughts jotted down in haphazard fashion".  While RFC8275 was approved despite these concerns, we might want to think about addressing the inadequacies in existing treatments of NFSv4 security. 
> 
> If the working group does take on the work of revising the NFSv4 security approach, then we need to be in agreement about how to characterize the choice between the decoupled approach and the current approach, as I expect both to exist for quite some time with neither being deprecated.   Clearly AUTH_SYS will remain appropriately deprecated, at least when used in the clear.
> 
> I'd like to hear people's opinions on whether the working group should take on this work and any other comments about how we should address the decoupling issue from a specification point of view.   I'm particularly interested in the possible existence of arguments people might make to support retention of  the primacy of the current (coupled) approach, whether you think those arguments are valid or not. If we think the decoupled approach is OK in general,  then we need to say so, properly deal with cases where it isn't, and be prepared for any pushback.

I would like to see continued conversation about these issues
here on this mailing list, perhaps eventually stated more
officially in a requirements document.

--
Chuck Lever