Ticket History #333: How are /etc/srvtab files created now?

From ppomes@Qualcomm.com Mon Jan 6 14:24:29 1997
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id OAA24839 for <bugs@RT-11.MIT.EDU>; Mon, 6 Jan 1997 14:24:28 -0500
Received: from zelkova.qualcomm.com by MIT.EDU with SMTP
id AA14745; Mon, 6 Jan 97 14:24:27 EST
Received: (from ppomes@localhost)
by zelkova.qualcomm.com (8.8.4/8.8.4)
id LAA02260; Mon, 6 Jan 1997 11:24:14 -0800 (PST)
Message-Id: <199701061924.LAA02260@zelkova.qualcomm.com>
Date: Mon, 6 Jan 1997 11:24:14 -0800 (PST)
From: Paul Pomes <ppomes@Qualcomm.com>
Reply-To: ppomes@Qualcomm.com
To: krb5-bugs@MIT.EDU
Subject: How are new /etc/srvtab files created
X-Send-Pr-Version: 3.99

QUALCOMM, Inc.
6455 Lusk Blvd
San Diego, CA 92121-2779
Sparc 20/MP, Solaris 2.4, SparcWorks 3.01
System: SunOS zelkova 5.4 Generic_101945-27 sun4m sparc


Since many Macs are still using NCSA telnet with kconfig it's
important that we be able to create /etc/srvtab files so that
telnetd can support v4 clients. How can kadmin be used to
create /etc/srvtab files?
By searching docs and code, there is no way to do a xst4 anymore.
Needed.

From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krb5-bugs@MIT.EDU, ppomes@Qualcomm.com
Cc: Subject: Re: krb5-admin/333: How are new /etc/srvtab files created
Date: Mon, 6 Jan 1997 14:43:37 -0500

Use kadmin to create a V5 srvtab, then use the ktutil program
(kadmin/ktutil) to convert it to V4 format.

Barry


From: Paul Pomes <ppomes@Qualcomm.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: krb5-bugs@MIT.EDU, bjaspan@MIT.EDU
Subject: Re: krb5-admin/333: How are new /etc/srvtab files created
Date: Mon, 06 Jan 1997 12:34:23 -0800

The compatibility code isn't used within telnet at least. If the
/etc/srvtab file is absent then telnetd will not offer the KERBEROS_V4
option.

kadmin/ktutil might work, however kadmin saves the key as a des-cbc-crc:normal
enctype whereas /etc/srvtab needs des-cbc-crc:v4. I've tried reading in
a v5srvtab and writing out a srvtab with ktutil, however that form won't
work.

Entries added in previous versions show the v4 enctype:

