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

[Rick Macklem <[e-mail]>]

I 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.)
>
>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??
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?

Thanks for any clarification of this, rick


_______________________________________________
nfsv4 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/nfsv4