directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@gmail.com>
Subject Kerberos EType selection
Date Mon, 11 Mar 2013 17:43:21 GMT
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 ?

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


Mime
View raw message