[4177] in Kerberos
Re: Kerberos w/ one-time passwords?
daemon@ATHENA.MIT.EDU (Ted Lemon)
Mon Nov 14 14:35:24 1994
To: jgs@yurt.merit.edu (John Scudder)
Cc: kerberos@MIT.EDU
In-Reply-To: Your message of "14 Nov 1994 16:21:04 GMT."
<3a82pg$8qa@lastactionhero.rs.itd.umich.edu>
Date: Mon, 14 Nov 1994 11:20:22 -0800
From: Ted Lemon <mellon@ipd.wellsfargo.com>
> Since the s/key response is not secret (it may be transmitted in the
> clear across a snoopable wire, and probably is) then how can
> Kerberos trust a session key derived from the s/key response? The
> session key, being derived from non-secure information, would itself
> be non-secure.
Almost, but not quite. The s/key response *is* secret *until* you
transmit it in the clear across a snoopable wire. If you refrain from
doing that, it's still secret - almost like a regular password.
The only catch is (if I understand it correctly) the problem of skew
between your s/key password list and the server's. Both you and the
server have an idea of where on your s/key password list you are. If
you're both in sync, great. Things get complicated when you're not.
In one case, the server is ahead of you. That is, it thinks that
you've already used a password on your list that you don't think
you've used. I'm not sure how standard s/key deals with this
possibility, but it should be self-correcting. You have to cross
a password off your list once it's been sent across the net in the
clear, so every time you get a failed login, you'll try the next
password. Assuming that you don't cause a lockout to occur, you
should eventually get to the password that the host thinks you're on.
The other case is that you are ahead of the server. The server can
normally deal with this easily, since it can figure out what passwords
are next in your sequence.
Using s/key with Kerberos would turn this around. The server doesn't
get to see your key, so it has to assume that every time it issues a
TGT it must use the next key. This means that now you have to cycle
forward in your list to catch up to the server if it's ahead of you.
If it's behind you, you'll have to request new TGTs until one of them
decrypts successfully with the first key on your list.
This is possible. Whether it's worth it is another question. I'm
not convinced that it is, since in the end you still have a shared
secret/trusted third party system with many of the same
vulnerabilities. If you want more security, it's probably more
interesting to look at public key solutions that require neither a
shared secret nor a trusted third party.
_MelloN_
--
Ted Lemon Wells Fargo Bank, Information Protection Division
mellon@ipd.wellsfargo.com +1 415 477 5045
