directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Kerberos fixes...
Date Fri, 27 Jan 2012 08:52:07 GMT
Hi guys,

yesterday, we faced some big issues in the kerberos server. Some tests 
were failing, due to some modifications done earlier this week.

To be clear : the modifications weren't the cause of the problem, they 
just exposed the bug, and not on every environement.

What happened is that we added AES128 encryption algorithm to the list 
of encryption the server was supporting. As it's a strong encryption 
algorithm, it was put at the beginning of the list of the supported 
algorithm. (keep in mind that when Kerberos selects an encryption 
algorithm, it considers that the strongest one is on the left of the 
list, and every other is weaker, the weakest being on the right of the 

Now, the pb was that when we tried to send an AS_REQ to the server, and 
if the server requests that the client has to be authenticated, then the 
server returns a KRB-ERROR message asking for a pre-authentication to be 
sent ( ERR_PREAUTH_REQUIRED). In this error message, the server will 
push the list of accepted entryption type for the client to select the 
right one to encrypt a PA-ENC-TIMESTAMP (a Pre-authentication encoded 
timestamp). This list wasn't correctly generated, so the selected 
encryption algo used to encrypt the PA-ENC-TIMESTAMP was different than 
the selected encryption algo, thus it was impossible to decrypt the message.

What I've done is that I modified two things :
- first, the algo are now stroed into a List, and not a Set. A Set is 
basically unordered, when a List is ordered. As the seelction is done 
based on an ordered algorithm strength, it's absolutely critical to use 
an ordered collection.
- second, I modified the way we compute the list of accepted encryption 
algo when returning them in the KRB-ERROR message : it's now a lst built 
using the client algo contained in the server list, ordered following 
the client list (and not the server list).

The rational behind this second modification is that it's up to the 
client to dictate which order to use, the server is just here to use the 
best possible combination it supports from the client list.

Tests are now passing.

However, I do think that we badly need to review the kerberos server 
code sooner or later, because I think there are *many* part if the 
implementation that are not following the RFC. It will obviously take 

Emmanuel L├ęcharny

View raw message