Re: [nfsv4] questions w.r.t RPC-over-TLS draft

[Chuck Lever <[e-mail]>]

> On Jan 20, 2020, at 6:08 PM, Rick Macklem <[e-mail]> wrote:
> 
> Chuck Lever wrote:
>> May I add the FreeBSD implementation of RPC/TLS to Section 6? Did I
>> already ask you this and simply forgot to add it?
> Definitely a "work in progress" at this time, so you can decide if it should be
> mentioned. (I am making pretty good progress, but the FreeBSD kernel TLS
> only works for send at this time, unless you have hardware that does TOE.
> It may be a few months before the kernel TLS can do receive, so that it
> actually works.)
> 
>>> On Jan 19, 2020, at 7:30 PM, Rick Macklem <[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>> I've started implementing RPC-over-TLS for NFS and have run into a couple
>>> of questions related to the draft (#4, I haven't downloaded #5).
>>> 
>>> 1 - Given this description...
>>>  The flavor value of the verifier received in the reply message from
>>>  the server MUST be AUTH_NONE.  The bytes of the verifier's string
>>>  encode the fixed ASCII characters "STARTTLS".
>>> 
>>> Is the verifier coded as:
>>> A:   verifier length: 8
>>>     bytes STARTTLS
>>> OR
>>> B:   verifier length: 12
>>>     string length: 8
>>>     bytes STARTTLS
>>> 
>>> ie. Is there supposed to be a string length as coded by xdr_string() in the
>>> verifier? (It is the words "verifier string" the above that I find confusing.)
>> 
>> I agree, "string" is confusing. It should rather say "fixed-length
>> opaque".
> This might still hint at an extra length field.

A "fixed-length opaque" is explicitly defined in Section 3.9 of RFC 1832.
No length field.


> How about something like "The body of the verifier consists of the 8 ASCII bytes STARTTLS"?
> (Btw, this is how I had coded it and then, when I read "verifier string" I wasn't sure.)

OK, here's what I've changed it to:

>    The flavor value of the verifier received in the reply message 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.


Thoughts?


>> Section 7.2 of RFC 1831 has this:
>> 
>> enum auth_flavor {
>>     AUTH_NONE = 0,
>>     AUTH_SYS = 1,
>>    AUTH_SHORT = 2
>>     /* and more to be defined */
>> 
>> };
>> 
>> struct opaque_auth {
>>     auth_flavor flavor;
>>     opaque body<400>;
>> 
>> };
>> 
>> The flavor field contains AUTH_NONE (0), the opaque's length field
>> contains 8, and the opaque's data contains the ASCII characters
>> "STARTTLS".
>> 
>> 
>>> Then there is this sentence...
>>>  AUTH_ERROR.  If the client sends a STARTTLS after it has sent other
>>>  non-encrypted RPC traffic or after a TLS session has already been
>>>  negotiated, the server MUST silently discard it.
>>> 
>>> Does "other non-encrypted RPC traffic" refer specifically to traffic between
>>> the NULL RPC with AUTH_TLS and the STARTTLS or does it refer to non-NULL RPC traffic >or??
>> 
>> The client can't start a TLS session on a connection after it
>> has sent non-NULL RPC traffic.
> Cool. Maybe it needs to say that the NULL RPC with authentication flavor of AUTH_TLS
> constitutes a STARTTLS operation.

It's meant only to indicate that the sender supports RPC-over-TLS.
Is that really the same as a STARTTLS operation?

The replacement text reads:

>    If an RPC client attempts to use AUTH_TLS for anything other than the
>    NULL RPC procedure, the RPC server MUST respond with a reject_stat of
>    AUTH_ERROR.  If the client initiates a TLS session after it has sent
>    unencrypted non-NULL RPC traffic the server MUST silently discard it.



> That still doesn't really clarify if a NULL RPC with authentication flavor of AUTH_NULL
> is also allowed before the NULL RPC with authentication flavor of AUTH_TLS.

It seems to me the new text clearly allows an unencrypted NULL RPC at any
time. I'm not sure that's even feasible, but it's an implementer's choice.


> (FreeBSD currently uses NULL RPCs with AUTH_NULL as a "ping" to figure out if
> the server is up, however it uses a separate TCP connection to do this, so it shouldn't
> matter if it allowed on the same connection.)

The NULL with AUTH_TLS should be able to act as both announcing support
for RPC-over-TLS and a ping for a particular RPC Program.


>>> I am also confused about what "sends a STARTTLS" actually means?
>>> (I'll admit I know nothing about TLS and can only find STARTTLS mentioned w.r.t.
>>> an SMTP email command.)
>>> 
>>> Does this mean that the 8 bytes STARTTLS goes on the wire immediately after
>>> a NULL RPC with AUTH_TLS or does it mean the 8 bytes STARTTLS goes in a
>>> TCP RPC message (an 8byte message as indicated by the RPC over TCP record
>>> mark, which would normally be too small) or does "sends a STARTTLS" just saying
>>> that the TLS handshake should come immediately after the NULL RPC with AUTH_TLS?
>> 
>> 
>> "sends a STARTTLS" means "initiates a TLS session."
> That clarifies it. It might be even clearer if it said "initiates a TLS handshake"?
> Alternately, defining the NULL RPC with authentication flavor AUTH_TLS as a STARTTLS
> command would do so as well.
> 
> One slight problem here is that the above would seem to be TCP specific, since it assumes
> ordering, but is not in the TCP section. I know nothing about the UDP case and have no intention of implementing it, but it does seem that is TCP specific? (Would the UDP variant be non-NULL RPC traffic from the same client
> IP address or do you just not worry about this for UDP?)

Agreed, that language should probably be moved to Section 5.1.1.

--
Chuck Lever