Skip Menu |
 

History Show all quoted text — Show full headers
# Tue Sep 02 14:12:08 2003 Shawn.Emery@Sun.COM (Shawn Emery) - Ticket created
Date: Tue, 02 Sep 2003 12:12:02 -0600 (MDT)
From: Shawn Emery <Shawn.Emery@Sun.COM>
Subject: Exact match enctype
To: krb5-bugs@mit.edu
Cc: Shawn.Emery@Sun.COM
Download (untitled) / with headers
text/plain 1.2KiB
krbv5,

I'm currently in the Solaris security group at Sun and found an issue when using
our Solaris 9+ client with an MS AD server. I've checked the 1.3.1 source tree
and discovered that it also has this issue.

I found a problem to be that an exact match is performed between the enctype
in the response to the enctype in the keytab file. In actuality a "similar"
match should be performed when checking for encryption types. We've integrated
this change into our source tree and I'm just checking to see if you would be
interested in the diffs for this.

krb5-1.3.1/src/lib/krb5/krb/rd_req_dec.c:
*** 77,86 ****
--- 77,93 ----
if ((retval = krb5_kt_get_entry(context, keytab, req->ticket->server,
req->ticket->enc_part.kvno,
enctype, &ktent)))
return retval;

+ /*
+ * If we get this far then we know that the enc types are similar,
+ * therefore we should change the enc type to match that of what
+ * we are decrypting.
+ */
+ ktent.key.enctype = enctype;
+
retval = krb5_decrypt_tkt_part(context, &ktent.key, req->ticket);
/* Upon error, Free keytab entry first, then return */

(void) krb5_kt_free_entry(context, &ktent);
return retval;

Shawn.
--
# Wed Sep 03 16:04:27 2003 tlyu (Taylor Yu) - Correspondence added
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #1801] Exact match enctype
From: Tom Yu <tlyu@mit.edu>
Date: Wed, 03 Sep 2003 16:04:25 -0400
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.1KiB
Show quoted text
>>>>> "Shawn" == Shawn Emery via RT <rt-comment@krbdev.mit.edu> writes:

Show quoted text
Shawn> I found a problem to be that an exact match is performed
Shawn> between the enctype in the response to the enctype in the
Shawn> keytab file. In actuality a "similar" match should be
Shawn> performed when checking for encryption types. We've integrated
Shawn> this change into our source tree and I'm just checking to see
Shawn> if you would be interested in the diffs for this.

That's odd... the situation you're describing shouldn't be happening.
lib/krb5/kt_file.c already performs a "similar" match, and coerces the
enctype of the key it returns if the match isn't exact.

Do you have the following in your kt_file.c?

if (enctype != IGNORE_ENCTYPE) {
if ((kerror = krb5_c_enctype_compare(context, enctype,
new_entry.key.enctype,
&similar))) {
krb5_kt_free_entry(context, &new_entry);
break;
}

if (!similar) {
krb5_kt_free_entry(context, &new_entry);
continue;
}
/*
* Coerce the enctype of the output keyblock in case we
* got an inexact match on the enctype.
*/
new_entry.key.enctype = enctype;

}
# Thu Sep 04 15:00:10 2003 Shawn.Emery@Sun.COM (Shawn Emery) - Comments added
Date: Thu, 04 Sep 2003 12:57:51 -0600 (MDT)
From: Shawn Emery <Shawn.Emery@Sun.COM>
Subject: Re: [krbdev.mit.edu #1801] Exact match enctype
To: Shawn.Emery@Sun.COM, rt-comment@krbdev.mit.edu
Cc: krb5-prs@mit.edu
RT-Send-Cc:
Download (untitled) / with headers
text/plain 1.3KiB

Show quoted text
> >>>>> "Shawn" == Shawn Emery via RT <rt-comment@krbdev.mit.edu> writes:
>
> Shawn> I found a problem to be that an exact match is performed
> Shawn> between the enctype in the response to the enctype in the
> Shawn> keytab file. In actuality a "similar" match should be
> Shawn> performed when checking for encryption types. We've integrated
> Shawn> this change into our source tree and I'm just checking to see
> Shawn> if you would be interested in the diffs for this.
>
> That's odd... the situation you're describing shouldn't be happening.
> lib/krb5/kt_file.c already performs a "similar" match, and coerces the
> enctype of the key it returns if the match isn't exact.
>
> Do you have the following in your kt_file.c?

Tom,

You are right, our version of krb5_ktfile_get_entry() does not have the coercing
that you speak of. Thanks for clearing this issue for me.

Shawn.
--
Show quoted text
> if (enctype != IGNORE_ENCTYPE) {
> if ((kerror = krb5_c_enctype_compare(context, enctype,
> new_entry.key.enctype,
> &similar))) {
> krb5_kt_free_entry(context, &new_entry);
> break;
> }
>
> if (!similar) {
> krb5_kt_free_entry(context, &new_entry);
> continue;
> }
> /*
> * Coerce the enctype of the output keyblock in case we
> * got an inexact match on the enctype.
> */
> new_entry.key.enctype = enctype;
>
> }

Shawn.
--
# Thu Sep 04 15:03:51 2003 hartmans (Sam Hartman) - Tags nochange added
# Thu Sep 04 15:03:52 2003 hartmans (Sam Hartman) - Status changed from 'new' to 'resolved'