Re: [nfsv4] Agenda items for virtual interim

[Rick Macklem <[e-mail]>]

Chuck Lever III wrote:
>> 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?
No. To be honest, I do not see a reason for a client to not present a certificate to
the server during TLS handshake, if it has one.

I think the only decision the client will make is whether or not to do TLS
at all. (It might choose not to for performance reasons.)

If more pseudo-flavors are useful, I think it would be to tell the client that
security negotiation is not going to work unless the client can do X,
which would allow the client to log why security negotiation cannot
be completed (if it cannot do X). (Some security types prefer "security
via obscurity", but that can make it difficult for sysadmins to determine
why a failure is occurring.)

I would be fine with just a pseudo-flavor for TLS or similar is required,
since I think that is the only case where the client might optionally choose
to not do it.

>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.
Of course, although it can take a long time for a document to get
published, plus implementation get deployed.

>> 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.
Yes, I'm fine with anything that works. Maybe just saying that,
when done with TLS, the RPC credential should be ignored for these operations
and "same principal" should be assumed?

>> 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.
Yes, I think that "if TLS with certificates is required, using the same certificates makes sense".

>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.
Yes, that is one reason why requiring this may not be appropriate.
Another might be that an NFS server may not know how to do the TLS-probe and client
end of TLS handshake, due to lack of implementation.

The question really comes down to "is TLS security on the callback TCP connection needed?"
or is it better to just advise against it and allow extant rules from RFC7530 Sec. 3.3.3 to be
applied?

rick

> --> 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