RE: StartTLS issues (ITS#3037)

[kirill@softerra.com]

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