[17029] in Kerberos_V5_Development
Re: Multiple ETYPE-INFO-ENTRY with same etype but different salts
daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Jul 15 09:16:57 2011
From: Greg Hudson <ghudson@mit.edu>
To: Weijun Wang <weijun.wang@oracle.com>
In-Reply-To: <4E1FEA8F.5010506@oracle.com>
Date: Fri, 15 Jul 2011 09:16:51 -0400
Message-ID: <1310735811.2694.195.camel@t410>
Mime-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Fri, 2011-07-15 at 03:21 -0400, Weijun Wang wrote:
> I lookup RFC 4120 and there is no spec on what to do when there are
> multiple ETYPE-INFO-ENTRYs with the same etype but different salts. What
> shall I do now?
MIT krb5 uses the first entry for the most preferred enctype it can find
in the sequence. (That is, we iterate over our enctype preference list;
for each enctype we search the etype-info2 sequence for an entry with
that enctype, and we use the first entry we find.)
Heimdal appears to do the same thing.
> Or, is there a way to reconfigure their KDC and avoid
> such a response?
That's hard to answer with confidence without more information about the
KDC, but I'll go ahead and speculate that it's an MIT krb5 KDC with a
history of supporting krb4.
In this case, the etype-info2 entries are determined by the keys in the
KDB records. The KDC administrator could change the supported_enctypes
variable to include only one des-cbc-crc entry and then have the
affected users change their passwords.
It's arguably a bug that we return multiple etype-info2 entries with the
same enctype, and then (I assume) only try the first key entry matching
the enctype when decrypting an encrypted-timestamp preauth request. We
should either prune the etype-info2 entries to one per enctype, or try
multiple keys against a preauth request.
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
