Subject: RE: [Syslog] Secure substrate - need your input

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Tue, 25 Oct 2005 11:10:48 -0400

> Hi Folks,
> 
> I'll be asking this in Vancouver but would like to get some 
> input from the mailing list.
> 
> Our charter says that we will develop a secure method to 
> transport syslog messages.  We have BEEP (RFC 3195) but it 
> has a low implementation record. 
> Other groups have specified BEEP as well but are also moving 
> along towards using SSH or SSL.
> 
> 
> 1) What secure substrate should the WG look towards:
> 
> __  ssl
> 
> __  ssh
> 
> __  dtls  
> http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt
> 
> __  other

I believe it should be SSL 3.0 / TLS 1.0.  At least in web-server farm environments, you got SSL everywhere with a bunch of SSL accelerator hardware already in place.  

I also think several mappings can be defined. I am not a fan of options when it comes to standards, but allowing syslog over any kind of secure transport is a good thing. This was the whole idea of separating syslog-protocol from syslog-transport.  Frankly, I don't think it will be a lot of work to define those transport mappings.  

> 2) Why?

SSL/TLS is the most widely deployed network security protocol today. All e-commerce happens over it. Dozens of companies provide all shapes and forms of SSL accelerators. Many routers now have SSL accelartor modules.   

If I need to manage a large environment of servers where distributed logging really makes sense, being able to re-use existing infrastructure for scaling really helps.  A search for "SSH accelerator" on google does not reveal anything interesting, but "SSL accelarator" shows up with a bunch of listings, several of which claim thousands of new SSL sessions per second. This confirms my experience. BTW, with SSL session caching, accelerators (ie. load balancers) can do 100,000 connections per second and more. So, to scale syslog over SSH would I have to wait for SSH accelerators to come to market?

I see that there is a lot of work around SSH connection protocol and its potential use in new protocols. I have not followed these developments. There must have been a good reason for it. I would like to understand why people object to SSL, which is a well established technology. Any pointers?

Thanks,
Anton.

> 
> 
> 
> 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: Darren Reed <[email-masked]>
Date: Wed, 26 Oct 2005 01:38:14 +1000 (EST)

[ Charset ISO-8859-1 unsupported, converting... ]
> I believe it should be SSL 3.0 / TLS 1.0.

I agree and for all the reasons you said.

Darren

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 25 Oct 2005 13:36:25 -0400

> I see that there is a lot of work around SSH connection 
> protocol and its potential use in new protocols. I have not 
> followed these developments. There must have been a good 
> reason for it. I would like to understand why people object 
> to SSL, which is a well established technology. Any pointers?

I agree that SSL is widely deployed, especially for e-commerce. Nobody
has objected to SSL. In many ways, the ISMS decision was 6-of-one,
half-dozen of the other - so ISMS picked the one that Netconf had
chosen. ISMS chose SSH to work on first; there is nothing that
precludes also developing a transport mapping security model for SSL,
except the desire to limit standards options to improve
interoperability, and volunteer manpower.

The ISMS and Netconf WGs chose SSH because it is widely used by
operators to perform management tasks, there was a Netconf draft that
could be adapted for ISMS usage, and having "balanced" security across
management inetrfaces makes sense. If CLI, Netconf, and SNMP run over
SSH, and syslog runs over SSL, that may make it harder to ensure that
the security characteristics of the four management interfaces are
equivalent.

Netconf wants to add notifications, and I believe they are considering
trying to use syslog as their notification approach. That might be
easier if syslog worked over the same secure transport as Netconf.

David Harrington
[email-masked]

---

From: "Tom Petch" <[email-masked]>
Date: Tue, 25 Oct 2005 18:39:14 +0200

In the context of isms, ie SNMP, the choice was SSH v TLS + SASL; TLS provides
the security but not the authentication while SSH does both.  And SSH is a
well-established protocol.

I agree that TLS/SSL is the most widely used but that is because more people
access websites (securely) than access network devices.  If you limit yourself
to network operations of network devices, then it appears to be
SSH a significant number
TLS so small as to be invisible

Tom Petch

----- Original Message -----
From: "Anton Okmianski (aokmians)" <[email-masked]>
To: "Chris Lonvick (clonvick)" <[email-masked]>; <[email-masked]>
Sent: Tuesday, October 25, 2005 5:10 PM
Subject: RE: [Syslog] Secure substrate - need your input

> http://www.ietf.org/internet-drafts/draft-rescorla-dtls-05.txt

I believe it should be SSL 3.0 / TLS 1.0.  At least in web-server farm
environments, you got SSL everywhere with a bunch of SSL accelerator hardware
already in place.

I also think several mappings can be defined. I am not a fan of options when it
comes to standards, but allowing syslog over any kind of secure transport is a
good thing. This was the whole idea of separating syslog-protocol from
syslog-transport.  Frankly, I don't think it will be a lot of work to define
those transport mappings.

> 2) Why?

SSL/TLS is the most widely deployed network security protocol today. All
e-commerce happens over it. Dozens of companies provide all shapes and forms of
SSL accelerators. Many routers now have SSL accelartor modules.

If I need to manage a large environment of servers where distributed logging
really makes sense, being able to re-use existing infrastructure for scaling
really helps.  A search for "SSH accelerator" on google does not reveal anything
interesting, but "SSL accelarator" shows up with a bunch of listings, several of
which claim thousands of new SSL sessions per second. This confirms my
experience. BTW, with SSL session caching, accelerators (ie. load balancers) can
do 100,000 connections per second and more. So, to scale syslog over SSH would I
have to wait for SSH accelerators to come to market?

