Re: [nfsv4] AUTH_GSS for Callbacks

Mike Eisler <mike@eisler.com> Thu, 30 October 2003 23:00 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 SAA18322 for <nfsv4-archive@odin.ietf.org>; Thu, 30 Oct 2003 18:00:25 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFLlu-0006Kz-Ju for nfsv4-archive@odin.ietf.org; Thu, 30 Oct 2003 18:00:06 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9UN066a024355 for nfsv4-archive@odin.ietf.org; Thu, 30 Oct 2003 18:00:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFLlt-0006Kk-OJ for nfsv4-web-archive@optimus.ietf.org; Thu, 30 Oct 2003 18:00:05 -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 RAA18282 for <nfsv4-web-archive@ietf.org>; Thu, 30 Oct 2003 17:59:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFLlq-0004Ga-00 for nfsv4-web-archive@ietf.org; Thu, 30 Oct 2003 18:00:03 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AFLlq-0004GX-00 for nfsv4-web-archive@ietf.org; Thu, 30 Oct 2003 18:00:02 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFLlr-0006KH-E1; Thu, 30 Oct 2003 18:00:03 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AFLln-0006JI-AE for nfsv4@optimus.ietf.org; Thu, 30 Oct 2003 17:59:59 -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 RAA18278 for <nfsv4@ietf.org>; Thu, 30 Oct 2003 17:59:47 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AFLlk-0004GJ-00 for nfsv4@ietf.org; Thu, 30 Oct 2003 17:59:56 -0500
Received: from [207.230.99.20] (helo=eagle.sharedhosting.net) by ietf-mx with esmtp (Exim 4.12) id 1AFLl8-0004D1-00 for nfsv4@ietf.org; Thu, 30 Oct 2003 17:59:51 -0500
Received: from eisler.com (nat-198-95-226-230.netapp.com [198.95.226.230]) (authenticated bits=0) by eagle.sharedhosting.net (8.12.10/8.12.10) with ESMTP id h9UMsHJA019499; Thu, 30 Oct 2003 14:54:18 -0800 (PST)
Message-ID: <3FA19693.7000507@eisler.com>
From: Mike Eisler <mike@eisler.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "wurzl, mario" <wurzl_mario@emc.com>, 'Kevin Coffman' <kwc@citi.umich.edu>
CC: nfsv4@ietf.org
Subject: Re: [nfsv4] AUTH_GSS for Callbacks
References: <FA2F59D0E55B4B4892EA076FF8704F55055449CD@srgraham.eng.emc.com>
In-Reply-To: <FA2F59D0E55B4B4892EA076FF8704F55055449CD@srgraham.eng.emc.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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: Thu, 30 Oct 2003 14:54:11 -0800
Date: Thu, 30 Oct 2003 14:54:11 -0800
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

wurzl, mario wrote:

> Introducing a new protocol that increases client administration costs, is
> probably the most effective way to discourage deployment, and send the
> protocol to the same basket with other great but unmanageable ideas, like
> OSI.

That Kevin and you keep bringing up this issue suggests that
you are unhappy with using AUTH_NONE for SETCLIENTID, which solves the
ease of administration issue. So what is your proposal for something that
is more secure than using AUTH_NONE and still has the level of
ease of admin you want?





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