[2876] in Kerberos
A secure login scheme?
daemon@ATHENA.MIT.EDU (Robert G. Moskowitz)
Thu Oct 28 08:25:40 1993
Date: Thu, 28 Oct 93 11:49 GMT
From: "Robert G. Moskowitz" <0003858921@mcimail.com>
To: kerberos <kerberos@MIT.EDU>
To: ietf <ietf@ietf.cnri.reston.va.us>
Thank you for your comments. I still have more research to do, but a few
points made it possible for me to come up with, perhaps a 'better' idea.
First, I think the goal is not to add to the login handshake. That is, a
packet from the server to the client, and a return from the client to the
server.
So Draft 2:
The client and the server each have a public/private key and each knows the
other's public key. The client's public key is the password for accessing
the server. When a client requests a session with its ID, the server
replies with a password token consisting of a Random number encrypted in the
client's public key. This token must be decrypted by the client with its
private key and re-encrypted with the server's public key. The server
de-crypts the returned token with its private key and if the Random number
matches the original one for the session, the login process is successful
and the user is logged in. This use of the random number in a
challenge/reply senario protects against play-back spoofing. The two-way
encryption elimates any shared secret, the server can authorize a client by
simply adding the publically available key.
Problem is for the client to supply its private key at password token
construction time. How might this be easily entered or safely stored on a
workstation? A smart card has been suggested for this, but how does that
handle a PEM certificate which is also needed by this client. Remember,
security is needed for two things: logins and non-reputable mail.
Oh, the Random number could be a randomly generated DES key that can then be
used to encrypt the data traffic, if desired. Since it was encrypted both
ways across the network, it could be safely used for the duration of session
and the speed of DES encryption would be available for the session. Since
the login was not part of the DES encyrption session, there will be a little
in the way of clear text for a attack on this DES key.
Again, I will be at IETF and would like to talk to some much more
knowledgeable person than I on this. Or learn a better proposal than this.
Something like this will be needed by AIAG if they are to move CAD and EDI
over the INTERNET.
Bob Moskowitz
Chrysler Corp
(313) 758-8212
