Subject: Re: [nfsv4] AUTH_GSS for Callbacks

From: Mike Eisler <[email-masked]>
Date: Wed, 29 Oct 2003 14:53:36 -0800

> -----Original Message-----
 > From: [email-masked]
 > [mailto:[email-masked]]
 > Sent: Wednesday, October 29, 2003 2:16 PM
 > To: [email-masked]
 > 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
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. :-)

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>.

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.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 29 Oct 2003 14:57:30 -0800

> The client uses root/<fqdn of client host> as the initiator

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

> suspect this means that they'll be using AUTH_NONE for SETCLIENTID, but I

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 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.

> the server issuing the callback is the one that granted the delegation.

Enter CCM-MIC.

Cheers,

Nico
--