Skip Menu |
 

Date: Sat, 12 Jan 2013 12:57:48 -0500
From: Richard Basch <basch@alum.mit.edu>
Subject: Krb5-1.11 incompatibility
To: krb5-bugs@mit.edu

I am not sure what caused this, but krb5-1.11 KDC appears to cause problems with Solaris 10 kinit (causing it to die with SIGSEGV in the preauth section of code).

Date: Tue, 08 Oct 2013 08:19:45 -0400
From: Richard Basch <basch@alum.mit.edu>
Subject: Kerberos 1.11 incompatibility with some Solaris 10 systems
To: krb5-bugs@mit.edu

I can’t find the original email chain/bug report, but based on some side discussions at KIT 2013, I am sending an update.

 

Something in the wire protocol has changed which might affect certain legacy Solaris clients. Principals which have preauth required might encounter an issue on clients talking to Kerberos 1.11 KDC servers where the PAM stack will crash, whereas with Kerberos 1.10 KDC there isn’t a problem.

 

The problem only seems to manifest on Solaris 10 systems which are lacking a Sun patch:

124235-02 or higher (SPARC Solaris 10)

124236-02 or higher (x86 Solaris 10)

 

I never actually was able to trace the cause of the issue, but this was first noticed and fixed in 2006-2007 and the portion of the Sun patch which is relevant is the GSS mech_krb5.so module.

 

Hopefully, this update will help others who might encounter the same issue in the future, especially since 1.10 is likely nearing its end-of-support date.

John Devitofranceschi helped us narrow down this problem to the use
of explicit salts when the key data uses the default salt.

We intended to start always sending explicit salts in 1.7 (#6470) but
didn't actually succeed until 1.11. The stated rationale for sending
explicit default salts was pretty; after doing some testing I can
clarify it to this: when the canonical name differs from the
requested name and encrypted timestamp/challenge preauth is required,
an explicit salt must be communicated to the client, or the client
(at least, our client) will compute the wrong default salt. When
preauth is not required, the client uses the canonical name from the
KDC-REP to compute the default salt, so an explicit salt isn't really
needed.

We could narrow the use of explicit default salts to scenarios where
client principal aliases were used, but it would require more state
to be communicated into the KDC preauth code.