[146] in Kerberos
[Mike Kazar: Re: A few questions]
jon@ATHENA.MIT.EDU (jon@ATHENA.MIT.EDU)
Sun Aug 9 21:34:01 1987
From wesommer@ATHENA.MIT.EDU Mon Nov 24 09:43:14 1986
To: watchmakers, kerberos
Subject: [Mike Kazar: Re: A few questions]
Date: Mon, 24 Nov 86 09:41:53 EST
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
I asked Mike Kazar of CMU to describe the authentication scheme used by the
Vice fileserver; since the security of this was under discussion earlier
I figured that it would be appropriate to forward this to the list.
By the way, I made the Kerberos paper available to him via anonymous FTP,
since he showed some interest in it.
------- Forwarded Message
Return-Path: @po5.andrew.cmu.edu:kazar#@andrew.cmu.edu
Received: by PRIAM.MIT.EDU (5.45/4.7) id AA06596; Mon, 24 Nov 86 09:03:44 EST
Received: by ATHENA (5.45/4.7)
id AA10844; Mon, 24 Nov 86 09:03:27 EST
Received: by po5.andrew.cmu.edu (4.12/3.15) id <AA00369>; Mon, 24 Nov 86 08:59:51 est
Received: FROM mooncrest VIA queuemail
ID </cmu/common/mailqs/q006/QF.mooncrest.1fc85d25.1f8>;
Mon, 24 Nov 86 08:59:03 est
Message-Id: <MS.V3.18.kazar.80020c0c.mooncrest.ibm032.1181.1@andrew.cmu.edu>
Date: Mon, 24 Nov 86 08:58:58 est
From: kazar#@andrew.cmu.edu (Mike Kazar)
To: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
Subject: Re: A few questions.
The next release of venus will not use .cx or .hx files at all for the reason
you just hit. Unfortunately, bec requires the based editor 1 library as part
of it, and that is not a trivial thing to ship. How about I just send you
the object file version of bec, and you run it on your .cx and .hx files.
What machine type do you want it for? When I hear from you, I'll put the
appropriate machine type bec's on cmu's H vax, and you can ftp it over.
Anyway, all further vice updates will include the sources in regular text
file format.
As for our authentication scheme, it is essentially the one described under
Needham and Schroder's standard paper on the encryption. In particular, the
only thing shipped over the network in the clear is what we call a "secret
token", which is really a session key generated by the authentication server,
and encrypted with the file server's password. This session key, by virtue
of being encrypted with the file server's password, is useless for
eavesdroppers. Once it has been received by the file server, the secret
token is decrypted, yielding both the session key to use with this session,
and a time, set by the authentication server, that the token should be
considered obsolete. Our system currently runs with that time being 25
hours, after which the user of a vice console must re-authenticate using
login or the "log" program. After that time, the connection drops to an
unauthenticated level, and you are so warned by our console program.
Hopefully in the next release, venus will actually warn you before the token
expires.
That's the scheme, however, we're running a modified version thereof for
performance reasons. First of all, we have no DES hardware, so we use XOR
instead of DES. This is, of course, infinitely more susecptible to a known
cleartext attack. Secondly, at cmu we do not encrypt the packets used for
regular vice traffic at all.
We plan to remedy most of these problems in the next release. In particular,
while the cost of running DES in software is high, authentication happens
rarely enough that we can actually use it for conversations with the
authentication server without too much trouble, I believe. So, one item that
should get fixed shortly is that the secret token will really be encrypted
with DES.
The problem with the day-to-day traffic, however, is worse. We plan to offer
both headers-only encryption and whole-packet encryption modes, at a user's
option, but frankly, remote procedure call headers are so susceptible to
known clear-text attack that we may as well not bother doing any encryption
at all unless we use something better than XOR for the algorithm.
In short, while the framework is present for doing our full algorithm in a
secure manner, our use of XOR instead of DES means that it is possible, by
spying on the network, to inject a call into an RPC stream. This will screw
up the connection as far as the real user is concerned, but the injected call
will get handled.
What encrypted algorithm do you plan to use? How do you plan to get it to
run fast enough?
Yes, I would be very interested in seeing the Kerberos paper. I don't see
any real problems with you guys putting your own authentication system in
venus; it shouldn't take much work to figure out how to fit it in.
Mike
------- End of Forwarded Message
