Problems with krb5_get_in_tkt()

[Sam Hartman]

>>>>> "Barry" == Barry Jaspan <bjaspan at MIT.EDU> writes:

Hi.  I'll start out by saying that you should not be using
krb5_get_in_tkt because doing so will not work with AES or any newer
enctypes.  There's not really a good way to get
krb5_get_in_tkt_with_skey functionality without using krb5_get_in_tkt.
The right way to handle this is probably to implement a memory keytab
and then use that to get tickets.  But this problem hasn't come up
often enough to solve.




    Barry> - How is krb5_get_in_tkt_with_skey() supposed to behave?
    Barry> The api spec seems out of date and does not address this
    Barry> topic.  It seems pretty intuitive to me that it ought to
    Barry> work if the key's enctype is either listed anywhere in
    Barry> krb5.conf's default_tkt_enctypes or listed anywhere in the
    Barry> passed-in ktypes array.  Otherwise, why bother having a
    Barry> default array instead of a single default value, and why
    Barry> bother accepting an input array instead of a single input
    Barry> value?

I actually can't think of a correct way of implementing
krb5_get_in_tkt_with_skey.  The problem is that the ktypes array
controls two things.  First, it controls the set of long-term keys
that the KDC may use.  The KDC may encrypt the reply in any of the
user's keys that happens to have an enctype listed in ktypes.  Second,
it controls the list of session key enctypes the client claims to
support.

So, you want to have as broad of a list of ktypes as possible to
maximize the chance that you and the krbtgt service both support some
common enctype for session keys.

But you also want to have a narrow  list containing only the one
enctype you actually support for the reply key.

The easiest fix is probably to force krb5_get_in_tkt_with_skey to only
put the enctype of the keyblock it has into the  ktypes array.  This
will fail if that enctype is not  supported for session key enctypes.

    Barry> - Why does 1.3.1 use a hard-coded array of enctypes instead
    Barry> of the default_tkt_enctypes variable?  With 1.2.8, you
    Barry> could at least make applications that call _with_skey with
    Barry> a NULL ktypes work with DES_CBC_CRC keys by setting
    Barry> default_tkt_enctypes = des-cbc-crc, because then it would
    Barry> be the first enctype tried.  With 1.3.1, that doesn't work,
    Barry> so the applications must be fixed and recompiled.

Because krb5_get_in_tkt cannot work with any "new enctypes" under the
definition of Kerberos Clarifications--any enctype for which
etype_info2 support is required.  Since krb5_get_in_tkt_with_password
and krb5_get_in_tkt_with_keytab no longer call krb5_get_in_tkt, twe
didn't feel a new configuration parameter was desirable.

    Barry> - Why does krb5_obtain_padata() bail if the key_proc fails
    Barry> on
    request-> ktype[0]?  It has an array of enctypes; shouldn't it try
    request-> them
    Barry> all before giving up?

This is probably a bug.  

    Barry> - It seems like 1.2.8's default_tkt_enctypes or 1.3.1's
    Barry> hard-coded enctypes list is being used where
    Barry> permitted_enctypes ought to be used instead.  Passed-in
    Barry> enctypes not listed in the default list are discarded; that
    Barry> means the enctype is "not permitted," not that it is "not
    Barry> in the default list."

No, I think the problem is actually that ktypes is not fully
overriding the supplied list.  In the case of the 1.3.1 codebase this
is no longer a bug, because you need to make sure that krb5_get_in_tkt
never offers an enctype it cannot handle the preauth for.

    Barry> - skey_keyproc copies its input keyblock and then checks
    Barry> whether the copy's enctype matches the requested enctype;
    Barry> if not, it frees the copy and fails.  I'm unaware of a
    Barry> reason for it not to check the enctype match first and not
    Barry> copy the key at all if it does not match.

Nor am I.  The behavior is correct but not optimal.