Subject: [nfsv4] Review of draft-cel-nfsv4-rpc-tls-00

From: David Noveck <[email-masked]>
Date: Mon, 26 Nov 2018 11:18:24 -0500

*General Comments*

*Overall Evaluation*

One difficulty in reviewing this document is the contrast between the
overall text of the document and the impression conveyed by the  title and
abstract, which are more appropriate to a document of far more limited
scope. I have chosen to ignore, for the most part, these introductory
elements which promise a more limited scope and tried to the review the
document as a whole, including important elements not mentioned in this
introductory material.  For a more extensive discussion of this divergence,
see *Abstract*.

Looking at the document as whole,Trond and Chuck have produced a good start
on addressing an important problem for NFSv4 which has been around since
RFC3010.  The approach taken in RFCs 3010, 3530, 5661, and 7530, that of
encouraging use of RPCSEC GSS, while  it looked promising initially, has
not been followed up on to the degree originally expected.   As a result,
NFSv4 security has been left in an unsatisfactory state.   I believe that
the working group needs to tackle the issue and not simply assume that
another few years will allow the current approach to be used successfully
in most environments.  I feel that the working group would do well to base
its approach on the document under review although other approaches are
possible and should be considered if they were to be put forth.  Since none
have, I feel the working group should use this document as the basis for a
new approach to NFS security.   For more detail about how this might
happen, see *Connection with NFSv4* and *Potential Next Steps.*

One current weakness in the document has to do with the attempt to
rehabilitate AUTH_SYS.  While I believe that AUTH_SYS can be made secure in
a technically sound way, once the issues discussed below in *Handling of
AUTH_SYS "Authentication" *are addressed, I think the document needs to do
a better job of explaining why it is ncessary for people to use numeric
uid's and gid's again, which might strike many as a step backward for
Nfsv4.   While the document does make a clear case that RPCSEC GSS with
privacy/integrity gives rise to serious performance issues that need to be
addressed, it seems to me that the corresponding explanation for the other
divergence from the existing NFSv4 security approach will probably need
further elaboration to be convincing/acceptable to the IESG and the
Security Directorate.

*Connection with NFSv4*

This document is directed at RPC in general and is not presented as an
NFSv4 document, other than by the fact that it is associated with this
working group.   This make sense because that is where technical changes
are necessary, and the mechanisms proposed could be used by other RPC
protocols.

On the other hand, the motivation for this document is derived from
security issues within NFSv4, the deployment choices that need to be
discussed will concern NFSv4 (and other NFS) deployments and the
practicality of this aproach will essentially concern, in very large part,
the practicality of converting existing NFS implementations to use it.

Such considerations make it inevitable that the document contain some more
explicit mention of the role of NFS and NFSv4 in motivating the deployment
and use of this mechanism.  See the discussion in *4.3 Authentication
(editor's note*) for more detail.

*Handling of AUTH_SYS "Authentication"*

The current draft manifests a degree of confusion/uncertainty about the
potential role of AUTH_SYS which needs to be resolved at some point.   In
Section 4.3. it proposes a way of making use of AUTH_SYS reasonably secure
by combining it with client authentication, going so far as to describe it,
if I am not mistaken, as "optimal".   However, in an editor's note
appended  to that same section, it dicusses the possiiblity of dispensing
with TLS client authentication leaving the server with the role of
passively accepting and acting upon the user identities transmitted by an
unauthenticated client.

The security implications of such a step need to be considered and it needs
to be realized how insecure the resulting deployments would be. This would
leave use of RPCSEC GSS as the only way of providing user authetication,
which is inconsistent with the document's concerns about the administrative
overhead of RPCSEC GSS and the role of such issues in maintaining extensive
use of AUTH_SYS, despite its clear lack of security.

It may be that the authors are relying on the fact that AUTH_SYS with
encryption is better than AUTH_SYS in the clear and that AUTH_SYS is
currently used by many NFS deployments including NFSv4 deployments that
support, as required by RFCs 7530 and 5661, RPCSEC GSS with privacy and
integrity.   However, it needs to be realized that the degree of physical
isolation and administrative controls necessary to make the current
approach to use of AUTH_SYS reasonably  secure are not achievable by most
NFS deployments and that traffic encryption will not change that  fact.
While use of AUTH_SYS was allowed by RFC3530 (fifteen years ago) and has
continued to be allowed by subsequent RFCs,  deployments based on server
acceptance of unauthenticated requests should have been eliminated years
ago.  Since that has not happened yet, the time to enable that advance is
now.

*Potential Next Steps*

Chuck has already requested feedback regarding working group interst in
this approach with the expectation of converting this document to be a
working group item in the near future.   Although it is hard to fully gauge
working group interest, this review provides some relevant input and I note
that others have expressed interest and there have been no messages
indicating that this work is not needed or that it should be addressed in a
substantially different way.

My recommendation is that Chuck request working group status at the next
iteration of this document.   While my review has turned up a number of
issues that I think need to be addressed, I don't think that most of them
need to be adressed before the conversion to working group status.  The
excepton would be the issue of document scope discussed in *Abstract*.

It is true that Tom Talpey struck a cautionary tone, pointing out the
potential need for the the co-chairs and Spencer D to deal with
administrative issues raised by converting this to be a working group
item.   I feel that there is no need to be unduly worried about this issue
since the current charter already calls out security as a possible area of
working group interest and there is provision in the charter to add new
working group items after consultation with the Area Director.   If there
are additional difficulties for this draft, the best way of getting them
addressed would be for Chuck to follow his original plan and request
working group status when he and Trond feel the document is ready, leaving
it up to Beepy and the Spencers to deal with the administrative issues, or
push back, at that time.   The discussion on the mailing list up to that
point should provide the necessary background and there is also the
possibility of the authors supplementing that with email to the cochairs
and the AD, if necessary.

*Comments by Section*

*Abstract*

The abstract focuses on a single part of the document, ignoring other
important elements of the document.  The same goes for the title.  If one
looks at the document as a whole, there is significant concern with all the
reasons that RPCSEC GSS has not been deployed, whereas the abstract ignores
many of these and simply focuses on the non-deployment of RPCSEC GSS with
privacy and integrity, which would basically be a performance issue, if
RPPCSEC GSS were widely deployed and used.

I think the authors (and eventually the working group) face a choice
between:

   - Revising the abstract and title to reflect the document as a whole.
   - Revising the document so that it has a more limited focus consistent
   with the current abstract and title.

I would prefer the former choice and have done this review pretty much
assuming that this choice would be made. However, the latter choice could
result in a document that would be a useful advance that is worth pursuing,
with the other elements followed up on later.  Others in the working group
may well have different opinions about this issue and it probably would be
best if this issue were resolved before the document became a working group
item.

*1.  Introduction*

With regard to the second paragraph, suggest the following changes:

   - In the first sentence, replace "around" by "available as a Proposed
   standard".
   - In the second sentence, replace "years ago" by "over twenty years ago".
   - In the third sentence, replace "challenging" by "difficult".

With regard to the bullets following the second paragraph:

   - With regard to the first bullet, I'm not clear that *per-host*
administrative
   costs are the issue here.   Given that NFS currently does not authenticate
   clients, per-user administrative costs are of at least equal importance in
   explaining the troubling lack of  extensive use of RPCSEC GSS by NFSv4
   clients.
   - In the second bullet, suggest replacing "Parts" by "The parts" and
   "are a security exposure" by "constitite an important security exposure".
   - The third bullet only concerns cases in which privacy (or integrity)
   are used and so are not relevant to the difficulty of deploying RPCSEC GSS
   as cited in the introductory pargraph.  Not sure how to address this but it
   is likely that this mateial will have to be re-organized.
   - I don''t really understand what you're getting at in the fourth
   bullet.  Since other people have also asked about this, it seems that some
   clarification is required.

Suggest replacing the third (non-bulleted) paragraph by the following:

Regardless of the strength of a privacy mechanism, it cannot contribute to
security if the difficulties of deploying and using it are such that it is
not in fact used.   As an example, [RFC3530] first mandated the
implementation of RPCSEC GSS with privcy and integrity by NFSv4 servers
over fifteen years ago, yet use of these features is still quite limited
and use of AUTH_SYS with NFSv4 remains common.

In the paragraph headed "Protection of Existing Protocols, feel that citing
NFSv4.2 (alone) is not appropriate.   I believe all non-legacy NFS versions
need to be mentioned.  Suggest rewriting the second sentence to read as
follows:

RPC transport layer encryption could provide protection for all minor
versions of NFSv4 [RFC7530] [RFC5661] [RFC7862] and also legacy NFS
versions such as NFS version 3 [RFC1813] and NFS side-band protocols
such as the MNT protocol [RFC1813].

Also want to note that no non-NFS-related protocols are mentioned,
presumably because there is no significant use of such protocols. Don't
think that there needs to be any change to the text but feel that if this
is really pretty much about NFS and its side-band protocols, this will
affect the shape of the eventual Proposed Standard.

The paragraph headed "Decoupled Host and User Identities" does not make
clear why this is a "significant benefit" as promised by the lead-in
paragraph.

*4.1  Discovering Server-side TLS Support*

The first sentence of the first paragraph, is not, strictly speaking, true,
since the mechanism described is disabled in these circumstances, as
indicated in the second sentence.  Suggest rewriting this sentence as
follows:

The mechanism described in this document provides for full (unencrypted)
interoperation with RPC implementations that do not support it.

*4.2 Streams and Datagrams*

With regard to the first senence of the first paragraph, I am not aware of
any use of RPC on transports other that stream transports and datagram
transports or even if any such transports exist.  Suspect that "commonly"
needs to be deleted.

With regard to the second (TLS) sentence, the statement is true.  However,

   - In a standards-track document, which I believe this document aspires
   to become, the statement that something is "appropriate" is insufficient.
   You need to specify how it is to be used.
   - Given that section 4.1 has already done so, there is no point  in
   stating that what the previous section told you do is "appropriate".   If
   it weren't appropriate, it wouldn't be there.

With regard to the third (DTLS) sentence, the difficulties are
complementary:

   - You are saying it is appropriate but it is not clear how it would be
   used.
   - Given that it is not mentioned in Section 4.1, it is not clear if it
   is to be included in the eventual Proposed Standard.

I think you need to make a decision and make clear what you are doing about
DTLS.  You could:

   - Make this a more NFSv4-focused document and drop DTLS, at least for
   now.
   - Leave this document as it is as RPC-focusd but fully support DTLS, to
   the same degree that TLS is supported.  I'm not staying you have to go so
   far as to change the title of section 4.1 and add the string "STARTDTLS"
   :-), but you need to make clear how DTLS is to be supported by the eventual
   Proposed Standard, even though many implementations might not choose to do
   so.
   - Leave DTLS support as an item to be provided later, while making it
   clear that it will be provided for when the document is complete.

