[2148] in Kerberos
Re: New User Accounts
daemon@ATHENA.MIT.EDU (dean@ksr.com)
Wed Sep 2 16:01:20 1992
Date: Wed, 2 Sep 1992 15:33:46 -0400
From: dean@ksr.com
To: Derek Atkins <warlord@Athena.MIT.EDU>
Cc: dean@ksr.com, kerberos@Athena.MIT.EDU, ramus@nersc.gov (Joe Ramus)
My thought is that a service key (from the /etc/srvtab) can be used
to get a ticket and a session key for the "kerberos-SecurID" server.
The securID code would be encrypted using this session key and sent
to the kerberos-SecurID server, which could authenticate the code and
change the kerberos password (private key) to be the securID code.
The kerberos-securID server ask the securID server if the code is
valid, and performs the next code/new pin protocol with the client.
This communication would be encrypted in the session key obtained
previously.
When SecurID code is authenticated, the password is changed to the
securID code, and is changed again in 30 seconds to a random key so
the old code cannot be reused. (Thus limiting the damage if the real
code is stolen).
If the SecurID code in not authenticated, the kerberos password
(private key) is not changed.
The kerberos (re)initialization now proceeds as usual, kerberos sends
a ticket for the principal encrypted in the principal's current
kerberos key
Since the workstation has the correct SecurID code, it can decrypt
the response and obtain the ticket and the new session key only if
the securID authentication was successful.
I think the only way to compromise this scheme is to steal the
service key in the /etc/srvtab file and decrypt the communication
with the kerberos-SecurID server. If one could do this, one could
also steal the securID code as it were entered, by replacing the
login or kinit program. The problem of capturing good passwords
with a compromised workstation is not addressed by kerberos, and only
limited by SecurID by virtue of the changing password.
What say you?
--Dean
Dean Anderson
KSR Computing Facilities
Kendall Square Research
