[2874] in Kerberos
A secure login scheme?
daemon@ATHENA.MIT.EDU (Robert G. Moskowitz)
Wed Oct 27 12:14:09 1993
Date: Wed, 27 Oct 93 14:07 GMT
From: "Robert G. Moskowitz" <0003858921@mcimail.com>
To: kerberos <kerberos@MIT.EDU>
To: ietf <ietf@ietf.cnri.reston.va.us>
I am a big proponent of the Kerberos method of authentication, but as a
corporate creature I have always had a couple of problems with it. I read
the DASS proposal with great interest and find it a good step forward as
well. My 'real' security knowledge comes from attending Jeff Schiller;s
Kerberos class at Spring INTEROP '92. That and a lot of reading. I see PEM
mail as VERY important for corporations. But as discussed recently in this
list, DES is not the way to go for non-reputable certificates. This means I
would have to expect a user to have a X.509 public/private key for EMail and
a DES key for network identification (and such wonderful things as secure
RPCs). DASS kind of presents an alternative that appears to be strickly
X.509 based.
But another problem I have is I cannot count on all commercial entities that
I need to work with running a secure-trustable network. This is
particularly true for the small automotive suppliers that have rather
limited technical resources. Thus I have thought of the following scheme
that would give a secure logon accross the INTERNET for TELNET, TN3270, FTP,
and other such apps.
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
requests a password token. The token is composed by encrypting the current
GMT time/date in the client's private key and that in the server's public
key. The server then decrypts this first with its private key and then with
the client's public key. The GMT time/date is then checked for a minimum
time skew. If all goes well the user is logged in. The use of the GMT
time/date protects against play-back spoofing. The double encryption
elimates any shared secret, the server can authorize a client by simply
adding the publically available key. This will be very hard to break
because it is a double encryption.
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?
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
