Re: [nfsv4] New Version Notification for draft-dnoveck-nfsv4-security-08.txt

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

> On Mar 22, 2024, at 8:17 PM, Rick Macklem <[e-mail]> wrote:
> 
> On Tue, Mar 19, 2024 at 7:38 AM Chuck Lever III <[e-mail]> wrote:
>> 
>> 
>> 
>>> On Mar 19, 2024, at 10:27 AM, Rick Macklem <[e-mail]> wrote:
>>> 
>>> There are a couple of issues that this RFC could discuss/define related to this.
>>> - Chuck and I diverged w.r.t. how to implement this.
>>> a) I preferred putting the user name in the X.509 certificate presented during
>>>      TLS handshake.
>>> b) Chuck preferred a database on the NFSv4 server, keyed on certificate
>>>     issuer/serial#.
>>> (Chuck may have changed his mind, since his post was related to
>>> implementation a).)
>>> This can be considered just an implementation detail chosen by NFS server
>>> implementors, but it might be nice to have some standardization (for
>>> example, the
>>> exact format of the field in the X.509 certificate for a)).
>> 
>> IMO this falls in the category of server implementation detail.
>> I don't recall saying a serial# database should be required.
>> 
>> But, not something that goes on the wire, certainly, and
>> therefore outside the purview of the IETF.
> Wel, I said "maybe" and I'm still a "maybe".
> The working group has been very good at underspecifying things
> in the past and they still cause problems.
> For example, take the case of the domain component of Owner and
> Owner_group strings. What are they?
> I honestly do not know.
> I believe David does discuss this in his security draft.
> 
> Suppose Linux implements the "imbed a username in the X.509 certificate
> for TLS identity squashing", but at some point it is decided that Linux should
> not use a FreeBSD OID and chooses to use a different OID.
> (I used a FreeBSD OID, since I did not know how to acquire anything else and
> used the otherName componenent of SubjectAltName at the suggestion of
> Ben Kaduk.)
> Then you end up with a similar but non-identical way of doing it and sysadmins
> have to deal with potentially N different ways to create X.509 certs for clients
> to use with different servers. (These X.509 certs do go on the wire.)
> 
> Now, if by "server implementation detail" you were simply referring to choosing
> a) versus b), then I would agree.

That's all I meant: a) versus b) is an implementation detail.

If there's some question about the form of the SAN string
the server will use for squashing the RPC user identity,
then I agree, that will need standards action.


> I'll admit I have not explored standardization of the way to insert a
> username in
> a X.509 certificate.
> 
> However, I agree that resolving what to do with SP4_MACH_CRED is more
> important.
> I'd like to see either:
> - SP4_MACH_CRED extended to support any appropriate RPC layer
>  machine credential and any appropriate integrity/privacy provision
>  instead of the RPCSEC_GSS specific requirement in RFC8881.
> OR
> - A new SP4_MACH_CRED like variant for the above as an extension
>  to NFSv4.2.
> Then, along with the above, a specification for doing this for RPC-over-TLS.
> 
> rick
>> 
>> --
>> Chuck Lever
>> 
>> 

--
Chuck Lever