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

On Sun, Dec 5, 2021, 9:07 PM Rick Macklem <rmacklem@uoguelph.ca> wrote:

> In section 3.2:
> If an RPC client sends an RPC Call using one of these pseudo-flavors
>    and the underlying transport does not provide the required additional
>    security services as indicated above, the RPC server MUST reject the
>    RPC Call and respond with a reply_stat of MSG_DENIED, a reject_stat
>    of AUTH_ERR, and an auth_stat of AUTH_TOOWEAK.
>
> For NFSv4, wouldn't NFS4ERR_WRONGSEC be a more natural fit than
> AUTH_ERR with auth_stat AUTH_TOOWEAK?
> --> I understand you wanted to cover NFSv3 as well, but since NFSv4
>       clients will need to do a SecInfo/SecInfo_Noname, then it seems weird
>       that it will be triggered by a RPC level error and not
> NFS4ERR_WRONGSEC.
>

That's true but given that this is an RPC document, Chuck really can't
refer to NFSv4 errors.

> Is it possible to allow either AUTH_ERR/AUTH_TOOWEAK or NFS4ERR_WRONGSEC
> as a server reply?
>

I think we have to distinguish using AUTH_SYS_MPA handled as above and
using AUTH_SYS on a connection on which MPA is not in effect.  The RPC
document could make clear that this latter is a security issue with the
specific response left up to ULP.

Chuck and I have to work together to make sure that these documents fit
together appropriately.   I expect that security-04 will be able to
reference this document.

>
> rick
>
>
> ________________________________________
> From: nfsv4 <nfsv4-bounces@ietf.org> on behalf of Chuck Lever III <
> chuck.lever@oracle.com>
> Sent: Sunday, December 5, 2021 3:07 PM
> To: NFSv4
> Subject: [nfsv4] Fwd: New Version Notification for
> draft-cel-nfsv4-rpc-tls-pseudoflavors-00.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
> IThelp@uoguelph.ca
>
>
> > Begin forwarded message:
> >
> > From: internet-drafts@ietf.org
> > 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" <chuck.lever@oracle.com>, "Chuck Lever" <
> chuck.lever@oracle.com>
> >
> >
> > 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
>
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>