Hi All,
I am willing to accept this as a WG document. There are some items that
Miao has noted below. Let's get some discussion going now so Miao and
Yuzhi can deliver a clean -00 ID.
We're not going to have this ID available for the Dallas IETF meeting. As
such, I'm not planning on calling a meeting there. Please let me know if
you think otherwise.
Some comments in-line.
On Fri, 17 Feb 2006, Miao Fuyou wrote:
Hi Chris,
---------------------OUTLINE----------------------------------
1, Problem statement
In reviewing the messages around the threats to the syslog protocol, it
appears that the priority of threats is as follows:
Primary:
Modification
Disclosure
Masquerading
Secondary:
Message stream modification
Not highly considered:
DoS
Traffic Analysis
Disclosure has been controversial in the discussions. It has been noted
that syslog messages are freeform text and the possibility of sending
sensitive information will always exist. This is all the more true if high
levels of debugging are enabled.
Note: This section will summary the security threats to SYSLOG discussed on
mailing list.
This needs to include the definitions of "sender", "reviever", etc. as
they are defined in Section 3 of syslog-protocol-16. The TLS devices of
"client" and "server" should be defined in the next section, or in Section
4, or perhaps in the "Conventions Used in this Document" section. I
suspect that the syslog message "sender" will always be the TLC "client".
Anyone disagree with that?
2, Introduction to TLS
2.1 How TLS works
TLS establishes a private end-to-end connection, optionally including strong
mutual authentication, using a variety of cryptosystems. Initially, a
handshake phase uses three subprotocols to set up a record layer,
authenticate endpoints, set parameters, as well as report errors. Then,
there is an ongoing layered record protocol that handles encryption,
compression, and reassembly for the remainder of the connection. Application
data protocol, such as SYSLOG, works as a client of record protocol.
2.2 Security Property
TLS security properties: Integrity verification (by Hash MAC with MD5 and
SHA1), Data origin authentication (by Certificate/signature along with hash
MAC), Confidentiality/Privacy (by encryption/decryption with DES, AES, RC2
etc), Anti-replay (by sequence number with integrity verification).
3, TLS to mitigate SYSLOG security threats
Integrity verification to counter modification
Data origin authentication to counter masquerading
Confidentiality/Privacy to counter disclosure
Anti-replay to counter message stream modification
4, Framework
4.1 Roles
SYSLOG sender works as TLS client and receiver as TLS server.
Note: It is possible to reverse the role, i.e. sender is TLS server. But it
looks odd and there is no obvious benefit observed right now.
Syslog relay can be either TLS client or server.
A relay will be both TLS client and server.
4.2 Protocol Port
A port number should be allocated.
5, Protocol Elements
5.1 Initiation
The Sender should initiate a connection to the Receiver on the appropriate
port and then send the TLS ClientHello to begin the TLS handshake. When the
TLS handshake has finished the Sender may then initiate the first SYSLOG
message.
Note: We need to define how syslog interpret the authentication certificates
exchanged by handshake protocol.
Note: We need to discuss what authentication we need: client authenticated
to server, server authenticated to client, or both (mutual authentication)
This needs to be discussed by the Working Group. All: Please comment.
5.2 Sending data
All SYSLOG message MUST be sent as TLS "application data".
We need to discuss:
5.2.1, Multiple SYSLOG messages in one TLS message or one SYSLOG message in
one TLS message? How to parse TLS message into several SYSLOG messages in
the multiplexing mode?
I'll open a separate thread about this.
5.2.2, Does SYSLOG message truncation will affect the transport?
5.3 Closure
Sender MUST send a closure alert before closing the connection. Sender which
are unprepared to receive any more data MAY choose not to wait for the
Receiver 's closure alert and simply close the connection, thus generating
an incomplete close on the Receiver side. Receiver MUST attempt to initiate
an exchange of closure alerts with the Sender before closing the connection.
Receiver MAY close the connection after sending the closure alert, thus
generating an incomplete close on the Sender side.
5.4 Relay
5.4.1 It seems expensive to a SYSLOG Relay to become TLS client or server.
Is it possible to relay SYSLOG message without TLS processing?
No; the relay will need to view the <PRI> or other information in the
message to decide if it needs to be relayed, and if so to where.
5.4.2 There are hostname or IP in SYSLOG message header. A implementation
should not check the hostname/IP against TLS certificate because of relay.
This falls under the threat of message stream modification. A brief note
about this in the Security Considerations section should take care of
this. It will be fully addressed in syslog-sign.
6 Security Consideration
6.1 Coexist of TLS and SYSLOG-SIGN
TLS and SYSLOG-SIGN address quite different security requirements. Data
origin authentication of TLS checks whether the data is received from the
SENDER (device or relay), but the SYSLOG-SIGN check whether the data
originates from a specific DEVICE.
Do not reference syslog-sign in this document. We do not want to create
any additional dependencies. This document, syslog-protocol and
syslog-transport-udp will go to the IESG together. syslog-sign can come
after these.
The syslog-sign certificate and tls client certificate are not exchangeable
because a sender may be a relay. Another reason is sender may have several
certificates for different purpose.
6.2 Mutual Authentication?
Let's see what the WG has to say about this.
Thanks,
Chris
_______________________________________________
Syslog mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/syslog
