Re: Perl Sasl GSSAPI and
On Apr 23, 2009, at 8:27 PM, Graham Barr wrote: I have made a change to this effect and pushed to the repository. The perl-ldap repository is not available on github at http://github.com/gbarr/perl-ldap/tree/master This change is on the next branch, I would appreciate anyone testing it. For those who do not use git, you can download a snapshot of this by going to http://github.com/gbarr/perl-ldap/tree/next There is a download link where you can download either a tar or zip file Graham.
Re: Perl Sasl GSSAPI and
On Apr 14, 2009, at 7:53 AM, Graham Barr wrote:
On Apr 13, 2009, at 12:25 PM, Simon Wilkinson wrote:
On 13 Apr 2009, at 17:23, Dale Moore wrote:
I recommend that if we are going to use Net::LDAP get the peerhost,
and use it as part of the service name, that we modify Net::LDAP to
do the reverse DNS and not expect GSSAPI to do it. Or we change our
approach in dealing with hosts with round-robin ip addresses.
The reason why both MIT and Heimdal are moving away from doing
reverse lookups is that it introduces a security dependency on the
DNS. Given that (in general) the DNS is not secure, moving the
lookup elsewhere is a retrograde step. Net::LDAP should simply pass
the server name that it has been asked to connect to through to the
GSSAPI library. The correct place to handling name resolution
issues is on the server, or (once referral support is in place) on
the KDC.
I think the flaw is in having Net::LDAP decide the hostname to pass
to Auth::SASL
Currently an Authen::SASL object is passed to -bind and bind will
call $sasl-client_new(ldap,$connected_name);
Whatever the correct method anyone may think, that is not going to
work for some. What I propose is the option for the caller to call -
client_new and pass the result to bind. ie, if passed object -
isa('Authen::SASL') then we call client_new as we do now, otherwise
we use the given object as the connection object.
This would remain backwards compatible with what is there now, but
give greater control to those user that the current scheme does not
work for.
I have made a change to this effect and pushed to the repository.
The perl-ldap repository is not available on github at
http://github.com/gbarr/perl-ldap/tree/master
This change is on the next branch, I would appreciate anyone testing it.
Graham.
Re: Perl Sasl GSSAPI and
On Apr 13, 2009, at 12:25 PM, Simon Wilkinson wrote:
On 13 Apr 2009, at 17:23, Dale Moore wrote:
I recommend that if we are going to use Net::LDAP get the peerhost,
and use it as part of the service name, that we modify Net::LDAP to
do the reverse DNS and not expect GSSAPI to do it. Or we change our
approach in dealing with hosts with round-robin ip addresses.
The reason why both MIT and Heimdal are moving away from doing
reverse lookups is that it introduces a security dependency on the
DNS. Given that (in general) the DNS is not secure, moving the
lookup elsewhere is a retrograde step. Net::LDAP should simply pass
the server name that it has been asked to connect to through to the
GSSAPI library. The correct place to handling name resolution issues
is on the server, or (once referral support is in place) on the KDC.
I think the flaw is in having Net::LDAP decide the hostname to pass to
Auth::SASL
Currently an Authen::SASL object is passed to -bind and bind will
call $sasl-client_new(ldap,$connected_name);
Whatever the correct method anyone may think, that is not going to
work for some. What I propose is the option for the caller to call -
client_new and pass the result to bind. ie, if passed object -
isa('Authen::SASL') then we call client_new as we do now, otherwise
we use the given object as the connection object.
This would remain backwards compatible with what is there now, but
give greater control to those user that the current scheme does not
work for.
Graham.
Re: Perl Sasl GSSAPI and
Graham Barr wrote:
On Apr 13, 2009, at 12:25 PM, Simon Wilkinson wrote:
On 13 Apr 2009, at 17:23, Dale Moore wrote:
I recommend that if we are going to use Net::LDAP get the peerhost,
and use it as part of the service name, that we modify Net::LDAP to
do the reverse DNS and not expect GSSAPI to do it. Or we change our
approach in dealing with hosts with round-robin ip addresses.
The reason why both MIT and Heimdal are moving away from doing
reverse lookups is that it introduces a security dependency on the
DNS. Given that (in general) the DNS is not secure, moving the lookup
elsewhere is a retrograde step. Net::LDAP should simply pass the
server name that it has been asked to connect to through to the
GSSAPI library. The correct place to handling name resolution issues
is on the server, or (once referral support is in place) on the KDC.
I think the flaw is in having Net::LDAP decide the hostname to pass to
Auth::SASL
Currently an Authen::SASL object is passed to -bind and bind will
call $sasl-client_new(ldap,$connected_name);
Whatever the correct method anyone may think, that is not going to
work for some. What I propose is the option for the caller to call
-client_new and pass the result to bind. ie, if passed object
-isa('Authen::SASL') then we call client_new as we do now, otherwise
we use the given object as the connection object.
This would remain backwards compatible with what is there now, but
give greater control to those user that the current scheme does not
work for.
Graham.
Sounds like a reasonable plan to me.
Regards,
Clif Harden char...@pobox.com
Re: Perl Sasl GSSAPI and
On 13 Apr 2009, at 17:23, Dale Moore wrote: I recommend that if we are going to use Net::LDAP get the peerhost, and use it as part of the service name, that we modify Net::LDAP to do the reverse DNS and not expect GSSAPI to do it. Or we change our approach in dealing with hosts with round-robin ip addresses. The reason why both MIT and Heimdal are moving away from doing reverse lookups is that it introduces a security dependency on the DNS. Given that (in general) the DNS is not secure, moving the lookup elsewhere is a retrograde step. Net::LDAP should simply pass the server name that it has been asked to connect to through to the GSSAPI library. The correct place to handling name resolution issues is on the server, or (once referral support is in place) on the KDC. S.
