Hi All,
I'd like to address this topic in three parts:
1) The threat model and what threats we feel are important to address
2) How we should address those threats
3) Wording our charter
== 1 ==
I'd like to review the on-the-wire threats documented in RFC 3164 and see
what we want to address.
From RFC 3164 Section 6:
6.2 Message Authenticity (incl. Forgery)
6.3 Sequenced Delivery (incl. Replaying)
6.4 Reliable Delivery
6.5 Message Integrity
6.6 Message Observation
6.7 Message Prioritization and Differentiation
Including a per-message signing mechanisms would address message
authenticity (6.2). However, that would require key maintenance and would
require a lot of touching of the end-points. That seems to be
counter-productive to current implementations of syslog. I've found that
many are willing to put up with unauthenticated messages rather than to
have to step up their maintenance of those systems.
[ TLS is not required to authenticate the client. SSH can (SHOULD)
[ require that the user authenticate to the server. Utilizing SSH could
[ provide a mechanism to address 6.2, but again that seems to be higher
[ maintenance than what most people would like to do for syslog.
Sequenced delivery (6.3) will be addressed by the eventID SD element in
syslog-protocol.
[ syslog-sign will additionally address this by including the engineID.
[ Additionally, a REQUIRED secure transport would ensure proper
[ sequencing but would not alone provide stored-message sequence
[ verification.
Reliable delivery (6.4), message integrity (6.5), and message observation
(6.6) may be addressed through the use of a REQUIRED secure transport.
[ Both SSH and TLS will provide this as long as they use sufficiently
[ appropriate ciphers.
Message prioritization and differentiation are not entirely protocol
issues and they are addressed in RFC 3195.
[ I suggest that we drop this as a threat that we will address.
If we agree that message authenticity is not going to be in the
critical path of the current effort in the WG, then we can conclude that
our threats can be addressed by a REQUIRED secure transport.
Sequenced Delivery
Reliable Delivery
Message Integrity
Message Observation
== 2 ==
The discussion of a secure transport has come up before. Most of the list
requested that TLS be considered if we do go down that path. The
reasoning was that TLS is already in wide use to transport syslog messages
and implementors would really like to continue using that.
SSH as a transport is acceptable but seems to require a higher level of
operations support than TLS. There are also no currently known
implementaitons of syslog/SSH.
I'd suggest that we REQUIRE the use of TLS to address the identified
threats. If future implementors feel that it will be beneficial to merge
isms, netconf and syslog, then the work that they are currently doing to
bind their protocols to SSH will pave the way and a future effort can
document that.
With that being said, however, it appears that Sam will allow some
discussion of a secure transport if we can address the threats in our
charter. If so, then we can abstract the secure transport for the time.
I will still continue to say that syslog-sign provides mechanisms that
will be beneficial to the community. It will provide device
authentication, stored-message integrity, stored-message integrity,
and stored-message sequence verification. These cannot be as well
addressed with per-message signing. Since this will require high-touch
maintenance I will suggest that it be taken out of the critical path of
our charter. (We'll leave it for the end and see how many people
contribute to it and indicate that they will implement it.)
== 3 ==
Proposed charter revision below:
--vvv--
Syslog is a de-facto standard for logging system events. However, the
protocol component of this event logging system has not been formally
documented. While the protocol has been very useful and scalable, it has
some known security problems which were documented in the INFORMATIONAL
RFC 3164.
The goal of this working group is to address the security and integrity
problems, and to standardize the syslog protocol, transport, and a select
set of mechanisms in a manner that considers the ease of migration between
and the co-existence of existing versions and the standard.
Reviews have shown that there are very few similarities between the
message formats generated by heterogeneous systems. In fact, the only
consistent commonality between messages is that all of them contain the
<PRI> at the start. Additional testing has shown that as long as the
<PRI> is present in a syslog message, all tested receivers will accept any
generated message as a valid syslog message. In designing a standard
syslog message format, this Working Group will retain the <PRI> at the
start of the message and will introduce protocol versioning. Along these
same lines, many different charsets have been used in syslog messages
observed in the wild but no indication of the charset has been given in
any message. The Working Group also feels that multiple charsets will not
be beneficial to the community; much code would be needed to distinguish
and interpret different charsets. For compatibility with existing
implementations, the Working Group will allow that messages may still be
sent that do not indicate the charset used. However, the Working Group
will recommend that messages contain a way to identify the charset used
for the message, and will also recommend a single default charset.
syslog has traditionally been transported over UDP and this WG has already
defined RFC 3195 for the reliable transport for the syslog messages. The
WG will separate the UDP transport from the protocol so that others may
define additional transports in the future.
The threats that this WG will primarily address are sequenced delivery
(including replay attacks), reliable delivery, message integrity, and
message observation. These attacks may be thwarted by a secure transport.
However, it must be remembered that a great deal of the success of syslog
has been attributed to its ease of implementation and relatively low
maintenance level. The Working Group will consider those factors, as well
as current implementations, when deciding upon a secure transport.
The threat that this group will not primarily address is that of message
authentication. The Working Group expects that requiring key maintenence
for syslog senders would hamper the acceptance of a new protocol.
However, there does still remain an interest in providing message
authentication and a mechanism to verify the integrity and sequence of
stored messages. The Working Group feels that these aspects may be
addressed by a dissociated signature upon sent messages.
- A document will be produced that describes a standardized syslog
protocol. A mechanism will also be defined in this document
that will provide a means to convey structured data.
- A document will be produced that describes a standardized UDP
transport for syslog.
- A document will be produced that requires a secure transport for the
delivery of syslog messages.
- A document will be produced to describe the MIB for syslog entities.
- A document will be produced that describes a standardized mechanism
to sign syslog messages to provide integrity checking and source
authentication.
Milestones:
Mar 2006 Submit Syslog Protocol to IESG for consideration as a PROPOSED
STANDARD.
Mar 2006 Submit Syslog UDP Transport Mapping to IESG for consideration
as a PROPOSED STANDARD.
Jul 2006 Submit Syslog Device MIB to IESG for consideration as a
PROPOSED STANDARD.
Nov 2006 Submit a document that requires a reliable transport for syslog
to the IESG as a PROPOSED STANDARD.
Nov 2006 Submit Syslog Authentication Protocol to IESG for consideration
as a PROPOSED STANDARD.
---^^^---
== x ==
I've given the secure transport document a deadline of November of this
year. It should be a simple document to write if we can quickly agree to
the use of a transport. However, we will need to find a document author.
Comments and thoughts would be appreciated.
Thanks,
Chris
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
