confusion in ank. - Kerberos

This is a discussion on confusion in ank. - Kerberos ; hi all, While I was playing with kerberos, I came across this issue. I created a principal 'bug' with the ank command like this: kadmin: ank -pwexpire "5/5/2007 12:0:0 GMT" -randkey bug ; it successfully created the principal but when ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: confusion in ank.

  1. confusion in ank.

    hi all,

    While I was playing with kerberos, I came across this issue.
    I created a principal 'bug' with the ank command like this:
    kadmin: ank -pwexpire "5/5/2007 12:0:0 GMT" -randkey bug
    ; it successfully created the principal but when I tried to see
    this entry it is showing me
    .....
    Password expiration date: [none]
    .....

    My questions:
    1. Is this an expected behavior?
    2. Is this happening because of '-randkey'? (since not specifying -randkey
    gave proper Password expiration date.)

    Many thanks in advance!

    Regards,
    Rathor

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


  2. Re: confusion in ank.

    Vipin Rathor writes:

    > While I was playing with kerberos, I came across this issue.
    > I created a principal 'bug' with the ank command like this:
    > kadmin: ank -pwexpire "5/5/2007 12:0:0 GMT" -randkey bug
    > ; it successfully created the principal but when I tried to see
    > this entry it is showing me
    > ....
    > Password expiration date: [none]
    > ....


    > My questions:
    > 1. Is this an expected behavior?
    > 2. Is this happening because of '-randkey'? (since not specifying -randkey
    > gave proper Password expiration date.)


    It probably is happening because of -randkey, although I think that's a
    bug.

    -randkey is implemented under the hood by creating a disabled account with
    a fixed password, changing its password to a random password, and then
    enabling the account. I bet that the password expiration is applied to
    the initial account creation and then cleared immediately by the password
    change to the random password.

    (This is why, when you create an account with -randkey, it immediately
    ends up with a kvno of 2 instead of 1.)

    --
    Russ Allbery (rra@stanford.edu)
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: confusion in ank.

    hi all,

    >> My questions:
    >> 1. Is this an expected behavior?
    >> 2. Is this happening because of '-randkey'? (since not specifying

    -randkey
    >> gave proper Password expiration date.)


    >It probably is happening because of -randkey, although I think that's a
    >bug.


    If Russ thinks that it's a bug, can somebody please tell me that what should
    be the
    correct behavior? and Where can I get this(in RFC...I guess???)

    >-randkey is implemented under the hood by creating a disabled account with
    >a fixed password, changing its password to a random password, and then
    >enabling the account. I bet that the password expiration is applied to
    >the initial account creation and then cleared immediately by the password
    >change to the random password.


    >(This is why, when you create an account with -randkey, it immediately
    >ends up with a kvno of 2 instead of 1.)

    Is it okey to for a random key principal to have a kvno 2 for nothing?(or is
    there something
    to do with this?)

    Russ, thanks for reply. I really appreciete that.

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


  4. Re: confusion in ank.

    On 4/23/07, Vipin Rathor wrote:
    > hi all,
    >
    > >> My questions:
    > >> 1. Is this an expected behavior?
    > >> 2. Is this happening because of '-randkey'? (since not specifying

    > -randkey
    > >> gave proper Password expiration date.)

    >
    > >It probably is happening because of -randkey, although I think that's a
    > >bug.

    >
    > If Russ thinks that it's a bug, can somebody please tell me that what should
    > be the
    > correct behavior? and Where can I get this(in RFC...I guess???)


    I haven't looked at the code, but I think this is probably done on
    purpose and is not a bug. When you create a keytab, you create a new
    random key for the account. There is no password associated with that
    key, and there is no longer a reason for a password expiration.

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


  5. Re: confusion in ank.

    On Mon, Apr 23, 2007 at 11:27:22AM -0400, Kevin Coffman wrote:
    > I haven't looked at the code, but I think this is probably done on
    > purpose and is not a bug. When you create a keytab, you create a new
    > random key for the account. There is no password associated with that
    > key, and there is no longer a reason for a password expiration.


    Password quality policies certainly shouldn't apply to randomly-
    generated keys, but that does not mean that there cannot be a key
    expiration policy.
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  6. Re: confusion in ank.

    On 4/23/07, Nicolas Williams wrote:
    > On Mon, Apr 23, 2007 at 11:27:22AM -0400, Kevin Coffman wrote:
    > > I haven't looked at the code, but I think this is probably done on
    > > purpose and is not a bug. When you create a keytab, you create a new
    > > random key for the account. There is no password associated with that
    > > key, and there is no longer a reason for a password expiration.

    >
    > Password quality policies certainly shouldn't apply to randomly-
    > generated keys, but that does not mean that there cannot be a key
    > expiration policy.


    OK, I looked at the code.

    If the principal has a policy, and the policy has a pw_max_life, the
    password expiration is updated. If the principal has no policy, then
    the password expiration is reset. So I'm assuming this principal is
    not associated with a policy, or the policy doesn't have a
    pw_max_life.

    >From src/lib/kadm5/srv/svr_principal.c: kadm5_randkey_principal_3():


    if ((adb.aux_attributes & KADM5_POLICY)) {
    if ((ret = kadm5_get_policy(handle->lhandle, adb.policy,
    &pol)) != KADM5_OK)
    goto done;
    have_pol = 1;

    ret = krb5_dbe_lookup_last_pwd_change(handle->context,
    &kdb, &last_pwd);
    if (ret)
    goto done;

    #if 0
    /*
    * The spec says this check is overridden if the caller has
    * modify privilege. The admin server therefore makes this
    * check itself (in chpass_principal_wrapper, misc.c). A
    * local caller implicitly has all authorization bits.
    */
    if((now - last_pwd) < pol.pw_min_life &&
    !(kdb.attributes & KRB5_KDB_REQUIRES_PWCHANGE)) {
    ret = KADM5_PASS_TOOSOON;
    goto done;
    }
    #endif

    if(pol.pw_history_num > 1) {
    if(adb.admin_history_kvno != hist_kvno) {
    ret = KADM5_BAD_HIST_KEY;
    goto done;
    }

    ret = check_pw_reuse(handle->context, &hist_key,
    kdb.n_key_data, kdb.key_data,
    adb.old_key_len, adb.old_keys);
    if (ret)
    goto done;
    }
    if (pol.pw_max_life)
    kdb.pw_expiration = now + pol.pw_max_life;
    else
    kdb.pw_expiration = 0;
    } else {
    kdb.pw_expiration = 0;
    }
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  7. Re: confusion in ank.

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

    On Mon 2007-04-23 11:52:36 -0400, Nicolas Williams wrote:

    > Password quality policies certainly shouldn't apply to randomly-
    > generated keys, but that does not mean that there cannot be a key
    > expiration policy.


    i agree that it's worthwhile to support expiration policy for
    randomly-generated keys. One could even argue for iteratively
    applying password-quality policies to randomy-generated keys from a
    pragmatic approach:

    In the unlikely event the randomly-generated key happens to be
    guessable by common tools (dictionary attacks, limited character
    classes, etc), it's probably worth generating a new random key. While
    this reduces the overall space of possible random keys, it does keep
    the random keys out of the (admittedly tiny) space regularly probed by
    the most common brute force attackers.

    --dkg
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.6 (GNU/Linux)
    Comment: Processed by Mailcrypt 3.5.8+

    iD8DBQFGLOe3iXTlFKVLY2URAmTRAJ9eiJ2qnt5N22NhhMLE+8 jQeD9U+QCffrXU
    FuRYHsQwMjmsxx+7nDs3PxU=
    =MNUn
    -----END PGP SIGNATURE-----
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  8. Re: confusion in ank.

    On Apr 23, 2007, at 13:07, Daniel Kahn Gillmor wrote:
    > i agree that it's worthwhile to support expiration policy for
    > randomly-generated keys. One could even argue for iteratively
    > applying password-quality policies to randomy-generated keys from a
    > pragmatic approach:
    >
    > In the unlikely event the randomly-generated key happens to be
    > guessable by common tools (dictionary attacks, limited character
    > classes, etc), it's probably worth generating a new random key. While
    > this reduces the overall space of possible random keys, it does keep
    > the random keys out of the (admittedly tiny) space regularly probed by
    > the most common brute force attackers.


    Because of how salt strings are factored into the key generation
    process (except in the case of RC4), a dictionary attack based on
    passwords is going to have to incorporate specific salt strings --
    which in normal cases means incorporating the principal name in the
    attack. Which means an attacker would presumably know when they're
    attacking a service key that's likely to have been randomly
    generated, versus a user's password-derived key. (And Microsoft's
    server passwords should be long enough and random enough to evade
    dictionary attacks.)

    (Insert plug for my "randomize salt on password change" idea here,
    which would prohibit even building the dictionary of keys without
    talking to the KDC first to get the salt string.)

    I think an attacker continuing to use a dictionary in that case would
    be wasting cycles compared with simply trying 00...000, 00...001,
    etc. Should we also eliminate all the keys that are likely to be hit
    early in a simple sequential brute-force probe? That sort of thing
    simply changes where the clueful attacker starts his attack, and
    that's the attacker I'd be more concerned about.

    The salt-less RC4 cryptosystem kind of puts a crimp in this, in that
    you could use a dictionary of generated keys to try decrypting a
    bunch of messages, without paying attention to whether the messages
    were encrypted in a user's key or a randomized service key. Except,
    the distinction between uses of the initiator's key and the
    acceptor's key and a session key is generally pretty easy to make;
    only when a service is initiating authentication (getting tickets so
    it can authenticate to another service) would I expect randomized
    principal keys to come under dictionary attack. Even so, it's not a
    case I'm going to lose any sleep over; 2**128 is a pretty big
    number. If we were generating password strings randomly, then maybe,
    but not while we're randomly generating the bits of the key themselves.

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


  9. Re: confusion in ank.

    Daniel Kahn Gillmor writes:

    > i agree that it's worthwhile to support expiration policy for
    > randomly-generated keys.


    I do too. Audits often require that one rekey a system on a periodic
    basis, and being able to enforce that with expiration policy is useful.

    --
    Russ Allbery (rra@stanford.edu)
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread