Issue 3037 - Start TLS operation issue
Summary: Start TLS operation issue
Status: VERIFIED FEEDBACK
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-03-24 13:41 UTC by boba@softerra.com
Modified: 2021-08-03 18:13 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description boba@softerra.com 2004-03-24 13:41:14 UTC
Full_Name: Dmitry A.
Version: 2.1.25
OS: Linux RH 9.0
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (217.144.66.190)


Hello. Let me make a reservation that under no circumstances this issue could be
said is a bug of OpenLDAP server because it works pretty fine with �native�
(OpenLDAP) client. But at least it could be a subject for some improvements.

So the issue concerns the Start TLS extended operation performed by other LDAP
clients. When I use ldap_start_tls_s function of MS API client or perform an
extended operation with START_TLS_OID (since there is no ldap_start_tls_s
function at all) with help of Netscape API the server returns
LDAP_PROTOCOL_ERROR accompanied with the message �no request data expected�.
Short investigation showed inconsistency on binary level of LDAP packets sent by
OpenLDAP and other clients. Below is the hexadecimal representation of ASN1
sequences for extended LDAP requests had been cut out from network packets.

OpenLDAP API: 
30 1D 02 01 01 77 18 80 16 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 31 34 36 36 2E 32
30 30 33 37

MS API, Netscape API:
30 84 00 00 00 23 02 01 0E 77 84 00 00 00 1A 80 16 31 2E 33 2E 36 2E 31 2E 34 2E
31 2E 31 34 36 36 2E 32 30 30 33 37 81 00

ASN1 viewing tool revealed an empty �redundant� tag at the end of the
MS/Netscape API packets. I think it would be great if OpenLDAP server could be
able to display more tolerance to such clients (like it does Novell server for
example: www.nldap.com)

With respect,
Dmitry.

Comment 1 Kurt Zeilenga 2004-03-24 18:31:38 UTC
We are pretty liberal in accepting the other 8 octets of bogusity
in the PDU.  The problem I see here is that even if we were to
ignore the bogus empty sequence, would the client accept a properly
formed response (with no sequence).  That is, I don't mind being
liberal in what we accept, but we need to remain strict in what
we produce.

Kurt

At 05:41 AM 3/24/2004, boba@softerra.com wrote:
>Full_Name: Dmitry A.
>Version: 2.1.25
>OS: Linux RH 9.0
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (217.144.66.190)
>
>
>Hello. Let me make a reservation that under no circumstances this issue could be
>said is a bug of OpenLDAP server because it works pretty fine with �native�
>(OpenLDAP) client. But at least it could be a subject for some improvements.
>
>So the issue concerns the Start TLS extended operation performed by other LDAP
>clients. When I use ldap_start_tls_s function of MS API client or perform an
>extended operation with START_TLS_OID (since there is no ldap_start_tls_s
>function at all) with help of Netscape API the server returns
>LDAP_PROTOCOL_ERROR accompanied with the message �no request data expected�.
>Short investigation showed inconsistency on binary level of LDAP packets sent by
>OpenLDAP and other clients. Below is the hexadecimal representation of ASN1
>sequences for extended LDAP requests had been cut out from network packets.
>
>OpenLDAP API: 
>30 1D 02 01 01 77 18 80 16 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 31 34 36 36 2E 32
>30 30 33 37
>
>MS API, Netscape API:
>30 84 00 00 00 23 02 01 0E 77 84 00 00 00 1A 80 16 31 2E 33 2E 36 2E 31 2E 34 2E
>31 2E 31 34 36 36 2E 32 30 30 33 37 81 00
>
>ASN1 viewing tool revealed an empty �redundant� tag at the end of the
>MS/Netscape API packets. I think it would be great if OpenLDAP server could be
>able to display more tolerance to such clients (like it does Novell server for
>example: www.nldap.com)
>
>With respect,
>Dmitry.

Comment 2 Kurt Zeilenga 2004-03-24 22:37:49 UTC
changed notes
changed state Open to Feedback
Comment 3 Kurt Zeilenga 2004-03-24 22:37:55 UTC
changed notes
Comment 4 boba@softerra.com 2004-03-30 09:46:10 UTC
>> We are pretty liberal in accepting the other 8 octets
>> of bogusity in the PDU

Do you mean that the latest version of your server will accept such message
formed by MS or Netscape API?

>> The problem I see here is that even if we were to
>> ignore the bogus empty sequence, would the client
>> accept a properly formed response (with no sequence)

I don't think there will be any problems. Tests with Novell server revealed
that client accepts properly formed responses. And even if it wasn't so it
couldn't be a problem of OpenLDAP server anyway. But the fact is that there
is no possibility to send extended request to OpenLDAP server with help of
two most popular client LDAP APIs (MS, Natscape).

Thanx in advance.
Dmitry

Comment 5 Kurt Zeilenga 2004-04-02 05:09:41 UTC
At 01:46 AM 3/30/2004, boba@softerra.com wrote:
>But the fact is that there
>is no possibility to send extended request to OpenLDAP server with help of
>two most popular client LDAP APIs (MS, Natscape). 

I note that if these API implementations are not capable of
sending an LDAP extended request without extension data,
they are significantly flawed.  That is, you should report
a bug to the developers of these API implementations.

Your request to be liberal here remains under consideration.

Kurt 

Comment 6 boba@softerra.com 2004-04-28 15:48:53 UTC
Hello,
With all respect let me draw your attention to the fact that practically
this situation leads us to the absence of interoperability between OpenLDAP
server and huge amount of client installations that are already took their
place and it's hardly possible now to update any of them.
Thanx again.
Dmitry

Comment 7 Kurt Zeilenga 2004-05-12 03:35:04 UTC
changed notes
Comment 8 Kurt Zeilenga 2004-05-12 03:35:34 UTC
moved from Incoming to Software Enhancements
Comment 9 Kurt Zeilenga 2004-05-27 14:51:47 UTC
In this response, which I forward to <openldap-its> with
an appropriate subject so it will be attached to the ITS,
I'll discuss only the ITS#3037 issue.  The other issue
should be separately discussed as part of ITS#1590.

I believe the first to resolving this issue should be to
report the bugs in the APIs to the API developers.  Once
aware of the problem, I suspect they would fix their bug.
It's unclear to me whether the original submitter of
ITS#3037 ever attempted to report the bugs to the API
developers.

While this particular bug doesn't directly affect me (as I
don't use any of the APIs mentioned), I did notified Mozilla
LDAP folks of their bug and they fixed it quickly.  I'll
leave the reporting and tracking of bug reports with
vendor-developed APIs to those who have relationships with
those vendors.  I assume they will fix their bugs in a
reasonable amount of time.

Have you (or anyone else) reported the problem to Microsoft?
If so, what did they say they would do about it?

I'm not warm to the idea of adding a workaround in the
meantime.  I would be more receptive to the idea if I knew that
the bug was reported to the vendors and the vendors agreed
that it was a bug and agreed to fix it (hence my encouragement
to report these API implementation bugs to the API developers).
I'm quite concerned that if we don't get them to fix their bug
now, we'll have repeats of this problem with numerous other
extended operations, like WhoAmI?, which send no data in
requests.

Kurt



