Ticket History #1324: kdc logs bogus error for enc timestamp wrong passwd

Somewhere between krb5-1.2.3 and krb5-1.2.7, Cyrus saslauthd using
Kerberos 5 for password verification (yes, I know the reasons that I
shouldn't do this; it's a fallback for SSL users). The kdc logs
the following:

Jan 16 00:25:38 noisybox krb5kdc[16932]: AS_REQ (3 etypes {16 1 3}) 140.239.226.142(88): NEEDED_PREAUTH: jered@CONVIVIAN.COM for krbtgt/CONVIVIAN.COM@CONVIVIAN.COM, Additional pre-authentication required
Jan 16 00:25:38 noisybox krb5kdc[16932]: preauth (timestamp) verify failure: No matching key in entry
Jan 16 00:25:38 noisybox krb5kdc[16932]: AS_REQ (3 etypes {16 1 3}) 140.239.226.142(88): PREAUTH_FAILED: jered@CONVIVIAN.COM for krbtgt/CONVIVIAN.COM@CONVIVIAN.COM, Preauthentication failed
Jan 16 00:25:38 noisybox krb5kdc[16932]: DISPATCH: repeated (retransmitted?) request from 140.239.226.142 port 88, resending previous response
Jan 16 00:25:38 noisybox krb5kdc[16932]: preauth (timestamp) verify failure: No matching key in entry
Jan 16 00:25:38 noisybox krb5kdc[16932]: AS_REQ (3 etypes {16 1 3}) 140.239.226.142(88): PREAUTH_FAILED: jered@CONVIVIAN.COM for krbtgt/CONVIVIAN.COM@CONVIVIAN.COM, Preauthentication failed
Jan 16 00:25:38 noisybox saslauthd[13564]: auth_krb5: krb5_get_init_creds_password

This appears to be identical to newly-occuring problems for Windows client
users (currently unresolved?) as documented at:
http://mailman.mit.edu/pipermail/kerberos/2002-April/000617.html
http://www.mail-archive.com/kerberos@mit.edu/msg02724.html
http://www.mail-archive.com/kerberos@mit.edu/msg02783.html

kinit functions normally. kinit and saslauthd use nearly identical
calls to krb5_get_init_creds_password:

kinit:
code = krb5_get_init_creds_password(k5->ctx, &my_creds, k5->me,
0, kinit_prompter, 0,
opts->starttime,
opts->service_name,
&options);

saslauthd:
if (krb5_get_init_creds_password(context, &creds,
auth_user, password, NULL, NULL,
0, NULL, &opts)) {


I see a potential culprit. Between 1.2.3 and 1.2.7, there is a
single change to kdc_preauth.c:
--- krb5-1.2.3/src/kdc/kdc_preauth.c Wed Jan 9 17:27:28 2002
+++ krb5-1.2.7/src/kdc/kdc_preauth.c Mon Aug 12 18:50:02 2002
@@ -533,7 +533,7 @@
while (1) {
retval = krb5_dbe_search_enctype(context, client, &start, -1,
-1, 0, &client_key);
- if (retval == ENOENT)
+ if (retval == KRB5_KDB_NO_MATCHING_KEY)
break;
if (retval)
goto cleanup;

with the ChangeLog:
2002-08-12 Sam Hartman <hartmans@mit.edu>

* kdc_preauth.c (get_etype_info): We get KRB5_KDB_NO_MATCHING_KEY
not ENOENT; per 5.27 of kdb_xdr.c.
[pullup from trunk]


HOWEVER, between the two releases, the only change in kdb_xdr.c is:
--- krb5-1.2.3/src/lib/kdb/kdb_xdr.c Wed Jan 9 17:27:49 2002
+++ krb5-1.2.7/src/lib/kdb/kdb_xdr.c Mon Aug 12 18:48:35 2002
@@ -726,6 +726,7 @@
krb5_key_data *datap;
krb5_error_code ret;

+ ret = 0;
if (kvno == -1 && stype == -1 && ktype == -1)
kvno = 0;

2002-08-12 Sam Hartman <hartmans@mit.edu>

* kdb_xdr.c (krb5_dbe_search_enctype): Initialize ret to 0; thanks
to Lubos Kejzlar <kejzlar@civ.zcu.cz>
[pullup from trunk]


This patch does not seem to correspond to the change in kdc_preauth.c.
I am unable to usefully debug this further. What was the purpose of the
above change to kdc_preauth?

--Jered

"Sam Hartman via RT" <rt-comment@krbdev.mit.edu> writes:


I'm going to look at this further later in the week; I'll get
back to you.

Can you tell me what is the meaning of the error the KDC is returning?
That might be helpful.

--Jered

"Sam Hartman via RT" <rt-comment@krbdev.mit.edu> writes:


I don't believe so. Given that my mother hasn't complained about not
being able to check her mail, I'm assuming that hers still works.
"getprinc" shows the same set of keys as with my principal.

When I have a free moment, I will create a new principal and try to
reproduce.

--Jered

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

pullup from trunk


To generate a diff of this commit:



cvs diff -r5.251.2.1 -r5.251.2.2 krb5/src/kdc/ChangeLog
cvs diff -r5.35 -r5.35.2.1 krb5/src/kdc/kdc_preauth.c