I see that there is a lot of work around SSH connection protocol and its
potential use in new protocols. I have not followed these developments. There
must have been a good reason for it. I would like to understand why people
object to SSL, which is a well established technology. Any pointers?

Thanks,
Anton.

---

From: Rodney Thayer <[email-masked]>
Date: Tue, 25 Oct 2005 14:46:39 -0700

> TLS so small as to be invisible

A couple of comments -

I disagree that TLS is rare.  TLS is common, in my experience, because
many devices have web-based management interfaces and those are secured with
TLS.

Also, if your logic were correct, then all those SASL folks who hassled us
TLS people into going with STARTLS/SASL/etc must have been wrong - this
is one of those "the IETF can't declare both 1 and 0 to be truth, depending
on which RFC you read" problems.

OTOH you are using SOME standard protocol so I'm fine with SSH...

---

From: "Andrew Ross" <[email-masked]>
Date: Wed, 26 Oct 2005 10:33:17 +1300

Good points Anton,

My preference is also for using SSL/TLS. From an implementers point of view,
there is a good supply of SSL/TLS components and source code available (both
commercial and open source). This would make it easy for customers to add
secured syslog support to their apps.

We currently use SSH in our secure syslog tunnel app, but could replace it
with SSL very easily. I heard that Rainer is going to add SSL support soon
as well.

Please, no one suggest we try and run the secure protocol over UDP :-) Let's
keep to TCP as the transport for the secure/reliable protocol and keep using
UDP for the simple send and forget system.

The idea is to make it as simple as possible for a programmer to make his
application/appliance send syslog messages. Grab an SSL library, choose a
socket stack and Bob's your mother's brother.

I believe that one of the reasons that 3195 is so slow to take off is that
it is not easy to create an implementation from scratch. It is a lot easier
to just grab a UDP socket library and put <PRI> at the start of each
message. Simple is as simple does.

Cheers

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Anton Okmianski (aokmians)
Sent: Wednesday, 26 October 2005 4:11 a.m.
To: Chris Lonvick (clonvick); [email-masked]
Subject: RE: [Syslog] Secure substrate - need your input

I believe it should be SSL 3.0 / TLS 1.0.  At least in web-server farm
environments, you got SSL everywhere with a bunch of SSL accelerator
hardware already in place.  

I also think several mappings can be defined. I am not a fan of options when
it comes to standards, but allowing syslog over any kind of secure transport
is a good thing. This was the whole idea of separating syslog-protocol from
syslog-transport.  Frankly, I don't think it will be a lot of work to define
those transport mappings.  

SSL/TLS is the most widely deployed network security protocol today. All
e-commerce happens over it. Dozens of companies provide all shapes and forms
of SSL accelerators. Many routers now have SSL accelartor modules.   

If I need to manage a large environment of servers where distributed logging
really makes sense, being able to re-use existing infrastructure for scaling
really helps.  A search for "SSH accelerator" on google does not reveal
anything interesting, but "SSL accelarator" shows up with a bunch of
listings, several of which claim thousands of new SSL sessions per second.
This confirms my experience. BTW, with SSL session caching, accelerators
(ie. load balancers) can do 100,000 connections per second and more. So, to
scale syslog over SSH would I have to wait for SSH accelerators to come to
market?

I see that there is a lot of work around SSH connection protocol and its
potential use in new protocols. I have not followed these developments.
There must have been a good reason for it. I would like to understand why
people object to SSL, which is a well established technology. Any pointers?

Thanks,
Anton.

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 26 Oct 2005 11:16:03 +0200

Just to add the figures that support my assertion, in an e-mail from Wes
Hardaker, who surveyed the network operators, to isms

"Of the various authentication systems in use at that time by the people that
responded:

  66%  local accounts
  49%  SSH-keys
  40%  Radius
  29%  TACACS+
  14%  X.509 Certificates
  10%  Kerberos

  [numbers don't add to 100 because more than one option could be selected]"

which I have paraphrased as
SSH a significant number
TLS so small as to be invisible

Of course, as I hope is clear, I am talking in the context of network
operations, not of Web access (where I accept that SSL dominates).

Tom Petch

---

From: Darren Reed <[email-masked]>
Date: Wed, 26 Oct 2005 22:48:02 +1000 (EST)

> TLS so small as to be invisible

I disagree.  I don't think the numbers above provide that kind of
conclusion at all.  We don't know what the survey was, etc.  Just
like any set of statistics, they can be interpreted to mean many
things, depending on how you want to read them.

Anyway, I'm not interested in that.

But, to put the problem differently, in how many different places can
you use TLS/SSL for authentication today, to sign in ?

If there's nowhere for people to use TLS then of course the numbers
won't be high.

Darrn

---

From: "Tom Petch" <[email-masked]>
Date: Wed, 26 Oct 2005 16:21:51 +0200

In case anyone else should be interested, the survey I keep referring to was
performed of 149 operators at NANOG at the request of the IETF AD to provide
evidence that there was a problem with SNMPv3 security that the IETF should work
on.  The results were presented at IETF60 and the IESG were convinced; hence the
isms WG.

I refer to it because the IETF often bemoans the lack of operator input and this
is one time when it was sought and obtained.

And yes, as Rainer pointed out, we don't know what X.509 means and SSL/TLS (and
a few others) could be lurking in there (nothing like a survey for creating the
need for more surveys:-(.

Tom Petch