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
- 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