[Freeipa-devel] LDAP TLS issues

[Simo Sorce]

On Fri, 2007-11-09 at 18:20 -0500, 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?

We enforce encryption to accept a connection, so we should be ok.

> > 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.

Ok on this premise I will probably also encrypt the kerberos Master
password that will be hold in the krbMKey attribute on the kerberos
container (currently only on a file on disk).