Mailing List Message #92236
From: Thom O'Connor <>
Subject: RE: SASL authentication with external LDAP - for SIP/XMPP/Pronto
Date: Wed, 15 Aug 2007 13:38:52 -0700
To: <>
From: Bret Miller
> It can work, as long as it can read a plain text password from the
> directory. The problem is that many implementations don't allow the password
> to be read-- only checked. And if a challenge/reponse method is used to
> supply the password, it can be hijacked just as easily. In other words, I
> can watch the packets across the network and see that you challenged with
> this and it answered with that. If I could authenticate by supplying both
> the challenge and response, I might as well use plain text.

No no no! This is exactly the point.

The challenge will have changed by the next iteration of the attempt.
You cannot just supply the same response, and the client cannot provide
the challenge. Only CommuniGate Pro can provide the challenge, and the
response can *only* be calculated using the challenge + the plain text
password. This is the inherent security in the SASL challenge/response

> So we're really back where we started here. In order to support SASL
> methods, you need access to the plain text password-- either on the server
> side or on the client side.

Think about it this way. You can either have the plain text password in
your (hopefully) secure internal network. Or you can pass the plain-text
password across the Internet.

> In order to support this properly, two calls would be needed to the external
> auth module:
> SASL-C = give me back something to challenge the user with.
> SASL-R = here is what the user answered.
> That way the module could act as a true client proxy in a secure
> authentication system.

CommuniGate Pro can use an external SASL implementation...if only one
existed in any other product. Ideally, if CommuniGate Pro could only
provide the challenge key and response to the LDAP directory, and have
it validated. The CommuniGate Pro side of this is documented here:

> I'd like to see SSL authentication implemented, along with a "synchronize
> CGPro password with external password" option that would, when any type of
> external authentication (OS, extauth, ....) is required, set the CGPro
> password automatically to match so that future authentication can be handled
> internally until the password changes.

I believe there is an authLDAP script around someplace which does this.
The problem of course is synchronizing any future password change.

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster