Subject: Re: srvtab file
From: mdw@umich.edu
Date: Wed Sep 15 1993 - 20:16:22 EDT
A srvtab consists of one or more records of:
a null-terminated string, the "name"
a null-terminaed string, the "instance"
a null-terminated string, the "realm".
a byte, the "key version number"
8 bytes, the "key".
For netatalk, the name should always be "afpserver", the instance
should always be the name of the server as it appears in the chooser,
and the realm would of course be in all-upper case -- perhaps
something like "NORTHSTAR.DARTMOUTH.EDU" or "KIEWIT.DARTMOUTH.EDU"?
The key version# should be 0. NZ values would be used
if you were going to update the key, and wanted old service
tickets to continue to work; not real important for netatalk.
The key should be the same value that appears in the kerberos server
data base for this (name + instance) entity. Usually both the
srvtab & the kerberos entity would be created at the same time
by the same person. Sometimes, instead, the srvtab is created
later and the key extracted from the kerberos database, but this
procedure is difficult to do in a secure fashion and I do not
recommend its use.
[ useful background information on keys & kerberos:
[
[ All passwords in kerberos are converted
[ via a one way function, the "string to key" function, into
[ an 8 byte "key" and this key then used for all purposes requiring
[ proof of your identity; knowing this key is logical proof you are who
[ you claim to be. The keys would be worthless if their value
[ was known, therefore, they are never shipped over the network in
[ the clear. Normally this key would be used to get one or more
[ service tickets and then immediately discarded. In stock MIT
[ kerberos, the user's key does not depend on the realm and
[ so is the same in all realms thus presenting an obvious
[ weakness. AFS Kerberos, to further protect users in multiple
[ realms, makes the realm one of the arguments to the string to key
[ function, this makes the key different in each cell so that if
[ one cell was compromised, the user's identity in other
[ cells would still be secure.
To make srvtab's, I use "ksrvutil". Source for this can be
found in /afs/umich.edu/user/m/d/mdw/src/ksrvutil. It asks
for a password, and since we're an AFS site, I've linked this
against a modified kerberos library with the AFS string to key
function, I can type in the same random password as
I've set for the kerberos entry.
To extract the key for a kerberos entity, there is a utility
"ext_srvtab" - for which I also have source, in
/afs/umich.edu/user/m/d/mdw/src/srvtab, but I do not recommend
its use. It will not work with current releases of AFS 3.2
because, by default, the KAM_GetPassword function is not
compiled into kaserver. Even when compiled in, it only
works with the loopback interface so the program must
be run on the DB server.
An even better utility might generate a random key for the
entity and set the key in both the the kerberos database
and the srvtab at the same time. It would be less complicated
to use, and so less of a nuisance.
-Marcus Watts
UM ITD RS Umich Systems Group
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:19:52 EST