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
- Re: [Syslog] Some revised text for syslog TLS tom.petch
- [Syslog] Some revised text for syslog TLS Joseph Salowey (jsalowey)
- Re: [Syslog] Some revised text for syslog TLS Rainer Gerhards
- Re: [Syslog] Some revised text for syslog TLS Rainer Gerhards
- Re: [Syslog] Some revised text for syslog TLS Pasi.Eronen
- Re: [Syslog] Some revised text for syslog TLS Rainer Gerhards
- Re: [Syslog] Some revised text for syslog TLS Pasi.Eronen
- Re: [Syslog] Some revised text for syslog TLS Rainer Gerhards
- Re: [Syslog] Some revised text for syslog TLS Martin Schütte
- Re: [Syslog] Some revised text for syslog TLS Moehrke, John (GE Healthcare)
- Re: [Syslog] Some revised text for syslog TLS Anton Okmyanskiy (aokmians)
- Re: [Syslog] Some revised text for syslog TLS Pasi.Eronen
- Re: [Syslog] Some revised text for syslog TLS tom.petch
- Re: [Syslog] Some revised text for syslog TLS tom.petch
- Re: [Syslog] Some revised text for syslog TLS tom.petch
- Re: [Syslog] Some revised text for syslog TLS Rainer Gerhards
- Re: [Syslog] Some revised text for syslog TLS robert.horn
- Re: [Syslog] Some revised text for syslog TLS tom.petch
- Re: [Syslog] Some revised text for syslog TLS Rainer Gerhards
- Re: [Syslog] Some revised text for syslog TLS Pasi.Eronen
- Re: [Syslog] Some revised text for syslog TLS tom.petch
- Re: [Syslog] Some revised text for syslog TLS robert.horn
- Re: [Syslog] Some revised text for syslog TLS Martin Schütte
- Re: [Syslog] Some revised text for syslog TLS Martin Schütte