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.
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.
changed notes changed state Open to Feedback
changed notes
>> 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
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
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
moved from Incoming to Software Enhancements
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.
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. >
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. >>
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. > >> > >
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. >>
interop issue fixed in mozilla, not yet fixed in MS-LDAP.