Principal: rcmd/vega1@GLOBALSTAR.COM
Expiration date: Wed Dec 30 16:00:00 PST 2037
Last password change: [never]
Password expiration date: [none]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Fri Mar 22 08:23:33 PST 1996 (K/M@GLOBALSTAR.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 2, DES cbc mode with CRC-32, Version 4
Attributes:
Policy: [none]

New principals behave quite differently after any of randkey or xst is applied
to the entry:

kadmin: ank rcmd/zelkova@GLOBALSTAR.COM
Enter password for principal "rcmd/zelkova@GLOBALSTAR.COM":
Re-enter password for principal "rcmd/zelkova@GLOBALSTAR.COM":
Principal "rcmd/zelkova@GLOBALSTAR.COM" created.
kadmin: getprinc rcmd/zelkova@GLOBALSTAR.COM
Principal: rcmd/zelkova@GLOBALSTAR.COM
Expiration date: [never]
Last password change: Mon Jan 06 12:19:19 PST 1997
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Mon Jan 06 12:19:19 PST 1997 (ppomes/admin@GLOBALSTAR.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 5
Key: vno 1, DES cbc mode with CRC-32, no salt
Key: vno 1, DES cbc mode with CRC-32, Version 4
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
Attributes:
Policy: [none]

Watch what happens after a "xst rcmd/zelkova@GLOBALSTAR.COM" is done:

kadmin: xst -k /tmp/foo rcmd/zelkova@GLOBALSTAR.COM
Entry for principal rcmd/zelkova@GLOBALSTAR.COM with kvno 2, encryption type
DES-CBC-CRC added to keytab WRFILE:/tmp/foo.
kadmin: getprinc rcmd/zelkova@GLOBALSTAR.COM
Principal: rcmd/zelkova@GLOBALSTAR.COM
Expiration date: [never]
Last password change: Mon Jan 06 12:20:56 PST 1997
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Mon Jan 06 12:20:56 PST 1997 (ppomes/admin@GLOBALSTAR.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 2, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]

After rcmd/zelkova@GLOBALSTAR.COM is deleted, "ank -randkey rcmd/zelkova@
GLOBALSTAR.COM" is seen to have similar results:

kadmin: ank -randkey rcmd/zelkova@GLOBALSTAR.COM
Principal "rcmd/zelkova@GLOBALSTAR.COM" created.
kadmin: getprinc rcmd/zelkova@GLOBALSTAR.COM
Principal: rcmd/zelkova@GLOBALSTAR.COM
Expiration date: [never]
Last password change: Mon Jan 06 12:23:42 PST 1997
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Mon Jan 06 12:23:42 PST 1997 (ppomes/admin@GLOBALSTAR.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 2, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]

So far as I can tell, the new entries are not even available to V4 processes
when all the keys are present. hydra1 is an old entry and findable, zelkova
cannot:

Jan 6 12:25:26 draco1 krb5kdc[9955]: PROCESS_V4:APPL Request
ppomes.@GLOBALSTAR.COM on 129.46.148.32 for rcmd.hydra1

Jan 6 12:30:43 draco1 krb5kdc[9955]: PROCESS_V4:APPL Request
ppomes.@GLOBALSTAR.COM on 129.46.148.32 for rcmd.zelkova
Jan 6 12:30:43 draco1 krb5kdc[9955]: PROCESS_V4:UNKNOWN "rcmd" "zelkova"



From: Marc Horowitz <marc@cygnus.com>
To: ppomes@Qualcomm.com
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/333: How are new /etc/srvtab files created
Date: 06 Jan 1997 15:43:56 -0500

Paul Pomes <ppomes@Qualcomm.com> writes:


You can use the ktutil command to convert a v5 keytab to a v4 srvtab.

Marc

From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: Paul Pomes <ppomes@Qualcomm.com>
Cc: krb5-bugs@MIT.EDU, bjaspan@MIT.EDU
Subject: Re: krb5-admin/333: How are new /etc/srvtab files created
Date: Mon, 06 Jan 1997 15:50:02 -0500


Errr, Paul, I don't want to call you a liar, but the compatibility code
is in read_service_key(), so assuming that you used the built-in V4 code,
then it should just work. My V5 telnetds offer KERBEROS_V4 authentication
and I definately don't have /etc/srvtab's.

Now, I haven't actually _TESTED_ to see if it works or not, but it does
offer it in the option negotiation :-)

--Ken

From: Paul Pomes <ppomes@Qualcomm.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: krb5-bugs@MIT.EDU, bjaspan@MIT.EDU
Subject: Re: krb5-admin/333: How are new /etc/srvtab files created
Date: Tue, 07 Jan 1997 14:40:30 -0800

|Errr, Paul, I don't want to call you a liar, but the compatibility code
|is in read_service_key(), so assuming that you used the built-in V4 code,
|then it should just work. My V5 telnetds offer KERBEROS_V4 authentication
|and I definately don't have /etc/srvtab's.

I really don't see how that can be unless the location of the v4 srvtab file
has been reset. In libtelnet/kerberos.c is the routine

kerberos4_init(ap, server)
Authenticator *ap;
int server;
{
FILE *fp;

if (server) {
str_data[3] = TELQUAL_REPLY;
if ((fp = fopen(KEYFILE, "r")) == NULL)
return(0);
fclose(fp);
} else {
str_data[3] = TELQUAL_IS;
}
return(1);
}

where KEYFILE is defined by the krb4_srvtab entry in krb5.conf or to
/etc/srvtab by default. One place or another there has to be a srvtab
file defined before telnetd will offer KERBEROS_V4 as an option.

After some more work it's my feeling that rel 1.0 has a new problem that
wasn't in b6 with the creation of v4-compatible principles. rcmd/foo entries
created before rel 1.0 continue to work. rcmd/foo entries made afterwards
do not.

Here are the log entries and getprinc results for rcmd/andromeda (old entry)
and rcmd/cetus1 (new entry). Note that the V4_PROCESS can't even locate the
rcmd/cetus1 entry.

Jan 7 14:24:31 draco1 krb5kdc[9955]: PROCESS_V4:APPL Request ppomes.@GLOBALSTAR.COM on 129.46.148.32 for rcmd.andromeda
Jan 7 14:25:18 draco1 krb5kdc[9955]: PROCESS_V4:APPL Request ppomes.@GLOBALSTAR.COM on 129.46.148.32 for rcmd.cetus1
Jan 7 14:25:18 draco1 krb5kdc[9955]: PROCESS_V4:UNKNOWN "rcmd" "cetus1"

Principal: rcmd/andromeda@GLOBALSTAR.COM
Expiration date: Wed Dec 30 16:00:00 PST 2037
Last password change: [never]
Password expiration date: [none]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Fri Mar 22 08:23:33 PST 1996 (K/M@GLOBALSTAR.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 1
Key: vno 2, DES cbc mode with CRC-32, Version 4
Attributes:
Policy: [none]

Principal: rcmd/cetus1@GLOBALSTAR.COM
Expiration date: [never]
Last password change: Tue Jan 07 08:40:04 PST 1997
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Tue Jan 07 08:40:04 PST 1997 (ppomes/admin@GLOBALSTAR.COM)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 5
Key: vno 1, DES cbc mode with CRC-32, no salt
Key: vno 1, DES cbc mode with CRC-32, Version 4
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm
Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only
Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3
Attributes:
Policy: [none]

Again if I do either of xst or 'cpw -randkey' only the CRC-32, no salt version
will be left.

Here are the two entries from a dump run

princ 38 29 1 1 0 rcmd/andromeda@GLOBALSTAR.COM 0 86400 604800 2145830400 0 0 0 0 2 23 05d452314b2f4d40474c4f42414c535441522e434f4d00 2 2 1 26 0800dd210e866151970982f441b9487dc95a535191e0adfbc977 1 0 -1 -1;


rcmd/cetus1 after a 'cpw -randkey'

princ 38 26 2 1 0 rcmd/cetus1@GLOBALSTAR.COM 0 36000 604800 0 0 0 0 0 2 32 a4cfd23270706f6d65732f61646d696e40474c4f42414c535441522e434f4d00 1 4 a4cfd232 1 2 1 26 080056729d1b7d4068bf1b0899f49495eb61577b059bb065a6ee -1;

From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: Paul Pomes <ppomes@qualcomm.com>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/333: How are new /etc/srvtab files created
Date: Tue, 07 Jan 1997 23:59:58 -0500


Sorry about that; I didn't see that bit of code!

(But it would seem to me that you could get around that by just adding
the appropriate entry to krb5.conf so that the srvtab just points to
an existing file, since the v4 routines will apparantly look at the V5
keytab. But I don't want to put my foot in my mouth AGAIN, so I won't
claim that this actually works :-) ).


Do you have the "supported_enctypes" line in your kdc.conf? The OV admin
server will only create new keys with those enctypes listed in that profile
line. Mine says:

supported_enctypes = des-cbc-crc:normal des:v4

--Ken

From: Paul Pomes <ppomes@Qualcomm.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/333: How are new /etc/srvtab files created
Date: Wed, 08 Jan 1997 06:33:10 -0800

The keys are created with multiple types as shown in the previous message.
The three problems are that 1) -randkey argument to cpw or ank deletes the
extra keys, 2) xst also deletes the extra keys, 3) new principals *with
instances* created by kadmin are not visible to V4 requests. New principals
with null instances work just fine with V4. Old principals with non-null
instances created with kdb5_edit also work with V4.

