Re: [Syslog] Some revised text for syslog TLS

robert.horn@agfa.com Thu, 29 May 2008 13:42 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 CFADE3A6880; Thu, 29 May 2008 06:42:04 -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 C0F843A6914; Thu, 29 May 2008 06:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
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 gAmsMlXDcfh0; Thu, 29 May 2008 06:41:58 -0700 (PDT)
Received: from mornm02-out.agfa.com (mornm02-out.agfa.com [134.54.1.77]) by core3.amsl.com (Postfix) with ESMTP id D3DC83A6919; Thu, 29 May 2008 06:41:56 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,561,1204498800"; d="scan'208";a="41188490"
Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm02-out.agfa.com with ESMTP; 29 May 2008 15:41:47 +0200
In-Reply-To: <000d01c8c179$92441c80$0601a8c0@allison>
To: "tom.petch" <cfinss@dial.pipex.com>
MIME-Version: 1.0
Message-ID: <OF5AD733E7.F3F185BA-ON85257458.00491823-85257458.004B3B05@agfa.com>
From: robert.horn@agfa.com
Date: Thu, 29 May 2008 09:41:43 -0400
Cc: syslog <syslog@ietf.org>, syslog-bounces@ietf.org
Subject: Re: [Syslog] Some revised text for syslog TLS
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

[tom-petch]> 
> True, but authentication of what? This logic says you might as well use 
naked
> public/private keys, as SSH does.  For me, the point of all the 
> extra hassle of
> certificates is that the keys are bound to an identity/identifier so you 
can
> tell, to some degree (depending on what checks the CA has performed)
> to whom you
> are talking.  Then it becomes a question of what identifier to use, CN, 
MAC,
> etc.

You live in a radically different threat-asset environment than healthcare 
I can tell.  In our environment the SSH process would do fine for about 
half the users, and the official root CA approach is appropriate to about 
0% of the users.  The value of using the certificates for all of them is 
software development.  Certificates are a widely supported mechanism in 
most security libraries.  There is no comparable alternative for a 
standard format.  The half of our world that deals with authentication out 
of band can use certificates and ignore all the extraneous infrastructure. 
 Out of band mechanisms are very significant in healthcare.  We have all 
sorts of patient safety issues that must be managed.  For example, any 
hardware change (even just a board swap) can require safety retesting for 
patient contact devices.  Adding machine identification and authentication 
to that process is a low cost addition.  It's much cheaper than building 
up a suitable PKI infrastructure for the smaller sites.

The official root CA approach is a non-starter because in the other half 
of our world where chain of trust does make sense, the usual root CAs 
haven't a clue.  Do you really think that Verisign knows whether that PC 
in my local hospital has been configured for the admitting clerk's desk or 
for the surgical suite?  They do not and they do not want to keep track of 
that information.  There is a completely different chain of trust used in 
hospitals and clinics.  The trusted anchor is part of the hospital and 
clinic organization.  It coordinates with the Bio-med department regarding 
device allocation.  It does know what machines are assigned where and for 
what purposes.

In healthcare you pick a trusted anchor that knows these things.  It will 
not chain outside the healthcare organization.  This organization might be 
rather large when you get into various national health systems, but the 
anchor is within the healthcare system.

R Horn

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