Ticket History #879: krb4 services will not properly function if there are more than one des3 key in the keytab

From epeisach@MIT.EDU Tue Aug 22 10:05:07 2000
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28])
by rt-11.mit.edu (8.9.3/8.9.3) with SMTP id KAA11719
for <bugs@RT-11.MIT.EDU>; Tue, 22 Aug 2000 10:05:06 -0400 (EDT)
Received: from KANGAROO.MIT.EDU by MIT.EDU with SMTP
id AA11480; Tue, 22 Aug 00 10:05:22 EDT
Received: by kangaroo.mit.edu (5.65v3.2/1.1.10.5/14Jun00-0334PM)
id AA10809; Tue, 22 Aug 2000 10:05:04 -0400
Message-Id: <10008221405.AA10809@kangaroo.mit.edu>
Date: Tue, 22 Aug 2000 10:05:04 -0400
From: epeisach@MIT.EDU
Reply-To: epeisach@MIT.EDU
To: krb5-bugs@MIT.EDU
Cc:
Subject: krb4 services will not properly function if there are more than one des3 key in the keytab
X-Send-Pr-Version: 3.99

MIT
Dec alpha.
System: OSF1 kangaroo.mit.edu V4.0 464 alpha
Machine: alpha
When dealing with des3 keys - the kdc knows that
for kerberos 4 applications, a hardcoded list of keys are searched for
in a specific order. (see kdc/kerberos_v4.c about line 487).

The kerberos 4 library can deal with reading a keytab when looking for services
but will return the first key in the keytab. (lib/krb4/rd_svc_key.c).
Potentially, if someone enables multiple des3 keytypes and extracts a keytab,
the v4 application will not function.

I also believe, but have not verified that the order of keys in the
keytab matter - i.e. if a des key is first, then someone requesting
des3 services will fail.

Probably a hardcoded search order will be required as well...
This requires further thought.

Ezra