Re: [nfsv4] AUTH_GSS for Callbacks

Nicolas.Williams@sun.com

From: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Re: [nfsv4] AUTH_GSS for Callbacks
Message-ID: <20031029225729.GC24528@binky.central.sun.com>
Date: Wed, 29 Oct 2003 14:57:30 -0800

On Wed, Oct 29, 2003 at 02:53:36PM -0800, Mike Eisler wrote:
> 
> 
> > -----Original Message-----
> > From: rick@snowhite.cis.uoguelph.ca
> > [mailto:rick@snowhite.cis.uoguelph.ca]
> > Sent: Wednesday, October 29, 2003 2:16 PM
> > To: nfsv4@ietf.org
> > Subject: [nfsv4] AUTH_GSS for Callbacks
> >
> >
> > It's me, confused again:-)
> >
> > I've read Sec. 3.4 a couple of times and can't figure out
> > quite what the
> > server is supposed to do w.r.t. GSS authentication for Callbacks.
> >
> > The first para. seems to state that the server should use the same
> > principal the client used when doing the SetClientid. Later, it seems
> > to state that the server should use the form:
> 
> Here's an example of how it is intended to work with Kerberos V5
> according to my interpretation (intent really since I contributed
> that section) of 3.4.
> 
> The client uses root/<fqdn of client host> as the initiator

you must mean root@client  (root/... is Kerberos syntax) :)

> principal when it did SETCLIENTID. Note that RFC3530 doesn't
> mandate this form at all ... think of that lack of
> mandate it as a concession to the
> camp of NFS client implementors that think machine creds are evil. I
> suspect this means that they'll be using AUTH_NONE for SETCLIENTID, but I
> digress. :-)

Single user clients shouldn't need "root" creds.  Multi-user clients
should either do a SETCLIENITD per-user or else they should have a
hostbased credential to protect the SETCLIENTID with - otherwise there
may be attacks where one user collaborates with a compromised file
server to redirect mounts that other users are interested in.

> The target principal for SETCLIENITD is mandated to be nfs@<fqdn of server 
> host>.
> 
> When the server does the call back, the target and initiator principals
> are simply reversed. The initiator principal is nfs@<fqdn of server host>, 
> and
> the target principal is root/<fqdn of client host>.

That's what I thought.  This works, more or less, for Kerberos, but it
doesn't really work for LIPKEY.

> It can't be any other way ... otherwise the server can't be
> sure the client it is sending the callback to is the right client
> (the one that owns the client id), and similarly, the client can't be sure
> the server issuing the callback is the one that granted the delegation.

Enter CCM-MIC.

Cheers,

Nico
-- 

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4