RE: I-D ACTION:draft-salzr-ldap-repsig-00.txt

[Rich Salz <salzr@certco.com>]

> Boy, you're a tough customer.  Given that RFC 2649 is experimental, it's
> not surprising that you thing that changes need to be made...

Well, you did ask. :)  I understand that it's experimental.  As specified,
it's got enough problems -- for the problem I need to solve -- that it
was not a good base on which to work.

I'll write two replies.  The first (this one) talks about those items I
can address purely from a crypto/security viewpoint.  The other one will
address those issues that are style or taste.

> How does a hash of the search reply protect it?  This wasn't viewed as a
> requirement at the time.

The hash is across *all* the the replies.  So any tampering with the
reply string will be detected.  I assume you know that, so your question
leads me to think I need to add some more clarification.

> >	3. An adversary could intercept search replies undetected.
> 
> If you are concerned about this, you can protect the channel.

No, transport-level protection is NOT the same as application-level
protection.  For dispute resolution, or (contractual) proof that
proper action/due diligence was performed, I need an application-level
signature.  "See, I did search for the latest CRL and the repository
didn't give it to me.  So it's not my fault I trusted a revoked certificate."
A reply signature addresses that; saving ALL the TLS packets, key exchanges,
etc., is not practical.  And, it forces TLS in places where a simple
signature is all that's needed.

> >	4. Audit entries aren't linked; an adversary could intercept or
> >"trim off"
> >	   the end, or tamper intermediates
> An adversary would need to have sufficient access to the directory to do
> this.  If someone hacks into the directory, any number of things can happen.

I was talking about remote access, where the client/server channel can
be tampered.  Security of local log files or transaction records -- thing
necessary if/when someone hacks into the directory - are not the issue
here.  The spec defines audit entries that have remote access, and
the security thereon is insufficient.
 
> >	5. Replies aren't cryptographically tied to queries; what prevents a
> >	   man in the middle attack?
> 
> LDAP over TLS can easily prevent this.

See #3.

> >	6. For a repository that is mainly holding signed data (certs and
> >crls),
> >	   I don't see what security "sign by server" gets you, and it
> >weakens
> >	   the overall system (making some of the above attacks possible)
> 
> If this is not a requirement, don't use it.  The sign by server request
> allows the client that trusts the server to sign the operations to do the
> work.  This is an optional feature that was deemed to be useful in some
> environments.

Well 2649 isn't (directly) the topic here, but I still don't see the
point.:)  It DOES weaken the security of the system, as I mentioned.
As a server operator, I would be *extremely* leary of being asked to
sign anything I didn't generate.  It might be possible for me to
generate a bizarre LDAP modify request that translates to an EDI
or other binary funds-transfer protocol. :)

Also, since you can have combinations of entries, and since the timestamp
is therefore coming from different places, my trust would be weakened.

But I'm not interested in audit records, I just threw in those complains
as free review.  (Worth every penny. :)

> >	7. Sequence numbers aren't required to be monotonically increasing
> >within an
> >	   object, so an adversary could intercept intermediate ones without
> >detection.
> 
> Sequence number are required to be increasing.  RFC 2649 indicates"
> "Subsequent sequence numbers indicate the sequence of changes that have
> been made to this directory object.  Note that the sequence of the changes
> can be verified due to the fact that the signed directory object will have
> a timestamp as part of the signature object, and that the sequence
> numbering as part of the change attribute should be considered to be an
> unverified aid to the LDAP client.  Sequence numbers are meaningful only
> within the context of a single directory entry..."  In any case the
> sequenceNumbers in RFC 2649 are used as an aid to the client to show the
> sequence of operations that were applied to that operation.

The ordering can be verified; the complete sequence can't be.
Can a server increment by 10's or 3's?  I might want to use a fine-grain
resolution time-of-day clock.  In any of those choices, if I remotely
query the audit trail, I have no way of knowing if something was
intercepted.  Requiring TLS is too heavyweight, it feels improper (why
require privacy for public data?), and as I tried to explain above,
isn't really a correct solution anyway.

Imagine doing an audit.

If remote access is not the issue, then I don't see how this is
appropriate to specify. :)

> >	8. On the other hand, audit trail sequence numbers aren't global, so
> >it
> >	   doesn't seem possible to step through and determine exactly when
> >something
> >	   bad happened.
> 
> Sequence numbers are global, within an entry.  Each signature has a
> timestamp as well.  So, you will know exactly when something bad happened
> to an entry.

"Global within an entry" is an uncommon use of the terms.

Is "client sign" allowed in audit records?  If so, then why can't a
client set his clock forward one day, and delete a CRL?

> I don't follow this one.  For your purposes, you just only use client
> signature mechanism. The sign by server request doesn't apply.

No.  As a CA, I want a "return receipt requested"  I want cryptographic
proof that the LDAP server got my publication request.  2649 doesn't do it.

>   I also think that it is important to have the
> ability to store the signatures stored in the directory along with the
> entry, so that other clients can retrieve the signatures... 

Sure, some folks do need that.  But it's not what the reply signatures
I-D does.
	/r$, college dropout.