[32037] in Kerberos
Re: Automatically distributing nfs/ssh host principals
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Tue Feb 9 12:25:29 2010
Mime-Version: 1.0 (Apple Message framework v1077)
From: Ken Raeburn <raeburn@mit.edu>
In-Reply-To: <4B71364D.1050104@inria.fr>
Date: Tue, 9 Feb 2010 10:24:28 -0500
Message-Id: <676A4421-0E1F-47E3-93D2-43248D84753B@mit.edu>
To: Guillaume Rousse <Guillaume.Rousse@inria.fr>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Feb 9, 2010, at 05:17, Guillaume Rousse wrote:
> However, this is still a bit painful, as it can't be included in
> automatic installation scenarios, for instance. And requires us to track
> information for each user, which doesn't prove to be very useful. I was
> wondering of the security implication of changing the application
> behaviour to automatically deliver a keytab file containing a
> nfs/hostname principal, creating it if not already existing,
> corresponding to the IP adress of the contacting machine, without any
> kind of autentication. This way, as simple wget/curl/lynx command in
> automated installation would allow to install everything needed.
The idea has been kicked around before, and I believe one variant (registering a new host principal over a kadmin session protected by anonymous PKINIT) has been tried out in MIT's current development code.
> Of course, this would allow someone able to spoof the IP adress of
> another host to also usurpate its principal for those services, but:
> - the application is only accessible from internal network
> - our users machines are in a different LAN than our servers
> - we use switched LANs, not hubs
> This would reduce the spoofing scope to other workstations only.
You might consider making it only work if the principal doesn't already exist. That allows for easy provisioning of a new host, but prevents hacking of one that's already set up and which someone may be actually relying on for something. Depends on your threat model....
You should also look at how the server verifies that the hostname and address match; is it using the insecure DNS protocol, or are you securely providing it with a copy of your host database?
> Moreover, I don't think usurpating another host nfs principal has any
> interest, and ssh has its own mechanism (host keys) to prevent spoofing.
If you can change the NFS key, you can prevent people from accessing files. If you can extract the existing host key, you can access anyone else's files. I don't think Kerberos-enabled SSH uses the SSH-style host keys; I think part of the point was avoiding having to have two authentication mechanisms at work. I could be wrong about that.
--
Ken Raeburn / raeburn@mit.edu / no longer at MIT Kerberos Consortium
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
