Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt

Yes the mount will fail as you describe, but, in that case, the error would
be first detected when you try to access the krb5-only fs.   In the case
Tigran
is mentioning,  the server is interested in preventing unencrypted access
from
the beginning.

This can be an issue in liight of the fact that there is no way (without
rpc-tls)
to cause such operations as EXCHANGE_ID and CREATE_SESSION to be
done with privacy protection.   Also, if the server supports AUTH_SYS at
all,
I think it has to accept it for these operations (again no privacy).  The
problem
that this  leads to is that the clientid and sessionid are the kind of
protocol artifacts that RFC7258 warns us against making observable.   In
the
case of NFSv4.1 they can be the basis of denial of service attacks in that
once the COMPOUND is accepted (easy if AUTH_SYS is supported by
the server at all; not much more difficult in the RPCSEC GSS case since only
a single user needs to be compromised), spurious COMPOUNDs can be
issued so that a legitamate client will have its requests rejected since
they apear
to have invalid slot sequence values :-(.
requests

On Tue, Apr 23, 2019 at 9:42 AM Olga Kornievskaia <aglo@umich.edu> wrote:

> On Tue, Apr 23, 2019 at 4:44 AM Mkrtchyan, Tigran
> <tigran.mkrtchyan@desy.de> wrote:
> >
> >
> >
> > The other aspect that probably makes sense to describe is the behavior
> > when server insist on TLS, some thing like that only operation NULL
> > is accepted and anything else fails with error AUTH_TOOWEAK or similar.
> > In general, the point is not to enforce one or an other way, but clearly
> > specify the client/server interaction to avoid ambiguity for
> implementors.
> > IOW, pure egoism :)
>
> Isn't this already taken care of by the NFS layer. Say my server is
> exporting only krb5 flavors and my client mounts with sec=sys, I will
> get a ERR_WRONGSEC back and mount would fail.
>
> >
> > Tigran.
> >
> > ----- Original Message -----
> > > From: "Benjamin Kaduk" <kaduk@mit.edu>
> > > To: "Chuck Lever" <chuck.lever@oracle.com>
> > > Cc: "NFSv4" <nfsv4@ietf.org>
> > > Sent: Monday, April 22, 2019 5:48:15 PM
> > > Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-rpc-tls-01.txt
> >
> > > On Tue, Apr 16, 2019 at 01:11:54PM -0400, Chuck Lever wrote:
> > >>
> > >> > On Apr 16, 2019, at 1:09 PM, David Noveck <davenoveck@gmail.com>
> wrote:
> > >> >
> > >> > I'm confused by the addition of the word "opportunistically" in the
> abstract.
> > >> > This document defines an important way of providing security to
> RPC-based
> > >> > protocols such as NFSv4, so as to deal with the very real security
> problemms
> > >> > that these protocols have.    While these facilities can only be
> used when both
> > >> > client and the server provides support, I don't think that fact
> alone make the
> > >> > use of these facilties "opportunistic".    What exactlty is this
> word intended
> > >> > to imply?
> > >>
> > >> "Opportunistic" is a term of art. See:
> > >>
> > >> https://en.wikipedia.org/wiki/Opportunistic_TLS
> > >
> > > RFC 7435 is also a good reference for this topic (and one that has IETF
> > > consensus, FWIW).
> > >
> > > The summary of the reasoning for the use of this term is basically
> that it
> > > does not provide protection in the face of an *active* attacker (that
> can
> > > force downgrade to the previous/insecure technology), but does protect
> > > against passive observation.
> > >
> > > -Ben
> > >
> > > _______________________________________________
> > > 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
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>