RE: I-Draft on signed operations

[Vesna Hassler <hassler@infosys.tuwien.ac.at>]

Thomas,

Thanks a lot for your comments.

At 11:20 30.03.98 -0500, you wrote:
>1. I'm unclear as to how the actual signing process must proceed.
>Section 2 says:
>   "The value of the encrypted field is computed over the entire
>LDAPMessage with the encrypted field set to NULL (i.e. absent)."
>
>Does this mean that you create the message, encode it as BER, and
>compute the encrypted field.  Then you recreate the message with the
>encrypted field set as computed and regenerate the BER?  It seems you
>must recreate the BER because the length of the message changes when you
>insert the encrypted bit string.
>
>If so, then to validate the signature, you must do the opposite: extract
>the encrypted field and regenerate the BER, then compute the signature
>and compare them.  This requires that the same BER be generated by both
>client and server.

Yes, that's how it should work.

>The current Ldap requirements are not strict enough
>to ensure this.  You would need to require DER, or at least require
>minimum-length length fields.

I'm not an encoding expert, but this sounds reasonable. This
means, the first part (encoding for computing of the encrypted field)
should be DER, right? The controlValue is an OCTET STRING, and it
has to be encoded in the primitive form anyway (rfc2251), so the
encoding for transmission may remain the usual LDAP BER encoding.

>2. Section 1 says, "A disadvantage of this approach is that it would be
>necessary to define a new Extended Request/Response pair for each basic
>operation that should be signed. "
>
>I believe it only requires a single Extended Request/Response pair.  Its
>requestValue would be a SEQUENCE containing the signature, and a
>complete LdapMessage.  The SecurityParameters could remain as a control
>in the embedded LdapMessage.  By wrapping an entire message in a
>sequence, it would be clear what the signature applied to and it would
>not be necessary to reencode the BER, effectively removing the
>requirement for DER encoding of the entire LdapMessage.
>
>In fact, unless I'm totally confused about my first point above, I'd
>recommend that the document be changed to use an Extended operation as
>I've just described.

This is a very interesting idea, and would, in fact, give a
direct implementation of the X.509's ASN.1 for SIGNED.
The only thing that I'm not quite sure about is the additional
complexity for the directory server. With your proposal the server
would have to recognize both the ExtendedOperation and the Control;
how much overhead is it really? Less than encoding the message
twice?

>3. In Section 2, SecurityParameters are defined as a SET.  I'd recommend
>changing it to a SEQUENCE so that you don't need to add the DER ordering
>rule for set members.

I think this is a good idea.

>4. How is 'none' used as a value for target ?

This really needs more explanation. X.511 says:

"The target ProtectionRequest may appear only in the request for an
operation to be carried out, and indicates the requestor's preference
regarding the degree of protection to be provided on the result.
Two levels are provided: none (no protection requested, the default),
and signed (the Directory is requested to sign the result)."

In the draft I extended the use of this field so that the server
may request the client to sign its requests as well (a soft of
authentication without the secure session overhead).

>5. Section 3.3 says "If the time and random field of the control are
>used in an appropriate way, ..."  Perhaps there should be a reference to
>a document (x.509 ?) that defines "appropriate".

Yes, you are right, there should be a reference (X.511). However, X.511
only says:

"The time is the intended expiry time for the validity of the signature,
when signed arguments are used. It is used in conjunction with the
random number to enable the detection of replay attacks."

The "style" of using timestamps/random numbers can be similar to
X.509: Strong authentication procedures.


Vesna Hassler
Technical University of Vienna
Information Systems Institute