At 06:45 AM 5/27/2004, Kirill Kovalenko wrote:
>Hello,
>
>We've spent some time digging into the issue. Here is the results; 
>
>1. Request
>
>The following table illustrates how parameters passed to the
>ldap_extended_operation_s() influence upon the ANS.1 data being transferred
>on wire.
>
>Client API    |ldap_extended_operation_s()           | Sent Message
>=======================================================================
>OpenLDAP      | requestdata = NULL                         | w/o data octets
>-----------------------------------------------------------------------
>OpenLDAP      | requestdata = struct berval{0, NULL} | an empty berval
>-----------------------------------------------------------------------
>Netscape      | requestdata = NULL                   | N/A (crash)
>-----------------------------------------------------------------------
>Netscape      | requestdata = struct berval{0, NULL} | the empty berval
>-----------------------------------------------------------------------
>Microsoft     | requestdata = NULL                   | the empty berval
>-----------------------------------------------------------------------
>Microsoft     | requestdata = struct berval{0, NULL} | the empty berval
>----------------------------------------------------------------------- 
>
>Form this table you can see that Netscape and Microsoft API always send
>empty an berval structure even if request data has to be absent (i.e. NULL).
>
>Unfortunately, OpenLDAP server does not accept such requests for the
>'StartTLS' extended operation because of the following code:
>
>starttls.c (starttls_extop() function):
>
>        if ( op->ore_reqdata != NULL ) {
>                /* no request data should be provided */
>                rs->sr_text = "no request data expected";
>                return LDAP_PROTOCOL_ERROR;
>        }
>
>This code makes it impossible to execute 'StartTLS' operation if it is made
>by clients who compiled against Netscape or Microsoft APIs. (The same is
>true for the 'Who Am I' operation)
>
>The fix for the problem is trivial: 
>
>        if ( op->ore_reqdata != NULL && op->ore_reqdata->bv_len > 0) {
>                /* no request data should be provided */
>                rs->sr_text = "no request data expected";
>                return LDAP_PROTOCOL_ERROR;
>        }
>
>We completely understand that this workaround contradicts RFC2830
>(Lightweight Directory Access Protocol (v3): Extension for Transport Layer
>Security)
>saying:
>...
>   A Start TLS extended request is formed by setting the requestName
>   field to the OID string given above.  The requestValue field is
>   absent.
>...
>Still, we believe that the fix should be applied because of the huge amount
>of mentioned clients installed worldwide.

Comment 10 Kirill Kovalenko 2004-05-27 15:20:22 UTC
Kurt,

> Have you (or anyone else) reported the problem to Microsoft?

Yes, I have.
http://groups.google.com.ua/groups?hl=uk&lr=&ie=UTF-8&th=8acf9a3c907b33b6&se
ekm=b3f80464.0404280733.75c0401%40posting.google.com&frame=off

As you can see the status is unclear for now.

