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
Reply-To: Shawn Emery <Shawn.Emery@Sun.COM>
Message-Id: <0HKP0091VE0FK0@giza-mail1.Central.Sun.COM>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-Md5: 4YDKjQIu7XJU+VWqCdy+jg==
RT-Send-Cc: 
Content-Length: 1397


> >>>>> "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.
--
> 	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.
--