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

[Rick Macklem <[e-mail]>]

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.

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