Re: [nfsv4] AUTH_GSS for Callbacks

Mike Eisler <mike@eisler.com> Thu, 30 October 2003 00:49 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 TAA17483 for <nfsv4-archive@odin.ietf.org>; Wed, 29 Oct 2003 19:49:22 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF0zm-0007MN-AN for nfsv4-archive@odin.ietf.org; Wed, 29 Oct 2003 19:49:02 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9U0n2mH028285 for nfsv4-archive@odin.ietf.org; Wed, 29 Oct 2003 19:49:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF0zm-0007M8-61 for nfsv4-web-archive@optimus.ietf.org; Wed, 29 Oct 2003 19:49: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 TAA17450 for <nfsv4-web-archive@ietf.org>; Wed, 29 Oct 2003 19:48:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF0zk-0001JW-00 for nfsv4-web-archive@ietf.org; Wed, 29 Oct 2003 19:49:00 -0500
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AF0zj-0001JT-00 for nfsv4-web-archive@ietf.org; Wed, 29 Oct 2003 19:48:59 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF0zl-0007Ky-64; Wed, 29 Oct 2003 19:49:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AF0yp-0007JT-1U for nfsv4@optimus.ietf.org; Wed, 29 Oct 2003 19:48:03 -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 TAA17424 for <nfsv4@ietf.org>; Wed, 29 Oct 2003 19:47:53 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AF0yn-0001Hp-00 for nfsv4@ietf.org; Wed, 29 Oct 2003 19:48:01 -0500
Received: from [207.230.99.20] (helo=eagle.sharedhosting.net) by ietf-mx with esmtp (Exim 4.12) id 1AF0ym-0001Hl-00 for nfsv4@ietf.org; Wed, 29 Oct 2003 19:48:00 -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 h9U0luJA015383; Wed, 29 Oct 2003 16:47:58 -0800 (PST)
Message-ID: <3FA05FB7.2070702@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>
CC: nfsv4@ietf.org
Subject: Re: [nfsv4] AUTH_GSS for Callbacks
References: <FA2F59D0E55B4B4892EA076FF8704F55055449BB@srgraham.eng.emc.com>
In-Reply-To: <FA2F59D0E55B4B4892EA076FF8704F55055449BB@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: Wed, 29 Oct 2003 16:47:51 -0800
Date: Wed, 29 Oct 2003 16:47:51 -0800
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


wurzl, mario wrote:


> This implies that a system administrator will have to generate keys for a
> service 'root@client' and store it in the Kerberos keytab of all client
> systems. I have a hard time imagining a system administrator doing this
> process for a network with several thousand clients.
> It may become even worse if the principal for SETCLIENTID could be any user.

What's the alternative?

I'm having some trouble understanding this oft repeated
system administrator's environment, since he seems to be interested
in security. How does each client get an IP address assigned to it?
Since we reject a manual process for several thousand clients,
we are left with DHCP or something like it. How does the client then get
its OS installed for first time? Some kind of automatic network installation/boot,
such as JumpStart.

But how does the client authenticate the DHCP server, the install server, and
the boot server?  And how is this authentication made mutual ... after
all, you don't want attackers inject trojan horses into the
physical network that capture user passwords.

There's a fundamental boot stapping problem. Which is
not my problem to solve, but if it is solved, securely, then
if there can be a service that securely and automatically
hands out IP addresses and OS images (including configuration files, possibly customized ...
JumpStart can do it) to clients, then it follows that there can be a service
that securely and automatically hands out customized krb5.keytab files to clients.

If the sys admin isn't concerned about the bootstrap problem, then why would
he be worried about the machine cred problem? Thus he might as well
configure his client (when it netinstalled) to use AUTH_NONE for SECINFO.



	-mre





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