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

["Mkrtchyan, Tigran" <[e-mail]>]

----- Original Message -----
> From: "Rick Macklem" <[e-mail]>
> To: "Chuck Lever" <[e-mail]>
> Cc: "NFSv4" <[e-mail]>
> Sent: Wednesday, January 22, 2020 12:09:20 AM
> Subject: Re: [nfsv4] questions w.r.t RPC-over-TLS draft

> Chuck Lever wrote:
>>> 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.
> Yep. Sounds fine to me.
> 
>>> 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?
> Yep, as above, sounds fine to me.
> 
>>>> 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?
> Well, whatever the correct terminology, the server needs to know when to switch
> from
> receiving Sun RPC messages (with record marks in front of them for TCP) to
> receiving
> TLS records for the handshake.
> 
> If the NULL RPC with AUTH_TLS doesn't do that, then something else must be added
> that does do it (and it needs to be in a Sun RPC message or start with 4 bytes
> that
> are obviously not a Sun RPC over TCP record mark).
> It sounds like Tigran assumes the NULL RPC with AUTH_TLS does this switchover
> and
> I am fine with that too (and have coded it that way).
> 
> Admittedly I am not sure if STARTTLS is mentioned anywhere in RFC-8446, so it
> might not
> be the right term for whatever says "a TLS record to start the handshake is
> coming
> immediately after this".
> 
>>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.
> Yea. I'm not sure if this is feasible either (at least for TCP), but NULL RPCs
> seem
> harmless, so I think the current wording is ok, at least for reliable ordered
> transports
> like TCP.


I am pretty sure, that once TLS session is established, you can't sent any other
requests outside of it.

Tigran.

> 
>>> (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.
> Agreed. However it comes back to whether or not is to me immediately followed by
> the first TLS handshake record.
> Yes -->can only be done once, just before the TLS handshake and, as such, other
>            NULL RPCs with AUTH_NULL before it might be useful.
> No-->means something else needs to be defined so that the server knows when to
>          switch from "receiving Sun RPC messages" to "receiving TLS handshake records".
> I think "yes" is appropriate and what Tigan has already assumed was the case.
> 
> As already noted, I think the above wording (which does allow other NULL RPCs)
> is fine.
> 
>>>>> 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."
> Yes, but as noted above, something must go on the wire to indicate this.
> I think the NULL RPC with AUTH_TLS is fine for doing this, but if not, something
> else
> needs to be defined to do so.
> 
>>>> 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.
> Yep.
> 
> rick
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4