Re: (ITS#7759) Wrong parsing of LDAP message

[hyc@symas.com]

Lukas Slebodnik wrote:
> On (09/12/13 00:59), Howard Chu wrote:
>> Lukas Slebodnik wrote:
>>> On (07/12/13 08:37), Howard Chu wrote:
>>>> lslebodn@redhat.com wrote:
>>>>> Full_Name: Lukas Slebodnik
>>>>> Version: 2.4.38
>>>>> OS: Fedora
>>>>> URL: ftp://ftp.openldap.org/incoming/Lukas-Slebodnik-131205.tar.gz
>>>>> Submission from: (NULL) (209.132.186.34)
>>>>
>>>> Fixed now in git master.
>>>
>>> Thank you.
>>>
>>> According commit 80e6316d37dd024bf32ed6db024f195c1b51ef7f, it seems to me
>>> I was right that ApacheDS send wrong response.
>>> Could you confirm this statement? because I am not expert in ldap protocol
>>> and I would like to file a bug to ApacheDS upstream.
>>
>> The hex dumps you included were a bit difficult to read. I couldn't
>> tell what was sent from the server vs the client and what the message
>> boundaries were.
> It is output directly from wireshark. Indented lines represent response
> from server.
>
> ldap_communication_without_PP.hexdump
> ----------------------------------------------------------------------------
> 00000000  30 5f 02 01 01 60 3b 02  01 03 04 2a 63 6e 3d 57 0_...`;. ...*cn=W
> 00000010  69 6c 6c 69 61 6d 20 42  75 73 68 2c 6f 75 3d 70 illiam B ush,ou=p
> 00000020  65 6f 70 6c 65 2c 64 63  3d 65 78 61 6d 70 6c 65 eople,dc =example
> 00000030  2c 64 63 3d 73 6b 80 0a  6a 61 68 6f 64 61 2e 31 ,dc=sk.. jahoda.1
> 00000040  32 33 a0 1d 30 1b 04 19  31 2e 33 2e 36 2e 31 2e 23..0... 1.3.6.1.
> 00000050  34 2e 31 2e 34 32 2e 32  2e 32 37 2e 38 2e 35 2e 4.1.42.2 .27.8.5.
> 00000060  31                                               1
> ^^^^^^^^
> client
>
>      00000000  30 0c 02 01 01 61 07 0a  01 00 04 00 04 00       0....a.. ......
>      ^^^^^^^^
>      server
>
> 00000061  30 05 02 01 02 42 00                             0....B.
> ^^^^^^^^
> client
> ----------------------------------------------------------------------------
>
>> If you can reproduce the behavior using e.g.
>> ldapwhoami -d7 that would be more legible.
> output from command ldapwhoami is in the attached file screenlog.2
> but it loks like ApacheDS does not support LDAP_EXOP_WHO_AM_I.

The point was to show a Bind request using the ppolicy control. The actual 
WhoAmI operation was irrelevant. But you didn't specify ppolicy in your 
invocation. Please read the ldapwhoami manpage.

Use -E ppolicy to use the ppolicy control, the screenlog you attached has 
nothing interesting without the ppolicy traffic.

>> Meanwhile you can refer to draft-behera-ldap-password-policy for the
>> specification of the response control. The control value is mandatory
>> for this control.
> If I read draft "6.2. Response Control" correctly,
> http://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-6.2
> response can be sequence of "PasswordPolicyResponseValue".
> I think that sequence means "0 or more values"

The sequence is required to begin with a Sequence marker.

> In theory, there needn't be any password policy response value after control
> type. In this case, either my patch or your patch are wrong.
> Did I miss something?
>
> The controlType is 1.3.6.1.4.1.42.2.27.8.5.1 and the controlValue is
> the BER encoding of the following type:

"the controlValue is the BER encoding of a Sequence." - even if the sequence 
has zero members, it cannot be omitted.

>        PasswordPolicyResponseValue ::= SEQUENCE {
>           warning [0] CHOICE {
>              ...snip... } OPTIONAL,
>           error   [1] ENUMERATED {
>              ...snip... } OPTIONAL
>        }
>
> Thank you very much for response.
>
> LS
>


-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/