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

From: Bruce Greenblatt <[email-masked]>
Date: Sat, 06 May 2000 10:02:37 -0700

At 11:01 AM 5/4/2000 -0400, Salz, Rich wrote:
>>Why can't you use the mechanisms defined in RFC 2649 as a basis for this?
>>Your proposal seems remarkably similar to the definitions in RFC 2649.
>
>I have a couple of issues with 2649:

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...

>	1. Why S/MIME, why not just a raw signature?

During the process of creating RFC 2649, we discussed using raw signatures,
but it was deceided that the benefits of using a standard mechanism that
was already recognized by other applications was substantial.  S/MIME is a
standard mechanism for the interchange of signed and encrypted data.  It
allows easy transfer of the signature between Internet applications.  I
don't see this changing.  So, I'd urge you to consider paying the overhead
of using the standard interchange mechanism.

>	2. Protection of search replies is too heavyweight; no intermediate
>	   step (like "just hash")

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

>	3. An adversary could intercept search replies undetected.

If you are concerned about this, you can protect the channel.

>	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.

>	5. Replies aren't cryptographically tied to queries; what prevents a
>	   man in the middle attack?

LDAP over TLS can easily prevent this.

>	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.

>	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.

>	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.

>	9. Allowing both "client signs" and "sign by server" probably means
>an adversary
>	   can do bad things by messing around with his local clock.

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

>Hope this helps.

Actually, it doesn't.  I still think that you can use RFC 2649 mechanisms
for your requirements.  In your draft, you state: "In many environments the
final step of certificate issuance is publishing the certificate to a
repository. Unfortunately, there is no way for a Certification Authority
(CA) to have a secure application-level acknowledgement that the proper
repository did, in fact, receive the certificate."  In my mind, this is
exactly what RFC 2649 provides.  When the CA publishes the certificate to a
repository (presumably via an LDAP modify operation), it will receive a
signed result from the LDAP server, and the LDAP server will store the
signed operation from the CA along with the modified LDAP entry.  If there
are specific things that need to happen in the CA - LDAP Server interaction
that don't happen in the machanisms defined by RFC 2649, then maybe we
should update RFC 2649.  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... 

Bruce

>	/r$
==============================================
Bruce Greenblatt, Ph. D.
Directory Tools and Application Services, Inc.
http://www.directory-applications.com
Sign up for our LDAP Technical Overview Seminar at:
http://www.acteva.com/go/dtasi

---

From: Rich Salz <[email-masked]>
Date: Sat, 6 May 2000 15:09:26 -0400 (EDT)

> 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

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.

> 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.

> 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.
 
> LDAP over TLS can easily prevent this.

See #3.

> work.  This is an optional feature that was deemed to be useful in some

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. :)

> 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. :)

> timestamp as well.  So, you will know exactly when something bad happened

"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?

> 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

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