Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA09513; Mon, 11 Mar 96 11:55:16 EST
Received: from TERTIUS.MIT.EDU by MIT.EDU with SMTP
	id AA16757; Mon, 11 Mar 96 11:54:03 EST
Received: (from hartmans@localhost) by tertius.mit.edu (8.6.12/8.6.9) id LAA21588; Mon, 11 Mar 1996 11:54:36 -0500
Sender: hartmans@MIT.EDU
To: "Richard Basch" <basch@lehman.com>
Cc: krbdev@MIT.EDU, krb5-bugs@MIT.EDU
Subject: Re: K5 problems, esp. with k4 compatibility
References: <199603111636.LAA25335@badger.lehman.com>
From: hartmans@MIT.EDU (Sam Hartman)
Date: 11 Mar 1996 11:54:35 -0500
In-Reply-To: "Richard Basch"'s message of Mon, 11 Mar 1996 11:36:18 -0500
Message-Id: <tslzq9nd0z8.fsf@tertius.mit.edu>
Organization: Massachusetts Institute of Technology
Lines: 23

>>>>> "Richard" == Richard Basch <basch@lehman.com> writes:

    Richard> Let's just say there is quite a bit of work to do to get this to work.
    Richard> I just put V5 servers into production at Lehman, but much of our
    Richard> existing infrastructure is still V4, so the kdc is trying to run in
    Richard> compatibility mode.

    Richard> Problems seen:
    Richard> 1. DES_CBC_CRC = DES_CBC_MD5 = DES_* in terms of V4, but the key lookups only
    Richard>    do one mode, and that isn't necessarily the mode that was encoded in
    Richard>    the db, especially for non-V4 salt keys.

	Strange.  If you set things up per the default config files,
everything appears to be encoded as DES_CBC_CRC for v4 salt and
non-v4-salt keys..  It appears the code is in there to get DES_CBC_MD5
keys even if only a CRC key exists in the db.

    Richard> Richard Basch                   
    Richard> Sr. Developer/Analyst           URL: http://web.mit.edu/basch/www/home.html
    Richard> Lehman Brothers, Inc.           Email: basch@lehman.com, basch@mit.edu
    Richard> 101 Hudson St., 33rd Floor      Fax:   +1-201-524-5828
    Richard> Jersey City, NJ 07302-3988      Voice: +1-201-524-5049

