Re: [Syslog] Some revised text for syslog TLS

robert.horn@agfa.com Wed, 28 May 2008 13:24 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 D540E3A69EA; Wed, 28 May 2008 06:24:02 -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 5878A3A69EA; Wed, 28 May 2008 06:24:01 -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=[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 X3+WE-QSUPs1; Wed, 28 May 2008 06:23:55 -0700 (PDT)
Received: from mornm02-out.agfa.com (mornm02-out.agfa.com [134.54.1.77]) by core3.amsl.com (Postfix) with ESMTP id 13E9C3A698B; Wed, 28 May 2008 06:23:54 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,555,1204498800"; d="scan'208";a="41090824"
Received: from morswa037.agfa.be (HELO morswa037.be.local) ([10.232.220.21]) by mornm02-out.agfa.com with ESMTP; 28 May 2008 15:23:48 +0200
In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA3090C1@grfint2.intern.adiscon.com>
To: rgerhards@hq.adiscon.com
MIME-Version: 1.0
Message-ID: <OFE9F68834.71EB286E-ON85257457.0047D1FF-85257457.00499511@agfa.com>
From: robert.horn@agfa.com
Date: Wed, 28 May 2008 09:23:43 -0400
Cc: 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

The new text looks close.  I agree with Rainer that the MUST on checking 
IP Address should drop to a MAY, or better yet be removed entirely.   It 
could be subsumed within the general ability to check various content 
fields within the certificate.  I find that CN is much more useful.  A MAY 
for CN checking makes much more sense to me.

I think that this is just a leftover from someone's particular use case, 
rather than based on a real security analysis.  Passing the certificate 
test means that both sides have demonstrated that they know their own 
private keys.  That is the good mandatory check.  If either side does not 
know their own private key you have strong evidence that they are not who 
they claim to be.  The real system will always know its own private keys. 
IP address is just a special case.

Passing the certificate test does not mean 100% certainty for 
authentication.  There is always the risk that the machine has not 
protected its private keys.  They can be stolen and the machine can be 
penetrated.  Perhaps someone could explain why the presence of the IP 
Address in the certificate should automatically imply that security has 
been compromised.  Plus why does matching IP address in certificate and 
network eliminate that implication.  I can think of special use cases 
where this is the case, but by making it a MUST the RFC makes this is a 
global statement.

In practice, if the MUST goes through I'll just make formal policy 
recommendations that healthcare never include IP Address in certificates. 
This is a reasonable recommendation anyhow.  In the present world of NAT, 
DHCP, IPv6 negotiation, mobile machines, etc. the IP address is rather 
unstable.  It doesn't make sense to put it into certificates.  If really 
pressed, I might mention that there is also a minor bug in the syslog-tls 
RFC.

Kind Regards,

Robert Horn | Agfa HealthCare
Research Scientist | HE/Technology Office
T  +1 978 897 4860

Agfa HealthCare Corporation, 100 Challenger Road, Ridgefield Park, NJ, 
07660-2199, United States
http://www.agfa.com/healthcare/
Click on link to read important disclaimer: 
http://www.agfa.com/healthcare/maildisclaimer
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog