Kerberos fixes...

[Emmanuel Lecharny <el...@gmail.com>]

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

Re: Kerberos fixes...

[Alex Karasulu <ak...@apache.org>]

On Fri, Jan 27, 2012 at 11:52 AM, Pierre-Arnaud Marcelot <pa...@marcelot.net>wrote:

> Awesome Emmanuel!
>
>
Ditto - nice job Emm.

-- 
Best Regards,
-- Alex

Re: Kerberos fixes...

[Pierre-Arnaud Marcelot <pa...@marcelot.net>]

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
>