Thanks for the comments Chris.
Note that PKI is not the only device authentication open to ipsec - a
pre-shared secret is much simpler to initiate and delivers mutual
authentication of client and server.
I don't think the 'protection' of syslog has any real connection with the
reliable delivery. TCP is the obvious way to go if syslog need reliable
delivery, rather than creating yet another TCP-like protocol. TCP will work
fine over IPSEC, and syslog will get feedback from TCP if messages are not
getting through to the server.
I agree that to meet the charter goals, signatures will be needed in the
syslog messages. A similar proposal is being worked for Secure-BGP - the
updates are digitally signed, and the BPG messages themselves (TCP flow) are
protected in transit by IPSEC - here's a pointer to more on this :
http://www.net-tech.bbn.com/sbgp/
Thanks for the reply,
Cheers, Steve.
-----Original Message-----
From: Chris Lonvick [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 17, 2000 5:31 PM
To: Waters, Stephen;
Subject: Re: IPSEC usage to protect syslog
Hi Steven,
Comments in-line.
At 10:34 AM 8/14/00 +0100, Waters, Stephen wrote:
>I have checked some of the archived messages on this topic, but not all.
>
>I have a few points of view that I would be grateful for some feedback on
>regarding using IPSEC to protect syslog.
>
>IPSEC/IKE/PKI is regarded as 'the best available' key management,
>authentication and encryption suite. Although IPSEC has been architected as
>a 'system-wide' or 'interface-wide' security screen, this is just one of
the
>implementation options. It can be used/implemented in a similar way to
other
>system services. For example, a protocol stream, say SNMP, could use an
>IPSEC API to express an interest in an SNMP stream (or more than one) to a
>particular host/protocol/port using specific connection authentication
>information (pre-shared secret, certificate, other 'legacy'
authentication).
>
>
>IPSEC has been implemented on Solaris, Windows, Apple, Lynix, Firewalls,
>Routers/Switches.
>
>Even with other changes that may be needed to syslog (reliable transport?),
>it seems useful to re-use the best, and most widely deployed IP protection
>protocols.
>
>This would also allow protection of 'legacy' syslog, or protection of any
>unicast IP flow for that matter.
"Protection" can be interpreted in various ways. IPsec will place a
security wrapper around the packets in a flow and will associate a very
strong device authentication with each packet sent. The receiver will
be able to validate that the sender is actually the device claiming to
have sent it. It may be that this feature is undesirable for syslog
going forward. In the past, people have just entered the address of
the syslog server into devices and left them to send messages as they
happened. This required no device authentication. Requiring strong
device authentication before a new device can be added (gen a cert,
have it signed, transfer it to a CA/PKI or to the other side, & import
certs or public keys of other participants, etc.) may add far more
complexity that what we're after. SSL can provide any of bi-directional
device authentication, uni-directional device authentication, or no
device authentication. It may be that this group decides to utilize
SSL so that the syslog server can present a cert while the client
can present a null cert. In this way, new clients may be added without
so much hassle. A secret key that may be utilized within the syslog
process may suffice for the authentication that we desire.
I would also suggest that a total dissociation of the current syslog
mechanisms from the protection is not desirable. One of the problems
with syslog is verifiable delivery and/or the recognition of the loss
of transmitted event messages. Having syslogd hand off the message to
UDP is actually very similar to udp handing off the packet to the IPsec
process. Generally, the SAD is not exposed and is not used by other
processes. If UDP does not deliver the packet, there is no message sent
back to syslogd. If IPsec does not establish the SA and deliver the
upd/syslog message, there is still no message sent back to syslogd or
to udp. Without great modification, syslogd will not monitor the SAD
to ensure delivery.
It may be that IPsec is chosen by this WG to add confidentiality,
integrity and device authentication for the transport of event messages.
I do feel, however, that the syslog processes on both the sender and
receiver require greater participation if we are to meet the goals of
our charter.
Thanks,
Chris
>Separating security and syslog allows the two 'technologies' to evolve
>separately with the generic security developments being available to other
>protocols as other security risks are addressed.
>
>I have read in the archive about the requirement for syslog
'finger-printed'
>messages, so that the authenticity of messages can be checked latter. If
>IPSEC is protecting the syslog messages arriving, then this option could be
>disabled. If the authenticity needs to be 'historical' or 'mobile', then
per
>message finger printing could be used as well - perhaps using digital
>signatures (another service from the 'security API' perhaps).
>
>
>Thanks, Steve.