|(But it would seem to me that you could get around that by just adding
|the appropriate entry to krb5.conf so that the srvtab just points to
|an existing file, since the v4 routines will apparantly look at the V5
|keytab. But I don't want to put my foot in my mouth AGAIN, so I won't
|claim that this actually works :-) ).

I've tried pointing krb4_srvtab at /etc/krb5.srvtab with no joy. The
client runs up against problem #3 above and fails to obtain the rcmd/<hostname>
ticket from the KDC. That suggestion *does* work for hosts that had their
rcmd/<hostname> entries created by kdb5_edit in previous releases.

Doesn't this last bit imply that the key for rcmd/<hostname> must be the
same as that for host/<hostname>.<domain>?

/pbp


From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: Paul Pomes <ppomes@qualcomm.com>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/333: How are new /etc/srvtab files created
Date: Wed, 08 Jan 1997 11:18:46 -0500


Odd; I'm using the beta 7 OV admin server, but that definately isn't the
behavior I'm seeing. Oh, wait, I just realized; the keys I _do_ use for
V4 stuff have don't have V4 keys associated with them! Of course, now that
I think about it, it really shouldn't matter; you aren't ever converting
strings to keys, since the raw key is stored in the keytab, so it shouldn't
really matter if there is a V4 salt for that key or not, right?


