[3663] in Kerberos
Re: S/KEY integrated with Kerberos?
daemon@ATHENA.MIT.EDU (Ganesan)
Mon Aug 8 12:23:20 1994
From: bf4grjc@socrates.MIT.EDU (Ganesan)
To: bcn@ISI.EDU (Clifford Neuman)
Date: Mon, 8 Aug 1994 12:16:31 -0500 (EDT)
Cc: kerberos@MIT.EDU
In-Reply-To: <199408081446.AA02561@cym.isi.edu> from "Clifford Neuman" at Aug 8, 94 07:46:14 am
Reply-To: bf4grjc@bell-atl.com
> Not quite. The KDC can not derive on its own the passphrase to be
> used. Instead, the passphrase typed by the user can be verified, but
> must be received by the KDC from the user in a form that can be
> recovered. Public key cryptography is needed to send the passphrase
> to the KDC in a recoverable form without requesting any other "secret"
> information from the user.
I'm now COMPLETELY confused.
Here's how S/Key (simplified) works:
We have a one way function F. Let X0, X1, X2, X3 ,.....,X100 be a
sequence where: Xn+1 = F(Xn). Lets also assume we have a UNIX system.
The user knows X1. To begin with X100 is stored in /etc/passwd. At
log on time, user computes X99 by applying F(F(F(...(X0), 99 times to
X0, and gives X99 to host. Host computed F(X99) and sees if it equals
X100 stored in /etc/passwd, if so (i.e. F(X99) == X100) it lets user
in, and then changes /etc/passwd entry to X99. Next time user
calculates X98 from X0 and so on. Observe that the /etc/passwd file
CAN BE PUBLIC.
This is the original Lamport scheme really, and what SKEY does (since
Bellcore wants to save its owners the cost of hardware devices :-) )
is to give the user, say, X90 to X99 for the next 10 logins. The user
writes these down. To make things even friendlier, instead of actually
writing down X90 - X99 which are bits, SKEY gives you a pass phrase
which can be converted to bits, using some algorithm A(). I dont think
A() needs to be prviate, F() of course is public.
OK. Now lets try and resolve this discussion.
The solution proposed was to have the Kerberos server store X0 for each
user, (and a counter), So when user logs in for 1st time, Kerberos
encrypts the TGT in X99, when user logs in for the 2nd time, it computes
X98, etc. Let the client program do the A(pass-phrase) = x99 bit. (similar
to the string_to_des function in the kerberos code
As far as I can see, this DOES work. Bur its not really SKEY, in the sense
that the server HAS to STORE the X0's securely. This is of-course perfectly
ok in the Kerberos world, but was preceisely what Lamport/SKEY was invented
to avoid! So in this sense this is not really integrating SKEy with Kerberos.
The rest of Cliff's message lost me completely - I must be missing
something. As far as I can see, you only need public-key when you do
NOT want to store X0 on the KDC. But I do nto see what this has to do
with having the kerberos secret key chosen by a spoofed kinit. Under
this assumption, you are anyway totally compromised so nothing else
matters anyway!
Thanks,
Ravi
************************************************************
Ravi Ganesan
Senior Manager
Center of Excellence for Electronic Commerce, Bell Atlantic
e-mail: Ravi.Ganesan@Bell-Atl.Com
v-mail: (301) 236-7583
Fax: (301) 236-8569
************************************************************
