IPv6 Kerberos server address handling in SASL2 GSSAPI plugin

Xu, Qiang (FXSGSC) Qiang.Xu at fujixerox.com
Thu Aug 6 05:08:05 EDT 2009

> -----Original Message-----
> From: Alexey Melnikov [mailto:alexey.melnikov at isode.com] 
> Sent: Thursday, August 06, 2009 4:27 PM
> To: Xu, Qiang (FXSGSC)
> Cc: Howard Chu; cyrus-sasl at lists.andrew.cmu.edu
> Subject: Re: IPv6 Kerberos server address handling in SASL2 
> GSSAPI plugin
> Xu, Qiang (FXSGSC) wrote:
> >Hi, all: 
> >
> >In my testing of SASL LDAP binding, I found the GSSAPI 
> plugin library (/usr/lib/sasl2/libgssapiv2.so) will go mad if 
> an IPv6 address of Kerberos authentication server is passed 
> to it. It just can't recognize the IPv6 address, and would 
> take it as a hostname. 
> >
> >For example, the IPv6 address of the Kerberos server is 
> "3ffe:2000:0:1:e0be:1872:d4f8:6b2c", and the authentication 
> domain is "xcipv6.com". When GSSAPI plugin receives this IPv6 
> address, it would think the address is in a form of 
> "hostname:port", so would split the address at the first 
> colon, and combine it with the domain name, to form an FQDN 
> "3ffe.xcipv6.com". Then it would try to resolve this FQDN to 
> get the IP address (v4?). Of course, the resolving would lead 
> to an error. And SASL binding can't go through.
> >  
> >
> I believe this is happening inside MIT Kerberos V5 library, 
> so you need to talk to MIT.

Hi, Alex:

On second thoughts, I wonder how you can determine it is a problem inside MIT Kerberos V5 distribution? Because in my testing, authentication has no problem. Only LDAP queries (done with SASL binding) failed after the user logs in. And from the trace, it seems the problem can be boiled down to that the Kerberos server can't be located in LDAP SASL interaction. In this process, shouldn't it be Cyrus-SASL library's responsiblity to find out the location of Kerberos server? 

Could you tell me the reason why you think MIT distribtion is the blackhand?

Thanks a lot,
Xu Qiang

More information about the Cyrus-sasl mailing list