I'm not sure; I am currently only using V4 for POP, and my instance is a
FQDN. You know, it's my impression that the only thing you actually need
a "host/<hostname>" principal, and the V5 KDC will do the right translation
magic needed. Certainly I remember seeing the translation code in either
the KDC or the krb5 library ...

--Ken

From: Paul Pomes <ppomes@Qualcomm.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/333: How are new /etc/srvtab files created
Date: Wed, 08 Jan 1997 10:20:11 -0800

At 11:18 EST on Wednesday, January 8, 1997, Ken Hornstein wrote:

|>The keys are created with multiple types as shown in the previous message.
|>The three problems are that 1) -randkey argument to cpw or ank deletes the
|>extra keys, 2) xst also deletes the extra keys, 3) new principals *with
|>instances* created by kadmin are not visible to V4 requests. New principals
|>with null instances work just fine with V4. Old principals with non-null
|>instances created with kdb5_edit also work with V4.

I've determined the problem to be one that has bitten me before, incorrect
principal conversion. The v4_instance_convert stanza had not been updated
with the new machine cetus1.glab.globalstar.com for the realm GLOBALSTAR.COM.
A v4 query for rcmd.cetus1 was being converted to

host/cetus1.globalstar.com@GLOBALSTAR.COM instead of the correct form of
host/cetus1.glab.globalstar.com@GLOBALSTAR.COM

The new default_domain specification is most welcome now.

What I would urge to make this translation clearer is to change the logging.
What the KDC couldn't find wasn't the v4 'rcmd.cetus1@GLOBALSTAR.COM'
principal, but the v5 'host/cetus1.globalstar.com@GLOBALSTAR.COM' principal.
If the latter had been logged it would have a lot more obvious what was
going on and what I needed to do to fix it.

For the record my steps were

On the KDC hosts I editted /etc/krb5.conf to replace the v4_instance_convert
stanza with a "default_domain = GLAB.GLOBALSTAR.COM" entry.

On the target machines, e.g., cetus1, I used kadmin with the command
'xst -k /etc/krb5.keytab host/cetus1.glab.globalstar.com ftp/cetus1.glab.globalstar.com'

This was followed by ktutil:
rkt /etc/krb5.keytab
wst /etc/srvtab

Thank you all for the help and feedback.

/pbp

State-Changed-From-To: open-closed
State-Changed-By: tlyu
State-Changed-When: Sat Jan 25 22:34:35 1997
State-Changed-Why:

problem solved; user needed clarification