[31482] in Kerberos
Re: addprinc -randkey broken in 1.7?
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Sep 16 23:29:36 2009
From: Greg Hudson <ghudson@mit.edu>
To: Mike Friedman <mikef@berkeley.edu>
In-Reply-To: <alpine.BSF.1.10.0909161534150.15429@brillig.security.berkeley.edu>
Date: Wed, 16 Sep 2009 23:29:12 -0400
Message-Id: <1253158152.9347.37.camel@ray>
Mime-Version: 1.0
Cc: "Leonard J. Peirce" <leonard.peirce@gmail.com>,
"kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Wed, 2009-09-16 at 18:39 -0400, Mike Friedman wrote:
> OK, so maybe I'm misinterpreting the code. But the fact is that I add
> host principals with -randkey all the time with no problem. I've been
> doing this for several releases up to and including our current 1.6.3.
> We may go to 1.7 soon, so possibly something's changed there, but in the
> meantime, could someone clarify all this?
Here's the history of the temporary password used for addprinc -randkey:
* Through krb5 1.1, it was "dummy", which would fail any password
policy requiring multiple character classes or more than five
characters. This might explain Russ's experiences.
* In r9210 (October 1996), it was changed to a 255 byte string
containing all possible nonzero byte values, which would pass any policy
with a reasonable minimum length. I believe this change first hit the
field in krb5 1.2.
* In r20650 (August 2008), it was changed to 255 weakly random
lowercase letters, which would fail any policy requiring multiple
character classes. According to the commit log, this was to avoid a
problem where the RC4 string-to-key function requires the password to be
valid UTF-8. This change first hit the field in krb5 1.7.
It would be trivial to fix this regression by picking a temporary
password which is valid UTF-8 but still contains all five character
classes. I think that will be the best minimal fix for 1.7.1. For the
trunk, time permitting, I will review and apply Marcus Watts's patch,
which is a more elegant solution.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
