directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: Kerberos EType selection
Date Mon, 11 Mar 2013 17:48:53 GMT
On Mon, Mar 11, 2013 at 11:13 PM, Emmanuel L├ęcharny <elecharny@gmail.com>wrote:

> Hi guys,
>
> I think we have a problem in the way we select the EncryptionType on the
> server.
>
> The idea is to select the strongest supported EType by both the client
> and the server. The client send a list (ordered) of ETypes it supports,
> and the server check on its configured EType list to find one matching
> EType (and it should be the strongest one).
>
> The method that does this selection is the following :
>
>     public static EncryptionType getBestEncryptionType(
> Set<EncryptionType> requestedTypes, Set<EncryptionType> configuredTypes )
>     {
>         for ( EncryptionType encryptionType : requestedTypes )
>         {
>             if ( configuredTypes.contains( encryptionType ) )
>             {
>                 return encryptionType;
>             }
>         }
>
>         return null;
>     }
>
> As we can see, we iterate on the client provided ETypes, and if the
> EType is present on the server set of EType, we are done. This is not
> good : the test I have made shos that the client send such a list :
>
> [des-cbc-md5 (3), des-cbc-crc (1), rc4-hmac (23), des3-cbc-sha1-kd (16),
> aes128-cts-hmac-sha1-96 (17), aes256-cts-hmac-sha1-96 (18)]
>
> As we can see, the weakest EType are on the left.
>
> The server configured ETypes are :
>
> [aes128-cts-hmac-sha1-96 (17), des3-cbc-sha1-kd (16), des-cbc-md5 (3)]
>
> It's obvious that the selected EType will be des-cbc-md5, and not
> aes128, as expected...
>
> So first, we should invert the logic : iterate using the configured
> ETypes, checking on the set of ETypes provided by the client, from teh
> strongest to the weakest.
>
> But I also think we should use a List to store the configured ETypes in
> the server (even if the order is maintained, as we are using a
> LinkedHashSet to store the ETypes), and not a Set. This is confusing.
> For the client, we can still use a Set.
>
> Thoughts ?
>
> +1, but the existing logic shouldn't cause any authentication failure
cause the server will send the selected EType in EncryptedData of AsRep

> --
> Regards,
> Cordialement,
> Emmanuel L├ęcharny
> www.iktek.com
>
>


-- 
Kiran Ayyagari
http://keydap.com

Mime
View raw message