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 >
