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

[David Noveck <[e-mail]>]

> The issue with that was that NFSv4.0 does not have
> NFS4ERR_WRONG_CRED. Is there a suitable alternative
> for NFSv4.0?

Depends what you mean by "suitable".

I'd like to avoid any need for an rfc7530bis, so I would try to limit
things to errors already returned by SETCLIENTID.  I think I'll try
NFS4ERR_INVAL  in -05 and let the wg discuss its suitability.

I'm

On Fri, Jan 28, 2022 at 11:52 AM Chuck Lever III <[e-mail]>
wrote:

>
> > On Jan 28, 2022, at 11:38 AM, David Noveck <[e-mail]> wrote:
> >
> >> On Fri, Jan 28, 2022 at 9:57 AM Chuck Lever III <[e-mail]>
> wrote:
> >>
> >> > On Dec 21, 2021, at 5:34 AM, David Noveck <[e-mail]>
> wrote:
> >> >
> >> > > 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'm assuming that it is.  I hope that anyone who does have an objection
> will state it now
> > to avoid wasting Chuck's time and mine.   I guess the appropriate time
> to discuss consensus
> > for this issue is when rfc5661bis becomes a (set of) working group
> documents(s) .  It seems that
> > is a few months away..
>
> The issue with that was that NFSv4.0 does not have
> NFS4ERR_WRONG_CRED. Is there a suitable alternative
> for NFSv4.0?
>
>
> >> > 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.
> >>
> >> Is there any objection to adopting
> >> rpc-tls-pseudoflavors as a WG document?
> >
> > Not on my part.
> >
> > I suggest we give people a month to object and proceed to adopt this
>
> Works for me. I will ask again on February 28.
>
>
> >> I was reminded recently that somewhere we have to mandate
> >> the use of RPC-with-TLS on the backchannel connection when
> >> an NFSv4.0 client connects using RPC-with-TLS on the forward
> >> channel. IMO that mandate belongs in nfsv4-security.
> >
> > I will do that draft-ietf-nfsv4-security-05, either as it is done in
> draft-dnoveck-nfsv4-security-04 or
> > in some other way to diding this up that Chuck and I are both
> comfortable with.
> >
> >> Also, I'd like to discuss how to divide the material in
> >> Section 5.2.1 between rpc-tls-pseudoflavors and
> >> nfsv4-security. Where do we begin?
> >
> > I think we begin where we are in -04 with anyone, including most
> particularly you, proposing a different arrangement.
>
> I can have a look at Sections 13 and 14 of -04 and
> propose some alternatives.
>
> By the way, s/Rouge/Rogue
>
>
> --
> Chuck Lever
>
>
>
>