[DIRAPI-323] Decoding extended operations which require a value isn't enforcing the value to be present

• Type: Bug
• Status: Resolved
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: 2.0.0.AM2
• Fix Version/s: 2.0.0.AM3
• Assignee: Unassigned
• Reporter: Emmanuel Lécharny
• Created: 18/Oct/18 09:58
• Updated: 02/Jan/19 12:45
• Resolved: 02/Jan/19 12:45

Description

Currently, when we decode an extended operation for which we know about (ie, it's registred in the LdapApiService instance), and if the RequestValue part is required, we have no way to enforce it to be present, which means the decoding will succeed, even if the resulting extended operation is invalid.

This is due to the fact that the extended operation grammar makes the value optionnal :

        ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
             requestName      [0] LDAPOID,
             requestValue     [1] OCTET STRING OPTIONAL }

        ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
             COMPONENTS OF LDAPResult,
             responseName     [10] LDAPOID OPTIONAL,
             responseValue    [11] OCTET STRING OPTIONAL }

(works for a request or a response), while for a specific implementation, like the CancelRequest, defined in RFC 3909, the grammar is :

   The Cancel request is an ExtendedRequest with the requestName field
   containing 1.3.6.1.1.8 and a requestValue field which contains a
   BER-encoded cancelRequestValue value.

      cancelRequestValue ::= SEQUENCE {
          cancelID        MessageID
                          -- MessageID is as defined in [RFC2251]
      }

and it's clearly not optional.

It boils down to be able to detect the extended operation type (given by the request name, if present), and then check if the request value is present or not. It's a semantic check, while the decoding just take care of the syntax, which makes it impossible to detect such a missing value.

There is a solution for PDU which ends with no controls, as we can tell the grammar that there is some expected value, which will fail if the PDU ends, but if we have controls, then the grammar will keep going as some more data is present (we just have to change the isGrammarEndAllowed to false to make that works when no control is present, but obviously that does not work when we have some controls).

ATM, I have no solution to this problem. What would be required is to set a flag when we meet the ExtendedOperation tag (ie 0x77 or 0x78) and check this flag when we have fully decoded a PDU, but this flag has a semantic meaning, which would break the decoder as a generic ASN.1 decoder. One solution would be to have the container check itself when we reach the PDU_DECODED state in the Asn1Decoder loop...