Review of draft-ietf-nfsv4-rpc-tls04

*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.

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