[11284] in Kerberos-V5-bugs
[krbdev.mit.edu #6622] kinit_fast fails if weak enctype is among
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Wed Jan 6 17:59:13 2010
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Greg Hudson via RT" <rt-comment@krbdev.MIT.EDU>
In-Reply-To: <rt-6622@krbdev.mit.edu>
Message-ID: <rt-6622-32068.1.47576793254963@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #6622'":;"'AdminCc of krbdev.mit.edu Ticket #6622'":;@MIT.EDU
Date: Wed, 6 Jan 2010 17:59:04 -0500 (EST)
Reply-To: rt-comment@krbdev.MIT.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
There are a few things going on here:
* When it comes time to generate the PA_ETYPE_INFO2 padata,
etype_info_helper is getting a KRB5_KDB_NO_PERMITTED_KEY error from
krb5_dbe_search_enctype and is barfing. So there is no etype
information transmitted to the client in the preauth-required error.
This is the main cause of the bug.
* This is causing the encrypted timestamp code to try to string-to-key
the password with a 0 enctype, which in turn causes it to fail and not
generate any padata.
* Then we get bug #6430 where the client loops if it doesn't manage to
generate any padata.
The appropriate fix is under discussion. The krb5_dbe_search_enctype
logic for when to return NO_PERMITTED_KEY is a little weird, and perhaps
it should not be returning that error if *start was not 0 upon entry to
the function (because that implies matching keys were previously returned).
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
