[3791] in Kerberos-V5-bugs

home help back first fref pref prev next nref lref last post

Re: [krbdev.mit.edu #1324] cannot reproduce

daemon@ATHENA.MIT.EDU (Tom Yu via RT)
Fri Jan 24 21:18:19 2003

Date: Fri, 24 Jan 2003 21:17:59 -0500 (EST)
Mail-Followup-To: rt@krbdev.mit.edu
Message-Id: <rt-1324-4016.16.5551192358085@krbdev.mit.edu>
In-Reply-To: <rt-1324@krbdev.mit.edu>
From: "Tom Yu via RT" <rt-comment@krbdev.mit.edu>
Mail-Copies-To: never
To: jered@convivian.com
cc: krb5-prs@mit.edu
Reply-To: rt-comment@krbdev.mit.edu
Errors-To: krb5-bugs-bounces@mit.edu

>>>>> "Jered" == Jered Floyd via RT <rt-comment@krbdev.mit.edu> writes:

Jered> Rather, when I type the principal's password correctly, both kinit
Jered> and saslauthd succeed.  When I give an incorrect password, both
Jered> log the error that I reported.

Jered> Arguably, the error message is not particularly good at indicating
Jered> that the password is incorrect.

I agree.  Inspection of the code in verify_enc_timestamp() reveals
that if a key is found that matches the enctype in the encrypted
timestamp preauth, and the decryption fails, the loop continues.  This
is presumably because the encrypted timestamp preauth doesn't carry
salt information or any other information that would permit the KDC to
correctly choose between multiple keys having the same enctype but
having different salts.

Probably the correct thing to do is to set a flag when decryption is
attempted, so that if the loop exits with an error of NO_MATCHING_KEY
and the flag is set, the KDC will correctly report a bad password.

---Tom

_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
http://mailman.mit.edu/mailman/listinfo/krb5-bugs

home help back first fref pref prev next nref lref last post