Re: Review of draft-ietf-nfsv4-rpc-tls04

Hi Dave,


> On Nov 27, 2019, at 9:52 AM, David Noveck <[email protected]> wrote:
> 
> General Comments
> 
> Importance of this Work
> 
> This work addresses the two biggest problems in NFSv4 security and could serve as a basis to allow secure  use of NFSv4 on the internet, which was one of the original goals of NFSv4.  My thanks to Chuck and Trond for taking this on and bringing the work to this point.
> 
> State of the Document.
> 
> This document is in good shape.   The issues I've found concern how the material is presented rather than indicating problems in the approach taken or the specific choices made.   
> 
> Per-Section Comments
> 
> 1.  Introduction
> 
> I feel that some reorganization of the second paragraph and the associated bullets would be helpful.   I think you need to decide whether the focus is to be on the diffculties of deploying RPCSEC_GSS or the difficulties of deploying RPCSEC_GSS with privacy, which, to me are more clear-cut and are really the major thing that this proposal addresses.   Note that, of the four bullets below this paragraph, only two are relevant to privacy while the paragraph after the bullets only makes sense if it speaking about RPCSEC_GSS with privacy.   It is not the case that RPCSEC_GSS is not used at all, altough it is not used as much as originally hoped.
> 
> I think you might consider a replacement along the following lines:
> The Remote Procedure Call version 2 protocol has been a Proposed Standard for three decades (see [RFC5531] and its antecedants). Eisler et al. first introduced an in-transit encryption mechanism for RPC with RPCSEC GSS over twenty years ago [RFC2203].  However, experience has shown that RPCSEC GSS with in-transit encryption can be difficult to deploy and use:
> Parts of each RPC header remain in clear-text, and can constitute a significant security exposure.
> On-host cryptographic manipulation of data payloads can exact a significant CPU and memory bandwidth cost on RPC peers. Offloadng does not appear to be practical using GSS privacy since each message is encrypted using its own key based on the issuing RPC user. As a result, the performance penalty is so significant that, for many important RPC-based protocols, RPCSEC_GSS wiith privacy is hardly ever used.
> However strong a privacy service is, it cannot provide any security if the challenges of using it result in it not being used at all.
> In addition, the use of AUTH_SYS remains common despite the negative effect on security that server acceptnce of uids and gids from unauthenticated clients brings with it.   This is in part because:
> Per-client deployment and administrative costs are not scalable and, in many environments may be considered excessive. Keying material must be provided for each RPC client user, including transient users.
> Host identity management and user identity management must be carried out in the same security realm.  In certain environments, different authorities might be responsible for provisioning client systems versus provisioning new users.
> Through the use of TLS-aided client authentication these difficulties can be addressed without the security compromises that result from the use of AUTH_SYS, without client authentication and in the cleaar.
> At the the start of the third (non-bulleted) paragraph, suggest replacing "an alternative approach" by "The Alternative approach proposed here".
> With regard to your benefits paragraphs I feel some reorganization could be helpful to render the presentation more impactful:
> While "Encryption by default" is strong, it would better if it was immediately followed up by the second major benefit "Encryption Offload".
> I feel it is a mistake to mention AUTH_SYS where you do, before telling people you have rendered it more safe.  So "Decoupled User and Host Identities" should appear after "Securing AUTH_SYS" and be revised in light of the fact that AUTH_SYS has been rendered OK (e.g. changing "still using" to "safely using").
> "Protection of Existing Protocols" should not be listed among these benefits since the first sentence of the paragraph is true of RPCSEC_GSS as well.   I think you can add some of this material to a revised penultimate paragraph as I suggest below.
> 
> With regard to the penultimate paragraph of this section, I'm suggesting a revision to 
> Incorporate material  from "Protection of Existing Protocols" 
> Eliminate the reference to RFC7435 (entitled "Opportunistic Security: Some Protection Most of the Time").  
> Although both this document and "opportunistic TLS" use the word "opportunistic",  they are effectively homonyms and 
> referencing RFC7435 adds confusion. 
> Would like you to consider the following replacement paragraphs:
> This document specifies the use of RPC on a TLS-protected transport in a fashion that is transparent to upper layer protocols based on RPC. This transport layer encryption can protect all minor versions of  NFS version 4 [RFC7530][RFC5661][RFC7862] as well legacy NFS versions such as NFS version 3 [RFC1813], NFS side-band protocols such as the MNT protocol [RFC1813] and other protocols using RPC.
> We specify policies that enable RPC-on-TLS to be deployed opportunistically in environments with RPC implementations that do not support TLS.  Specifications for RPC-based upper layer protocols are free to adopt stricter policies to guarantee that TLS with encryption or TLS with host authentication and encryption is used for every connection or that  connections for which these facilities are not available are restricted as to the facilities they are allowed to use .
> 4.2.1.  Using TLS with RPCSEC GSS
> I don't think the word "client" in the second paragraph is correct.  IIUC, it is the requesting user rather than the client itself that is authenticated. 
> 5.1.3.  Operation on Other Transports
> In the third sntence of the first paragraph, suggest:
> replacing "provisions" by "other provisions"
> replacing "could" by "would need to be"
> In the first sentence of the second pragraph, suggest replacing "accommodared" by "addressed".
> In the second sentence ofthe second paragraph, suggest replacing "might" by "would"
> 7.2.  Multiple User Identity Realms
> I don't see how establishing an independent TLS session for each user identity domain would prevent privileged users in each security realm from monitoring RPC traffic emitted on behalf of users in other security realms on the same peer.  What am I missing?   Are there some unstated assumptions about what privileged users might be allowed to do?
> 7.3.  Security Considerations for AUTH_SYS on TLS
> With regard to the penultimate paragraph, I don't see how this recommendation, desirable as it is, can provide any assurance that 
> clients are "acting responsibly"  Suggest the following as a possible replacement:
> In light of the above, it is RECOMMENDED that when AUTH_SYS is used, RPC clients present authentication material to  RPC servers and that servers use this material to determine if the client is a known one, so that they can make a determination whther the UIDs and GIDs in AUTH_SYS requests can be accepted as-is, subject to some degree some filtering or montitoring, or whther all AUTH_SYS requests on this connection are to be rejected. 
> With regard to the last sentence of the last paragraph, I think it should be noted that this issue could be addressed by not having 
> names for these users and using numeric id's instead.
> 

Thanks for the thorough comments. I will review these carefully over the holiday weekend and respond next week.

Meanwhile, the Last Call for this document expires December 13... everyone else has plenty of opportunity to read and comment on rpc-tls! Happy Thanksgiving [US].


--
Chuck Lever

_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4