Viewing Incoming/6463
Full headers

Major security issue: yes  no

Notes:
no ldaps handling: dup of ITS#6462? no DN: conforms to RFC4511
Notification:

Date: Wed, 27 Jan 2010 01:41:54 +0000
From: jochen@keutel.de
To: openldap-its@OpenLDAP.org
Subject: dnssrv_back_referrals: ldaps not handled, search base gone

Full_Name: Jochen Keutel
Version: 2.4.21
OS: Solaris 10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (87.159.206.14)


dnssrv_back_referrals() always returns ldap URLs - even when the original
request was a ldaps query.

Additionally only protocol and hostname are put into the URL - the search base
doesn't appear any more.

Problematic code:

		url.bv_len = STRLENOF( "ldap://" ) + strlen( hosts[i] );
		url.bv_val = ch_malloc( url.bv_len + 1 );

		strcpy( url.bv_val, "ldap://" );
		strcpy( &url.bv_val[STRLENOF( "ldap://" )], hosts[i] );

I'm not sure whether you want me to deliver a complete patch or not ... 

Thanks to my colleague Manuel Gaupp for detecting this problem.

Best regards,  Jochen.

Followup 1

Date: Sun, 18 Apr 2010 00:52:42 +0200 (CEST)
Subject: Re: (ITS#6463) dnssrv_back_referrals: ldaps not handled,
      search base gone
From: masarati@aero.polimi.it
To: jochen@keutel.de
Cc: openldap-its@openldap.org

> Full_Name: Jochen Keutel
> Version: 2.4.21
> OS: Solaris 10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (87.159.206.14)
>
>
> dnssrv_back_referrals() always returns ldap URLs - even when the original
> request was a ldaps query.

This is a (logical) duplicate of ITS#6462; see related answers.

> Additionally only protocol and hostname are put into the URL - the search
> base
> doesn't appear any more.
>
> Problematic code:
>
> 		url.bv_len = STRLENOF( "ldap://" ) + strlen( hosts[i] );
> 		url.bv_val = ch_malloc( url.bv_len + 1 );
>
> 		strcpy( url.bv_val, "ldap://" );
> 		strcpy( &url.bv_val[STRLENOF( "ldap://" )], hosts[i] );
>
> I'm not sure whether you want me to deliver a complete patch or not ...

This behavior conforms to RFC4511, section 4.1.10:

   - If the <dn> part is present, the client uses this name in its next
     request to progress the operation, and if it is not present the
     client uses the same name as in the original request.

I note that few lines above the same RFC states:

   - It is RECOMMENDED that the <dn> part be present to avoid ambiguity.

However, slapd-dnssrv(5) computes the referral from DNS SRV records,
rather than returning data it knows about.  So returning the <dn> part
here would be incorrect, in my opinion, as the client could legitimately
rely on the fact that the returned DN is appropriate, while it may not.

p.