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
- [nfsv4] AUTH_GSS for Callbacks rick
- Re: [nfsv4] AUTH_GSS for Callbacks Nicolas Williams
- Re: [nfsv4] AUTH_GSS for Callbacks J. Bruce Fields
- Re: [nfsv4] AUTH_GSS for Callbacks Mike Eisler
- Re: [nfsv4] AUTH_GSS for Callbacks Nicolas Williams
- RE: [nfsv4] AUTH_GSS for Callbacks wurzl, mario
- Re: [nfsv4] AUTH_GSS for Callbacks Nicolas Williams
- Re: [nfsv4] AUTH_GSS for Callbacks J. Bruce Fields
- Re: [nfsv4] AUTH_GSS for Callbacks Mike Eisler
- Re: [nfsv4] AUTH_GSS for Callbacks Kevin Coffman
- RE: [nfsv4] AUTH_GSS for Callbacks wurzl, mario
- Re: [nfsv4] AUTH_GSS for Callbacks Mike Eisler
- Re: [nfsv4] AUTH_GSS for Callbacks Nicolas Williams