Re: [nfsv4] Agenda items for virtual interim

[Chuck Lever III <[e-mail]>]

> On Oct 17, 2021, at 8:41 PM, Rick Macklem <[e-mail]> wrote:
> 
> Chuck Lever III wrote:
> [lots of stuff snipped]
>> So expose the security mechanisms but not the transport
>> types here. The pseudoflavors should work just like GSS
>> in Appendix B of RFC 5531. The pseudoflavor numbers here
>> are just examples.
>> 
>>       AUTH_NONE               0       /* plain old NONE */
>>       AUTH_SYS                1       /* plain old SYS */
>> 
>>       AUTH_NONE_PEERAUTH      400001  /* peer authentication */
>>       AUTH_NONE_ENC           400002  /* encryption */
>>       AUTH_NONE_PA_ENC        400003  /* authentication and encryption */
>> 
>>       AUTH_SYS_PEERAUTH       410001  /* peer authentication */
>>       AUTH_SYS_ENC            410002  /* encryption */
>>       AUTH_SYS_PA_ENC         410003  /* authentication and encryption */
> I think this sounds reasonable. There is another case that might be worth
> considering. I am thinking of a rather specific case where an X.509
> certificate provided by a client is pinned to a fixed IP address/DNS name.
> --> The server expects that the X.509 certificate will have a DNS or IP component
>       in subjectAltName that matches the IP address used by the client to connect
>       to the server. (There is an RFC that discusses this for the case where a client is
>       checking a server's certificate.)
> 
> Maybe a generic term for it could be something like:
>          AUTH_xxx_PEERAUTH_FIXED_IPADDR

I'm not understanding why a server would need to communicate
this to a client during security negotiation. Wouldn't it
just be a matter of setting up this policy on the server?
Does a client choose a special certificate to use in this
case?

But also, I think we have some leeway here to introduce a
narrow basic set of pseudoflavors now and then expand them
as needs arise, via additional documents.


> Btw, there are a couple of things that I don't recall being in the draft I read (an
> earlier one). If they are there now, please just ignore the following...
> 
> machine credential - It seems that a TLS handshake and/or verification of a
>    client's X.509 peer certificate establishes a "client machine credential".
>    However, there is no "machine principal" that can be used by the client
>    for RPCs that must be done with a "machine principal" (such as EXCHANGE_ID...)
>    --> One possibility I can think of is adding a new authentication flavor called
>          something like "AUTH_MACHINE_PRINCIPAL" that would indicate
>          "use the machine credential established via TLS handshake and/or X.509
>            certificate verification" as the credentials for this RPC.

I had forgotten about that!

Again, not sure there needs to be a unique p-flavor, but
I agree there needs to be some documentation about
promoting a client's peer credential for authenticating
lease management operations.


> Then there is the case of the NFSv4.0 callback TCP connection.
> Should the server attempt to use RPC-with-TLS if the client-->server TCP connection is doing so?
> And, should the server stop doing callbacks if the RPC-with-TLS probe or handshake fails?

IMO those are (reasonable) security policy choices.


> RFC 7530 Sec. 3.3.3 addresses the use of the credentials in the callback RPCs, but I don't
> think it answers the above questions.
> If an NFSv4.0 server were to do a successful TLS handshake and/or provide an appropriate
> X.509 certificate to the client, it could use the AUTH_MACHINE_PRINCIPAL described above.

Or the client and server could be required to use the same
certificate pair that was used to establish the forward
channel? I recall there is a similar restriction on which
GSS service principals are used for callback operation.

Establishing a TLS-protected callback channel would
necessitate that the client have a certificate/PSK. The
server-only encryption mode would not work at all.


> --> Although you could argue this is a server implementation choice, interoperability will be
>      impacted negatively if there is no guidance in this (or a companion) document, I think?

--
Chuck Lever