Subject: [nfsv4] Fwd: New Version Notification for draft-cel-nfsv4-rpc-tls-pseudoflavors-01.txt

From: Chuck Lever III <[email-masked]>
Date: Wed, 15 Dec 2021 16:51:08 +0000

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-cel-nfsv4-rpc-tls-pseudoflavors-01.txt
> Date: December 15, 2021 at 11:43:23 AM EST
> To: "Charles Lever" <[email-masked]>, "Chuck Lever" <[email-masked]>
> 
> 
> A new version of I-D, draft-cel-nfsv4-rpc-tls-pseudoflavors-01.txt
> has been successfully submitted by Chuck Lever and posted to the
> IETF repository.
> 
> Name:		draft-cel-nfsv4-rpc-tls-pseudoflavors
> Revision:	01
> Title:		Pseudo-flavors for Remote Procedure Calls with Transport Layer Security
> Document date:	2021-12-15
> Group:		Individual Submission
> Pages:		15
> URL:            https://www.ietf.org/archive/id/draft-cel-nfsv4-rpc-tls-pseudoflavors-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpc-tls-pseudoflavors/
> Html:           https://www.ietf.org/archive/id/draft-cel-nfsv4-rpc-tls-pseudoflavors-01.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-rpc-tls-pseudoflavors
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-cel-nfsv4-rpc-tls-pseudoflavors-01
> 
> Abstract:
>   Recent innovations in Remote Procedure Call (RPC) transport layer
>   security enable broad deployment of encryption and mutual peer
>   authentication when exchanging RPC messages.  These security
>   mechanisms can protect peers who continue to use the AUTH_SYS RPC
>   auth flavor, which is not cryptographically secure, on open networks.
>   This document introduces RPC auth pseudo-flavors that an RPC service
>   can use to indicate transport layer security requirements for
>   accessing that service, and a mechanism the service can use to
>   enforce those requirements.

I submitted a fresh revision of this document that I hope addresses
the concerns voiced by Rick Macklem and Dave Noveck. In particular:

- The document now defines only pure pseudo-flavors that the RPC
  layer is not aware of.
- The document suggests NFSv3 layer status codes for security
  policy violations
- The language is kept non-Normative wherever possible
- The document proposes enforcement of security policy for
  EXCHANGE_ID

I'm sure I've missed some details. Please review and comment.

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Thu, 16 Dec 2021 01:28:10 +0000

Mostly looks fine to me.
However, I am confused by the following para,
   The RPC-with-TLS specification requires the use of peer
   authentication and TLS session encryption, so the presence of TLS
   under an RPC transport is enough to secure pseudo-flavors that
   require both mutual peer authentication and encryption.

I thought RPC-with-TLS allowed a client to optionally do a TLS
handshake without providing a X.509 certificate to the server.
If this statement is correct, then I do not think the above para.
can say "requires the use of peer authentication". (Yes, the server
always provides a certificate to the client, but that is not "mutual
peer authentication".)

Could the above para. be changed to something like:
   The RPC-with-TLS specification requires the use of TLS session
   encryption, so the presence of TLS under an RPC transport is
   enough to secure pseudo-flavors that require encryption.
   The RPC-with-TLS specification also allows the server to
   require that the client provide a certificate during handshake.
   When a client certificate is required during TLS handshake,
   the presence of TLS under an RPC transport is enough
   to secure pseudo-flavors that require both mutual peer
   authentication and encryption.

 rick

________________________________________
From: nfsv4 <[email-masked]> on behalf of Chuck Lever III <[email-masked]>
Sent: Wednesday, December 15, 2021 11:51 AM
To: NFSv4
Subject: [nfsv4] Fwd: New Version Notification for draft-cel-nfsv4-rpc-tls-pseudoflavors-01.txt

CAUTION: This email originated from outside of the University of Guelph. Do not click links or open attachments unless you recognize the sender and know the content is safe. If in doubt, forward suspicious emails to [email-masked]

--
Chuck Lever

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Chuck Lever III <[email-masked]>
Date: Thu, 16 Dec 2021 15:07:31 +0000

> On Dec 15, 2021, at 8:28 PM, Rick Macklem <[email-masked]> wrote:
> 
> Mostly looks fine to me.

You're right, that's sloppy. I'll fix that up.

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Thu, 16 Dec 2021 15:15:05 +0000

Righto. Btw, I like your idea to have ExchangeID return NFS4ERR_WRONG_CRED.
Hopefully, this minor change to RFC8881 is acceptable for others.

And I didn't even spot any obvious typos, rick

________________________________________
From: Chuck Lever III <[email-masked]>
Sent: Thursday, December 16, 2021 10:07 AM
To: Rick Macklem
Cc: NFSv4
Subject: Re: New Version Notification for draft-cel-nfsv4-rpc-tls-pseudoflavors-01.txt

--
Chuck Lever

---

From: Rick Macklem <[email-masked]>
Date: Mon, 20 Dec 2021 22:16:17 +0000

Btw, NFS4ERR_WRONG_CRED is not defined for NFSv4.0, so it cannot be used
as a reply to SetClientID/SetClientIDConfirm.

rick

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 21 Dec 2021 05:34:43 -0500

> Btw, I like your idea to have ExchangeID return
> NFS4ERR_WRONG_CRED.

I do as well.

> Hopefully, this minor change to RFC8881 is acceptable for others.

I had tried to address this issue in security-03, but reading Chuck's text
has convinced me that further work will be needed.

There is no time to do this in security-04, which will be our by
Christmas.  Given the need to address both 4.0 and 4.1 there will have to
be discussion of how to divide this material between security-05 and
rfc5661bis.

> as a reply to SetClientID/SetClientIDConfirm.

True, but we will need to figure out an error to return.   Not planning
7530bis, so this would need to be specified in security-05.

On Mon, Dec 20, 2021 at 5:16 PM Rick Macklem <[email-masked]> wrote:

> Subject: [nfsv4] Fwd: New Version Notification for
> draft-cel-nfsv4-rpc-tls-pseudoflavors-01.txt
>
> CAUTION: This email originated from outside of the University of Guelph.
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe. If in doubt, forward suspicious emails to
> [email-masked]
>
>
>
> > Begin forwarded message:
> >
> > Subject: New Version Notification for
> draft-cel-nfsv4-rpc-tls-pseudoflavors-01.txt
> > URL:
> https://www.ietf.org/archive/id/draft-cel-nfsv4-rpc-tls-pseudoflavors-01.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-cel-nfsv4-rpc-tls-pseudoflavors/
> > Html:
> https://www.ietf.org/archive/id/draft-cel-nfsv4-rpc-tls-pseudoflavors-01.html
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-rpc-tls-pseudoflavors
> > Diff:
> https://www.ietf.org/rfcdiff?url2=draft-cel-nfsv4-rpc-tls-pseudoflavors-01
> >
> > Abstract: