RE: StartTLS issues (ITS#3037)

[Kurt@OpenLDAP.org]

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.
>>