Subject: RE: [Syslog] Coming to consensus on syslog threats

From: "David B Harrington" <[email-masked]>
Date: Thu, 16 Feb 2006 10:01:39 -0500

Hi Miao and Yuhzi,

It would be easier if you used a consistent numbering/lettering scheme
in your outline, so a reviewer can refer to your #2, and be
unambiguous.

I recommend adding the following as you expand the outline:
1) The Problem Description - what security threats need to be
addressed for syslog environments (free of any discussion of TLS as
the soution)
Describe the relationships between the architectural syslog entities
(sender vs receiver vs relay), and the threats to each entity and the
connections between them (the discussion that has been happening
recently on the list).

2) Introduction to TLS
2a) Include an introduction to how TLS works, free of any discussion
of syslog, described in a high-level manner, for all those syslog
users who do not have a background in TLS.
A simple high-level description of the basic steps would be helpful.
2b) The threats that different features of TLS are designed to
mitigate (your current #2).

3) How TLS addresses the syslog threats
The threats to syslog (from #1 above) and how TLS threat mitigation
(#2b above) applies to those threats in a syslog environment, possibly
described in an architectural way: the connection fron sender to relay
has the threat of disclosure, so the encryption features of TLS should
be applied to that connection, etc.

And I have these comments:

4) The WG has had a problem staying focused on security. I would avoid
the discussion of the upgrade from syslog/TCP to syslog/tcp/tls in the
document if possible. It is not currently in scope for this WG to
discuss or standardize syslog/TCP, and mentioning syslog/tcp in the
syslog/tls document could open a big rathole for those who want to
discuss syslog/tcp before discussing syslog/tls. It can also lead to
references between this document and a yet-to-be-written document, and
that can get messy in the publication process. The best approach might
be to have the charter state that there are two scenarios, but that
this document only addresses syslog/tls, not syslog/tcp/tls, so you
can totally ignore it in the syslog/tls document.

5) there has been some IETF work done on using TCP-based transport for
NM protocols. If you haven't already looked at them, there might be
some useful information about session management in the netconf
-transport- drafts and in the snmp/tcp RFC. The ISMS WG will also need
to address these issues, so don't be afraid to touch base with ISMS
participants (but please don't cross-post). To my knowledge, none of
the NM/secure-stream protocols have done a good job discussing TCP and
session issues. You might also consult with Margaret Wasserman
(netconf/ssh) and Juergen Shoenwaelder (snmp/tcp) to make sure the
likely issues are identified.

David Harrington
[email-masked]

> -----Original Message-----
> From: Miao Fuyou [mailto:[email-masked]] 
> Sent: Thursday, February 16, 2006 3:55 AM
> To: 'Chris Lonvick'
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Syslog] Coming to consensus on syslog threats
> 
> Chris, 
> 
> 
> Outline of Syslog TLS Transport
> 
> 1, Security threats of syslog and security properties of TLS
> 1) Syslog threats: modification, eavesdropping and masquerading 
> 2) TLS security properties: Integrity verification(Hash MAC with 
> MD5 and SHA1) to counter modification, Data origin authentication
> (Certificate/signature along with hash MAC) to counter masquerading,
>  Confidentiality/Privacy(encryption/decryption with DES, AES, RC2 
> etc) to counter disclosure. The security property of TLS counters
>  the threats to SYSLOG well. So the primary problem is how to
>  make SYSLOG work along with TLS. 
> 	
> 2, Framework
> 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.
> 
> 3, Protocol Port
> Two modes: SYSLOG over TLS and Upgrading TCP to TLS within SYSLOG 
> SYSLOG over TLS: SYSLOG communication happens after TLS Shakehand.
>  A port number should be allocated for the mode. UpgradingTCP to
>  TLS within SYSLOG: SYSLOG communication already happens over TCP
> , server/client send a message to peer to ask the other party to
>  use TLS over the same TCP connection. This mode reuses SYSLOG
>  TCP transporting port number allocated (probably not available 
> right now). The draft only deals with the first scenarios. 
> 
> 4, Protocol Elements
> 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 discuss what authentication we need: client 
> authenticated to server, server authenticated to client, or 
> both (mutual authentication)
> 
> 2) Sending data
> All SYSLOG message MUST be sent as TLS "application data".
> We need to discuss:
> a, 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? 
> b, Does SYSLOG message truncation will affect the transport? 
> 
> 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.
> 
> 4) Relay
> a, It seems expensive to a SYSLOG Relay to become TLS client
>  or server. Is it possible to relay SYSLOG message without 
> TLS processing? 
> b, There are hostname or IP in SYSLOG message header. A 
> implementation should not check the hostname/IP against TLS
>  certificate because of relay.
> 
> 5, Security Consideration
> 1, Coexist of TLS and SYSLOG-SIGN
> TLS and SYSLOG-SIGN address quite different security requirements.
>  Data origin authentication of TLS authenticates whether the
>  data is received from the SENDER (device or relay), but the 
> SYSLOG-SIGN check whether the data originates from a specific
>  DEVICE. 2, Mutual Authentication? 
> 
> 
> -----Original Message-----
> From: Chris Lonvick [mailto:[email-masked]] 
> Sent: Sunday, February 12, 2006 5:14 AM
> To: Miao Fuyou
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Syslog] Coming to consensus on syslog threats
> 
> 
> Hi Miao and Yuzhi,
> 
> As Tom Petch pointed out we do need to establish that a TLS 
> transport will 
> address the threats we have described.  Would you briefly 
> outline how you 
> propose to utilize TLS to address Modification, Disclosure, 
> Masquerading? 
> (Others can jump in here with more comments and concerns so 
> the document 
> can get a good start.)  Once we establish that I believe we 
> can accept 
> your offer to write the document.
> 
> Many thanks,
> Chris
> 
> 
> On Wed, 8 Feb 2006, Miao Fuyou wrote:
> 
> >
> > I and Yuzhi would like to edit a draft on syslog tls transport. We

