Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input

From: "Anton Okmianski \(aokmians\)" <[email-masked]>
Date: Tue, 25 Oct 2005 17:04:18 -0400

Tom:

TLS provides for asymmetric authentication. RFC 2264 Section 1:

"The peer's identity can be authenticated using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This authentication can be made optional, but is generally required for at least one of the peers."

SSL/TLS with server-side certs is pretty much a norm for all HTTPS deployments. SSL/TLS with client-side certs are used less frequently, but some organizations use those in mail clients. SMTP, IMAP, POP3 and ACAP all have mappings to TLS transport (RFC2487, RFC 2595) with commercial deployments.  

I think the reason SASL comes into the picture with certain protocols (like RFC 2595) is that TLS provides asymmetric authentication, and SASL symmetric (based on passwords), which is preferred in some protocol like mail for legacy reasons.  

Not sure if SSH provides for symmetric auth for server (vs. user) authentication. As far as I can tell from quick scan only asymmetric key support is required in SSH draft (sec 4.1):
http://www.employees.org/~lonvick/secsh-wg/2005-sep-07/draft-ietf-secsh-architecture-23.txt

I am not sure if support for symmetric keys (passwords) should be a requirement, anyway.  Maintaining a database of passwords instead of public keys (in form of certs or other way) sounds like a security threat, not to mention a choir when one could just maintain single root CA (plus revocation lists if needed).  Thoughts?

Finally, I suspect mapping to SSH will take longer to develop and longer to deploy because it will be dependent on SSH drafts (see above).    

Thanks,
Anton.

> -----Original Message-----
> From: Tom Petch [mailto:[email-masked]] 
> Sent: Tuesday, October 25, 2005 12:39 PM
> To: Anton Okmianski (aokmians); Chris Lonvick (clonvick); 
> [email-masked]
> Subject: Why not TLS was Re: [Syslog] Secure substrate - need 
> your input
> 
> 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
> 
> 
> > 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.
> 
> >
> 

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

---

From: Rainer Gerhards <[email-masked]>
Date: Wed, 26 Oct 2005 11:04:27 +0200

I agree with Anton (both his initial comment and this one) and the
others talking in favor of SSL/TLS. In addition, I would like to mention
that in current practice, ssl/tls protected syslog solutions are
*already* being deployed. This is possible thanks to the
non-IETF-standard plain tcp syslog mode that is supported by so many of
the major implementations. On top of that run either vendor-specific
ssl/tls implementations or - most often - generic tunneling via stunnel.
It is also not uncommon to authenticate the sender and client via
certificates in ssl/tls (not only in theory, but in practice).

So, I would also like to see a ssl/tls based approach - simply because
we already see massive acceptance for it.

I also agree on Anton's idea that creating a transport mapping for it is
easy. HOWEVER, that brings us back to the issue of a "really stupid
simple" tcp transmission mode. In my point of view, that would need to
be defined first and then a ssl/tls  mapping on top of it. Of course, it
can be done in a single document, but I would prefer to have two small
ones. My reasoning is that I think that would receive easier acceptance
in the implementor community.

Obviously, putting syslog in sync with netconf by using SSH is also
desirable. I just doubt that this will become quickly implemented. If
there is demand, we could add just another transport mapping. Sure, this
means multiple choices and multiple effort required. But if we talk
about effort, we must face reality: rfc 3195 is not being implemented
that often because it is much more effort than plain tcp syslog - which
provides nearly as good reliability. Current non-standard tcp syslog is
nearly no effort to implement yet still provides close to100% of the
benefits.

Let me talk as an implementor: I like to implement things that customers
(paying or not) ask for. Being a lazy person, I prefer things that are
easy to do (which means there are libraries available and some reference
implementations). I also like to implement things in areas where others
are also implementing, so I can ask questions on interpretations and
such. I like things that work reasonable well. From that perspective, a
simple tcp transport protected by ssl/tls is *very* attractive. Granted,
it does not provide the 100% reliability that rfc 3195 provides. But it
provides 99,9% of that - at a much lower cost. And if we go for a simple
app-level ACK mechanism, we would end up very close to what rfc 3195
offers in terms of reliability. If we add ssl/tls (easily done), we end
up very close to what rfc 3195 offers in terms of authenticy and
encryption (side note: rfc 3195 uses TLS, it just uses a complicated way
of configuring it...).

Given that we try to build on existing technology, this approach could
also be very quickly implemented. That, together with the known customer
demand, would probably give a standard in that area a jump start. I
prefer to sacrify being in sync with the other network management
protocols.

Just for the records: I am saying this *after* I have implemented rfc
3195. So if we would stick with 3195, only, I would already be set for
most things.

Rainer

---

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

It is not a question of asymmetric or symmetric authentication but of
user(client)
authentication; SSH has got it, TLS has not, hence the need for SASL.  To quote
the Security AD, from an e-mail he sent to the isms list detailing options to
consider,

