[4183] in Kerberos
Re: Kerberos w/ one-time passwords?
daemon@ATHENA.MIT.EDU (Gintaras Richard Gircys (GG148))
Mon Nov 14 16:21:19 1994
From: "Gintaras Richard Gircys (GG148)" <rich@oester.com>
To: kerberos@MIT.EDU
In-Reply-To: Message from Mon, 14 Nov 1994 11:20:22 -0800.
<199411141920.LAA24061@rurapenthe.ipd.wellsfargo.com>
Date: Mon, 14 Nov 1994 13:07:41 -0800
>
> > 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.
I'm no skey expert, but for my own edification, I don't understand
the point being made. It's no big deal to send one time passwords in the clear.
I assume you're not talking about the initial password which of course must be
entered in a secure manner for theory to work.
>
> 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.
>
As far as I know, you must be in sync. Period. As far as I know (and hope),
skey doesn't adjust for forward skew at all - like makes the concept of
one time passwords silly.
I also don't understand why there's a problem in general with sequences. The
skey prompt includes a sequence and a seed value. If you have a piece of paper
with responses, I beleive they all print with the sequence number.
If you're at a X term, using skey is simple; cut n'paste.
> 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
IMHO, no it should not be self correcting; for security reasons.
> 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.
Again, no, I hope. That skey can be a pain is indeed true, and many people
hate it, because if you muck up the sequence, you can be pumping mud
trying to get it (though I haven't found this to be a problem myself).
> 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.
>
I think there's some confusion about skey passwords. It is ok to send skey
passwords in the clear. BUT, do not send the initializing password in the clear.
And, if you can enter the inital password secretly (DES telnet, console entry,
secure link), then there's no third party that knows your skey secret password.
have fun,
rich
