Re: Updated Draft - Security Considerations comments solicited

[Alex Brown]

Secure transport on the network (#1 and #2) is not the only security problem in a thoroughly designed log system.   An important  problem pointed out by the Schneier/Kelsey papers I mentioned, esp. http://www.counterpane.com/secure-logs.html, is attack on log files in compromised log hosts.   This requires "complimentary" attention to #3, application layer security, and data formats.

An XML encoding and  XML security wrappers are appropriate for  application layer secured log data, because  the encoding and its security properties are independent of the network's security properties,  and can be designed according to site policies rather than network equipment security requirements; and whatever they are, these security properties are retained in the persistent logfile.  Something like the Schneier/Kelsey encoding, complex as it is, might possibly be managable as an additional set of  optional attributes in an XML encoding.

(There's also a possible argument for efficient use of crypto resources, if security wrappers can be applied only to limited sensitive segments of the XML encoded log stream, e.g. authentication events.)

Alex
 

Herve Schauer wrote:

In his/her message, Balazs Scheidler wrote:
>From [EMAIL PROTECTED]  Tue Jul 18 19:15:54 2000
>Subject: Re: Updated Draft - Security Considerations comments solicited

[Charset iso-8859-2 unsupported, skipping...]

> 1 implement authentication, protection at the network layer (IPSec)
> 2 implement authentication, protection at the transport layer (SSL, SSH)
> 3 implement authentication, protection at the application layer, in our
>   protocol

     Logging is handling datas. We need integrity and authentication.
 So I think that the right place to implement authentication and protection
 is at the data layer. An XML data format and XML signatures is the obvious
 candidate : http://njlug.rutgers.edu/projects/syslog/xml-log-1.txt.

     The working charter does not allow us to standardize the data format.
 I believe that this is a mistake to standardize a new syslog protocol
 without standardizing the data format, because the key purpose of
 logging is the logging information.

     Use of #1 or #2 for another security purpose and for confidentiality,
 network or transport layer, is complementary.

         HERVE

-- 
Alex Brown <[EMAIL PROTECTED]> http://www.msg.com/~abrown +1 617 504 8761