John Dennis wrote:
Both the server and the client can specify the minssf I believe, and the security strength will be the maximum of these two.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/orI 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?
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.
Description: S/MIME Cryptographic Signature