Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt

"Rainer Gerhards" <rgerhards@hq.adiscon.com> Tue, 13 May 2008 05:46 UTC

Return-Path: <syslog-bounces@ietf.org>
X-Original-To: syslog-archive@megatron.ietf.org
Delivered-To: ietfarch-syslog-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E99828C2C3; Mon, 12 May 2008 22:46:01 -0700 (PDT)
X-Original-To: syslog@core3.amsl.com
Delivered-To: syslog@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1F328C2C3 for <syslog@core3.amsl.com>; Mon, 12 May 2008 22:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zbVG1q2L2CM for <syslog@core3.amsl.com>; Mon, 12 May 2008 22:45:58 -0700 (PDT)
Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 2803228C2AB for <syslog@ietf.org>; Mon, 12 May 2008 22:45:57 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 2ECAA7ADFD3; Tue, 13 May 2008 07:43:07 +0200 (CEST)
Received: from mailin.adiscon.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzuA-OkcdREZ; Tue, 13 May 2008 07:43:07 +0200 (CEST)
Received: from grfint2.intern.adiscon.com (p50989a7c.dip0.t-ipconnect.de [80.152.154.124]) by mailin.adiscon.com (Postfix) with ESMTP id E39BA7ADD46; Tue, 13 May 2008 07:43:06 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 13 May 2008 07:43:46 +0200
Message-ID: <577465F99B41C842AAFBE9ED71E70ABA308FC5@grfint2.intern.adiscon.com>
In-Reply-To: <AC1CFD94F59A264488DC2BEC3E890DE505C95BEA@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt
Thread-Index: AcixJ3ChaVnUq5oITfGwAnnHJ7WqPwAfO5owABfCe0AAmYDUoAAETG6AABAwLkA=
References: <20080507150001.D3CB428C65B@core3.amsl.com> <OF13490747.F0126D34-ON85257443.00540976-85257443.00574A09@agfa.com> <577465F99B41C842AAFBE9ED71E70ABA308FB3@grfint2.intern.adiscon.com> <AC1CFD94F59A264488DC2BEC3E890DE505C95869@xmb-sjc-225.amer.cisco.com> <577465F99B41C842AAFBE9ED71E70ABA308FC3@grfint2.intern.adiscon.com> <AC1CFD94F59A264488DC2BEC3E890DE505C95BEA@xmb-sjc-225.amer.cisco.com>
From: Rainer Gerhards <rgerhards@hq.adiscon.com>
To: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>, robert.horn@agfa.com, syslog@ietf.org
Subject: Re: [Syslog] I-D Action:draft-ietf-syslog-transport-tls-12.txt
X-BeenThere: syslog@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Issues in Network Event Logging <syslog.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/syslog>
List-Post: <mailto:syslog@ietf.org>
List-Help: <mailto:syslog-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/syslog>, <mailto:syslog-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: syslog-bounces@ietf.org
Errors-To: syslog-bounces@ietf.org

Hi Joe,

[big snip]
> [Joe] We are not talking about HTTPS we are talking about syslog.
What
> applies to one may not necessarily apply to the other (HTTP provides
> other ways to authenticate the client etc.).  In addition HTTPS
> authenticates the server in most cases.  In any case, I don't think
you
> can claim confidentiality if you do not take care of masquerade or
> man-in-the-middle as either will result in a breach of
confidentiality,
> you are still vulnerable to active attackers.
> 
> I believe that implementations need to support mutual authentication
> and
> authorization with certificates.  The recommended mechanisms for this
> probably still need some discussion, however I think it is important
to
> provide this capability.  I think what is more to the point in the
> current discussion is what is required by default.  

That is what I was talking about. I do not say that I do not like full
blown security. What I say is that I prefer weaker security even for the
unskilled user in favor of no security. As I wrote, my suggestions were
for the default case.

> I would like to
> suggest that server authentication, certificate path validation and
> authorization be required by default, because I without this I don't
> think any security goals are met.  I would also suggest that by
default
> clients should present and authenticate with a certificate, however a
> server does not necessarily need to perform path validation or
> authorization, it can just record the certificate (or fingerprint)
that
> carries the public key used in the authentication so it can be
> validated
> at a later time.
> 
> This requires configuration on the client, but not necessarily on the
> server.

The server needs to be configured with the client identities.

Anyhow... I think we have exchanged enough arguments for now. We are
right now obviously looking from different angles (skilled users via
home users), which makes it hard to come to a conclusion.

At least I will now continue to implement the current draft. I can
always add different authentication modes later, so it doesn't hurt to
implement a basic set. Plus, the draft allows for anonymous
authentication. I'll make it very easy to turn this on, what probably
solves the home user problem I see.

I'll post notes if I come along anything noteworthy during
implementation.

Rainer

_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog