[Freeipa-devel] LDAP TLS issues

Richard Megginson rmeggins at redhat.com
Fri Nov 9 23:23:53 UTC 2007


John Dennis wrote:
> Simo Sorce wrote:
>> On Fri, 2007-11-09 at 17:09 -0500, John Dennis wrote:
>>
>> SASL/GSSAPI already provides (strong) encryption, you shouldn't need
>> TLS.
>> It's either/or
>
> I thought, but perhaps I was wrong, with SASL establishing encrypted 
> transport was optional and independent of the auth mech. Or is it the 
> case with GSSAPI encrypted transport the default is to always use 
> encrypted transport? Or am I wrong that the use of encrypted transport 
> is is a configurable property in SASL?
Both the server and the client can specify the minssf I believe, and the 
security strength will be the maximum of these two.
>
>> Anyway, why would you need to encrypt something in directory server?
>> When you search these attributes you will get them back in clear, the
>> encryption is useful only to protect the data in case someone steals the
>> disk and even then only if the secret is manually entered at start-up I
>> believe ...
>>
>> Care to elaborate more?
>
> Sure, I think you missed last Wednesday meeting. I'm storing radius 
> client information in LDAP. One of those attributes is a secret shared 
> between the NAS and Radius server. The Radius server must have 
> plaintext  access to the secret. The secret will be protected by 
> ACL's, however it was felt the additional step of encrypting that 
> attribute in the database was prudent.
>
> The secret is best thought of as an encryption key used to encrypt 
> parts of the network communication between a radius client and the 
> radius server. The secret is NOT a user password. Each NAS has it's 
> own secret. If the secret were compromised it would be possible to 
> decrypt sniffed radius protocol and possibly gain access to user 
> passwords used in the radius protocol.
>
> In a conventional freeRADIUS installation the client data is store in 
> a flat file protected by standard UNIX DAC. If the IPA server machine 
> were root compromised that flat file could be read, the same is true 
> of the LDAP database which in our case is also holding those secrets. 
> However, if the LDAP database encrypted those attributes it would be 
> one extra layer of protection. I believe the LDAP encryption key is 
> stored on the server as well, so I suppose if the machine were root 
> compromised it wouldn't be any worse than having the secrets in a flat 
> file, but the hassle factor of getting the LDAP encryption key and 
> decrypting the database may be more than the low hanging fruit a 
> typical attacker is willing to invest in.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20071109/4de1088a/attachment.bin>


More information about the Freeipa-devel mailing list