Subject: kerberos junk principals

From: Marcus Watts <[email-masked]>
Date: Thu, 05 Dec 2002 18:39:34 -0500

I have another interesting idea which I've been thinking about
occasionally for a while now, which I think may be useful
to mention here.

This is "kerberos junk principals".

Here's what they are:
	strong random key
	random "useless" name that cannot match any real name.
	absolutely no record in kdc database

How to get them:
	Use anonymous DH to get to special "kerberos junk key server".
	It creates a random junk name, and generates a key based on the
		random name using a keyed hash with some secret it
		shares with the kdc but not you.
	The equivalent of a keytab is then returned secured under the
		DH shared secret.
To use: save result from kerberos junk key server in keytab
	or parse it out, save bits in memory, use it direct,
	scrub it from memory when done just like any other
	cryptographic secret.
What the KDC does when it sees one:
	Take name, generate key based on keyed hash with
		secret it shares only with kerberos junk key server,
		pretend that was always in the database.

Because kerberos junk principals have absolutely no per instance
	permament record, you can create as many as you want, as often
	as you want, subject only to how much CPU the kerberos junk key
	server is willing to spend on your IP address's behalf.

You are done using a junk key?  Throw it away.
Your junk key is compromised?  Throw it away.
You permitted files to your compromised kerberos junk principal?  Tough.
	You should have protected your key better.  Maybe you can rename
	the name associated with the UID that you should be using as a
	level of indirection between kerberos names and file acls.
You want to verify your kerberos junk keytab came from the real server?
	If you have a service running on the local machine
	who has a key you trust, get a service key for that
	service, see if you can talk to that server.  If it
	succeeds; your key is good - no need for the server
	to expose its key to you, or visa-versa.
Somebody tries to log in on a workstation using a kerberos junk principal?
	(1) kerberos junk principals don't have a plaintext password
		just a random binary key.
	(2) kerberos junk principals probably have weird names like
		K/E1/[email-masked]
		does your login program really think that's a valid
		loginid?
	(3) authentication and authorization should be separate.  Do you
		really let *everyone* in your realm login to your workstation?
Why can't a bad guy just make up a weird kerberos junk name?
	Well, sure he can, but he won't know what key would go
	with that name, since he doesn't know whatever secret
	the kdc & kerberos junk key server share.

Junk kerberos principals could be used and discarded
	in a matter of seconds, or they could be kept around
	and used for private machine principals for years.
What to do if a junk principal tries to change its password via kadmind?
	Refuse it.  It's read-only.

The kerberos junk key's server is compromised, or you want to start over
	and invalidate all existing junk principals?
	Generate a new secret to share between the kdc & junk
	key server.  Poof.  All existing principals are no longer good.
	Probable major disruption to life in your realm, of course.

I think of many users for kerberos junk principals.  Using it for
preauth is a straight-forward and obvious idea, but they could also be
useful for anonymous machine instances where the identity doesn't
really matter, just so long as it doesn't change (often).  Perhaps the
identity is specified in a config file shared between two machines or
is otherwise published, or perhaps there's some other expensive way
(perhaps involving human interaction) to acquire the identify on an
occasional basis.

You probably don't want to allow kerberos junk principals to acquire
service tickets for real humans.  But you shouldn't be allowing real
humans to acquire service tickets for other real humans anyways.

				-Marcus Watts
				UM ITCS Umich Systems Group

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 17 Dec 2002 12:05:28 -0500 (EST)

> 		does your login program really think that's a valid

Mine does, and also has syntax that would allow the user to specify an
arbitrary local username to try to log in as (obviously, authorization
checks are performed).  We see this as a feature, though, not a problem.