Re: StartTLS issues (ITS#3037)

[Kurt@OpenLDAP.org]

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.