[7792] in Kerberos
Re: Mundane kerberos question: srvtab management
daemon@ATHENA.MIT.EDU (Shawn Mamros)
Fri Aug 16 09:26:55 1996
Date: Fri, 16 Aug 1996 09:14:32 -0400
To: kerberos@MIT.EDU
From: mamros@ftp.com (Shawn Mamros)
Reply-To: mamros@ftp.com
hartmans@MIT.EDU (Sam Hartman) wrote:
>>>>>> "Phi" == Phi H Truong <orion@iastate.edu> writes:
>
> Phi> Don't know about company but our client machines got the
> Phi> srvtab with minimal human intervention. Actually I think I
> Phi> know the company, DEC or rather the product DECAthena (aka
> Phi> MIT Athena on steroid). Their way required the master key
> Phi> and admin key which was kind of rediculous when one thought
> Phi> of setting up lots of machines all over campus. We just
> Phi> entered the machine into our database (we used moira service,
> Phi> an Athenaism) and user (be it may professor, grad student,
> Phi> ...etc) plug in the machine, perform remote installation,
> Phi> answer two or three questions, go get some coffee, come back
> Phi> in 15 mins and ready to login. Ok, so we are a bit lazy when
> Phi> it comes to walking around campus.
>
> How did you securely transport the srvtab from the Kerberos
>server to the machine?
Well, I think I can answer that one, because if Phi is talking about
what I think he's talking about, then I'm the one who wote the remote
srvtab generation program in question... :-)
It's been a few years, but I think I remember most of the important
details: it made use of the kadmin protocol (hence the need for an
admin key) to obtain the key of the service principal (which was added
to the database beforehand) in question. There was a little-used opcode
in the V4 kadmin protocol that allowed one to do this; however, the
kadmind server (either by design or accident, not sure which) left
the service key encrypted with the master key. Thus, one needed the
Kerberos master key on the "client" side to decrypt the service key
before it was placed in the srvtab file.
Obviously, this restriction meant that one had to be a sufficiently
privileged sysadmin to run this install procedure. But, it should
be pointed out that this install procedure was only needed for
"stateful" machines, such as {KNFS, Zephyr, etc.} servers. For
"stateless" clients which did not support inbound network services
(just like the public cluster machines at MIT, I believe), no srvtab
file was needed, so "anyone" could install those.
It may not have been the best, prettiest, or even the most secure way
of installing srvtab files. But it had the advantage of working with
the V4 kadmin protocol as-was(*), met the requirements that we had
to meet, and was at least somewhat more secure than the method we had
been using previously for installing srvtabs (which wasn't my idea,
and which I'd be far too embarrassed to admit to - it was sooooo insecure
it wasn't even funny).
(*) I believe that the last patchlevel of V4 from MIT (patchlevel 10?),
which postdated the work I did, had a better way of doing this that
didn't require typing in the master password. But, if I remember right,
there was an additional opcode added to the kadmin protocol to do it,
or else their program actually generated the key and added it to the
database via kadmin, then built in into the srvtab.
-Shawn Mamros (former DECathena engineer)
E-mail to: mamros@ftp.com
