[36049] in Kerberos
Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter
daemon@ATHENA.MIT.EDU (Will Fiveash)
Tue Apr 15 15:23:43 2014
Date: Tue, 15 Apr 2014 14:22:46 -0500
From: Will Fiveash <will.fiveash@oracle.com>
To: Simo Sorce <simo@redhat.com>
Message-ID: <20140415192246.GA26630@oracle.com>
Mail-Followup-To: Simo Sorce <simo@redhat.com>,
Nico Williams <nico@cryptonector.com>,
"kerberos@mit.edu" <kerberos@mit.edu>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1397589189.19767.345.camel@willson.li.ssimo.org>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Tue, Apr 15, 2014 at 03:13:09PM -0400, Simo Sorce wrote:
> On Tue, 2014-04-15 at 13:48 -0500, Will Fiveash wrote:
> > On Tue, Apr 15, 2014 at 11:36:34AM -0500, Nico Williams wrote:
> > > Will,
> > >
> > > Mobile devices don't really have stable hostnames, so the system
> > > should support non-hostbased host/root credentials.
> >
> > If you are referring to the NFS v4 client requiring root have a krb cred
> > in order to function as I described in an earlier e-mail I would ask why
> > NFS v4 clients require root to have a krb cred in the first place (NFS
> > v3 doesn't as you may recall)? As you can imagine, many IT departments
> > would balk (putting it mildly) if they were asked to provision keytabs
> > on laptops or other mobile devices that need access to krb protected NFS
> > v4 shares.
> >
> > As to how that requirement happened, according to one of the NFSv4
> > developers here that regularly attends Connectathon, the consensus among
> > the NFS v4 implementors for various Linux platforms was that a properly
> > configured NFS v4 client meant it had a keytab containing host service
> > princ keys which could then be leveraged to protect the lease renewal
> > traffic. My opinion is that unless there is a very good reason to
> > protect that traffic, krb protection for lease renewal traffic should be
> > optional, depending on configuration.
>
>
> There is a good reason to require a keytab on a client if you use
> kerberos for authentication to the machine, and that is that you need
> validation for login.
>
> You also need a host key if you want to allow to use gssapi
> authentication for ssh.
>
> So it is not too far fetched to expect to find a host key on every
> machine participating to a kerberos REALM.
But if this is a work laptop, which is typically a single user system
and operates as a client in various contexts, requiring IT provision it
with a keytab seems onerous to me. Note that a Solaris NFS v3 client
does not require root have a krb cred to operation, even when
automounting -- it only requires the user that triggered the automount
have a krb cred.
> That said it is unclear to me why the NFSv4 server should try to use a
> new channel to communicate with the client instead of just using the
> existing channel the client opened against the server.
I think part of the problem is that the gss security context protecting
the channel along with the user's krb cred could expire at any time. I
think that's why they wanted root to use a key stored in the keytab (I
could be wrong of course).
--
Will Fiveash
Oracle Solaris Software Engineer
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
