"Mark D. Roth" wrote:
> [...]
> I think we need to nail down exactly what we're trying to accomplish
> here. There are a few interrelated issues:
>
> 1) Tamper-proofing on the wire
> 2) Verifying that a message originated from a given source
> 3) Verifying the intermediate hop/timestamp information
> 4) Verifying a single "message thread" (e.g., all messages from a
> single daemon process)
>
> If we're only addressing issue (1), it sounds like TLS/IPSec should be
> sufficient. If we're trying to solve issue (2), we'd really need to
> have the process which submits the message generate the signature,
> because otherwise any user on the system would be able to fake a
> message from the daemon whose logs you're looking at.
First let me say that you're assuming the logs are being generated on a
multi-user/multi-purpose system, which is actually not the most common scenario
in
highly-networked security-sensitive environment (I'm starting to sound like Alex
Brown and Chris Lonvick).
Meanwhile, there are other ways to go besides having the individual logging
processes sign the messages. For example, setting up logging queues that only a
process with certain privileges or a certain UID can access and still have the
logging system sign everything, but indicate in the signed data what
privs/uid/whatever the originating process had. On the other hand, all such
issues are way down the path of implementation compared to where we're at right
now.
> If the protocol is designed to transport an arbitrary payload, one
> approach for issue (3) is to have the intermediate syslog server
> simply wrap the original message (signature intact) in its own signed
> message. The final destination would then recursively unwrap the
> message until it gets to the original message. The obvious problem,
> of course, is that the transmitted message winds up growing quite a
> bit at each hop.
Agreed. In fact, I put together a proposal for using XML for this stuff that wa
s
discussed during the secure logging BOF session at the last IETF meeting.
Basically, the reaction was that:
1) Such issues are premature and are likely to require coordination with the
Intrusion Detection Working Group (IDWG).
2) The underlying protocol must be able to handle old style syslog traffic and
whatever the IDWG comes up with (though we can steer them in the direction of ou
r
thinking...). This means is should probably be fairly payload agnostic.
> Issue (4) basicly boils down to a lightweight version of issue (2).
> Instead of generating permanent public/private key pairs for each
> application, you can simply have syslogd generate a small key when the
> equivalent of openlog() is called, and from then on everything
> associated with that process must be signed with the private key.
> (You could even do things like call openlog() before you fork() child
> processes if you wanted to have several processes using the same
> stream. But I guess I'm getting into implementation details here...)
Yup.
The plan right now is to first come up with a document that details requirements
for a secure logging protocol. Once that is done, the next step is to actually
design the protocol and then finally to implement it (OK, design and
implementation should go hand in hand to the extent that you can't verify that t
he
design is reasonable unless you can implement it).
--
Chris Calabrese
Internet Infrastructure and Security
Merck-Medco Managed Care, L.L.C.
[EMAIL PROTECTED]
.
