Re: [nfsv4] AUTH_GSS for Callbacks

Nicolas Williams <Nicolas.Williams@sun.com> Wed, 29 October 2003 23:02 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12628 for <nfsv4-archive@odin.ietf.org>; Wed, 29 Oct 2003 18:02:21 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEzKE-0006TE-SY for nfsv4-archive@odin.ietf.org; Wed, 29 Oct 2003 18:02:03 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9TN22aX024866 for nfsv4-archive@odin.ietf.org; Wed, 29 Oct 2003 18:02:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEzKE-0006Sz-NB for nfsv4-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 18:02:02 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12618 for <nfsv4-web-archive@ietf.org>; Wed, 29 Oct 2003 18:01:50 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEzKC-0006Jg-00 for nfsv4-web-archive@ietf.org; Wed, 29 Oct 2003 18:02:00 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AEzKB-0006Jd-00 for nfsv4-web-archive@ietf.org; Wed, 29 Oct 2003 18:01:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEzKD-0006Rn-63; Wed, 29 Oct 2003 18:02:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AEzJw-0006Qo-5M for nfsv4@optimus.ietf.org; Wed, 29 Oct 2003 18:01:44 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12596 for <nfsv4@ietf.org>; Wed, 29 Oct 2003 18:01:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AEzJt-0006J8-00 for nfsv4@ietf.org; Wed, 29 Oct 2003 18:01:41 -0500
Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AEzJs-0006J3-00 for nfsv4@ietf.org; Wed, 29 Oct 2003 18:01:40 -0500
Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id h9TN1b5u002692; Wed, 29 Oct 2003 16:01:37 -0700 (MST)
Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id h9TN1a2o001855; Wed, 29 Oct 2003 16:01:36 -0700 (MST)
Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h9TMvUQx010072; Wed, 29 Oct 2003 14:57:30 -0800 (PST)
Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h9TMvU02010071; Wed, 29 Oct 2003 14:57:30 -0800 (PST)
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Mike Eisler <mike@eisler.com>
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] AUTH_GSS for Callbacks
Message-ID: <20031029225729.GC24528@binky.central.sun.com>
Mail-Followup-To: Mike Eisler <mike@eisler.com>, nfsv4@ietf.org
References: <3FA044F0.4080307@eisler.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3FA044F0.4080307@eisler.com>
User-Agent: Mutt/1.4i
Sender: nfsv4-admin@ietf.org
Errors-To: nfsv4-admin@ietf.org
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/nfsv4/>
X-Original-Date: Wed, 29 Oct 2003 14:57:30 -0800
Date: Wed, 29 Oct 2003 14:57:30 -0800

On Wed, Oct 29, 2003 at 02:53:36PM -0800, Mike Eisler wrote:
> 
> 
> > -----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

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

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

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

That's what I thought.  This works, more or less, for Kerberos, but it
doesn't really work for LIPKEY.

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

Enter CCM-MIC.

Cheers,

Nico
-- 

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