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: <20031029222614.GZ24528@binky.central.sun.com>
Date: Wed, 29 Oct 2003 14:26:14 -0800

On Wed, Oct 29, 2003 at 05:16:18PM -0500, rick@snowhite.cis.uoguelph.ca wrote:
> 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:
> 
> nfs@hostname (or nfs/hostname@REALM for Kerberos)

"nfs@hostname" corresponds to the GSS hostbased name type.

> and then it seems to hint that this will be what the client would have
> used for the SetClientID.

Yes.

> So, should the server use whatever principal the client provided
> OR
> nfs@client-hostname (with or without domain spec)
> OR
> nfs@server-hostname (with or without domain spec)?
> 
> I suppose it can just be left up to the sysadmin, since whatever is
> used has to be in the server's /etc/krb5.keytab (or does it, I'm a
> Kerberos midget), set in the exports file, or similar.
> 
> Anyhow, I'd be interested in hearing what others think, rick

Well, assuming that the initiator could turn around and act like an
acceptor (and similarly for the acceptor) the right thing to do would be
for the server to use the client's source name as the target and the
client's target name as the source name.

I.e., if the client did a setclientid with root@client to nfs@server,
then the server should do the callback with nfs@server to root@client.

In practice this doesn't work.

I've proposed (off-list) that we do the following instead:

 - add a new callback op (args: clientid; result: void) which tells the
   client that the server wants the client to establish a GSS-API
   context (and RPCSEC_GSS ctx handle) with the initiator principal name
   used to setup the given clientid

 - use CCM-MIC to establish GSS-API contexts in the callback channel
   using an established GSS-API context from the NFSv4 channel.

The trick here is that CCM-MIC is a very special GSS-API pseudo-
mechanism whose purpose is to setup a new context based on an existing
context.

See the CCM I-D linked to from the NFSv4 WG page:

http://www.ietf.org/internet-drafts/draft-ietf-nfsv4-ccm-02.txt

We have yet to spec the new callback op for this (it's v4.x work).

Cheers,

Nico
-- 

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