RE: I-Draft on signed operations

["Salter, Thomas A" <Thomas.Salter@unisys.com>]

I think you'll find that needing to encode the BER for an Ldap Message
twice will prove difficult for implementations that use the U-Mich
ber_printf encoding routines.  There's a tendency with those routines to
discard information as soon as its encoded.

I think the single, extended message would be much simpler for both the
encoder and decoder alike.  A simple approach to decoding would be to
process the extended operation and then just pass the embedded message
on to the regular processing.  It's probably more efficient also, as you
don't need to encode the message twice.

I believe it would also avoid the requirement for DER.  I think the OSI
protocols required DER because they allowed intermediate systems to
re-encode a message, and there are multiple equivalent BER encodings.
With Ldap, I believe the server always gets exactly the same BER as the
client sent (and vice-versa), so it is safe to apply a hash to whatever
BER is received.

> ----------
> From: 	Vesna Hassler[SMTP:hassler@infosys.tuwien.ac.at]
> Sent: 	Tuesday, March 31, 1998 10:29 AM
> To: 	Salter, Thomas A; ldap@umich.edu; ietf-ldapext@netscape.com
> Subject: 	RE: I-Draft on signed operations
> 
> 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
>