Subject: [nfsv4] AUTH_GSS for Callbacks

From: [email-masked]
Date: Wed, 29 Oct 2003 17:16:18 -0500 (EST)

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)

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

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

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

---

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

> nfs@hostname (or nfs/hostname@REALM for Kerberos)

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

> used for the SetClientID.

Yes.

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 29 Oct 2003 17:35:26 -0500

> nfs@hostname (or nfs/hostname@REALM for Kerberos)

I think you're confusing the principal that the server authenticates to with
the principal that it authenticates as.

--Bruce Fields