[4242] in Kerberos
Re: remote kpasswd
daemon@ATHENA.MIT.EDU (Josh Osborne)
Wed Nov 23 11:20:11 1994
From: stripes@uunet.uu.net (Josh Osborne)
To: warlord@MIT.EDU (Derek Atkins)
Date: Wed, 23 Nov 1994 09:55:39 -0500 (EST)
Cc: brian@nothing.ucsd.edu, hobbit@asylum.sf.ca.us,
mcguire@rocinante.digex.net, kerberos@MIT.EDU
In-Reply-To: <199411230154.UAA00401@incommunicado.cambridge.ma.us> from "Derek Atkins" at Nov 22, 94 08:54:56 pm
[...run Kerberos on the client...]
>It doesn't even have to have IP connectivity, all it needs is enough
>CPU to run DES and do a little data formatting. If you have this,
>then you have enough to move kerberos into the client.
>
>In fact, this was my Bachelor's Thesis, "Charon: Kerberos Extensions
>for Authentication Over Secondary Networks". You can get the paper
>via anonymous ftp:
> ftp://toxicwaste.mit.edu/pub/charon/thesis.ps.Z
Not to belittle your fine idea, but having recently been involved in a
situation where it was decided by others that "doing TCP/IP will be harder
then our own little magic protocall", I can tell you that it isn't. A
minimal TCP/IP + telnet + some of the "standard services" (TCP chargen,
UDP echo) has been written in less then 8K of ROM on a machine with
less then 3K of RAM (this was an embedded CPU with a 6502 core).
(yeah it is an extreme example - but if it can be done in 8K with great
effort it can fit into any ROM budget, and I don't think implmenting
TCP/IP/(and a subset of)PPP is going to be that much simpler then inventing
a new error correcting protocall, testing it, and debugging it, and
testing it, and revising it when the specs change, and...)
Don't let anyone tell you TCP isn't lightweight. At least not when you
implment it to be.
(yeah - I would prefer to have Kerberos over a magic protocall to just
a plain wire, but I would prefer kinit over TCP + ktelnet and/or krlogin
over TCP)
