another similar enctype issue
William.Fiveash at sun.com
Sun Oct 2 23:47:17 EDT 2005
On Fri, Sep 30, 2005 at 02:22:18PM -0500, Nicolas Williams wrote:
> On Fri, Sep 30, 2005 at 01:24:25PM -0400, Sam Hartman wrote:
> > etype_info_helper
> Exactly, if the principal has a long-term key of one enctype that has
> similar enctypes, then the KDC ought to offer all of them for pre-auth
> modulo realm policy. And the code is there for that, so if Will is
> seeing failures that indicate that the KDC is not offering des-cbc-crc,
> then maybe we have a bug.
> > My concern is not what happens to the session key, but what happens to
> > the reply key.
> Me too.
After looking at this more closely with Nico, here is what we
1. When the KDC is creating a AS_REP and adding padata to it, it uses
the enctypes in the AS_REQ to determine which of the client's keys to
use from the princ DB. There is an issue here as the db2 backend is
using similiarity matching when looking for the key which appears to
be a violation of the DAL (see krb5_dbe_find_enctype() and
krb5_dbe_search_enctype() in kdb_xdr.c).
2. The KDC is then using the enctype found in the client key
(des-cbc-md5) which may not be a literal match to that requested in
the AS_REQ (des-cbc-crc). See return_etype_info2(). This appears to
be a bug as the client code is doing a literal comparion of the
padata enctype in the AS_REP with those it requested.
3. The KDC is returning only a PA-ETYPE-INFO2 even though the AS_REQ
only contains des-cbc-crc. That appears to violate the text in
When the AS server is to include pre-authentication data in a
KRB-ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not PA-ETYPE-
INFO, if the etype field of the client's AS-REQ lists at least one
"newer" encryption type. Otherwise (when the etype field of the
client's AS-REQ does not list any "newer" encryption types), it MUST
send both PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for
each enctype). A "newer" enctype is any enctype first officially
specified concurrently with or subsequent to the issue of this RFC.
The enctypes DES, 3DES, or RC4 and any defined in [RFC1510] are not
Hint, look at return_padata() in kdc_preauth.c and etype-info
instance of the preauth_systems (no return_padata function
So I now understand Sam's point that the problem I'm seeing is not on
the client side but instead it is the KDC code that is buggy.
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)
More information about the krbdev