> On May 27, 2020, at 11:57 PM, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote:
>
>
>
>> On May 27, 2020, at 11:02 PM, worley@xxxxxxxxxxx wrote:
>>
>> Chuck Lever <chuck.lever@xxxxxxxxxx> 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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
