Subject: RE: [Syslog] Re: Threat model and charter

From: "Rainer Gerhards" <[email-masked]>
Date: Wed, 11 Jan 2006 10:37:54 +0100

Chris,

I can probably not comment on everything in the conversation between
Chris and Sam, but I can put in some real-world experience. With syslog,
we have not (yet) natively  implemented TLS (this is planned, but if an
I-D will surface, we'll probably wait a little bit and try to do it "the
standards way"). However, we support syslog over SSL/TLS with the help
of the stunnel tool. This option is quite popular. Besides that it
requires a second software, you can think of it as being an syslog/TLS
implementation (this is also the reason we are not really pressed in
implementing it natively).

It is true, TLS does not necessarily provide peer authentication. Many
folks have deployed it without authentication because their primary
threat is the clear text message transport. They do not want the data to
be visible to an onlooker. Unauthenticated TLS works well with that.

These systems are often inside the local Intranet, only. Some of them
guard the syslogd via firewall rules, others allow only specific senders
and again others combine these two methods. As the underlying transport
is (non-standard) syslog/plain tcp, it is not trivial to spoof a sender
IP address, so this level of "authentication" is usually considered to
be sufficient. It is also extremly esay to implement, which explains its
popularity.

However, it *is* possible to authenticate the peers via X.509
certificates. Any TLS implementation can do client and server
certificate verification as part of the session setup process. To the
best of my knowledge, some folks use this feature with stunnel. So the
server accepts messages only from clients which are authenticated via
their certificate (their certificate-based names are configured at the
server side).

Please note that this does not authenticate a specific *user* but rather
a sender machine (or process). In my point of view, this is not a
disadvantage but a requirement. Syslog senders need to be capable of
automatically restarting and thus some authentication information must
be stored at the client (please note that for highest security, you can
protect the certificate with a passphrase so that upon machine startup
an operator must manually enter it - this option is IMHO impractical for
syslog, but I wanted to state it).

Based on this experience, I would recommend the following:

#1 REQUIRE (unauthenticated) TLS to address
   6.4 Reliable Delivery
   6.6 Message Observation

#2 RECOMMEND / allow certificate-based authentication
   during TLS session setup to address
   6.5 Message Integrity
   6.3.4 Replaying
   6.2 Message Authenticity
   8.8.  Misconfiguration (from -protocol-16, solved partly)
   8.11.  Denial of Service (from -protocol-16, mitigated)

[all section numbers are from RFC 3164 except otherwise noted]

The important point is that I recommend NOT to mandate authentication,
as the operational overhead might not be desirable for an operator
(practice tells me this).

On the other hand, it might make sense to mandate that a -transport-tls
(let me call it so for now) compliant implementation MUST support #2,
but MUST be configurable to not use it. That way, we would require that
each implementation supports full security but do not force the operator
to use it. However, I am not sure if such wording is within the scope of
the IETF.

Programatically, implementing #2 is pretty easy when #1 is done. So #2
should technically not cause any loss of implementor acceptance.

I am not expert enough to tell what other subleties TLS might have in
stock. I am talking on my practical experience ;)

-transport-tls would need to have two parts:

#1 framing (how to place -transport messages into the stream)
#2 tls specific wording

If it helps, I would be available to work on #1, but #2 is most probably
above my head.

As -transport-tls calls to a final solution to the dangling framing
issue, it technically makes sense to hold final submission of -protocol
until this has been solved. The framing discussion might be more
productive if we are somewhat flexible in the -protocol area (namely:
ending terminator, we have only a very weak consensus on this). I do not
see any big problem when we hold submission of -protocol and
-transport-udp unless -transport-tls is finished. Except, of course, all
milestones must be moved accordingly. In any case, we should still
finish work on -protocol and -transport-udp NOW and then concentrate on
-transport-tls. Changes to -protocol should only be made if there is
really good reasoning to do so.

