Mailing List CGatePro@mail.stalker.com Message #92228
From: Bret Miller <bret.miller@wcg.org>
Subject: RE: SASL authentication with external LDAP - for SIP/XMPP/Pronto
Date: Wed, 15 Aug 2007 10:03:57 -0700
To: CommuniGate Pro Discussions <CGatePro@mail.stalker.com>
X-Mailer: CommuniGate Pro MAPI Connector 1.2.12/1.2.12(local)
> Background:
> Difficulties using SASL auth "challenge-response" mechanisms with an
> external LDAP directory have often been discussed here, including but
> not-limited to these discussion threads on the mailing list:
>
>   http://mail.stalker.com/Lists/CGatePro/Message/92121.html
>   http://mail.stalker.com/Lists/CGatePro/Message/90954.html
>   http://mail.stalker.com/Lists/CGatePro/Message/81572.html
>   http://mail.stalker.com/Lists/CGatePro/Message/79431.html
>
> (If your have been unable to authenticate via SIP, XMPP, or Pronto and
> you are using an external LDAP directory - this was likely
> the cause of
> the problem.)
>
> Recommended Approach:
> Please note that one technique to achieve SASL auth with an external
> LDAP Directory is now documented at the following page, and a new
> authLDAP plugin which implements it is provided there:
>
> https://support.communigate.com/tickets/kb_article.php?ref=227
> 2-WTXV-8661
>
> Using this method, CommuniGate Pro can perform SASL
> authentication with
> an external LDAP Directory - this allows for SIP, XMPP, and Pronto
> (XIMSS) authentication (including Pronto SSL) via external LDAP.
>
> (Please note: In order to use Pronto with SSL, CommuniGate Pro 5.1.12e
> or later is required. For SIP and XMPP authentication, as
> well as Pronto
> non-SSL SASL authentication, this technique should work with
> earlier 5.1
> releases).
>
> An example is provided there for OpenLDAP configuration.
>
> Please review this and let us know if you have any questions.


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.

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.

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.

The only other way around this is to provide secure transport of the
password from the client to the server. But then, I'm not sure most clients
support SSL as an authentication protocol without making the whole session
SSL. Certainly you could do it in your own clients (CLI, XIMSS, Pronto,
webmail, mapi...).

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.

Bret



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