directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot ...@marcelot.net>
Subject Re: Kerberos fixes...
Date Fri, 27 Jan 2012 09:52:42 GMT
Awesome Emmanuel!

I confirm that trunk now compiles fine.

Thanks for the heads up.

Regards,
Pierre-Arnaud


On 27 janv. 2012, at 09:52, Emmanuel Lecharny wrote:

> 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 list).
> 
> 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 time...
> 
> -- 
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.iktek.com
> 


Mime
View raw message