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

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

> Begin forwarded message:
> 
> From: [e-mail]
> Subject: New Version Notification for draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt
> Date: December 5, 2021 at 2:41:27 PM EST
> To: "Charles Lever" <[e-mail]>, "Chuck Lever" <[e-mail]>
> 
> 
> A new version of I-D, draft-cel-nfsv4-rpc-tls-pseudoflavors-00.txt
> has been successfully submitted by Chuck Lever and posted to the
> IETF repository.
> 
> Name:		draft-cel-nfsv4-rpc-tls-pseudoflavors
> Revision:	00
> Title:		Pseudo-flavors for Remote Procedure Calls with Transport Layer Security
> Document date:	2021-12-05
> Group:		Individual Submission
> Pages:		14
> URL:            https://www.ietf.org/archive/id/draft-cel-nfsv4-rpc-tls-pseudoflavors-00.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-00.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-cel-nfsv4-rpc-tls-pseudoflavors
> 
> 
> 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 several RPC auth pseudo-flavors and other
>   mechanisms that an RPC service can use to indicate transport layer
>   security requirements for accessing that service.
> 
> 
> 
> 
> The IETF Secretariat

I've submitted this personal draft to provide a fleshed-out version of
a proposal I have outlined in the recent past:

https://mailarchive.ietf.org/arch/msg/nfsv4/tU1WfkYQUm2AbiZUA3L2uX56uR4/
https://mailarchive.ietf.org/arch/msg/nfsv4/7psVqBBY8uhP9L9bMfF7hUbVXK0/

among other places.

This document provides a similar but contrasting approach to the one
described in Sections 13 through 15 of draft-dnoveck-nfsv4-security-03.
In addition to covering NFSv4, my document also addresses NFSv2/3 and
other RPC services that might wish to employ transport layer security.
I'm hoping that comparing and contrasting these two approaches will
sharpen our vision and thinking as the WG comes to a rough consensus.

Another important reason for a separate document is there seems to be
palpable demand for a standards-based NFS in-transit encryption solution.
The RPC protocol changes put forth in draft-ietf-nfsv4-rpc-tls are
necessary but not sufficient to accomplish this goal. I would like to
see a vehicle for moving the remaining components through WG consensus
and into the publication queue as quickly as possible. This document
might serve as that vehicle.

An -00 is, as always, a rough cut. There are likely to be significant
gaps in this proposal, which at this point is still quite malleable.
Thanks in advance for your time and attention to this work.


--
Chuck Lever