Use ssh key to acquire TGT?

[Marcus Watts]

Adam Megacz <megacz at hcoop.net> writes:
> Date:    Thu, 31 May 2007 19:14:50 PDT
> To:      kerberos at mit.edu
> From:    Adam Megacz <megacz at hcoop.net>
> Subject: Use ssh key to acquire TGT?
> 
> I know the idea will make some people recoil in horror, but are there
> any KDCs or patches out there that do this?
> 
> The idea would be that the KDC would issue a TGT to any user who could
> prove they had posession of the private key corresponding to one of
> the user's ~/.ssh/authorized_keys (assume for simplicity that the KDC
> has copies of these).
> 
> I know there are solutions out there for generating a TGT in response
> to other authentication mechanisms (secureid, etc), so this can't be
> *that* crazy.
> 
> Our (hcoop.net) users love their new AFS homedirs, but are complaining
> a lot about ssh public keys not working the way they're accustomed to.
> Telling them to "kinit" after logging in doesn't quite cut it either.
> 
> We're aware that this goes against the grain of kerberos security, but
> without something like this users will just start hardcoding their
> plaintext password into scripts, which is even worse.  At least with
> ssh keys we can urge them to password-encrypt their on-disk private
> keys.
> 
>   - a

There are KDC mods today to use X.509 certificates, which covers
the essential mechanics of what you asked.  This doesn't
quite do what you actually want.

The deeper problem though is one of "trust" (whatever "trust" means).
In your problem you have 4 trust domains:
/1/ KDC.
	ultimate "center" of trust:  The kdc.
	radiating out: administrative principals, mechanism
	to create keytabs, mechanism to create user principals,
	mechanism to disperse user passwords.
/2/ AFS.
	ultimate 'center" of trust:  db & fs hosts -- KeyFile.
	also behind that, kerberos.
	2 more notions of admin: "UserList", system:administrators.
	radiating out: fs superstructure, mechanism to create
	user pt instance and home dir.
/3/ the login host.
	ultimate 'center' of trust: kernel.
	local admin: root.
	intersects with the other 3 trust domains:
	sshd - host key.
	should have a k5 host key - possession .eqv. "has root".
	afs cm
/4/ each of your users (individually.)
	kerberos password
	local unix password (if any)
	ssh client keys.

What your asking for, in a literal sense, is for the KDC (/1/) to trust
the word of the login host (/3/).  Yes.  People will recoil.  One of
the goals of kerberos is the ability to deploy multiple different login
environments, each with their own separate local "root" authority and
set of users, such that these individual different environments do not
need to "trust" each other.  That is, a compromise of any one part of
this does not compromise the other parts.  This assumption breaks when
you require that kerberos trust the login host.

Let's deconstruct this a bit.  sshd looks at "~/.ssh/authorized_keys
to verify a key (that's /3/ login host).  In your environment that's
stored in AFS (/2/), in a file that has to be read before getting tokens
(unauthenticated--oops).  You want to end up with kerberos tickets
(/1/) or at least an AFS token (/2/).  This is definitely a problem in
several ways.  Horrors.

Assuming you can actually modify your users (/4/) and train them
*not* to think of ~/.ssh/authorized_keys as useful, you can fix this.
*Instead* of authorized_keys, you train them to use some new command, say
"ssh-authorize", which would take a public key and associate it with their
kerberos principal in K5.  Now the trust is in the right place.  To make
this work, modify sshd & kdc, so that when they login, sshd talks to the
kdc to acquire the user's public key, and then depends on the kdc for the
interaction to establish a shared master key.  (The straightforward way is
to put the host key & all the math in the kdc, but it would be better to
leave the host key & as much of the math as possible in the login host.)
You want 2-3 outputs from this: the ssh session key or master secret,
a kerberos tgt, & in your case you'd be going right back for an afs
service ticket as well.  You should not be looking at the user's home
directory at all until you get that afs service ticket.  This is not
likely to be a simple project, but it should be doable.  [ I believe
this is pretty much what Russ is saying as well. ]

Before you dig too deep into this, you might also want to investigate
gssapi support in various versions of ssh.  gssapi support may include
the ability to use either k5 or x509.  Some versions of openssh also
include special handling for afs tickets.

				-Marcus Watts