I don't understand why the second paragraph is here.  There is some useful
stuff to be said about the interaction of this mechanism and encryption
below the transport layer but:

   - I'm not sure it belongs in this section.
   - Any treatment of this issue should not be limited to RDMA.
   - If the issue is that there is to be no support for this mechanism when
   RPC-over-RDMA is used, that needs to be stated explicitly and possibly in
   some other section.

*4.3 Authentication (main body)*

As regards the first sentence of the first paragraph, it is not clear to me
that TLS does have its own concept of user authenication.  If it does, this
needs to be clarified.

I have problems with the use of the word "optimal" in the second sentence.
Specifically:

   - It is unclear exactly what it means when all of security, efficiency,
   flexibility are mentioned.
   - It is unlikely that a single approach will satisfy all needs while one
   which is truly "optimal" might be expected to.
   - It is unnecessary to promise something as difficult as optimality,
   since all we need to provide is something that is useful for a range of
   deployments, which are not being otherwise addressed.

Suggest, as a possible replacement, the following:

Although many combinations are possible, the combination of host
authentication via TLS and user authentication via RPC provides a high
degree of security together with more efficient encryption, and
sufficient flexibility to accommodate deployments that have been
unable to use RPCSEC GSS due to its administrative overhead
requirements.

Despite the fact that this is not an NFSv4-focused document, there needs to
be a some note taken of the security problems with use of AUTH_SYS, given
that some deployment possibilities using AUTH_SYS are mentioned.   Even
though AUTH_SYS is allowable for NFSv3 and retained, pretty much on
sufference, by NFSv4, there needs to some acknowledgement of the security
issues that use of AUTH_SYS gives rise to, even in the absence of someone
minitoring your traffic, which is the prime focus of the encryption
proposed here.  Specifically,

   - The section on "TLS encryption-only with AUTH_SYS" needs some sort of
   acknowledgement that what is proposed is a scheme in which a server acts on
   RPC requests for which there is no trustworthy authentication whatsoever.
    The only authentication is provided by an unauthenticated client, which,
   in security terms, is pretty much valueless.   Certainly, this is a step up
   from AUTH_SYS without encryption but it needs to be made clearer that this
   still leaves an enormous security hole.
   - The section on "TLS per-client certificate with AUTH_SYS" needs some
   additiional text that makes clear the need to authenticate the client if
   you are essentially trusting the client to authenticate the users.  Suggest
   adding the following after the current first sentence:

Once the client is authenticated, there is a reasonable basis for accepting
the UID and GID values in RPC requests it issues, under the assumption that
the authenticated client is responsible for user authentication.

 Regarding the section headed "TLS per-user certificate with AUTH_NONE", I