Given the wide deployment of SSL/TLS syslog and the low deployment of
SSH (I think Kiwi uses it optionally), I'd strongly recommend taking the
TLS route. Implementor acceptance will probably be much greater thanks
to the well-known, well-used, well-available and quite good openssl
library. I do not see what SSH would offer us that TLS can not do.

Rainer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Chris Lonvick
> Sent: Tuesday, January 10, 2006 7:33 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Syslog] Re: Threat model and charter
> 
> Hi Working Group,
> 
> I'll pass this along to those people who have already implemented 
> syslog/TLS(SSL).  Please be specific about why you did this.
> 
> Thanks,
> Chris
> 
> On Tue, 10 Jan 2006, Sam Hartman wrote:
> 
> > Hi.
> >
> > Can you explain what actions on a part of an attacker are 
> prevented in
> > terms of attacks on message integrity without authenticating the
> > source of the message?
> >
> > In general, the security community is very suspicious of mechanisms
> > that provide integrity without authentication.  If you are going to
> > propose such a mechanism then you need to explain why it is
> > appropriate in your environment.
> >
> > In effect, in terms of integrity, it sounds like you say that it is
> > important for a sender to know that the message has been transported
> > to the receiver unmodified.  However since the receiver 
> does not know
> > who is sending it the message, the receiver cannot know 
> anything about
> > the integrity of the message.
> >
> > It may be a bit more complicated than that.  If the message contains
> > confidential information that an attacker could not have generated
> > then the receiver may actually know that the message is unmodified
> > without knowing who generated it.
> >
> > However it seems like your proposal does not protect 
> against a number
> > of attacks.  In particular, an attacker can generate messages
> > appearing to come from any source and containing content of the
> > attacker's choosing.  This combined with the ability to suppress
> > messages sounds like enough to get around any message integrity you
> > might have.
> >
> >
> > Also, I'd reword the charter bullet regarding the secure transport.
> > You want a bullet claiming that you will write a document 
> describing a
> > secure transport.  Actually requiring the secure transport be
> > implemented happens in the protocol document.  As a result, 
> you cannot
> > submit syslog-protocol to the IESG until this transport document is
> > written.  It might be possible for the protocol document not to
> > discuss mandatory transports at all and for there to be a later
> > applicability statement for syslog requiring protocol, the secure
> > transport and UDP.  RFC 2026 does allow that structure but I don't
> > know of any WG who has actually done things that way.
> >
> > --Sam
> >
> 
> _______________________________________________
> 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: Balazs Scheidler <[email-masked]>
Date: Wed, 11 Jan 2006 13:04:04 +0100

