Jakub Hrozek wrote:
> On 16 Mar 2015, at 21:06, Michael Ströder
<michael(a)stroeder.com> wrote:
>
> Stephen Gallagher wrote:
>> On Mon, 2015-03-16 at 10:33 +0100, Michael Ströder wrote:
>>> BTW: I consider it to be a bug that sssd tries to read the rootDSE
>>> before binding.
>>
>> Why do you consider this a bug? The RootDSE contains information to
>> allow SSSD to learn what mechanisms it's allowed to use when binding.
>> That's one of its primary purposes.
>>
>> That said, if we can't reach it, we just guess, connect and then
>> reread the rootDSE after binding.
>
> Ouch! A client MUST NOT assume that anything security relevant is really
> true when reading the rootDSE. The client has to obey its configuration.
> Period.
Sorry, but can you elaborate effect does the sssd's mechanism of trying
anonymous first and retrying with anonymous have? I still don't see why you
consider this a bug..
I consider this a bug because in my setups anon searches does not reveal
anything at all.
Also if a client chooses StartTLS policy or SASL authc mechs based on rootDSE
information that's clearly a violation of best practices because of possible
down-grade attacks. The client's configuration is the only trustworthy source.
Some hints herein:
http://tools.ietf.org/html/rfc4513#section-6
For SASL:
http://tools.ietf.org/html/rfc4513#section-6.4
Unfortunately this is pretty blurry and I'm pretty sure today this would have
been written differently:
http://tools.ietf.org/html/rfc4513#section-5.2.1.5
One could argue that if TLS is already established there is an integrity
protection.
But frankly I don't consider rootDSE to be really trustworthy even if no evil
attacker is part of the game.
Ciao, Michael.