Hello,
My users are managed on a common LDAP / Kerberos setup. I don’t have access in any ways to the user password in clear text mode.
I’ve start to follow this tutorial http://www.kamailio.org/wiki/tutorials/mini-howto-admin/ldap-user-auth and check this documenation http://kamailio.org/docs/modules/4.1.x/modules/ldap.html
But it seems LDAP module provided in Kamailio don’t handle this scenario, it except to have user password in clear text mode in the LDAP database (wrong in so many ways…).
Do we have a way with existing Kamailio plugin to use a authentication backend who don’t provide access to clear text password?
I provide different authentication « adapter » who can help any service not compatible with Kerberos to handle authentication: - ldap bind - sasl - pam
Do we’ve a way to use one of this backend as an authentication service (and not just a users database).
Best regards, Yoann
Hello,
the constraint to have access to text password or HA1 format (md5 over username, password, realm) comes from WWW Authentication mechanism which is used by SIP.
Writing something different in kamailio would be possible (it is open source), but you don't have phones able to do it and provide the adequate details.
The only alternative now is using tls/ssl client certificates that attest who is the user/phone.
Cheers, Daniel
On 21/04/14 13:56, Yoann Gini wrote:
Hello,
My users are managed on a common LDAP / Kerberos setup. I don’t have access in any ways to the user password in clear text mode.
I’ve start to follow this tutorial http://www.kamailio.org/wiki/tutorials/mini-howto-admin/ldap-user-auth and check this documenation http://kamailio.org/docs/modules/4.1.x/modules/ldap.html
But it seems LDAP module provided in Kamailio don’t handle this scenario, it except to have user password in clear text mode in the LDAP database (wrong in so many ways…).
Do we have a way with existing Kamailio plugin to use a authentication backend who don’t provide access to clear text password?
I provide different authentication « adapter » who can help any service not compatible with Kerberos to handle authentication:
- ldap bind
- sasl
- pam
Do we’ve a way to use one of this backend as an authentication service (and not just a users database).
Best regards, Yoann
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Le 22 avr. 2014 à 11:03, Daniel-Constantin Mierla miconda@gmail.com a écrit :
the constraint to have access to text password or HA1 format (md5 over username, password, realm) comes from WWW Authentication mechanism which is used by SIP.
Writing something different in kamailio would be possible (it is open source), but you don't have phones able to do it and provide the adequate details.
Are you sure? You’ve a Radius backend for example, Radius don’t allow you to access to clear text password, it isn’t?
The only www authentication mechanism who must have access to clear text password is the DIGEST auth. But if we consider using SIP over TLS, we may be able to use BASIC authentication…
What do you think ? Does the authentication kind is negotiated during the communication?
On 23/04/14 08:06, Yoann Gini wrote:
Le 22 avr. 2014 à 11:03, Daniel-Constantin Mierla <miconda@gmail.com mailto:miconda@gmail.com> a écrit :
the constraint to have access to text password or HA1 format (md5 over username, password, realm) comes from WWW Authentication mechanism which is used by SIP.
Writing something different in kamailio would be possible (it is open source), but you don't have phones able to do it and provide the adequate details.
Are you sure?
Sure you can't be sure of anything but this one.
You’ve a Radius backend for example, Radius don’t allow you to access to clear text password, it isn’t?
Look at digest module for (free)radius, if there is something like that for ldap, then you may get it working with some patch. But it still requires access to plain text password or HA1.
The only www authentication mechanism who must have access to clear text password is the DIGEST auth. But if we consider using SIP over TLS, we may be able to use BASIC authentication…
What do you think ? Does the authentication kind is negotiated during the communication?
If you use tls and give a signed certificate to client, then you can simply authenticate it by trusting the certificate and checking the owner fields to match sip headers.
If you control the client and develop it, you can add any authentication mechanism. You will eventually have to add to kamailio appropriate authentication support, but that's easy, it's open source.
However, SIP RFC enforces www digest authentication and it is what all the phones I am aware of in the wild support now.
Le 23 avr. 2014 à 09:50, Daniel-Constantin Mierla miconda@gmail.com a écrit :
However, SIP RFC enforces www digest authentication and it is what all the phones I am aware of in the wild support now.
Thanks for all this informations.
That explain me why all SIP product I see on the market have this really big issue of requiring a distinct PIN code for SIP account.
As a sys admin who maintain a unique identity for all enterprise services, it’s hard to accept to make an exception for SIP…
I don’t understand how it's possible to end up on a RFC like that…
The good point for me is, on OS X Server, I’ve a private API who can provide me DIGEST challenge, so something is possible. But for my FreeBSD based server, I’m stuck…
TLS authentication is harder to deploy in SMB. That mean a internal CA and a overhead to ensure that each client certificate are well secured.
The solution of BASIC authentication over TLS connection (with certificate only on the server) is widely used by HTTPS based software or event e-mail protocols to allow add-on services to be connected to existing directory services without requiring access to clear text password.
Cheers, Yoann
-
Daniel-Constantin Mierla -
Yoann Gini