RE: [nfsv4] AUTH_GSS for Callbacks

> -----Original Message-----
> From: nfsv4-admin@ietf.org [mailto:nfsv4-admin@ietf.org] On 
> Behalf Of Mike Eisler
> Sent: Wednesday, October 29, 2003 17:54
> To: nfsv4@ietf.org
> Subject: 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>.

This implies that a system administrator will have to generate keys for a
service 'root@client' and store it in the Kerberos keytab of all client
systems. I have a hard time imagining a system administrator doing this
process for a network with several thousand clients.
It may become even worse if the principal for SETCLIENTID could be any user.

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

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