have a few issues to note:

   - It is unclear what is to be conveyed by the statement that such
   deplyments are not "typical". My understanding is that the typical NFS
   deployment uses AUTH_SYS in the clear :-(, making everything else, to some
   degree, atypical. If the potential deployments mentioned here do not exist,
   or are very rare, that shoud be clearly stated. That need not be a reason
   to apologize, if there are good reasons, as I believe there might be, to
   create such deployments now.
   - I'm not clear how this model would work in the case of NFSv4 in which
   there is the possibillity of significant state shared among users. Would
   these connections share a clientid and/or a session? Such issues would need
   to be addressed at some point. If there needs to be further work to resolve
   such questions, that fact should be noted.

*4.3 Authentication (editor's note)*

I agree that there is material that is currently skeletal, although I don't
think that the current Section 4.3 itself is skeletal.  That section
currently lays out a wide range of possibilities and I feel it is right for
it do so.  I agree that there is a need for a selection of those that
should be deployed leading to recommendations and possibly requirements for
deployment.  I feel that what is needed  is a new section dealing with
deployment choices rather than major surgery (amputations?) within Section
4.3.   Although these choices need to be further clarified, the nature of
those choices will depend on the protocols to be supported.  In other
words, even if the document as a whole is not to be NFS-focused or
NFSv4-focused, this new section pretty much has to be one or the other.

With reagrd to the existing bullets:

   - Any such culling of deployment models only makes sense in the context
   of a specific group of protocols, such as the NFSv4 protocols, or all
   NFS-related protocols   It is best if the discussion of possible choices
   makes that choice explicit.
   -  I don't see how you can dispense with client authentication,
   especially since you chracterize it in Section 4.3 as being part of an
   "optimal" approach ;-).   In fact, if you cannot have two AUTH_SYS-based
   models, I would feel that the one without authenication would have to go
   and it is difficult to see the IESG and the Security Directorate accepting
   another zero-authentication model for use by NFSv4, even though we are
   (unfortunately) currently living with one.   It is true that encrypting the
   traffic is a positive but the AUTH_SYS gaping hole caused by the lack of
   secure user authentication remains.  I think that if you have a chance of
   providing client authenication, we have to provide for its reasonably safe
   use and the framwork you have already elaborated is a good opportunity to
   do that.

*5. Security Considerations*

Given that explicit reference is made elsewhere in this document to the
potential use of AUTH_SYS, I believe that there need to be some discussion
of the security issues that this brings in its wake in the Security
Considerations section.   The treatment  will depend on choices yet to be
made but I don't see how a Security Considerations section can avoid
dealing with the issues, no matter which choices are made.

*7.1. Normative References*

Unless the material regardiing RPC-over-RDMA were to be substantially
expanded, I don't see why the reference to RFC8166 should  be Normative and
I think it makes more sense as Informative.

*7.2. Informative References*

As already noted I believe that RFCs 7530 and 5661 should be reference,
presumably informatively.  However, it is possible that a discussion of
authentication issues (as discussed above) might need to reference these
documents normatively.

---

From: Chuck Lever <[email-masked]>
Date: Tue, 27 Nov 2018 11:38:22 -0500

Hi Dave, thanks for the review. I will endeavor to produce another
revision that addresses most of your review comments. Section 4.3
is obviously an area that will need an intense amount of discussion.

A few immediate reactions are inline below.

> On Nov 26, 2018, at 11:18 AM, David Noveck <[email-masked]> wrote:
> 
> General Comments
> 
> Overall Evaluation
> 
> One difficulty in reviewing this document is the contrast between the overall text of the document and the impression conveyed by the  title and abstract, which are more appropriate to a document of far more limited scope. I have chosen to ignore, for the most part, these introductory elements which promise a more limited scope and tried to the review the document as a whole, including important elements not mentioned in this introductory material.  For a more extensive discussion of this divergence, see Abstract.
> 
> Looking at the document as whole,Trond and Chuck have produced a good start on addressing an important problem for NFSv4 which has been around since RFC3010.  The approach taken in RFCs 3010, 3530, 5661, and 7530, that of encouraging use of RPCSEC GSS, while  it looked promising initially, has not been followed up on to the degree originally expected.   As a result,  NFSv4 security has been left in an unsatisfactory state.   I believe that the working group needs to tackle the issue and not simply assume that another few years will allow the current approach to be used successfully in most environments.  I feel that the working group would do well to base its approach on the document under review although other approaches are possible and should be considered if they were to be put forth.  Since none have, I feel the working group should use this document as the basis for a new approach to NFS security.   For more detail about how this might happen, see Connection with NFSv4 and Potential Next Steps.
> 
> One current weakness in the document has to do with the attempt to rehabilitate AUTH_SYS.  While I believe that AUTH_SYS can be made secure in a technically sound way, once the issues discussed below in Handling of AUTH_SYS "Authentication" are addressed, I think the document needs to do a better job of explaining why it is ncessary for people to use numeric uid's and gid's again, which might strike many as a step backward for Nfsv4.   While the document does make a clear case that RPCSEC GSS with privacy/integrity gives rise to serious performance issues that need to be addressed, it seems to me that the corresponding explanation for the other divergence from the existing NFSv4 security approach will probably need further elaboration to be convincing/acceptable to the IESG and the Security Directorate.
> 
> Connection with NFSv4
> 
> This document is directed at RPC in general and is not presented as an NFSv4 document, other than by the fact that it is associated with this working group.   This make sense because that is where technical changes are necessary, and the mechanisms proposed could be used by other RPC protocols.  
> 
> On the other hand, the motivation for this document is derived from security issues within NFSv4, the deployment choices that need to be discussed will concern NFSv4 (and other NFS) deployments and the practicality of this aproach will essentially concern, in very large part, the practicality of converting existing NFS implementations to use it. 
> 
> Such considerations make it inevitable that the document contain some more explicit mention of the role of NFS and NFSv4 in motivating the deployment and use of this mechanism.  See the discussion in 4.3 Authentication (editor's note) for more detail.

I'm not sure I understand the issue here. NFSv4 depends on RPC
for identifying users. What more do you believe needs to be said
and why do you feel it needs to be said in this document?

> Handling of AUTH_SYS "Authentication"
> 
> The current draft manifests a degree of confusion/uncertainty about the potential role of AUTH_SYS which needs to be resolved at some point.   In Section 4.3. it proposes a way of making use of AUTH_SYS reasonably secure by combining it with client authentication, going so far as to describe it, if I am not mistaken, as "optimal".   However, in an editor's note appended  to that same section, it dicusses the possiiblity of dispensing with TLS client authentication leaving the server with the role of passively accepting and acting upon the user identities transmitted by an unauthenticated client.  
> 
> The security implications of such a step need to be considered and it needs to be realized how insecure the resulting deployments would be. This would leave use of RPCSEC GSS as the only way of providing user authetication, which is inconsistent with the document's concerns about the administrative overhead of RPCSEC GSS and the role of such issues in maintaining extensive use of AUTH_SYS, despite its clear lack of security. 
> 
> It may be that the authors are relying on the fact that AUTH_SYS with encryption is better than AUTH_SYS in the clear and that AUTH_SYS is currently used by many NFS deployments including NFSv4 deployments that support, as required by RFCs 7530 and 5661, RPCSEC GSS with privacy and integrity.   However, it needs to be realized that the degree of physical isolation and administrative controls necessary to make the current approach to use of AUTH_SYS reasonably  secure are not achievable by most NFS deployments and that traffic encryption will not change that  fact.  While use of AUTH_SYS was allowed by RFC3530 (fifteen years ago) and has continued to be allowed by subsequent RFCs,  deployments based on server acceptance of unauthenticated requests should have been eliminated years ago.  Since that has not happened yet, the time to enable that advance is now.
> 
> Potential Next Steps
> 
> Chuck has already requested feedback regarding working group interst in this approach with the expectation of converting this document to be a working group item in the near future.   Although it is hard to fully gauge working group interest, this review provides some relevant input and I note that others have expressed interest and there have been no messages indicating that this work is not needed or that it should be addressed in a substantially different way.   
> 
> My recommendation is that Chuck request working group status at the next iteration of this document.   While my review has turned up a number of issues that I think need to be addressed, I don't think that most of them need to be adressed before the conversion to working group status.  The excepton would be the issue of document scope discussed in Abstract.
> 
> It is true that Tom Talpey struck a cautionary tone, pointing out the potential need for the the co-chairs and Spencer D to deal with administrative issues raised by converting this to be a working group item.   I feel that there is no need to be unduly worried about this issue since the current charter already calls out security as a possible area of working group interest and there is provision in the charter to add new working group items after consultation with the Area Director.   If there are additional difficulties for this draft, the best way of getting them addressed would be for Chuck to follow his original plan and request working group status when he and Trond feel the document is ready, leaving it up to Beepy and the Spencers to deal with the administrative issues, or push back, at that time.   The discussion on the mailing list up to that point should provide the necessary background and there is also the possibility of the authors supplementing that with email to the cochairs and the AD, if necessary.
>   
> Comments by Section
> 
> Abstract
> 
> The abstract focuses on a single part of the document, ignoring other important elements of the document.  The same goes for the title.  If one looks at the document as a whole, there is significant concern with all the reasons that RPCSEC GSS has not been deployed, whereas the abstract ignores many of these and simply focuses on the non-deployment of RPCSEC GSS with privacy and integrity, which would basically be a performance issue, if RPPCSEC GSS were widely deployed and used.    
> 
> I think the authors (and eventually the working group) face a choice between:
> 	• Revising the abstract and title to reflect the document as a whole.
> 	• Revising the document so that it has a more limited focus consistent with the current abstract and title.
> I would prefer the former choice and have done this review pretty much assuming that this choice would be made. However, the latter choice could result in a document that would be a useful advance that is worth pursuing, with the other elements followed up on later.  Others in the working group may well have different opinions about this issue and it probably would be best if this issue were resolved before the document became a working group item.

The term "Encryption by default" has a particular connotation in other
areas of network protocol development. It is really the big-picture
benefit delivered by the mechanism proposed in this document. I prefer
to keep that term in the Title.

However, the Abstract text is still quite flexible. One thing that can
be done is to spend a few sentences in the Abstract to explain the
intended meaning of "Encryption by default". 

> 1.  Introduction
> 	• In the first sentence, replace "around" by "available as a Proposed standard".
> 	• In the second sentence, replace "years ago" by "over twenty years ago".
> 	• In the third sentence, replace "challenging" by "difficult".
> 	• With regard to the first bullet, I'm not clear that per-host administrative costs are the issue here.   Given that NFS currently does not authenticate clients, per-user administrative costs are of at least equal importance in explaining the troubling lack of  extensive use of RPCSEC GSS by NFSv4 clients.
> 	• In the second bullet, suggest replacing "Parts" by "The parts" and "are a security exposure" by "constitite an important security exposure".
> 	• The third bullet only concerns cases in which privacy (or integrity) are used and so are not relevant to the difficulty of deploying RPCSEC GSS as cited in the introductory pargraph.  Not sure how to address this but it is likely that this mateial will have to be re-organized.
> 	• I don''t really understand what you're getting at in the fourth bullet.  Since other people have also asked about this, it seems that some clarification is required.
> Regardless of the strength of a privacy mechanism, it cannot contribute to security if the difficulties of deploying and using it are such that it is not in fact used.   As an example, [RFC3530] first mandated the implementation of RPCSEC GSS with privcy and integrity by NFSv4 servers over fifteen years ago, yet use of these features is still quite limited and use of AUTH_SYS with NFSv4 remains common. 
> 
> In the paragraph headed "Protection of Existing Protocols, feel that citing NFSv4.2 (alone) is not appropriate.   I believe all non-legacy NFS versions need to be mentioned.  Suggest rewriting the second sentence to read as follows:
> RPC transport layer encryption could provide protection for all minor versions of NFSv4 [RFC7530] [RFC5661] [RFC7862] and also legacy NFS versions such as NFS version 3 [RFC1813] and NFS side-band protocols such as the MNT protocol [RFC1813].
> Also want to note that no non-NFS-related protocols are mentioned, presumably because there is no significant use of such protocols.  Don't think that there needs to be any change to the text but feel that if this is really pretty much about NFS and its side-band protocols, this will affect the shape of the eventual Proposed Standard.
> 
> The paragraph headed "Decoupled Host and User Identities" does not make clear why this is a "significant benefit" as promised by the lead-in paragraph.  
> 
> 4.1  Discovering Server-side TLS Support
> 
> The first sentence of the first paragraph, is not, strictly speaking, true, since the mechanism described is disabled in these circumstances, as indicated in the second sentence.  Suggest rewriting this sentence as follows:
> 
> The mechanism described in this document provides for full (unencrypted) interoperation with RPC implementations that do not support it.
> 
> 4.2 Streams and Datagrams
> 
> With regard to the first senence of the first paragraph, I am not aware of any use of RPC on transports other that stream transports and datagram transports or even if any such transports exist.  Suspect that "commonly" needs to be deleted. 
> 
> 	• In a standards-track document, which I believe this document aspires to become, the statement that something is "appropriate" is insufficient.  You need to specify how it is to be used.
> 	• Given that section 4.1 has already done so, there is no point  in stating that what the previous section told you do is "appropriate".   If it weren't appropriate, it wouldn't be there.
> With regard to the third (DTLS) sentence, the difficulties are complementary:
> 	• You are saying it is appropriate but it is not clear how it would be used.
> 	• Given that it is not mentioned in Section 4.1, it is not clear if it is to be included in the eventual Proposed Standard.
> I think you need to make a decision and make clear what you are doing about DTLS.  You could:
> 	• Make this a more NFSv4-focused document and drop DTLS, at least for now.
> 	• Leave this document as it is as RPC-focusd but fully support DTLS, to the same degree that TLS is supported.  I'm not staying you have to go so far as to change the title of section 4.1 and add the string "STARTDTLS" :-), but you need to make clear how DTLS is to be supported by the eventual Proposed Standard, even though many implementations might not choose to do so.
> 	• Leave DTLS support as an item to be provided later, while making it clear that it will be provided for when the document is complete.
> I don't understand why the second paragraph is here.  There is some useful stuff to be said about the interaction of this mechanism and encryption below the transport layer but:
> 	• I'm not sure it belongs in this section.
> 	• Any treatment of this issue should not be limited to RDMA.
> 	• If the issue is that there is to be no support for this mechanism when RPC-over-RDMA is used, that needs to be stated explicitly and possibly in some other section.

I don't understand the issue you raise here.

You say that the treatment of this issue should not be limited to
RDMA. What other existing RPC transports should/can be discussed?

Section 8.2.1 of RFC 8166 discusses this issue more deeply. I can
cite that section here. 

> 4.3 Authentication (main body)
> 
> As regards the first sentence of the first paragraph, it is not clear to me that TLS does have its own concept of user authenication.  If it does, this needs to be clarified.
> 
> I have problems with the use of the word "optimal" in the second sentence.  Specifically:
> 	• It is unclear exactly what it means when all of security, efficiency, flexibility are mentioned.
> 	• It is unlikely that a single approach will satisfy all needs while one which is truly "optimal" might be expected to.
> 	• It is unnecessary to promise something as difficult as optimality, since all we need to provide is something that is useful for a range of deployments, which are not being otherwise addressed.
> Although many combinations are possible, the combination of host authentication via TLS and user authentication via RPC provides a high degree of security together with more efficient encryption, and sufficient flexibility to accommodate deployments that have been unable to use RPCSEC GSS due to its administrative overhead requirements.
> Despite the fact that this is not an NFSv4-focused document, there needs to be a some note taken of the security problems with use of AUTH_SYS, given that some deployment possibilities using AUTH_SYS are mentioned.   Even though AUTH_SYS is allowable for NFSv3 and retained, pretty much on sufference, by NFSv4, there needs to some acknowledgement of the security issues that use of AUTH_SYS gives rise to, even in the absence of someone minitoring your traffic, which is the prime focus of the encryption proposed here.  Specifically,
> 	• The section on "TLS encryption-only with AUTH_SYS" needs some sort of acknowledgement that what is proposed is a scheme in which a server acts on RPC requests for which there is no trustworthy authentication whatsoever.   The only authentication is provided by an unauthenticated client, which, in security terms, is pretty much valueless.   Certainly, this is a step up from AUTH_SYS without encryption but it needs to be made clearer that this still leaves an enormous security hole.
> 	• The section on "TLS per-client certificate with AUTH_SYS" needs some additiional text that makes clear the need to authenticate the client if you are essentially trusting the client to authenticate the users.  Suggest adding the following after the current first sentence:
> Once the client is authenticated, there is a reasonable basis for accepting the UID and GID values in RPC requests it issues, under the assumption that the authenticated client is responsible for user authentication.
> 
>  Regarding the section headed "TLS per-user certificate with AUTH_NONE", I have a few issues to note:
> 	• It is unclear what is to be conveyed by the statement that such deplyments are not "typical".   My understanding is that the typical NFS deployment uses AUTH_SYS in the clear :-(, making everything else, to some degree, atypical.   If  the potential deployments mentioned here do not exist, or are very rare, that shoud be clearly stated.   That need not be a reason to apologize, if there are good reasons, as I believe there might be, to create such deployments now.
> 	• I'm not clear how this model would work in the case of NFSv4 in which there is the possibillity of significant state shared among users.  Would these connections share a clientid and/or a session?  Such issues would need to be addressed at some point.   If there needs to be further work to resolve such questions, that fact should be noted.
> 4.3 Authentication (editor's note)
> 
> I agree that there is material that is currently skeletal, although I don't think that the current Section 4.3 itself is skeletal.  That section currently lays out a wide range of possibilities and I feel it is right for it do so.  I agree that there is a need for a selection of those that should be deployed leading to recommendations and possibly requirements for deployment.  I feel that what is needed  is a new section dealing with deployment choices rather than major surgery (amputations?) within Section 4.3.   Although these choices need to be further clarified, the nature of those choices will depend on the protocols to be supported.  In other words, even if the document as a whole is not to be NFS-focused or NFSv4-focused, this new section pretty much has to be one or the other.
> 
> 	• Any such culling of deployment models only makes sense in the context of a specific group of protocols, such as the NFSv4 protocols, or all NFS-related protocols   It is best if the discussion of possible choices makes that choice explicit.
> 	•  I don't see how you can dispense with client authentication, especially since you chracterize it in Section 4.3 as being part of an "optimal" approach ;-).   In fact, if you cannot have two AUTH_SYS-based models, I would feel that the one without authenication would have to go and it is difficult to see the IESG and the Security Directorate accepting another zero-authentication model for use by NFSv4, even though we are (unfortunately) currently living with one.   It is true that encrypting the traffic is a positive but the AUTH_SYS gaping hole caused by the lack of secure user authentication remains.  I think that if you have a chance of providing client authenication, we have to provide for its reasonably safe use and the framwork you have already elaborated is a good opportunity to do that.    
> 5. Security Considerations
> 
> Given that explicit reference is made elsewhere in this document to the potential use of AUTH_SYS, I believe that there need to be some discussion of the security issues that this brings in its wake in the Security Considerations section.   The treatment  will depend on choices yet to be made but I don't see how a Security Considerations section can avoid dealing with the issues, no matter which choices are made.
> 
> 7.1. Normative References
> 
> Unless the material regardiing RPC-over-RDMA were to be substantially expanded, I don't see why the reference to RFC8166 should  be Normative and I think it makes more sense as Informative.
> 
> 7.2. Informative References
> 
> As already noted I believe that RFCs 7530 and 5661 should be reference, presumably informatively.  However, it is possible that a discussion of authentication issues (as discussed above) might need to reference these documents normatively. 
> 

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 27 Nov 2018 13:17:06 -0500

> Section 4.3
> is obviously an area that will need an intense amount of discussion

The group has to be prepared for a lot of discussdion.   What I fear is that
it will not eventually terminate :-(

> Such considerations make it inevitable that the document contain some
more explicit mention of the role of NFS and NFSv4 in motivating the
deployment and use of this mechanism.  See the discussion in 4.3
Authentication (editor's note) for more detail.

> I'm not sure I understand the issue here.

Let me give you an example.   As you say, we will need a discussion of
Section 4.3 focusing on getting a set of deployment choices that people can
adopt to facilitate interoprable operation.   Unless I am very much
mistaken that discussion will be essentially about making sure we have
interoprable NFSv4 (or NFS) implementations.   If the results of that
discussion are written down, I don't see how you can avoid making it clear
that interoperable having NFSv4 (or NFS) is the goal.

> NFSv4 depends on RPC for identifying users.

I guess it depends on it for publising the results of user authentication.
 In the case of AUTH_SYS without client authentication, it is posible that
this will be faux authentication.

> What more do you believe needs to be said

What will be said depends on the results working group discussion but I
think you cannot to avoid the discussion how the changes you propose will
affect the security of NFSv4.   The bulk of that discussion will probably
win up in another document but I don't see how we can focus on the task of
improving NFSv4 security if it is not stated somewhere that this is an
important goal of the effort.

> intended meaning of "Encryption by default".

I think that needs to be done somewhere although probably not in the
abstract.

I think what is need in the abstract is some mention of the changes that I
expect you will be proposing, to, as I put it, to "rehabilitate" AUTH_SYS.
 You cite a number of issues that have interfered with extensive use of
RPCSEC GSS.   If that reluctance is to be considered legitimate as opposed
to deplorable laziness on the part of administrators, then you/we will have
to convince people that this is OK and I think that effort needs to
mentioned somehow in the abstract.

> RDMA.

I said that if RDMA is to be discussed, so should other similar sorts of
encryption.
I'm not sure any really need to be.

> What other existing RPC transports should/can be discussed?

The only possibility is use of VPN's which provides an equivalent to
physical network
security.  I don't see why that needs to be discussed, but if it doesn't,
why should
the equivalent for rdma be discussed?

> Section 8.2.1 of RFC 8166 discusses this issue more deeply. I can

If so the section should be re-oriented to be about the relationship to the
underlying transport in general.

On Tue, Nov 27, 2018 at 11:38 AM Chuck Lever <[email-masked]> wrote:

> see Abstract.
> > Looking at the document as whole,Trond and Chuck have produced a good
> start on addressing an important problem for NFSv4 which has been around
> since RFC3010.  The approach taken in RFCs 3010, 3530, 5661, and 7530, that
> of encouraging use of RPCSEC GSS, while  it looked promising initially, has
> happen, see Connection with NFSv4 and Potential Next Steps.
> >
> a technically sound way, once the issues discussed below in Handling of
> AUTH_SYS "Authentication" are addressed, I think the document needs to do a
> better job of explaining why it is ncessary for people to use numeric uid's
> and gid's again, which might strike many as a step backward for Nfsv4.
>  While the document does make a clear case that RPCSEC GSS with
> > Such considerations make it inevitable that the document contain some
> more explicit mention of the role of NFS and NFSv4 in motivating the
> deployment and use of this mechanism.  See the discussion in 4.3
> Authentication (editor's note) for more detail.
>
> > The security implications of such a step need to be considered and it
> needs to be realized how insecure the resulting deployments would be. This
> would leave use of RPCSEC GSS as the only way of providing user
> authetication, which is inconsistent with the document's concerns about the
> administrative overhead of RPCSEC GSS and the role of such issues in
> maintaining extensive use of AUTH_SYS, despite its clear lack of security.
> >
> excepton would be the issue of document scope discussed in Abstract.
> >
> >       • Revising the document so that it has a more limited focus
> consistent with the current abstract and title.
> >       • With regard to the first bullet, I'm not clear that per-host
> administrative costs are the issue here.   Given that NFS currently does
> not authenticate clients, per-user administrative costs are of at least
> equal importance in explaining the troubling lack of  extensive use of
> RPCSEC GSS by NFSv4 clients.
> >       • In the second bullet, suggest replacing "Parts" by "The parts"
> and "are a security exposure" by "constitite an important security
> exposure".
> >       • The third bullet only concerns cases in which privacy (or
> integrity) are used and so are not relevant to the difficulty of deploying
> RPCSEC GSS as cited in the introductory pargraph.  Not sure how to address
> this but it is likely that this mateial will have to be re-organized.
> >       • I don''t really understand what you're getting at in the fourth
> > Regardless of the strength of a privacy mechanism, it cannot contribute
> to security if the difficulties of deploying and using it are such that it
> is not in fact used.   As an example, [RFC3530] first mandated the
> > In the paragraph headed "Protection of Existing Protocols, feel that
> citing NFSv4.2 (alone) is not appropriate.   I believe all non-legacy NFS
> versions need to be mentioned.  Suggest rewriting the second sentence to
> read as follows:
> versions such as NFS version 3 [RFC1813] and NFS side-band protocols such
> as the MNT protocol [RFC1813].
> > The first sentence of the first paragraph, is not, strictly speaking,
> true, since the mechanism described is disabled in these circumstances, as
> > With regard to the first senence of the first paragraph, I am not aware
> of any use of RPC on transports other that stream transports and datagram
> >       • In a standards-track document, which I believe this document
> aspires to become, the statement that something is "appropriate" is
> insufficient.  You need to specify how it is to be used.
> >       • Given that section 4.1 has already done so, there is no point
> in stating that what the previous section told you do is "appropriate".
>  If it weren't appropriate, it wouldn't be there.
> >       • Given that it is not mentioned in Section 4.1, it is not clear
> if it is to be included in the eventual Proposed Standard.
> >       • Leave this document as it is as RPC-focusd but fully support
> DTLS, to the same degree that TLS is supported.  I'm not staying you have
> to go so far as to change the title of section 4.1 and add the string
> "STARTDTLS" :-), but you need to make clear how DTLS is to be supported by
> the eventual Proposed Standard, even though many implementations might not
> choose to do so.
> >       • Leave DTLS support as an item to be provided later, while making
> it clear that it will be provided for when the document is complete.
> > I don't understand why the second paragraph is here.  There is some
> useful stuff to be said about the interaction of this mechanism and
> encryption below the transport layer but:
> >       • If the issue is that there is to be no support for this
> mechanism when RPC-over-RDMA is used, that needs to be stated explicitly
> and possibly in some other section.
>
> > As regards the first sentence of the first paragraph, it is not clear to
> me that TLS does have its own concept of user authenication.  If it does,
> this needs to be clarified.
> >
> >       • It is unlikely that a single approach will satisfy all needs
> while one which is truly "optimal" might be expected to.
> >       • It is unnecessary to promise something as difficult as
> optimality, since all we need to provide is something that is useful for a
> range of deployments, which are not being otherwise addressed.
> degree of security together with more efficient encryption, and sufficient
> flexibility to accommodate deployments that have been unable to use RPCSEC
> GSS due to its administrative overhead requirements.
> > Despite the fact that this is not an NFSv4-focused document, there needs
> to be a some note taken of the security problems with use of AUTH_SYS,
> given that some deployment possibilities using AUTH_SYS are mentioned.
>  Even though AUTH_SYS is allowable for NFSv3 and retained, pretty much on
> >       • The section on "TLS encryption-only with AUTH_SYS" needs some
> sort of acknowledgement that what is proposed is a scheme in which a server
> acts on RPC requests for which there is no trustworthy authentication
> whatsoever.   The only authentication is provided by an unauthenticated
> client, which, in security terms, is pretty much valueless.   Certainly,
> this is a step up from AUTH_SYS without encryption but it needs to be made
> clearer that this still leaves an enormous security hole.
> >       • The section on "TLS per-client certificate with AUTH_SYS" needs
> some additiional text that makes clear the need to authenticate the client
> if you are essentially trusting the client to authenticate the users.
> Suggest adding the following after the current first sentence:
> > Once the client is authenticated, there is a reasonable basis for
> accepting the UID and GID values in RPC requests it issues, under the
> assumption that the authenticated client is responsible for user
> authentication.
> >
> >       • It is unclear what is to be conveyed by the statement that such
> degree, atypical.   If  the potential deployments mentioned here do not
> exist, or are very rare, that shoud be clearly stated.   That need not be a
> reason to apologize, if there are good reasons, as I believe there might
> be, to create such deployments now.
> >       • I'm not clear how this model would work in the case of NFSv4 in
> which there is the possibillity of significant state shared among users.
> Would these connections share a clientid and/or a session?  Such issues
> would need to be addressed at some point.   If there needs to be further
> work to resolve such questions, that fact should be noted.
> > I agree that there is material that is currently skeletal, although I
> don't think that the current Section 4.3 itself is skeletal.  That section
> >       • Any such culling of deployment models only makes sense in the
> context of a specific group of protocols, such as the NFSv4 protocols, or
> all NFS-related protocols   It is best if the discussion of possible
> choices makes that choice explicit.
> >       •  I don't see how you can dispense with client authentication,

---

From: Trond Myklebust <[email-masked]>
Date: Tue, 27 Nov 2018 14:36:27 -0500

Hi Dave,

I disagree with your apparent premise that this document needs to deal with
user authentication. The current scope of the document is just to enable a
transport level security, which authenticates the server to the client (and
may optionally authenticate the client to the server) and sets up a secure
channel for communication between the two.

The fact that authentication of the client to the server is optional is
very much intentional in the TLS protocol. It allows for alternate methods
of authentication of clients to the server through the secure channel that
is created. Since the server has been authenticated to the client, it also
allows the client to trust the server, for instance if it wants to transmit
a username+password as part of an alternative user authentication protocol
over the secure channel.

The server on the other hand has a number of options for dealing with a
client:

   1. It could allow access by unauthenticated clients and their users by
   offering access only to fully public parts of the namespace (i.e. those
   parts which offer access to the ANONYMOUS user).
   2. It could treat authenticated clients and their (unauthenticated)
   users as partially or fully trusted. e.g. squash the users to a single
   "trusted client" account, or simply accept AUTH_SYS information from that
   trusted client at face value.
   3. It could require that the users authenticate themselves. This could
   be done using the existing methods of setting up an RPCSEC_GSS/krb session
   over the trusted channel (no krbi or krbp options needed), but we could
   also look into setting up new authentication protocols that make use of the
   trusted channel.

None of the above 3 options really require us to define any new
authentication methods. They can all be used with existing tools.
I'd argue that (2) might benefit from a new "trusted client" special
identifier to allow users to set up ACLs specifically for dealing with this
situation, but that's not a requirement.
I'd also argue that (3) might benefit from having a 'LIPKEY'-like option to
allow users to authenticate using a user+password option in-band with the
RPC traffic. However again, that is not a requirement for being able to do
(3), and such a protocol could be defined as a separate document (much like
GSSAPI, SPKM and LIPKEY were defined as 3 separate documents).

Cheers
  Trond

On Tue, 27 Nov 2018 at 13:17, David Noveck <[email-masked]> wrote:

> I guess it depends on it for publising the results of user
> authentication.   In the case of AUTH_SYS without client authentication, it
> is posible that this will be faux authentication.
>
>> > My recommendation is that Chuck request working group status at the
>> next iteration of this document.   While my review has turned up a number
>> of issues that I think need to be addressed, I don't think that most of
>> them need to be adressed before the conversion to working group status.
>> The excepton would be the issue of document scope discussed in Abstract.
>> >
>> > The mechanism described in this document provides for full
>> (unencrypted) interoperation with RPC implementations that do not support
>> it.
>> >
>> >       • Leave DTLS support as an item to be provided later, while
>> making it clear that it will be provided for when the document is complete.
>> > As regards the first sentence of the first paragraph, it is not clear
>> to me that TLS does have its own concept of user authenication.  If it
>> does, this needs to be clarified.
>> >
>> > Despite the fact that this is not an NFSv4-focused document, there
>> needs to be a some note taken of the security problems with use of
>> AUTH_SYS, given that some deployment possibilities using AUTH_SYS are
>> mentioned.   Even though AUTH_SYS is allowable for NFSv3 and retained,
>> pretty much on sufference, by NFSv4, there needs to some acknowledgement of
>> the security issues that use of AUTH_SYS gives rise to, even in the absence
>> of someone minitoring your traffic, which is the prime focus of the
>> encryption proposed here.  Specifically,

---

From: David Noveck <[email-masked]>
Date: Wed, 28 Nov 2018 06:07:36 -0500

> I disagree with your apparent premise that this document needs to deal
with user authentication.

That is not my actual premise.

> The current scope of the document is just to enable a transport level
security, which authenticates the server to the client > (and may
optionally authenticate the client to the server) and sets up a secure
channel for communication between the
> two.

The current document does address  user authentication issues.  I have
problems with the way that is done, but would not object if a future
version deleted that material and dealt solely with transport security and
client authentication.

While I feel the working group does need to take steps to adress the fact
that AUTH_SYS continues to be heavily used for NFSv4,  your document is not
necessarily the right vehicle for that.   In any case, the working group
needs to consider what other work might be required and how to get that
work done.

On Tue, Nov 27, 2018 at 2:36 PM Trond Myklebust <[email-masked]> wrote:

> Hi Dave,
>
> I disagree with your apparent premise that this document needs to deal
> with user authentication. The current scope of the document is just to
> enable a transport level security, which authenticates the server to the
> client (and may optionally authenticate the client to the server) and sets
> up a secure channel for communication between the two.
>
> I'd also argue that (3) might benefit from having a 'LIPKEY'-like option
> to allow users to authenticate using a user+password option in-band with
> the RPC traffic. However again, that is not a requirement for being able to
> do (3), and such a protocol could be defined as a separate document (much
> like GSSAPI, SPKM and LIPKEY were defined as 3 separate documents).
>
> Cheers
>   Trond
>
>> I think what is need in the abstract is some mention of the changes that
>> I expect you will be proposing, to, as I put it, to "rehabilitate"
>> AUTH_SYS.   You cite a number of issues that have interfered with extensive
>> use of RPCSEC GSS.   If that reluctance is to be considered legitimate as
>> opposed to deplorable laziness on the part of administrators, then you/we
>> will have to convince people that this is OK and I think that effort needs
>> to mentioned somehow in the abstract.
>>
>>> > The current draft manifests a degree of confusion/uncertainty about
>>> the potential role of AUTH_SYS which needs to be resolved at some point.
>>>  In Section 4.3. it proposes a way of making use of AUTH_SYS reasonably
>>> secure by combining it with client authentication, going so far as to
>>> describe it, if I am not mistaken, as "optimal".   However, in an editor's
>>> note appended  to that same section, it dicusses the possiiblity of
>>> dispensing with TLS client authentication leaving the server with the role
>>> of passively accepting and acting upon the user identities transmitted by
>>> an unauthenticated client.
>>> >
>>> > Chuck has already requested feedback regarding working group interst
>>> in this approach with the expectation of converting this document to be a
>>> >       • I don''t really understand what you're getting at in the
>>> fourth bullet.  Since other people have also asked about this, it seems
>>> that some clarification is required.
>>> > Regardless of the strength of a privacy mechanism, it cannot
>>> contribute to security if the difficulties of deploying and using it are
>>> such that it is not in fact used.   As an example, [RFC3530] first mandated
>>> the implementation of RPCSEC GSS with privcy and integrity by NFSv4 servers
>>> > The paragraph headed "Decoupled Host and User Identities" does not
>>> make clear why this is a "significant benefit" as promised by the lead-in
>>> paragraph.
>>> >
>>> > With regard to the first senence of the first paragraph, I am not
>>> aware of any use of RPC on transports other that stream transports and
>>> datagram transports or even if any such transports exist.  Suspect that
>>> "commonly" needs to be deleted.
>>> >
>>> >       • The section on "TLS per-client certificate with AUTH_SYS"
>>> needs some additiional text that makes clear the need to authenticate the
>>> client if you are essentially trusting the client to authenticate the
>>> users.  Suggest adding the following after the current first sentence:
>>> >       • It is unclear what is to be conveyed by the statement that
>>> such deplyments are not "typical".   My understanding is that the typical
>>> NFS deployment uses AUTH_SYS in the clear :-(, making everything else, to
>>> some degree, atypical.   If  the potential deployments mentioned here do
>>> not exist, or are very rare, that shoud be clearly stated.   That need not
>>> be a reason to apologize, if there are good reasons, as I believe there
>>> might be, to create such deployments now.
>>> >       • I'm not clear how this model would work in the case of NFSv4
>>> in which there is the possibillity of significant state shared among
>>> users.  Would these connections share a clientid and/or a session?  Such
>>> issues would need to be addressed at some point.   If there needs to be
>>> further work to resolve such questions, that fact should be noted.
>>> > Given that explicit reference is made elsewhere in this document to
>>> the potential use of AUTH_SYS, I believe that there need to be some
>>> discussion of the security issues that this brings in its wake in the
>>> Security Considerations section.   The treatment  will depend on choices
>>> yet to be made but I don't see how a Security Considerations section can
>>> avoid dealing with the issues, no matter which choices are made.
>>> >
>>> > As already noted I believe that RFCs 7530 and 5661 should be
>>> reference, presumably informatively.  However, it is possible that a
>>> discussion of authentication issues (as discussed above) might need to
>>> reference these documents normatively.
>>> >
>>>
>>> --
>>> Chuck Lever
>>>
>>>
>>>
>>>

---

From: Rick Macklem <[email-masked]>
Date: Fri, 30 Nov 2018 00:34:23 +0000

First off, I'd like to say Thanks to Chuck and Trond for doing this, since I think
it will be useful. I plan on trying to implement this for FreeBSD this winter.

David Noveck wrote:
[stuff snipped]
>The current document does address  user authentication issues.  I have problems >with the way that is done, but would not object if a future version deleted that >material and dealt solely with transport security and client authentication..
I think that this would be a good way to go. That is "deal solely with transport
security and client authentication". I believe that this will result in a relatively
easy to implement update to the RPC code, so it can be deployed relatively quickly.

Btw, for this case
   TLS per-user certificate with AUTH_NONE:  Each user establishes her
      own TLS context with the server, identified by a unique
      certficate.  There is no need for any additional information at
      the RPC layer, so the RPC client can use the simplest
      authentication flavor for RPC transactions.  This configuration is
      not typical for NFS deployments, but it does enable strong
      certificate-based user authentication, which is currently not
      afforded by GSS.
I think you could implement something very close to this without defining it in
any document. For example, a server implementor could have an export option
similar to "squash-all" called something like "squash-to-certificate", which makes
the server ignore the authenticator in the RPC header and just use credentials
acquired via the certificate used for the connection.
(The RPCs would use AUTH_SYS or RPCSEC_GSS instead of AUTH_NULL, but that
 wouldn't matter, from what I can see.)

Just my opinion, not having attempted to implement this yet, rick

[rest of post left untouched...]
While I feel the working group does need to take steps to adress the fact that AUTH_SYS continues to be heavily used for NFSv4,  your document is not necessarily the right vehicle for that.   In any case, the working group needs to consider what other work might be required and how to get that work done.

On Tue, Nov 27, 2018 at 2:36 PM Trond Myklebust <[email-masked]<mailto:[email-masked]>> wrote:
Hi Dave,

I disagree with your apparent premise that this document needs to deal with user authentication. The current scope of the document is just to enable a transport level security, which authenticates the server to the client (and may optionally authenticate the client to the server) and sets up a secure channel for communication between the two.

The fact that authentication of the client to the server is optional is very much intentional in the TLS protocol. It allows for alternate methods of authentication of clients to the server through the secure channel that is created. Since the server has been authenticated to the client, it also allows the client to trust the server, for instance if it wants to transmit a username+password as part of an alternative user authentication protocol over the secure channel..

The server on the other hand has a number of options for dealing with a client:

  1.  It could allow access by unauthenticated clients and their users by offering access only to fully public parts of the namespace (i.e. those parts which offer access to the ANONYMOUS user).
  2.  It could treat authenticated clients and their (unauthenticated) users as partially or fully trusted. e.g. squash the users to a single "trusted client" account, or simply accept AUTH_SYS information from that trusted client at face value.
  3.  It could require that the users authenticate themselves. This could be done using the existing methods of setting up an RPCSEC_GSS/krb session over the trusted channel (no krbi or krbp options needed), but we could also look into setting up new authentication protocols that make use of the trusted channel.

None of the above 3 options really require us to define any new authentication methods. They can all be used with existing tools.
I'd argue that (2) might benefit from a new "trusted client" special identifier to allow users to set up ACLs specifically for dealing with this situation, but that's not a requirement.
I'd also argue that (3) might benefit from having a 'LIPKEY'-like option to allow users to authenticate using a user+password option in-band with the RPC traffic. However again, that is not a requirement for being able to do (3), and such a protocol could be defined as a separate document (much like GSSAPI, SPKM and LIPKEY were defined as 3 separate documents).

Cheers
  Trond

> I'm not sure I understand the issue here.

Let me give you an example.   As you say, we will need a discussion of Section 4.3 focusing on getting a set of deployment choices that people can adopt to facilitate interoprable operation.   Unless I am very much mistaken that discussion will be essentially about making sure we have interoprable NFSv4 (or NFS) implementations.   If the results of that discussion are written down, I don't see how you can avoid making it clear that interoperable having NFSv4 (or NFS) is the goal.

> NFSv4 depends on RPC for identifying users.

I guess it depends on it for publising the results of user authentication.   In the case of AUTH_SYS without client authentication, it is posible that this will be faux authentication.

> and why do you feel it needs to be said in this document?

What will be said depends on the results working group discussion but I think you cannot to avoid the discussion how the changes you propose will affect the security of NFSv4.   The bulk of that discussion will probably win up in another document but I don't see how we can focus on the task of improving NFSv4 security if it is not stated somewhere that this is an important goal of the effort.

> intended meaning of "Encryption by default".

I think that needs to be done somewhere although probably not in the abstract.

I think what is need in the abstract is some mention of the changes that I expect you will be proposing, to, as I put it, to "rehabilitate" AUTH_SYS.   You cite a number of issues that have interfered with extensive use of RPCSEC GSS.   If that reluctance is to be considered legitimate as opposed to deplorable laziness on the part of administrators, then you/we will have to convince people that this is OK and I think that effort needs to mentioned somehow in the abstract.

> You say that the treatment of this issue should not be limited to

I said that if RDMA is to be discussed, so should other similar sorts of encryption.
I'm not sure any really need to be.

> What other existing RPC transports should/can be discussed?

The only possibility is use of VPN's which provides an equivalent to physical network
security.  I don't see why that needs to be discussed, but if it doesn't, why should
the equivalent for rdma be discussed?

On Tue, Nov 27, 2018 at 11:38 AM Chuck Lever <[email-masked]<mailto:chuck.lever@oracle..com>> wrote:
Hi Dave, thanks for the review. I will endeavor to produce another
revision that addresses most of your review comments. Section 4.3
is obviously an area that will need an intense amount of discussion.

> On Nov 26, 2018, at 11:18 AM, David Noveck <[email-masked]<mailto:[email-masked]>> wrote:
>
> General Comments
>
> Overall Evaluation
>

--
Chuck Lever