> their certificate (their certificate-based names are configured at the

I basically agree with you, one minor addition that this X.509
certificate based authentication is a hop-by-hop authentication and
provided the operator trusts all devices on the message path and
requires authentication on each hop, then message authenticity can be
ensured. There's no per-message signature, thus it is not proovable that
a message was generated by a given device after it has been received and
stored. 

A parallel example: It is in a sense similar to client authentication in
HTTPS: if you upload a file using HTTPS where client certificate was
required and validated, then the file on the server can be trusted to a
certain extent (as much as the HTTPS server can be trusted), however
there's no means to prove that the file has not been tampered with after
it has been received. There was no signature _stored_ along the file and
no such signature exists in the HTTPS protocol itself, to do this the
HTTPS client would need to generate a signature before transmission and
upload the signature along with the file itself.

Back to syslog: TLS and X.509 certificate authentication is hop-by-hop
and authenticates the infrastructure and network transmission (like
HTTPS itself), syslog-sign is a per-message authentication similar to
the client-side-sign-and-upload-along-with-file example in HTTPS as
described above.

-- 
Bazsi

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 11 Jan 2006 06:19:00 -0800 (PST)

Hi,

I was thinking that if we have to do authentication then we could try to 
get consensus on a simple authentication mechanism - a shared secret. 
Essentially, each sender would have to be configured with a shared secret 
before it could use TLS.  The receivers and relays would also have that 
information.  When a sender prepares a message, it would hash the shared 
secret with the formed message.  That hash could be placed in an SD 
element ( [tlsAuthChk="12345678..."] ).  The recipient could extract the 
value, and then re-run the hash.  If the received hash is the same as the 
calculated hash then both the sender and the receiver must be using the 
same shared secret.  The caveat to this is in choosing the right hash 
algorithm.  This mechanism and shared secret authentication has been well 
defined in many prior RFCs.  A lot of those RFCs used MD5 which is now 
going out of favor.  Check out RFC 1305 (NTP - appendix D) and RFC 2385 
(authentication for BGP).

This suggestion tries to keep the ease-of-use of syslog.  Using 
credentials stored in an X.505 certificate (of the recipient) would 
provide a higher degree of authentication - shared secrets can be much 
more easily compromised (found, guessed, brute-forced, etc.) than the 
validated credentials contained in a certificate.

If we can get consensus that an in-packet authentication mechanism like 
this is sufficient to meet our threat model, then we can decide if the 
shared secret is sufficient (the REQUIRED mechanism), and/or if we want to 
RECOMMEND a similar X.509 mechanism.  That would require having each 
syslog sender to have an X.509 certificate, and have those signed and 
available.  That just seems to me to be getting a bit far away from the 
ease-of-use that makes syslog so easy to deploy.

Thoughts?

Thanks,
Chris

---

From: Balazs Scheidler <[email-masked]>
Date: Wed, 11 Jan 2006 15:28:02 +0100

> ease-of-use that makes syslog so easy to deploy.

I don't like this approach as this check does not prove authenticity as
each device in the chain can regenerate the same checksum. So I fail to
see how this adds to security compared to using hop-by-hop TLS with
x.509 certificate checking as it requires the same trust in the involved
devices.

-- 
Bazsi

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 11 Jan 2006 06:29:37 -0800 (PST)

Hi,

I forgot to address the use of SSH for authentication.  The isms WG is 
trying to use SSH to provide security for SNMPv3.  This can be done by 
having the devices authenticate by having a username and credential 
(password, public key, etc.).  Again, this sounds to me like it's getting 
further away from the ease of deployment for syslog than we'd like. 
However, Rainer mentioned that he thought some people were already using 
SSH to transport syslog.  I need to ask:  How many people have 
implementations that use SSH, and how many are planning this?

Thanks,
Chris

---

From: Balazs Scheidler <[email-masked]>
Date: Wed, 11 Jan 2006 15:40:06 +0100

> implementations that use SSH, and how many are planning this?

I for one (syslog-ng) don't plan to add native support to SSH, although
SSH can be integrated into syslog-ng by using the program destination,
something like this:

program("ssh -i /etc/syslog-ng/ssh.key [email-masked] /usr/bin/logger -f");

However I don't see this as a very good solution. On the other hand I'm 
planning on adding TLS natively (instead of using stunnel style hacks).

-- 
Bazsi

---

From: Sam Hartman <[email-masked]>
Date: Wed, 11 Jan 2006 10:00:12 -0500

I'm concerned that your analysis seems to be based on what is easy to
implement.

We also need to do the analysis of what security is actually required
by syslog deployments.
If the ansers are different, we'll have to deal with that.  

But e are in a different situation if we decide to do something
because we don't know how to do better than if we meet what we believe
the security requirements are.

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 11 Jan 2006 17:35:08 -0500

Hi,

Note that ISMS has a user-authenticatioin requirement for mapping to
data access controls, while I do not believe that to be a requirement
of syslog.

David Harrington
[email-masked]

> Sent: Wednesday, January 11, 2006 9:30 AM
> To: Balazs Scheidler
> Cc: [email-masked]
> Subject: SSH - RE: [Syslog] Re: Threat model and charter
> 
> Hi,
>

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 12 Jan 2006 07:48:14 -0800 (PST)

Hi Sam,

I also have a concern that we may try to craft an answer that provides 
good security but that won't actually be deployed.  As an analogy, snmp 
has similar characteristics to syslog.  usm has good security properties 
but has not been widely deployed.  isms is trying to redress that and is 
also getting bogged down in transport issues.

RFC 3562 (Key Management Considerations for the TCP MD5 Signature Option) 
indicates that shared secrets don't get deployed unless there is a real 
threat.  Even then, it takes a lot of effort to maintain those credentials 
across a very large network.  Utilizing X.509 credentials has much better 
security properties but are the operations groups of large networks going 
to be willing to implement that?

I would like to hear more discussion from developers, operators and 
network managers before we draw conclusions.

Thanks,
Chris

---

From: Sam Hartman <[email-masked]>
Date: Thu, 12 Jan 2006 15:53:07 -0500

I agree with your concerns.

I believe the only real issue you need to solve before you are done
with the chartering discussion is whether you are going to have a
transport or whether you are going to use something like syslog-sign.

I *think* that you'll need to know what security threats you consider
important in order to answer that question.

--Sam

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 13 Jan 2006 14:00:13 +0100

Replying to no-one specifically, I think one significant consideration is being
missed.

Basing security on a secure transport may already exist as an implementation but
not as an I-D.  I expect it to take at least 6 months, more like 12, to produce
an IESG ready I-D.  By that time, our long-suffering editor of syslog-protocol
says he will have had to stand down.  I believe that means we will never produce
the two I-Ds needed for advancement and that the WG will shut down with nothing
done.

More hopefully, I do believe that the threats can be met by syslog-sign.  Almost
every user I talk to about security wants encryption.  I have to work very hard
to do so, but mostly succeed, in demonstrating to them that what they need is
message origin authentication and integrity and it just so happens that that is
what most IPS protocols offer, and, even better, it is much cheaper than
encryption.

I believe syslog falls into this category for most users, and that the aims of
syslog-sign will meet most requirements.  I hear it criticised for having the
wrong algorithms.  Fine, we must change that since every security system
nowadays should be algorithm agnostic.  MD5 got busted, fine we switch to SHA-1.
SHA-1 under threat, no problem, roll on SHA-256.  This process will go on for
ever so we must incorporate it in anything we produce - like syslog-sign.

And, given the state of syslog-sign, current editors still willing, I believe we
can get those two I-Ds ready inside four monhts.

The only realistic alternative would be to incorporate signature blocks in the
style of syslog-sign in the structured data of the message being authenticated.

Tom Petch

---

From: Sam Hartman <[email-masked]>
Date: Fri, 13 Jan 2006 09:31:38 -0500

>>>>> "Tom" == Tom Petch <[email-masked]> writes:

    Tom> More hopefully, I do believe that the threats can be met by
    Tom> syslog-sign.  Almost every user I talk to about security
    Tom> wants encryption.  I have to work very hard to do so, but
    Tom> mostly succeed, in demonstrating to them that what they need
    Tom> is message origin authentication and integrity and it just so
    Tom> happens that that is what most IPS protocols offer, and, even
    Tom> better, it is much cheaper than encryption.

I'm not sure it is true that message origin authentication and
integrity is much cheaper than encryption with either symmetric or
asymmetric cryptography.

This may be true when comparing a traditional symmetric block cipher
to a hash implemented in software.

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 17 Jan 2006 12:20:45 -0800 (PST)

Hi Tom,

> style of syslog-sign in the structured data of the message being authenticated.

Your suggestion has good reasoning behind it.

I have not heard back from anyone about how SSL is currently being 
implemented for syslog.  From that, I might conclude that message 
confidentiality is not a priority for the community.  (Responses to that 
would be welcome.)

If origin authentication, and loss detection are important then 
syslog-sign is a fit.  Can we get some discussion on this?

Thanks,
Chris