Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) by krbdev.mit.edu (8.9.3) with ESMTP id VAA20948; Fri, 24 Jan 2003 21:17:57 -0500 (EST) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.9.3) id VAA10793; Fri, 24 Jan 2003 21:17:57 -0500 (EST) To: rt@krbdev.mit.edu Subject: Re: [krbdev.mit.edu #1324] cannot reproduce References: From: Tom Yu Date: Fri, 24 Jan 2003 21:17:57 -0500 In-Reply-To: ("Jered Floyd via RT"'s message of "Fri, 24 Jan 2003 19:51:44 -0500 (EST)") Message-Id: Lines: 22 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 1019 >>>>> "Jered" == Jered Floyd via RT 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