"1) TLS/SASL.  The combination of TLS and SASL go well together.  You
   typically use one or both.  In one common mode, TLS is used to
   authenticate the server (responder) to the client.  The server has
   a cert and the client does not.  You then use SASL to authenticate
   the client to the server.  TLS is used to protect the session.
   Another common mode supported by the TLS+SASL option only involves
   SASL.  You use a SASL security layer that provides mutual
   authentication to provide both data confidentiality and integrity
   to the session  and to authenticate both parties.  This SASL-only
   mode is used by Kerberos.  A third mode involves only TLS.  Both
   the client and server have certificates.  This actually often looks
   like the first mode because the SASL external mechanism is used to
   signal that TLS has provided the client authentication."

So for technical reasons, TLS alone was insufficient.  For syslog, which is
simplex not half-duplex, more change is needed to set up any form of a secure
channel and I am not clear about the technical ramifications of that, whether
TLS alone is sufficient.

For syslog, I think it really comes down to

a) the user marketplace; Web servers (TLS) or network operations (SSH)

b) coherence within the IETF; SMTP/HTTP(TLS) v Telnet/Netconf/isms (SSH)

In both cases, I am in the latter camp.

Whichever way we go, distributing security credentials to remote, network
devices is a pain as SNMPv3 has demonstrated; for network operators, as the isms
survey showed, this is a soluble problem for SSH.

I think that the issue of I-Ds is a red herring.  TLS is a string of I-Ds,
reflecting recent work on a protocol that many have not heard of, knowing only
of SSL.  SSH is a string of I-Ds, reflecting recent work on a protocol that many
are familiar with.  In both cases, there are problems of conformance, of there
being different, not quite standard flavours, and the work of the IETF is to
bring conformity to two well established protocols (bit like syslog:-).

Tom Petch

----- Original Message -----
From: "Anton Okmianski (aokmians)" <[email-masked]>
To: "Tom Petch" <[email-masked]>; "Chris Lonvick (clonvick)"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, October 25, 2005 11:04 PM
Subject: RE: Why not TLS was Re: [Syslog] Secure substrate - need your input

Tom:

"The peer's identity can be authenticated using asymmetric, or public key,
cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This authentication can be made
optional, but is generally required for at least one of the peers."

SSL/TLS with server-side certs is pretty much a norm for all HTTPS deployments.
SSL/TLS with client-side certs are used less frequently, but some organizations
use those in mail clients. SMTP, IMAP, POP3 and ACAP all have mappings to TLS
transport (RFC2487, RFC 2595) with commercial deployments.

I think the reason SASL comes into the picture with certain protocols (like RFC
2595) is that TLS provides asymmetric authentication, and SASL symmetric (based
on passwords), which is preferred in some protocol like mail for legacy reasons.

Not sure if SSH provides for symmetric auth for server (vs. user)
authentication. As far as I can tell from quick scan only asymmetric key support
is required in SSH draft (sec 4.1):
http://www.employees.org/~lonvick/secsh-wg/2005-sep-07/draft-ietf-secsh-architec
ture-23.txt

I am not sure if support for symmetric keys (passwords) should be a requirement,
anyway.  Maintaining a database of passwords instead of public keys (in form of
certs or other way) sounds like a security threat, not to mention a choir when
one could just maintain single root CA (plus revocation lists if needed).
Thoughts?

Finally, I suspect mapping to SSH will take longer to develop and longer to
deploy because it will be dependent on SSH drafts (see above).

Thanks,
Anton.

---

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

> reflecting recent work on a protocol that many have not heard of, knowing
> only of SSL.  SSH is a string of I-Ds, reflecting recent work on a protocol
> that many are familiar with.  In both cases, there are problems of
> conformance, of there being different, not quite standard flavours, and
> the work of the IETF is to bring conformity to two well established
> protocols (bit like syslog:-).

I think most people are going to be about as familiar with the TLS protocol
as they are with the SSH one - in terms of depth of knowledge.  As for use,
well as you've pointed out, anyone using "https" is using TLS/SSL, so it's
hard to say people are unaware of it.

In both cases, people generally follow a specific "script" to achieve a
given goal without being overly concerned about the flow of bits and bytes
in the middle.

In summary, I find this line of argument quite specious.

Darren

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 26 Oct 2005 11:26:52 -0400

Hi,

As this WG struggles with the question of which secure transport to use, I
recommend reading RFC3535 - "Overview of the 2002 IAB Network Management
Workshop".

This workshop, a "world tour" of ISP organizations, and the survey of which
Tom speaks were part of an effort by the IAB and the O&M Area Directors to
get direct input from operators to ensure that future O&M work would meet
operators' needs. Netconf and ISMS directions are largely the result of the
information gathered during this effort.

The survey was put together by Wes Hardaker of NET-SNMP, and the operators
at NANOG were asked to take the survey online. Tom, do you have a URL for
that survey, so the syslog WG can see the questions and responses, so they
can assess how applicable the survey is to syslog?

Dave Harrington
[email-masked]