> > will get the draft  posted ASAP.
> >
> > Miao
> > [email-masked]
> >
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]]
> > On Behalf Of Chris Lonvick
> > Sent: Tuesday, February 07, 2006 10:10 PM
> > To: [email-masked]
> > Subject: [Syslog] Coming to consensus on syslog threats
> >
> >
> > Hi,
> >
> > 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.
> >
> > Also from the list, it appears that the use of TLS is supported
and 
> > will address these threats.  I will ask for volunteers to write 
> > syslog-protocol-tls and get it through the process.
> >
> > It looks like syslog-protocol and syslog-transport-udp are 
> very close 
> > to being finished.  I'd like to wrap those up and fully 
> concentrate on 
> > syslog-transport-tls, syslog-sign, and syslog-device-mib. 
> > syslog-transport-tls will have to go through the process at 
> the same 
> > time as syslog-protocol and syslog-transport-udp.  I'll ask 
> Rainer and 
> > Anton to please be patient while we complete this final document.
> >
> >
> > With that, I'll propose the following Charter revision and 
> Milestones.
> >
> > ---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 modification, 
> 
> > disclosure, and masquerading.  A secondary threat is message
stream 
> > modification.  Threats that will not be addressed by this 
> WG are DoS 
> > and traffic analysis.  The primary 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 secondary threat of message stream 
> > modification can be addressed by a mechanism that will verify the 
> > end-to-end integrity and sequence of 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:
> >
> > Nov 2006   Submit Syslog Protocol to the IESG for consideration as
a
> >              PROPOSED STANDARD.
> > Nov 2006   Submit Syslog UDP Transport Mapping to the IESG for
> >              consideration as a PROPOSED STANDARD.
> > Nov 2006   Submit Syslog TLS Transport Mapping to the IESG for
> >              consideration as a PROPOSED STANDARD.
> > Nov 2006   Submit Syslog Device MIB to IESG for consideration as a
> >              PROPOSED STANDARD.
> > Nov 2006   Submit a document that defines a message signing and
> >              ordering mechanism to the IESG for consideration as a
> >              PROPOSED STANDARD
> >
> >
> > ---^^^---
> >
> > Thanks,
> > Chris
> >
> > _______________________________________________
> > Syslog mailing list
> > [email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

_______________________________________________
Syslog mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/syslog

---

From: "Rainer Gerhards" <[email-masked]>
Date: Fri, 24 Feb 2006 08:12:08 +0100

I agree with Anton. I would *expect*, however, that on the same client
the same cert is used. I would expect that multiple clients also use the
same cert (with less likelyhood). I would not outrule any of the
"unexpected" cases.

If you look at the current deployments using stunnel, you can find this
in practice.

Rainer 

> From: Anton Okmianski (aokmians) [mailto:[email-masked]] 
> Sent: Friday, February 24, 2006 6:20 AM
> To: Miao Fuyou
> Cc: [email-masked]
> Miao: 
> > I thinks it is good that all TCP/TLS clients in the same host
> > (device, relay or collector) share same client cert. 
> 
> It depends on what you want to authenticate. I would mandate 
> a tie of client identity to identity of the host.  
> 
> > My 
> > further suggestion
> > is to resuse
> > tls session for all clients in same host.  
> 
> While a valid use-case, we cannot mandate a central syslog 
> agent on host which all clients must use. Each application 
> should be allowed to function as independent an syslog client IMO. 
> 
> > But, I don't think 
> > the certs can be generic to different hosts, it will weaken 
> > the security of
> > TLS. 
> 
> There are legitimate use-case for that.  It depends on what 
> you want to authenticate.  For example, if I want to allow 
> access to my server to all applications of type X which all 
> share the same certificate even thought they are on different 
> hosts.  In this case, I am authenticating the application 
> type, not specific client or host. 
> 
> Anton. 
>