Kirill

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
> Sent: Thursday, May 27, 2004 5:52 PM
> To: Kirill Kovalenko
> Cc: openldap-its@OpenLDAP.org
> Subject: Re: StartTLS issues (ITS#3037)
> 
> 
> In this response, which I forward to <openldap-its> with
> an appropriate subject so it will be attached to the ITS,
> I'll discuss only the ITS#3037 issue.  The other issue
> should be separately discussed as part of ITS#1590.
> 
> I believe the first to resolving this issue should be to
> report the bugs in the APIs to the API developers.  Once
> aware of the problem, I suspect they would fix their bug.
> It's unclear to me whether the original submitter of
> ITS#3037 ever attempted to report the bugs to the API developers.
> 
> While this particular bug doesn't directly affect me (as I 
> don't use any of the APIs mentioned), I did notified Mozilla 
> LDAP folks of their bug and they fixed it quickly.  I'll 
> leave the reporting and tracking of bug reports with 
> vendor-developed APIs to those who have relationships with 
> those vendors.  I assume they will fix their bugs in a 
> reasonable amount of time.
> 
> Have you (or anyone else) reported the problem to Microsoft?
> If so, what did they say they would do about it?
> 
> I'm not warm to the idea of adding a workaround in the 
> meantime.  I would be more receptive to the idea if I knew 
> that the bug was reported to the vendors and the vendors 
> agreed that it was a bug and agreed to fix it (hence my 
> encouragement to report these API implementation bugs to the 
> API developers). I'm quite concerned that if we don't get 
> them to fix their bug now, we'll have repeats of this problem 
> with numerous other extended operations, like WhoAmI?, which 
> send no data in requests.
> 
> Kurt
> 
> 
> 
> At 06:45 AM 5/27/2004, Kirill Kovalenko wrote:
> >Hello,
> >
> >We've spent some time digging into the issue. Here is the results;
> >
> >1. Request
> >
> >The following table illustrates how parameters passed to the
> >ldap_extended_operation_s() influence upon the ANS.1 data being 
> >transferred on wire.
> >
> >Client API    |ldap_extended_operation_s()           | Sent Message
> >=============================================================
> ==========
> >OpenLDAP      | requestdata = NULL                         | 
> w/o data octets
> >-------------------------------------------------------------
> ----------
> >OpenLDAP      | requestdata = struct berval{0, NULL} | an 
> empty berval
> >-------------------------------------------------------------
> ----------
> >Netscape      | requestdata = NULL                   | N/A (crash)
> >-------------------------------------------------------------
> ----------
> >Netscape      | requestdata = struct berval{0, NULL} | the 
> empty berval
> >-------------------------------------------------------------
> ----------
> >Microsoft     | requestdata = NULL                   | the 
> empty berval
> >-------------------------------------------------------------
> ----------
> >Microsoft     | requestdata = struct berval{0, NULL} | the 
> empty berval
> >-------------------------------------------------------------
> ----------
> >
> >Form this table you can see that Netscape and Microsoft API 
> always send 
> >empty an berval structure even if request data has to be 
> absent (i.e. 
> >NULL).
> >
> >Unfortunately, OpenLDAP server does not accept such requests for the 
> >'StartTLS' extended operation because of the following code:
> >
> >starttls.c (starttls_extop() function):
> >
> >        if ( op->ore_reqdata != NULL ) {
> >                /* no request data should be provided */
> >                rs->sr_text = "no request data expected";
> >                return LDAP_PROTOCOL_ERROR;
> >        }
> >
> >This code makes it impossible to execute 'StartTLS' 
> operation if it is 
> >made by clients who compiled against Netscape or Microsoft 
> APIs. (The 
> >same is true for the 'Who Am I' operation)
> >
> >The fix for the problem is trivial:
> >
> >        if ( op->ore_reqdata != NULL && 
> op->ore_reqdata->bv_len > 0) {
> >                /* no request data should be provided */
> >                rs->sr_text = "no request data expected";
> >                return LDAP_PROTOCOL_ERROR;
> >        }
> >
> >We completely understand that this workaround contradicts RFC2830 
> >(Lightweight Directory Access Protocol (v3): Extension for Transport 
> >Layer
> >Security)
> >saying:
> >...
> >   A Start TLS extended request is formed by setting the requestName
> >   field to the OID string given above.  The requestValue field is
> >   absent.
> >...
> >Still, we believe that the fix should be applied because of 
> the huge amount
> >of mentioned clients installed worldwide.
> 


Comment 11 Kurt Zeilenga 2004-05-27 15:41:08 UTC
Is this newsgroup a formal bug reporting mechanism?

At 08:20 AM 5/27/2004, Kirill Kovalenko wrote:
>Kurt,
>
>> Have you (or anyone else) reported the problem to Microsoft?
>
>Yes, I have.
>http://groups.google.com.ua/groups?hl=uk&lr=&ie=UTF-8&th=8acf9a3c907b33b6&se
>ekm=b3f80464.0404280733.75c0401%40posting.google.com&frame=off
>
>As you can see the status is unclear for now.
>
>Kirill
>
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
>> Sent: Thursday, May 27, 2004 5:52 PM
>> To: Kirill Kovalenko
>> Cc: openldap-its@OpenLDAP.org
>> Subject: Re: StartTLS issues (ITS#3037)
>> 
>> 
>> In this response, which I forward to <openldap-its> with
>> an appropriate subject so it will be attached to the ITS,
>> I'll discuss only the ITS#3037 issue.  The other issue
>> should be separately discussed as part of ITS#1590.
>> 
>> I believe the first to resolving this issue should be to
>> report the bugs in the APIs to the API developers.  Once
>> aware of the problem, I suspect they would fix their bug.
>> It's unclear to me whether the original submitter of
>> ITS#3037 ever attempted to report the bugs to the API developers.
>> 
>> While this particular bug doesn't directly affect me (as I 
>> don't use any of the APIs mentioned), I did notified Mozilla 
>> LDAP folks of their bug and they fixed it quickly.  I'll 
>> leave the reporting and tracking of bug reports with 
>> vendor-developed APIs to those who have relationships with 
>> those vendors.  I assume they will fix their bugs in a 
>> reasonable amount of time.
>> 
>> Have you (or anyone else) reported the problem to Microsoft?
>> If so, what did they say they would do about it?
>> 
>> I'm not warm to the idea of adding a workaround in the 
>> meantime.  I would be more receptive to the idea if I knew 
>> that the bug was reported to the vendors and the vendors 
>> agreed that it was a bug and agreed to fix it (hence my 
>> encouragement to report these API implementation bugs to the 
>> API developers). I'm quite concerned that if we don't get 
>> them to fix their bug now, we'll have repeats of this problem 
>> with numerous other extended operations, like WhoAmI?, which 
>> send no data in requests.
>> 
>> Kurt
>> 
>> 
>> 
>> At 06:45 AM 5/27/2004, Kirill Kovalenko wrote:
>> >Hello,
>> >
>> >We've spent some time digging into the issue. Here is the results;
>> >
>> >1. Request
>> >
>> >The following table illustrates how parameters passed to the
>> >ldap_extended_operation_s() influence upon the ANS.1 data being 
>> >transferred on wire.
>> >
>> >Client API    |ldap_extended_operation_s()           | Sent Message
>> >=============================================================
>> ==========
>> >OpenLDAP      | requestdata = NULL                         | 
>> w/o data octets
>> >-------------------------------------------------------------
>> ----------
>> >OpenLDAP      | requestdata = struct berval{0, NULL} | an 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >Netscape      | requestdata = NULL                   | N/A (crash)
>> >-------------------------------------------------------------
>> ----------
>> >Netscape      | requestdata = struct berval{0, NULL} | the 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >Microsoft     | requestdata = NULL                   | the 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >Microsoft     | requestdata = struct berval{0, NULL} | the 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >
>> >Form this table you can see that Netscape and Microsoft API 
>> always send 
>> >empty an berval structure even if request data has to be 
>> absent (i.e. 
>> >NULL).
>> >
>> >Unfortunately, OpenLDAP server does not accept such requests for the 
>> >'StartTLS' extended operation because of the following code:
>> >
>> >starttls.c (starttls_extop() function):
>> >
>> >        if ( op->ore_reqdata != NULL ) {
>> >                /* no request data should be provided */
>> >                rs->sr_text = "no request data expected";
>> >                return LDAP_PROTOCOL_ERROR;
>> >        }
>> >
>> >This code makes it impossible to execute 'StartTLS' 
>> operation if it is 
>> >made by clients who compiled against Netscape or Microsoft 
>> APIs. (The 
>> >same is true for the 'Who Am I' operation)
>> >
>> >The fix for the problem is trivial:
>> >
>> >        if ( op->ore_reqdata != NULL && 
>> op->ore_reqdata->bv_len > 0) {
>> >                /* no request data should be provided */
>> >                rs->sr_text = "no request data expected";
>> >                return LDAP_PROTOCOL_ERROR;
>> >        }
>> >
>> >We completely understand that this workaround contradicts RFC2830 
>> >(Lightweight Directory Access Protocol (v3): Extension for Transport 
>> >Layer
>> >Security)
>> >saying:
>> >...
>> >   A Start TLS extended request is formed by setting the requestName
>> >   field to the OID string given above.  The requestValue field is
>> >   absent.
>> >...
>> >Still, we believe that the fix should be applied because of 
>> the huge amount
>> >of mentioned clients installed worldwide.
>> 

Comment 12 Kirill Kovalenko 2004-05-27 15:51:27 UTC
Kurt,

Well I'm not sure. I was told by an insider to post it there and I
definitely don't want to pay $99 for their official support request. 

Kirill

> -----Original Message-----
> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
> Sent: Thursday, May 27, 2004 6:41 PM
> To: Kirill Kovalenko
> Cc: openldap-its@OpenLDAP.org
> Subject: RE: StartTLS issues (ITS#3037)
> 
> 
> Is this newsgroup a formal bug reporting mechanism?
> 
> At 08:20 AM 5/27/2004, Kirill Kovalenko wrote:
> >Kurt,
> >
> >> Have you (or anyone else) reported the problem to Microsoft?
> >
> >Yes, I have. 
> >http://groups.google.com.ua/groups?hl=uk&lr=&ie=UTF-8&th=8acf
> 9a3c907b33
> >b6&se
> >ekm=b3f80464.0404280733.75c0401%40posting.google.com&frame=off
> >
> >As you can see the status is unclear for now.
> >
> >Kirill
> >
> >> -----Original Message-----
> >> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> >> Sent: Thursday, May 27, 2004 5:52 PM
> >> To: Kirill Kovalenko
> >> Cc: openldap-its@OpenLDAP.org
> >> Subject: Re: StartTLS issues (ITS#3037)
> >> 
> >> 
> >> In this response, which I forward to <openldap-its> with
> >> an appropriate subject so it will be attached to the ITS, I'll 
> >> discuss only the ITS#3037 issue.  The other issue should be 
> >> separately discussed as part of ITS#1590.
> >> 
> >> I believe the first to resolving this issue should be to 
> report the 
> >> bugs in the APIs to the API developers.  Once aware of the 
> problem, I 
> >> suspect they would fix their bug. It's unclear to me whether the 
> >> original submitter of ITS#3037 ever attempted to report 
> the bugs to 
> >> the API developers.
> >> 
> >> While this particular bug doesn't directly affect me (as I
> >> don't use any of the APIs mentioned), I did notified Mozilla 
> >> LDAP folks of their bug and they fixed it quickly.  I'll 
> >> leave the reporting and tracking of bug reports with 
> >> vendor-developed APIs to those who have relationships with 
> >> those vendors.  I assume they will fix their bugs in a 
> >> reasonable amount of time.
> >> 
> >> Have you (or anyone else) reported the problem to 
> Microsoft? If so, 
> >> what did they say they would do about it?
> >> 
> >> I'm not warm to the idea of adding a workaround in the
> >> meantime.  I would be more receptive to the idea if I knew 
> >> that the bug was reported to the vendors and the vendors 
> >> agreed that it was a bug and agreed to fix it (hence my 
> >> encouragement to report these API implementation bugs to the 
> >> API developers). I'm quite concerned that if we don't get 
> >> them to fix their bug now, we'll have repeats of this problem 
> >> with numerous other extended operations, like WhoAmI?, which 
> >> send no data in requests.
> >> 
> >> Kurt
> >> 
> >> 
> >> 
> >> At 06:45 AM 5/27/2004, Kirill Kovalenko wrote:
> >> >Hello,
> >> >
> >> >We've spent some time digging into the issue. Here is the results;
> >> >
> >> >1. Request
> >> >
> >> >The following table illustrates how parameters passed to the
> >> >ldap_extended_operation_s() influence upon the ANS.1 data being
> >> >transferred on wire.
> >> >
> >> >Client API    |ldap_extended_operation_s()           | 
> Sent Message
> >> >=============================================================
> >> ==========
> >> >OpenLDAP      | requestdata = NULL                         | 
> >> w/o data octets
> >> >-------------------------------------------------------------
> >> ----------
> >> >OpenLDAP      | requestdata = struct berval{0, NULL} | an 
> >> empty berval
> >> >-------------------------------------------------------------
> >> ----------
> >> >Netscape      | requestdata = NULL                   | N/A (crash)
> >> >-------------------------------------------------------------
> >> ----------
> >> >Netscape      | requestdata = struct berval{0, NULL} | the 
> >> empty berval
> >> >-------------------------------------------------------------
> >> ----------
> >> >Microsoft     | requestdata = NULL                   | the 
> >> empty berval
> >> >-------------------------------------------------------------
> >> ----------
> >> >Microsoft     | requestdata = struct berval{0, NULL} | the 
> >> empty berval
> >> >-------------------------------------------------------------
> >> ----------
> >> >
> >> >Form this table you can see that Netscape and Microsoft API
> >> always send
> >> >empty an berval structure even if request data has to be
> >> absent (i.e.
> >> >NULL).
> >> >
> >> >Unfortunately, OpenLDAP server does not accept such 
> requests for the
> >> >'StartTLS' extended operation because of the following code:
> >> >
> >> >starttls.c (starttls_extop() function):
> >> >
> >> >        if ( op->ore_reqdata != NULL ) {
> >> >                /* no request data should be provided */
> >> >                rs->sr_text = "no request data expected";
> >> >                return LDAP_PROTOCOL_ERROR;
> >> >        }
> >> >
> >> >This code makes it impossible to execute 'StartTLS'
> >> operation if it is
> >> >made by clients who compiled against Netscape or Microsoft
> >> APIs. (The
> >> >same is true for the 'Who Am I' operation)
> >> >
> >> >The fix for the problem is trivial:
> >> >
> >> >        if ( op->ore_reqdata != NULL &&
> >> op->ore_reqdata->bv_len > 0) {
> >> >                /* no request data should be provided */
> >> >                rs->sr_text = "no request data expected";
> >> >                return LDAP_PROTOCOL_ERROR;
> >> >        }
> >> >
> >> >We completely understand that this workaround contradicts RFC2830
> >> >(Lightweight Directory Access Protocol (v3): Extension 
> for Transport 
> >> >Layer
> >> >Security)
> >> >saying:
> >> >...
> >> >   A Start TLS extended request is formed by setting the 
> requestName
> >> >   field to the OID string given above.  The requestValue field is
> >> >   absent.
> >> >...
> >> >Still, we believe that the fix should be applied because of 
> >> the huge amount
> >> >of mentioned clients installed worldwide.
> >> 
> 
> 

Comment 13 Kurt Zeilenga 2004-05-27 16:03:58 UTC
Your description of 4) which relates to this issue is misleading.
The issue is not with their encoding of empty data, but their
inability to encode a PDU with no data.  empty != no (much like
"" != NULL in C).

Kurt

At 08:21 AM 5/27/2004, kirill@softerra.com wrote:
>Kurt,
>
>> Have you (or anyone else) reported the problem to Microsoft?
>
>Yes, I have.
>http://groups.google.com.ua/groups?hl=uk&lr=&ie=UTF-8&th=8acf9a3c907b33b6&se
>ekm=b3f80464.0404280733.75c0401%40posting.google.com&frame=off
>
>As you can see the status is unclear for now.
>
>Kirill
>
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org] 
>> Sent: Thursday, May 27, 2004 5:52 PM
>> To: Kirill Kovalenko
>> Cc: openldap-its@OpenLDAP.org
>> Subject: Re: StartTLS issues (ITS#3037)
>> 
>> 
>> In this response, which I forward to <openldap-its> with
>> an appropriate subject so it will be attached to the ITS,
>> I'll discuss only the ITS#3037 issue.  The other issue
>> should be separately discussed as part of ITS#1590.
>> 
>> I believe the first to resolving this issue should be to
>> report the bugs in the APIs to the API developers.  Once
>> aware of the problem, I suspect they would fix their bug.
>> It's unclear to me whether the original submitter of
>> ITS#3037 ever attempted to report the bugs to the API developers.
>> 
>> While this particular bug doesn't directly affect me (as I 
>> don't use any of the APIs mentioned), I did notified Mozilla 
>> LDAP folks of their bug and they fixed it quickly.  I'll 
>> leave the reporting and tracking of bug reports with 
>> vendor-developed APIs to those who have relationships with 
>> those vendors.  I assume they will fix their bugs in a 
>> reasonable amount of time.
>> 
>> Have you (or anyone else) reported the problem to Microsoft?
>> If so, what did they say they would do about it?
>> 
>> I'm not warm to the idea of adding a workaround in the 
>> meantime.  I would be more receptive to the idea if I knew 
>> that the bug was reported to the vendors and the vendors 
>> agreed that it was a bug and agreed to fix it (hence my 
>> encouragement to report these API implementation bugs to the 
>> API developers). I'm quite concerned that if we don't get 
>> them to fix their bug now, we'll have repeats of this problem 
>> with numerous other extended operations, like WhoAmI?, which 
>> send no data in requests.
>> 
>> Kurt
>> 
>> 
>> 
>> At 06:45 AM 5/27/2004, Kirill Kovalenko wrote:
>> >Hello,
>> >
>> >We've spent some time digging into the issue. Here is the results;
>> >
>> >1. Request
>> >
>> >The following table illustrates how parameters passed to the
>> >ldap_extended_operation_s() influence upon the ANS.1 data being 
>> >transferred on wire.
>> >
>> >Client API    |ldap_extended_operation_s()           | Sent Message
>> >=============================================================
>> ==========
>> >OpenLDAP      | requestdata = NULL                         | 
>> w/o data octets
>> >-------------------------------------------------------------
>> ----------
>> >OpenLDAP      | requestdata = struct berval{0, NULL} | an 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >Netscape      | requestdata = NULL                   | N/A (crash)
>> >-------------------------------------------------------------
>> ----------
>> >Netscape      | requestdata = struct berval{0, NULL} | the 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >Microsoft     | requestdata = NULL                   | the 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >Microsoft     | requestdata = struct berval{0, NULL} | the 
>> empty berval
>> >-------------------------------------------------------------
>> ----------
>> >
>> >Form this table you can see that Netscape and Microsoft API 
>> always send 
>> >empty an berval structure even if request data has to be 
>> absent (i.e. 
>> >NULL).
>> >
>> >Unfortunately, OpenLDAP server does not accept such requests for the 
>> >'StartTLS' extended operation because of the following code:
>> >
>> >starttls.c (starttls_extop() function):
>> >
>> >        if ( op->ore_reqdata != NULL ) {
>> >                /* no request data should be provided */
>> >                rs->sr_text = "no request data expected";
>> >                return LDAP_PROTOCOL_ERROR;
>> >        }
>> >
>> >This code makes it impossible to execute 'StartTLS' 
>> operation if it is 
>> >made by clients who compiled against Netscape or Microsoft 
>> APIs. (The 
>> >same is true for the 'Who Am I' operation)
>> >
>> >The fix for the problem is trivial:
>> >
>> >        if ( op->ore_reqdata != NULL && 
>> op->ore_reqdata->bv_len > 0) {
>> >                /* no request data should be provided */
>> >                rs->sr_text = "no request data expected";
>> >                return LDAP_PROTOCOL_ERROR;
>> >        }
>> >
>> >We completely understand that this workaround contradicts RFC2830 
>> >(Lightweight Directory Access Protocol (v3): Extension for Transport 
>> >Layer
>> >Security)
>> >saying:
>> >...
>> >   A Start TLS extended request is formed by setting the requestName
>> >   field to the OID string given above.  The requestValue field is
>> >   absent.
>> >...
>> >Still, we believe that the fix should be applied because of 
>> the huge amount
>> >of mentioned clients installed worldwide.
>> 

Comment 14 Kurt Zeilenga 2004-06-05 20:10:32 UTC
changed notes
Comment 15 OpenLDAP project 2014-08-01 21:04:52 UTC
interop issue
fixed in mozilla, not yet fixed in MS-LDAP.