[4181] in Kerberos
Re: Kerberos w/ one-time passwords?
daemon@ATHENA.MIT.EDU (John Scudder)
Mon Nov 14 15:25:00 1994
To: Ted Lemon <mellon@ipd.wellsfargo.com>
Cc: kerberos@MIT.EDU
In-Reply-To: Your message of "Mon, 14 Nov 1994 11:20:22 PST."
<199411141920.LAA24061@rurapenthe.ipd.wellsfargo.com>
Date: Mon, 14 Nov 1994 15:04:52 -0500
From: John Scudder <jgs@merit.edu>
> From: Ted Lemon <mellon@ipd.wellsfargo.com>
> To: jgs@yurt.merit.edu (John Scudder)
> CC: kerberos@MIT.EDU
> > 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.
But you _can't_ refrain from transmitting it, else how do you
authenticate yourself? (That's the nub of the problem. All the
verbiage below is just embellishment.)
The scenario is this:
My PC ---insecure channel--- host running --- kerberos --- auth
kinit server
Note that "my PC" is incapable of running the Kerberos protocol. So
_something_ MUST be sent in the clear to "host". "PC" can't
participate in an encrypted conversation.
> 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.
This isn't a problem, since your list shows both the challenge and
the correct response (see below).
> 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
The way standard s/key works is this: The server issues a challenge of
the form "947 yu462154". I form my response by iterating
md4(yu462154+my_secret_password) 947 times. Then I send it to the
server. The server iterates it once more and compares it to the stored
value of md4(yu462154+my_secret_password) iterated 948 times. If they
match, you win. The function md4() is assumed to be non-reversible.
You may notice that the server HAS NO IDEA of what the list of correct
responses looks like. Only you do, because only you have the string
my_secret_password. (If you are willing to entrust the server with
your secret password, then it can compute this list of responses too.
This might be okay in the Kerberos framework, insofar as vanilla
Kerberos authentication servers know the cleartext of users'
passwords.)
Even if you allow the authentication server know the cleartext of your
password, you still don't protect against an antagonist grabbing the
text of your one-time password as it passes between "PC" and "host."
> 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.
No, it can't. (See above.)
> 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
Can't do this w/o knowing the text of your password. Even if it does,
your one-time passphrase is still sent in the clear to the host. If an
antagonist intercepts both the passphrase and the TGT, he wins.
> 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_
I don't see that what you describe fixes my problem. To restate: I
need to run kinit in a remote login session passing over a non-trusted
link. I'm inclined to believe it can be done, but not by merely
replacing reusable passwords with s/key one-time passphrases.
--John Scudder
