Re: [Last-Call] [nfsv4] Genart last call review of draft-ietf-nfsv4-rpc-tls-07

[Chuck Lever <[e-mail]>]

> On May 27, 2020, at 11:57 PM, Chuck Lever <[e-mail]> wrote:
> 
> 
> 
>> On May 27, 2020, at 11:02 PM, [e-mail] wrote:
>> 
>> Chuck Lever <[e-mail]> writes:
>>>> Somewhere in this section you need to specify the semi-obvious:
>>>> 
>>>> [...]
>>> 
>>> I can add something like this in Section 4.1, but note that Sections
>>> 5.1.1 and 5.1.2 already explain the relationships between TCP/UDP
>>> and TLS/DTLS, respectively.
>> 
>> Hmmm, I want to answer "yes and no".  I think those passages were
>> written with the presupposition that those relationships were already
>> known and specified, and the text talks *about* that relationship.
>> E.g., 5.1.1 qualifies the sentence with "Typically", and neither section
>> uses normative language.
>> 
>> The point is that if you upgrade, if you start with TCP, you MUST
>> upgrade to TLS, and if you start with UDP, you MUST upgrade to DTLS.
>> Whereas it is conceivable that one could start with UDP to port 111,
>> discover rpc-tls support and then do a TLS connection to TCP port 111
>> ("the same port") to continue.  (After all, every NFS server listens on
>> 111 both with UDP and TCP, right?)  And you have to state that
>> explicitly as a requirement.
> 
> NFSv4 servers don't have to provide an rpcbind service on port 111 any
> more... but I get your point.
> 
> The proposed replacement text I posted earlier today explains how it is
> supposed to work but does not use normative language. It needs to take
> another step and /require/ that a client uses the appropriate protection
> mechanism for the transport it wants to use.

Proposing the following text to replace all of Section 4.1. It better
describes the initiation of an AUTH_TLS probe, and provides additional
normative requirements to help bridge the gap cleanly between the probe
and the establishment of a TLS session.


4.1.  Discovering Server-side TLS Support

   The mechanism described in the current document interoperates fully
   with RPC implementations that do not support RPC-on-TLS.  Policy
   settings on the RPC-on-TLS-enabled peer determine whether RPC
   operation continues without the use of TLS or RPC operation is not
   permitted.

   To achieve this interoperability, we introduce a new RPC
   authentication flavor called AUTH_TLS.  The AUTH_TLS authentication
   flavor signals that the client wants to initiate TLS negotiation if
   the server supports it.  Except for the modifications described in
   this section, the RPC protocol is unaware of security encapsulation
   at the transport layer.  The value of AUTH_TLS is defined in
   Section 8.1.

   An RPC client begins its communication with an RPC server by
   selecting a transport and destination port.  The choice of transport
   and port is typically based on the RPC program that is to be used.
   The RPC client might query the RPC server's rpcbind service to make
   this selection.  In all cases, an RPC server MUST listen on the same
   ports for (D)TLS-protected RPC programs as the ports used when (D)TLS
   is not available.

   To protect RPC traffic to a TCP port, the RPC client opens a TCP
   connection to that port and sends a NULL RPC procedure with an
   auth_flavor of AUTH_TLS on that connection.  To protect RPC traffic
   to a UDP port, the RPC client sends a UDP datagram to that port
   containing a NULL RPC procedure with an auth_flavor of AUTH_TLS.  The
   mechanism described in the current document does not support RPC
   transports other than TCP and UDP.

   The length of the opaque data constituting the credential sent in the
   RPC Call message MUST be zero.  The verifier accompanying the
   credential MUST be an AUTH_NONE verifier of length zero.

   The flavor value of the verifier in the RPC Reply message received
   from the server MUST be AUTH_NONE.  The length of the verifier's body
   field is eight.  The bytes of the verifier's body field encode the
   ASCII characters "STARTTLS" as a fixed-length opaque.

   If the RPC server replies with a reply_stat of MSG_ACCEPTED and an
   AUTH_NONE verifier containing the "STARTTLS" token, the client SHOULD
   proceed with TLS session establishment, even if the Reply's
   accept_stat is not SUCCESS.  If the AUTH_TLS probe was done via TCP,
   the RPC client MUST send the "ClientHello" message on the same
   connection.  If the AUTH_TLS probe was done via UDP, the RPC client
   MUST send the "ClientHello" message to the same UDP destination port.

   Conversely, if the Reply's reply_stat is not MSG_ACCEPTED, if its
   verifier flavor is not AUTH_NONE, or if its verifier does not contain
   the "STARTTLS" token, the RPC client MUST NOT send a "ClientHello"
   message.  RPC operation can continue, however it will be without any
   confidentiality, integrity or authentication protection from (D)TLS.

   If, after a successful RPC AUTH_TLS probe, the subsequent (D)TLS
   handshake should fail for any reason, the RPC client reports this
   failure to the upper-layer application the same way it reports an
   AUTH_ERROR rejection from the RPC server.

   If an RPC client uses the AUTH_TLS authentication flavor on any
   procedure other than the NULL procedure, or an RPC client sends an
   RPC AUTH_TLS probe within an existing (D)TLS session, the RPC server
   MUST reject that RPC Call by setting the reply_stat field to
   MSG_DENIED, the reject_stat field to AUTH_ERROR, and the auth_stat
   field to AUTH_BADCRED.

   Once the TLS session handshake is complete, the RPC client and server
   have established a secure channel for communicating.  A successful
   AUTH_TLS probe on one particular port/transport tuple never implies
   RPC-on-TLS is available on that same server using a different port/
   transport tuple.

--
Chuck Lever