serious protocol interop bug in krb5-1.3

[Tom Yu]

-----BEGIN PGP SIGNED MESSAGE-----


The krb5-1.3 release has a serious problem: it fails to correctly
implement the ETYPE-INFO2 preauthentication type, in both client and
server code.  This can cause a failure to obtain tickets.

We strongly suggest that krb5-1.3 not be deployed in production
systems, especially on client platforms.  The upcoming krb5-1.3.1
release should fix this problem.  Code older than krb5-1.3 will ignore
ETYPE-INFO2 completely.

A krb5-1.3 client will fail to get an initial ticket if the following
conditions are true:

* Client requests an initial ticket from a conforming KDC (e.g., not a
  krb5-1.3 KDC).

* Client receives an ETYPE-INFO2 containing the optional "salt"
  element.  This will only happen if the KDC knows a client principal
  key that was generated using a non-default salt, e.g., the v4 salt.

The krb5-1.3.1 release, currently in beta test, will issue the correct
ETYPE-INFO2.  For compatibility, the krb5-1.3.1 client library will
accept the incorrect ETYPE-INFO2 encoding emitted by a krb5-1.3 KDC.

We expect that the final krb5-1.3.1 release will happen next week.

NOTE
====

Lack of existing problems in an installation does not indicate that
future upgrades will be successful; a krb5-1.3 client may not exhibit
any obvious failure modes until attempting to communicate with a KDC
that emits the correct ETYPE-INFO2 encoding.  Even then, it will only
fail if non-default key salts are used.  The Kerberos v4 salt is the
most common non-default salt, and is frequently present in sites that
have migrated from Kerberos v4.

DETAILS
=======

The underlying problem is that the implementation of ETYPE-INFO2 in
krb5-1.3 fails to match the latest internet-draft of the Kerberos
protocol specification.  The client will erroneously reject a response
- From the KDC containing a conforming ETYPE-INFO2, since the client
will parse it as containing a malformed ETYPE-INFO2.  This prevents a
krb5-1.3 client from working with a conforming KDC if one happens to
be deployed later.  This is documented as ticket #1681 in our bug
database.

The main MIT Kerberos web page is

http://web.mit.edu/kerberos/

Updates on the situation will be posted there.

=========================
Tom Yu
MIT Information Systems
Kerberos Development Team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (SunOS)
Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard <http://www.gnupg.org/>

iQCVAwUBPyBgDKbDgE/zdoE9AQGPwgP7BAl+CnT9RVFnZGRBtEcUYCV+PQMTFBvY
OaD0ZpBXmZbPsj9iC4zg/xInp5ii4x8CkOaIGuLQZUIUvQRoy8A9BLgI6EdDgtIC
RO2K+DJZw0vB/jx5u5Lzmugfjfx/vdZMq/lEKCTyDXNlVNqO31yNnUolsHQqsyb3
nz4nxtwT0cg=
=F3Ak
-----END PGP SIGNATURE-----