[1026] in Kerberos_V5_Development
Bugs / Proposals
daemon@ATHENA.MIT.EDU (Richard Basch)
Tue Mar 19 15:49:43 1996
Date: Tue, 19 Mar 1996 15:48:15 -0500
To: krbdev@MIT.EDU
From: "Richard Basch" <basch@lehman.com>
There are several bugs in the handling of multiple encryption types,
mostly with DES vs. DES.
1. krb5_get_in_tkt_with_keytab()
This function blindly attempts an AS_REQ without regard to the local
keys (and types) that are contained in its keytab. I suggest that we
change the AS_REQ to mask the keytypes with what is contained locally in
the keytab. The function is called with ktypes as a parameter, so we
should use that as a basis.
If ktypes is NULL, the default ktypes for AS_REQ should be used. Once
that list is obtained, the keytab should be scanned for keys of the types
and then only those types found will be used in the request to the KDC.
(By the way, there may be a logic bug... ENCTYPE_NULL = 0, whereas
ENCTYPE_UNKNOWN = 0x1ff. The code for ktype list handling will not
handle ENCTYPE_NULL as a type to be passed to the KDC; the library
routines assume a ktype list is terminated with an enctype of 0. I have
not looked up the exact meaning of ENCTYPE_NULL to see if this is
appropriate.)
Comments? If everyone agrees, I think I have it coded (I just need to
test it further).
2. kdb5_edit: v4 srvtab extraction
kdb5_edit will not extract a V4 srvtab if there are no DES-CBC-CRC keys.
It is a simple patch to correct this problem.
3. kadmind5/kadmin5: key extraction
If there are multiple encryption types being used (eg. DES3 and DES),
you cannot extract all the keys appropriately, using xst or xst4. I
have yet to debug this to determine if this is a protocol bug or an
implementation bug for the EXTRACT_KEY function. It also suffers from
the same v4 srvtab extraction problem as kdb5_edit (ie. not recognizing
DES-CBC-MD5 as a valid key).
4. kadmind5: kvno handling
I tried "crk" a couple of times, and the kvno was not incremented.
5. kadmind5: acl parsing
Neither of the following lines alone is sufficient to give me full
access; I must use both together:
basch/admin@Lehman.COM x */*@*
basch/admin@Lehman.COM x *@*
Additionally, kadmind5 does not automatically detect the acl file being
modified; the process must be restarted.
6. kadmind5: cpw & keytypes
After loading a V4 database, I notice that "kadmin" password changes
keep the same enctype/salttype. There should be a way to specify that
keys should be overridden by the database defaults or a way to specify
that kadmin should keep the same keytypes, by default. This should
probably be a flag on the db entry.
Richard Basch
Sr. Developer/Analyst URL: http://web.mit.edu/basch/www/home.html
Lehman Brothers, Inc. Email: basch@lehman.com, basch@mit.edu
101 Hudson St., 33rd Floor Fax: +1-201-524-5828
Jersey City, NJ 07302-3988 Voice: +1-201-524-5049
