Re: [nfsv4] AUTH_GSS for Callbacks

 > -----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
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
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4