addprinc -randkey broken in 1.7?

[Leonard J. Peirce]

When running (in kadmin)

  addprinc -randkey host/host.domain

I get a complaint about the password not containing enough character
classes.  Did I miss something?  Not really a big deal since I can
just specify a password.

It used to work in 1.6.

- Leonard
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Russ Allbery]

"Leonard J. Peirce" <leonard.peirce@...> writes:

> When running (in kadmin)

>   addprinc -randkey host/host.domain

> I get a complaint about the password not containing enough character
> classes.  Did I miss something?  Not really a big deal since I can
> just specify a password.

> It used to work in 1.6.

addprinc -randkey hasn't worked for principals that have a password policy
set for somet time for me.  The way -randkey works under the hood is that
it adds the principal disabled with a fixed password (which is indeed
pretty bad except that it's very long), then randomizes the key, and then
enables the principal.

This has other strange artifacts (or at least did -- I don't know if
they've been fixed).  For example, adding a principal with -randkey and
-disallow_all_tix results in an enabled principal, igoring the
-disallow_all_tix option.

--
Russ Allbery (rra@...)             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Marcus Watts]

 Russ Allbery <rra@...> writes:

> Date:    Wed, 16 Sep 2009 13:13:13 PDT
> To:      "Leonard J. Peirce" <leonard.peirce@...>
> cc:      kerberos@...
> From:    Russ Allbery <rra@...>
> Subject: Re: addprinc -randkey broken in 1.7?
>
> "Leonard J. Peirce" <leonard.peirce@...> writes:
>
> > When running (in kadmin)
>
> >   addprinc -randkey host/host.domain
>
> > I get a complaint about the password not containing enough character
> > classes.  Did I miss something?  Not really a big deal since I can
> > just specify a password.
>
> > It used to work in 1.6.
>
> addprinc -randkey hasn't worked for principals that have a password policy
> set for somet time for me.  The way -randkey works under the hood is that
> it adds the principal disabled with a fixed password (which is indeed
> pretty bad except that it's very long), then randomizes the key, and then
> enables the principal.
>
> This has other strange artifacts (or at least did -- I don't know if
> they've been fixed).  For example, adding a principal with -randkey and
> -disallow_all_tix results in an enabled principal, igoring the
> -disallow_all_tix option.

Ah!  I have a patch for this.  I thought I had submitted this to MIT
long since, but I can't find any record that this happened.

Here's the patch:

/afs/umich.edu/user/m/d/mdw/build/krb5.15x/patches/krb5-1.6.3-ankfix1.patch

This changes the protocol to use a 'null' password to indicate randkey operation.
If a new client talks to an old server, the behavior is to fall back to the old case.
Obviously this was for 1.6.3, but it might apply to 1.7.

                                        -Marcus Watts
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Mike Friedman-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 16 Sep 2009 at 13:13 (-0700), Russ Allbery wrote:

> "Leonard J. Peirce" <leonard.peirce@...> writes:
>
>> When running (in kadmin)
>
>>   addprinc -randkey host/host.domain
>
>> I get a complaint about the password not containing enough character
>> classes.  Did I miss something?  Not really a big deal since I can just
>> specify a password.
>
>> It used to work in 1.6.
>
> addprinc -randkey hasn't worked for principals that have a password
> policy set for somet time for me.  The way -randkey works under the hood
> is that it adds the principal disabled with a fixed password (which is
> indeed pretty bad except that it's very long), then randomizes the key,
> and then enables the principal.

Russ,

I'm running 1.6.3 and don't have this problem.  In fact, looking at the
code in src/kadmin/cli/kadmin.c, it appears that when '-randkey' is used
for addprinc, the password is set initially to a 256 character string
containing all possible character values from 1 thru 255 plus a
terminating 0 (and then randomized in a separate step).  This, I would
think, should satisfy any password policy.

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?

Thanks.

_________________________________________________________________________
Mike Friedman                        Information Services & Technology
mikef@...                   2484 Shattuck Avenue
1-510-642-1410                       University of California at Berkeley
http://mikef.berkeley.edu            http://ist.berkeley.edu
_________________________________________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)

iEYEARECAAYFAkqxaSkACgkQFgKSfLOvZ1R4AQCfXFXtJkRSnWJ674knaWY9lwep
v4QAnjeWdiKCZmF3U84Jvc5hcQpLU2px
=FcNU
-----END PGP SIGNATURE-----
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Russ Allbery]

Mike Friedman <mikef@...> writes:

> I'm running 1.6.3 and don't have this problem.  In fact, looking at the
> code in src/kadmin/cli/kadmin.c, it appears that when '-randkey' is used
> for addprinc, the password is set initially to a 256 character string
> containing all possible character values from 1 thru 255 plus a
> terminating 0 (and then randomized in a separate step).  This, I would
> think, should satisfy any password policy.

Well, it's certainly rejected by our password policy.  :)  I don't know
how it interacts with the character class checking.  We have to always
clear policies on keys before using randkey.

--
Russ Allbery (rra@...)             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[ghudson-2]

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@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[Russ Allbery]

Greg Hudson <ghudson@...> writes:

> 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.

Ah, sorry, my experience is better explained by the fact that we patch the
KDC to apply cracklib checks on a password policy, and cracklib fails this
password.  Sorry about the confusion.

--
Russ Allbery (rra@...)             <http://www.eyrie.org/~eagle/>
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

[ghudson-2]

On Wed, 2009-09-16 at 23:29 -0400, Greg Hudson wrote:
> 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.

Just to close the loop on this, both the minimal fix and the long-term
fix are checked in.  We don't currently have a scheduled date for 1.7.1;
the schedule for 1.8 is March 2010 plus or minus three months.

I failed to credit Marcus Watts in my commit of the long-term fix, which
was adapted from his patch.  Apologies on that count.


________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos

On 21 sep, 19:44, Greg Hudson <ghud...@...> wrote:

> On Wed, 2009-09-16 at 23:29 -0400, Greg Hudson wrote:
> > 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.
>
> Just to close the loop on this, both the minimal fix and the long-term
> fix are checked in.  We don't currently have a scheduled date for 1.7.1;
> the schedule for 1.8 is March 2010 plus or minus three months.
>
> I failed to credit Marcus Watts in my commit of the long-term fix, which
> was adapted from his patch.  Apologies on that count.

Sorry to bring back this topic.

I had the same problem when using
addprinc -policy service -randkey host/xxx.be

My solution for -randkey to work, was to set -minclasses 1 for policy
service.
It was at 3 at the beginning and 2 didn't work aswell.

Found the solution here: http://blogg.cefit.se/

Hope this help.
Kenny

My config: apt-cache show krb5-admin-server

Package: krb5-admin-server
Priority: optional
Section: net
Installed-Size: 288
Maintainer: Sam Hartman <hartmans@...>
Architecture: i386
Source: krb5
Version: 1.7dfsg~beta3-1
Depends: debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.4), libcomerr2
(>= 1.01), libgssapi-krb5-2 (>= 1.6.dfsg.2), libgssrpc4 (>= 1.6.dfsg.
2), libk5crypto3 (>= 1.6.dfsg.2), libkadm5srv6 (>= 1.7dfsg~beta1),
libkdb5-4 (>= 1.7dfsg~alpha1), libkeyutils1, libkrb5-3 (=
1.7dfsg~beta3-1), libkrb5support0 (>= 1.7dfsg~beta2), libss2 (>=
1.01), krb5-kdc, lsb-base (>= 3.0-6)
Filename: pool/main/k/krb5/krb5-admin-server_1.7dfsg~beta3-1_i386.deb
________________________________________________
Kerberos mailing list           Kerberos@...
https://mailman.mit.edu/mailman/listinfo/kerberos