Issue 1590 - startTLS response does not include OID and closes on stopTLS
Summary: startTLS response does not include OID and closes on stopTLS
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: documentation (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-02-07 17:50 UTC by Cameron Morris
Modified: 2014-08-01 21:05 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 Cameron Morris 2002-02-07 17:50:36 UTC
I've noticed the ExtendedResponse for startTLS does not include the oid

of the startTLS extension as rfc 2830 says it should (section 2.1). 
I've been
testing against kurt's server at www.openLDAP.org.

- Cameron Morris


Comment 1 Kurt Zeilenga 2002-02-07 18:30:34 UTC
At 09:51 AM 2002-02-07, CMorris@novell.com wrote:
>I've noticed the ExtendedResponse for startTLS does not include the oid
>
>of the startTLS extension as rfc 2830 says it should (section 2.1). 
>I've been
>testing against kurt's server at www.openLDAP.org.

Per the current specification, yes, the OID of the request MUST be
provided.  IMO, that sentence:

   A Start TLS extended response MUST contain a responseName field which
   MUST be set to the same string as that in the responseName field
   present in the Start TLS extended request.

should be:
   A Start TLS extended response MAY contain a responseName field.
   If responseName field is present, it MUST be set to the same
   string as that in the responseName field present in the Start TLS
   extended request.

as clients MUST accept no responseName in certain error
conditions (such as protocolError).

I'll raise this issue to LDAPbis as they are currently working on
the 2830bis draft.

Comment 2 Kurt Zeilenga 2002-02-08 17:47:07 UTC
changed notes
changed state Open to Suspended
moved from Incoming to Software Bugs
Comment 3 Kurt Zeilenga 2003-05-18 15:11:17 UTC
changed notes
Comment 4 Kurt Zeilenga 2003-05-18 15:11:27 UTC
moved from Software Bugs to Documentation
Comment 5 Kurt Zeilenga 2004-05-27 15:17:32 UTC
At 06:45 AM 5/27/2004, Kirill Kovalenko wrote:
>2. Response
>
>Having fixed described above we came across another issues which concerns
>TLS extended operation response.
>
>As RFC2830 states:
>
>...
>   A Start TLS extended response MUST contain a responseName field which
>   MUST be set to the same string as that in the responseName field
>   present in the Start TLS extended request.
>...

The specification here is considered to be in error here.

An client which implements RFC 2830 must be capable of handling
responses from servers which do not implement RFC 2830.  And such
a server cannot be expected to know what responseName to specify,
this MUST is flawed.

We are working with the IETF to revise the specification to note
that responseName is optional (it really intended only for use
with unsolicited notifications, not extended operation responses
(as they are simply not needed)).

>Unfortunately OpenLDAP server doesn't return the 'responseName' field.

Why is it unfortunate?

>This defect may prevent other LDAP APIs from understanding the response of
>OpenLDAP servers.  For instance, Microsoft LDAP API doesn't accept the
>response without this field. We suggest to add the responseName field to the
>response.

It was previously reported that the Microsoft LDAP API implementation
did not require the responseName field to be present.  Please double
check.

Kurt 

Comment 6 Kurt Zeilenga 2004-10-04 21:02:19 UTC
changed notes
changed state Suspended to Closed
Comment 7 OpenLDAP project 2014-08-01 21:05:28 UTC
StartTLS I-D revised