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

[Rick Macklem <[e-mail]>]

Further to what I mentioned w.r.t. SP4_MACH_CRED,
here is a possible cleaner way to deal with it?

- Define a new SP4_MACH_CRED_RPC (or whatever you want to call it) for NFSv4.2
  that depends on the RPC layer to indicate that an RPC uses machine credentials
  and for the RPC layer to provide integrity/privacy protection.
  - It would use state_protect_ops4 in the same way as SP4_MACH_CRED, given
    a machine credential RPC as indicated by the RPC layer.

For RPC-over-TLS, this could be implemented by...
- A non-NULL RPC request specifying AUTH_TLS in the RPC request header.
  - If the client presented a verifiable X.509 certificate during TLS handshake
    for the TLS session the RPC is in, this would be an RPC with
machine credential.
  - If no verifiable X.509 certificate was presented during TLS handshake or
    the RPC is not in a TLS session, it would fail with AUTH_WEAK.

Then there is TLS identity squashing. (Chuck just posted, reminding me
of this stuff):

This refers to using the X.509 certificate presented during TLS handshake
to define a single user that is performing RPCs on the NFSv4 server using
the TLS session. (My use case was a personal device such as a laptop,
allowing the NFSv4 server to ignore the AUTH_SYS credentials in the
RPC's request header.) Chuck came up with the name. He's much better at
naming things than I am.
- In other words, all RPCs (or at least all using AUTH_SYS) would be done on
  the NFSv4 server as this user.

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

A more important consideration would be whether to squash all RPCs on only
RPCs with AUTH_SYS credentials in the RPC request header.

I have currently implemented a) and only AUTH_SYS.
I did only AUTH_SYS due to SP4_MACH_CRED requiring RPCSEC_GSS
credentials. If I replaced them with the "user" credential, SP4_MACH_CRED would
fail. If there was something like SP4_MACH_CRED_RPC, then this would be less of
an issue.

Since no one is using TLS identity squashing on FreeBSD at this time, I could
easily change the implementation. Over time that becomes more difficult.

These are security related things that could use specification/clarification and
make RPC-over-TLS more useful, I think?

rick


On Sun, Mar 3, 2024 at 6:53 AM David Noveck <[e-mail]> wrote:
>
> Got this in by the deadline.  Will discuss at IETF119.
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Sun, Mar 3, 2024 at 9:50 AM
> Subject: New Version Notification for draft-dnoveck-nfsv4-security-08.txt
> To: David Noveck <[e-mail]>
>
>
> A new version of Internet-Draft draft-dnoveck-nfsv4-security-08.txt has been
> successfully submitted by David Noveck and posted to the
> IETF repository.
>
> Name:     draft-dnoveck-nfsv4-security
> Revision: 08
> Title:    Security for the NFSv4 Protocols
> Date:     2024-03-03
> Group:    Individual Submission
> Pages:    113
> URL:      https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-security-08.txt
> Status:   https://datatracker.ietf.org/doc/draft-dnoveck-nfsv4-security/
> HTML:     https://www.ietf.org/archive/id/draft-dnoveck-nfsv4-security-08.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-dnoveck-nfsv4-security
> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-dnoveck-nfsv4-security-08
>
> Abstract:
>
>    This document describes the core security features of the NFSv4
>    family of protocols, applying to all minor versions.  The discussion
>    includes the use of security features provided by RPC on a per-
>    connection basis.  Important aspects of the authorization model,
>    related to the ACL feature, will be specified in a separate document.
>
>    The current version of the document is intended, in large part, to
>    result in working group discussion regarding existing NFSv4 security
>    issues and to provide a framework for addressing these issues and
>    obtaining working group consensus regarding necessary changes.
>
>    When the resulting documents (i.e. this document and one derived from
>    the separate ACL specification) are eventually published as RFCs,
>    they will, by updating these documents, supersede the description of
>    security appearing in existing minor version specification documents
>    such as RFC 7530 and RFC 8881,
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4