Re: [nfsv4] Roman Danyliw's Discuss on draft-ietf-nfsv4-rpc-tls-08: (with DISCUSS and COMMENT)

[Chuck Lever <[e-mail]>]

Hi Roman-

This reply addresses COMMENTs regarding Section 7.

> On Jul 6, 2020, at 11:24 PM, Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> ** Section 7.3.  Per “… it is RECOMMENDED that when AUTH_SYS is used, every RPC
> client should present authentication materials to RPC servers …”, is this the
> same thing as saying that when AUTH_SYS is used a mutual authentication
> TLS-scheme is RECOMMENDED?  I concur with this approach.  I would just
> recommended saying that explicitly.

Possible replacement:

OLD:

   In light of the above, it is RECOMMENDED that when AUTH_SYS is used,
   every RPC client should present host authentication material to RPC
   servers to prove that the client is a known one.  The server can then
   determine whether the UIDs and GIDs in AUTH_SYS requests from that
   client can be accepted.

NEW:

   In light of the above, when AUTH_SYS is used, the use of a TLS mutual
   authentication mechanism is RECOMMENDED to prove that the RPC client
   is known to the RPC server.  The server can then determine whether
   the UIDs and GIDs in AUTH_SYS requests from that client can be
   accepted.


> ** Section 7.4.  Is there a reason not to use normative language in this
> section?  Specifically, RECOMMENDED for the first bullet and SHOULD for the
> second.

The reason not to use normative language is merely that we believe there are
no interoperability ramifications for choosing not to follow the suggestions.
Combined with the changes made to address your DISCUSS:

OLD:

   RPC-over-TLS implementations and deployments are strongly encouraged
   to adhere to the following policies to achieve the strongest possible
   security with RPC-over-TLS.

   *  When using AUTH_NULL or AUTH_SYS, both peers are required to have
      DNS TLSA records, keys with which to perform mutual peer
      authentication using one of the methods described in Section 5.2,
      and a security policy that requires mutual peer authentication and
      rejection of a connection when host authentication fails.

   *  RPCSEC GSS provides integrity and privacy services which are
      redundant when TLS is in use.  These services should be disabled
      in that case.

NEW:

   RPC-over-TLS implementations and deployments are strongly encouraged
   to adhere to the following policies to achieve the strongest possible
   security with RPC-over-TLS.

   *  When using AUTH_NULL or AUTH_SYS, both peers are RECOMMENDED to
      have DNS TLSA records, keys with which to perform mutual peer
      authentication using one of the methods described in Section 5.2,
      and a security policy that requires mutual peer authentication and
      rejection of a connection when host authentication fails.

   *  RPCSEC GSS provides integrity and privacy services which are
      redundant when TLS is in use.  These services SHOULD be disabled
      in that case.


--
Chuck Lever