Re: Start TLS extended request

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 08:04 PM 1/22/2004, Siva Kollipara wrote:
>Hi,
> Thanks for your reply. I have done some more investigation into this and
>have the questions.
>
> This is with regard to ldap_start_tls_s extended operation. Please read
>through with patience (its a bit long with all kinds of debug dumps). I am
>using openldap 2.1.22 release.
>
> I am thankful for any feedback.
>
> the debug and dump traces follow below.
>
>Question 1)  "send_ldap_extended: err=0 oid= len=0"
>what i am trying to understand is why isnt the responseName field set?
>2380 says requestName=OID and requestValue field absent in the request and
>responseName=requestName=OID and responseValue field absent in the
>response.
>the ber dumps and the ber debug output above also say this.
>The result code seems to be correctly set, but why isnt the responseName
>being set to OID (or did i understand the implementation incorrectly?)

Note that the responseName field in the protocol is intended for
use in unsolicited notifications (where it needed) not extended
operations (where it not needed).  (This is why it's OPTIONAL).
That latter should be obvious in that a server which doesn't
recognize the requestName cannot possible know what value to
insert in the responseName.  And, even it did, there is no
reason to send a value (as the kind of response must be that
solicited by the request).

Anyways, RFC 2830 is known to be flawed in that it mandates
a particular responseName improperly (one, because servers
cannot always adhere to the mandate and, two, because the
mandate is not consistent with BCP 14 guidance for stating
such mandates).  This RFC is currently be revised, so stay
tuned.

>Question 2)
>I was trying to allow the slapd to ignore the extra requestData at the end
>of the PDU (just curious to see what the winclient says - i understand its
>against the protocol)
>so now slapd was sending the same response values to both openldap client
>and winldap client.  but winldap client errors by saying "operations
>error". i've attached the responses below
>
>slapd response: same as for openldap client
>        send_ldap_extended: err=0 oid= len=0
>        send_ldap_response: msgid=1 tag=120 err=0
>        ber_flush: 14 bytes to sd 9
>          0000:  30 0c 02 01 01 78 07 0a  01 00 04 00 04 00         0....x........
>        ldap_write: want=14, written=14
>          0000:  30 0c 02 01 01 78 07 0a  01 00 04 00 04 00         0....x........
>
>winldap client:
>        prot ver=3
>        tls failed 1 - Operations Error
>
>slapd exit:
>        TLS trace: SSL_accept:before/accept initialization
>        tls_read: want=11 error=Connection reset by peer
>        TLS trace: SSL_accept:error in SSLv2/v3 read client hello A
>        TLS: can't accept.
>        connection_read(9): TLS accept error error=-1 id=0, closing
>
>I am wondering and curious as to why winldap rejected the response?

Seems you answered that question below.

>(i think it is because the oid was null)
>starttls.c wasnt setting the rspoid argument, so i changed it to set it
>the oid value "1.3.6.1.4.1.1466.20037", now everything seems to work fine
>(in opendlap and winldap client worlds),
>NEW slapd response with OID output:
>-->     send_ldap_extended: err=0 oid=1.3.6.1.4.1.1466.20037 len=0
>        send_ldap_response: msgid=1 tag=120 err=0
>        ber_flush: 38 bytes to sd 9
>          0000:  30 24 02 01 01 78 1f 0a  01 00 04 00 04 00 8a 16   0$...x..........
>          0010:  31 2e 33 2e 36 2e 31 2e  34 2e 31 2e 31 34 36 36   1.3.6.1.4.1.1466
>          0020:  2e 32 30 30 33 37                                  .20037


>Question 3)
>The winldap client still sends some "extra data namely - 00 00" which I
>have no clue what it is..? (do you know what that piece means?)

They are sending a zero-length requestValue instead no requestValue.
If you look closely at their PDU, you note they also violate
Section 5.1 of RFC 2251 a couple of times.

>Question 4)
>is this correct (and does the latest version send the oid back?)

I believe all my comments apply to current versions (I won't
guess as to whether or not they apply to non-current versions,
my memory ain't that good).

>Question 5)
>> (winldap) you used, is malformed.  Specifically, the
>> PDU contains request data when shouldn't.  You should
>do those values mean that the request data tag is present but has null
>values?

It means the requestValue is present and has zero length.

>if yes, is that still invalid ? (coz the field is null which is
>tha same as being absent rite?)

No.  Absent field and a present field who's value is zero length
are not equivalent here.  Kind of like the difference between
a NULL pointer (x=NULL) versus pointer which points to an empty
string (y="") in C (e.g. x != y).

Kurt