From syslog-bounces@ietf.org Mon Sep 1 08:21:08 2008 Return-Path: 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 6634F3A689F; Mon, 1 Sep 2008 08:21:08 -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 5C5803A6896 for ; Mon, 1 Sep 2008 08:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_35=0.6] 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 foyOFaVq+gCV for ; Mon, 1 Sep 2008 08:21:05 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 8EC743A6859 for ; Mon, 1 Sep 2008 08:21:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 379E17AC0D1; Mon, 1 Sep 2008 17:16:55 +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 N5YBdVgZf2tD; Mon, 1 Sep 2008 17:16:55 +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 EDD697AC055; Mon, 1 Sep 2008 17:16:54 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Sep 2008 17:20:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F067@grfint2.intern.adiscon.com> In-Reply-To: <003801c90ac0$2c1bfc80$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Need your input on finalissuesondraft-ietf-syslog-transport-tls Thread-Index: AckKyYsm0Wasw2KERZqfvclhgZ+VYgBfHoHA References: <009201c9092e$3e587560$0601a8c0@allison> <003801c90ac0$2c1bfc80$0601a8c0@allison> From: "Rainer Gerhards" To: "tom.petch" , "Chris Lonvick" , Subject: Re: [Syslog] Need your input on finalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org I have been away, so my comments are late... > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf Of tom.petch > Sent: Saturday, August 30, 2008 6:43 PM > To: Chris Lonvick; syslog@ietf.org > Subject: Re: [Syslog] Need your input on finalissuesondraft-ietf- > syslog-transport-tls > [snip] > > b) Technically, I think it the wrong direction to allow a common name > to > override a subjectAltName, I believe the world is going the other way; > and I am > unclear from this how much wildcarding is permitted in a locally > configured name > (seems to be unconstrained ). I agree with Tom. I think we should NOT MANDATE to check the common name if a subject AltName is present. I always understood the previous text so that common name would be a fallback if and only if no subjectAltName was present. Rainer _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Sep 1 08:26:55 2008 Return-Path: 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 B69FF3A69DF; Mon, 1 Sep 2008 08:26:55 -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 48ECC3A69DF for ; Mon, 1 Sep 2008 08:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.104 X-Spam-Level: X-Spam-Status: No, score=-0.104 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_50=0.001, MIME_8BIT_HEADER=0.3] 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 iliRiLuipx7Q for ; Mon, 1 Sep 2008 08:26:54 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 24AC33A6899 for ; Mon, 1 Sep 2008 08:26:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 503C47AC0D1; Mon, 1 Sep 2008 17:22:56 +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 BvRb0N1bonjt; Mon, 1 Sep 2008 17:22:56 +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 17D327AC055; Mon, 1 Sep 2008 17:22:56 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Sep 2008 17:26:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F068@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Need your input on finalissueson draft-ietf-syslog-transport-tls Thread-Index: AckIy47NvV7xzenQQDKNc41GXr+xoAABwRNQANzwHLA= References: <48B631D1.4050206@mschuette.name> From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" , =?iso-8859-1?Q?Martin_Sch=FCtte?= , Subject: Re: [Syslog] Need your input on finalissueson draft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf Of Joseph Salowey (jsalowey) > Sent: Thursday, August 28, 2008 7:59 AM > To: Martin Sch=FCtte; syslog@ietf.org > Subject: Re: [Syslog] Need your input on finalissueson draft-ietf- > syslog-transport-tls > = > = > = > > -----Original Message----- > > From: syslog-bounces@ietf.org > > [mailto:syslog-bounces@ietf.org] On Behalf Of Martin Sch=FCtte > > Sent: Wednesday, August 27, 2008 10:04 PM > > To: syslog@ietf.org > > Subject: Re: [Syslog] Need your input on final issueson > > draft-ietf-syslog-transport-tls > > > > Chris Lonvick schrieb: > > > have comments, please send them in. If you read these and > > agree with > > > the changes, please comment to the WG list as well so we know that > > > we're getting an adequate review. > > > > Looks good to me. Only one question: > > > > > =3D=3D=3D 1 =3D=3D=3D > > > The '*' (ASCII 42) wildcard character is allowed in > > subjectAltName > > > values of type dNSName (and in Common Name, if used), > > and then only > > > as the left-most (least significant) DNS label in that value. > > > This > > > > Is this a MAY or a MUST? > > > [Joe] I think it is a MUST or RECOMMENDED. Other applications allow > wildcards to appear in certificates so it might be surprising for > deployers if it is not supported in Syslog TLS. Mhh... I'd say it should be a RECOMMENDED at most. Otherwise, we are back t= o the policy decision discussion we had earlier this year. As a side-note, I find it quite counter-productive to allow this at all. IM= HO "MAY" is even too strong. This opens up a can of worms, which leads to n= on-identification of the remote peer. So far, we had a very strong position= that the peer's *identity* must be known but "our" instance can decide whe= ther or not it accepts the peer's identity. With wildcards inside the certi= ficate, that choice is partly moved over to the remote peer. If we make it = a MUST, I already see users asking for a way to "turn off accepting wildcar= d certificates". So in my opinion this is a bad choice. Comparing to other = protocols makes only sense if the share the same security concerns, and I t= hink syslog's are quite unique (as has been stressed several times before b= y others on this list when it came to requesting support for anonymous peer= s;)). Rauber _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Sep 1 20:57:16 2008 Return-Path: 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 AF4653A6844; Mon, 1 Sep 2008 20:57:16 -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 C735E3A6844 for ; Mon, 1 Sep 2008 20:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.479 X-Spam-Level: X-Spam-Status: No, score=-5.479 tagged_above=-999 required=5 tests=[AWL=-0.970, BAYES_05=-1.11, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] 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 n0zv39XUSgB1 for ; Mon, 1 Sep 2008 20:57:13 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 1BFF53A6781 for ; Mon, 1 Sep 2008 20:57:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,312,1217808000"; d="scan'208";a="98429574" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 02 Sep 2008 03:57:12 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m823vC01012225; Mon, 1 Sep 2008 20:57:12 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m823vCeZ025248; Tue, 2 Sep 2008 03:57:12 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Sep 2008 20:57:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Sep 2008 20:57:19 -0700 Message-ID: In-Reply-To: <003801c90ac0$2c1bfc80$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Need your input on finalissuesondraft-ietf-syslog-transport-tls thread-index: AckKyYsJa3qKkNS7Qke3YPbpQyqW7AB24r0Q References: <009201c9092e$3e587560$0601a8c0@allison> <003801c90ac0$2c1bfc80$0601a8c0@allison> From: "Joseph Salowey (jsalowey)" To: "tom.petch" , "Chris Lonvick (clonvick)" , X-OriginalArrivalTime: 02 Sep 2008 03:57:12.0111 (UTC) FILETIME=[FAAB4BF0:01C90CAF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12119; t=1220327832; x=1221191832; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Syslog]=20Need=20your=20input=20on=20f inalissuesondraft-ietf-syslog-transport-tls |Sender:=20; bh=SGzBz2hefsidpXcHKQdu9Ru0FJopUebdrGrCPnGtOXE=; b=RKkKIsRSbkJCYWB1ev4eX+maLupwZANey1SyhO71zJUbaAQPfUUQBClH1K Sh3wuvebP49CR0Vjm9e3sD34pkuokSyhRlL+EW6BD43JjQqjeYdx2R2P9hbq +VFBSHAicl; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Syslog] Need your input on finalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org So many of these issues existed with draft-13, not that they aren't valid, however I am worried we may start going around in circles with this. > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of tom.petch > Sent: Saturday, August 30, 2008 9:43 AM > To: Chris Lonvick (clonvick); syslog@ietf.org > Subject: Re: [Syslog] Need your input on > finalissuesondraft-ietf-syslog-transport-tls > > Just to be clear, lest it be buried in my suggested text, my > objections to this text are threefold. > > a) the structure of the first sentence, which I think leads > the reader astray; I think the reference to certificate path > needs taking out into a separate section since the following > paragraphs seem unrelated to it. > [Joe] I agree that the first sentence is a bit awkward. I don't think the section needs to be split. "Implementations MUST support certification path validation [RFC5280]. In addition they MUST support specifying the authorized peers using locally configured host names and matching the name against the certificate as follows:" > b) Technically, I think it the wrong direction to allow a > common name to override a subjectAltName, I believe the world > is going the other way; and I am unclear from this how much > wildcarding is permitted in a locally configured name (seems > to be unconstrained ). > [Joe] SubjectAltName is no more or less valid of an identity than Subject Name. Common Name is only a portion of the Subject Name and it may not be unique, however it is commonly assumed to be unique. While the use of SubjectAltName for host names is preferred, there are still many deployments which rely upon the use of Common Name. Given this I really think implementations SHOULD support common name. We can remove the text about matching more than one identity. "Implementations MUST support matching the locally configured name against a SubjectAltName field with a type of dNSName and SHOULD support checking the name against the Common Name portion of the Subject Distinguished Name." Perhaps we should remove text on locally configured wildcard matching since it is a matter of local implementation. > c) Terminology is inconsistent and at variance with that of > RFC5280; I assume that this cannot be implemented without a > familiarity with RFC5280 and that its terminology is thus the > only one we should be using. > [Joe] I agree we should be in line with RFC 5280. Which terminology do you think is inconsistent? > Tom Petch > > ----- Original Message ----- > From: "tom.petch" > To: "Chris Lonvick" ; > Sent: Thursday, August 28, 2008 6:15 PM > Subject: Re: [Syslog] Need your input on final > issuesondraft-ietf-syslog-transport-tls > > > > No, not ok; I find 1) unclear, poorly written, hard to > parse, prone to > > misinterpretation. > > > > "Implementations MUST a, MUST b and matching c as follows:" > > followed by chunky paragraphs most of which start "If a", with a > > sneaky > 'also' > > carrying overtones that the writer thinks it will not be > clear where > > the list > of > > what follows starts and ends:-( > > > > I think that 'a' (ie locally configured names) should be treated as > > one and anything else, which seems not much, removed to another > > section, eg > > > > > > Implementations MUST support locally configured host names > to specify > > authorised [yuk, are we authorising or > authenticating?]peers, matching > > the locally configured host name with the certificate as follows. > > > > A) Implementations MUST support matching the locally > configured name > against > > a subjectAltName extension of dNSName and SHOULD support > checking the > > name against the common name portion of the subject distinguished > > name. If more than one identity is present in the certificate, a > > match on any identity is acceptable. > > > > [I think this wrong; draft-hodges, which we are not referencing, > > deprecates > the > > use of common name, while we are saying if common name matches, and > > subjectAltName does not, then that is acceptable; I think not - I > > think that best practice is that if subjectAltName is > present, it must > > match] > > > > B) If the locally configured name is an internationalized > domain name, > > conforming implementations MUST convert it to the ASCII Compatible > > Encoding (ACE) format as specified in Section 7 of RFC 5280. > > > > C) The '*' (ASCII 42) wildcard character is allowed in > subjectAltName > > values of dNSName (and in common name, if used) but only as the > > left-most (least significant) DNS label in that value. > This wildcard > > matches any left-most DNS label in the server name. That is, the > > subject *.example.com matches the server names a.example.com and > > b.example.com, but does not match example.com or a.b.example.com. > > > > D) Implementations MAY support wildcards in locally > configured names > > to match a range of values. For example, using wildcards makes it > > possible to deploy trust-root-based authorization where all > > credentials issued by a particular CA trust root are authorized. > > > > {Q is the use of wildcard constrained here or can I say > local.*.ca ? > > dunno} > > > > E) Implementations MAY support matching a locally configured IP > > address against a subjectAltName extension of iPAddress. In this > > case, the locally configured IP address is converted to an octet > > string as specified in RFC 5280, Section 4.2.1.6 [RFC5280]. > A match > > occurs > if > > this octet string is equal to the value of a subjectAltName > extension > > of iPAddress. > > > > Tom Petch > > > > ----- Original Message ----- > > From: "Chris Lonvick" > > To: > > Sent: Thursday, August 28, 2008 12:43 AM > > Subject: [Syslog] Need your input on final issues > > ondraft-ietf-syslog-transport-tls > > > > > > > Hi Folks, > > > > > > The DISCUSSes and COMMENTs are here: > > > https://datatracker.ietf.org/idtracker/ballot/2334/ > > > > > > Joe, Pasi and Chris Newman have been having a discussion > to come up > > > with modifications to address them. We want to bring > these things > > > to the WG to make sure that implementors are comfortable > with these > > > changes. If you have comments, please send them in. If you read > > > these and agree with the changes, please comment to the > WG list as > > > well so we know that we're getting an adequate review. > > > > > > === 1 === > > > We have a proposed change to Section 5.2, Subject Name > > > Authorization, which are the first three paragraphs of > Chris Newman's DISCUSS. > > > > > > Implementations MUST support specifying the > authorized peers using > > > locally configured host names, MUST support certification path > > > validation [RFC5280] and matching the name with the > certificate as > > > follows: > > > > > > Implementations MUST support matching the locally > configured name > > > against a SubjectAltName field with a type of dNSName > and SHOULD > > > support checking the name against the Common Name > portion of the > > > Subject Distinguished Name. If more than one > identity is present > > > in the certificate, a match in any one of the set is > considered > > > acceptable. > > > > > > If the locally configured name is an > internationalized domain name, > > > conforming implementations MUST convert it to the > ASCII Compatible > > > Encoding (ACE) format as specified in Section 7 of RFC 5280. > > > > > > The '*' (ASCII 42) wildcard character is allowed in > subjectAltName > > > values of type dNSName (and in Common Name, if used), > and then only > > > as the left-most (least significant) DNS label in > that value. This > > > wildcard matches any left-most DNS label in the > server name. That > > > is, the subject *.example.com matches the server > names a.example.com > > > and b.example.com, but does not match example.com or > a.b.example.com. > > > > > > Implementations also MAY support wildcards in locally > configured > > > names to match a range of values. Using wildcards makes it > > > possible to deploy trust-root-based authorization where all > > > credentials issued by a particular CA trust root are > authorized. > > > > > > Implementations MAY support matching a locally configured > > > IP address against a SubjectAltName of type > ipAddress. In this > > > case, the locally configured IP address is converted > to an octet > > > string as specified in RFC 5280, Section 4.2.1.6. A > match occurs > > > if this octet string is equal to the value of > subjectAltName of > > > type iPAddress. > > > > > > ==== 2 === > > > > > > Joe also wrote for the fourth paragraph of Chris Newman's DISCUSS: > > > I think the last outstanding issue in the Discuss with > using an IANA > > > registry for hash function names. I think we could use > the registry > > > for RFC 4572. The allocation is tied to PKIX documents, > which is probably OK. > > > The one question is whether someone would adopt a hash > function that > > > become common convention for naming, but was not adopted > by PKIX. I > > > think the risk is very low here. It would change the label in the > > > draft from "SHA1" to "sha-1". > > > > > > The mechanism to generate a fingerprint is to take the hash of > > > the DER-encoded certificate using a cryptographically strong > > > algorithm and convert the result into colon separated, > > > hexadecimal bytes, each represented by 2 uppercase ASCII > > > characters. When a fingerprint value is displayed or > configured > > > the fingerprint is prepended with an ASCII label > identifying the > > > hash function followed by a colon. The ASCII label > is take from > > > the IANA registry for Hash Function Textual > > > Names. Implementations MUST support SHA-1 as the hash > algorithm > > > and use the ASCII label "sha-1" from the registry to > identify the > > > SHA-1 algorithm. The length of a SHA-1 hash is 20 > bytes and the > > > length of the corresponding fingerprint string is 64 > characters. > > > An example certificate fingerprint is: > > > > > > > sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D > > > > > > === 3 === > > > > > > We have already cleared Lars' DISCUSS on the system port. > > > > > > === 4 === > > > > > > I'd like to get a "me too" for Tim's COMMENT: > > > s/(as described in Sections 5.2 and 5.3)/(as described in > Sections > > > 5.3 and 5.4)/ > > > > > > ========= > > > > > > > > > Please comment on these proposed changes. > > > > > > Actually, please comment _NOW_ as these are the last > things holding > > > up the three core IDs. :-) > > > > > > Thanks, > > > Chris > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@ietf.org > > > https://www.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > > Syslog mailing list > > Syslog@ietf.org > > https://www.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Sep 1 21:09:36 2008 Return-Path: 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 61D153A685A; Mon, 1 Sep 2008 21:09:36 -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 930613A67FF for ; Mon, 1 Sep 2008 21:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.051 X-Spam-Level: X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 3gWw8mn2l+qA for ; Mon, 1 Sep 2008 21:09:34 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5E8243A6781 for ; Mon, 1 Sep 2008 21:09:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,312,1217808000"; d="scan'208";a="150697075" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 02 Sep 2008 04:09:40 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8249eYm011555; Mon, 1 Sep 2008 21:09:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m8249e3C027423; Tue, 2 Sep 2008 04:09:40 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Sep 2008 21:09:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 1 Sep 2008 21:09:48 -0700 Message-ID: In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F068@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Need your input on finalissueson draft-ietf-syslog-transport-tls thread-index: AckIy47NvV7xzenQQDKNc41GXr+xoAABwRNQANzwHLAAGmyaQA== References: <48B631D1.4050206@mschuette.name> <577465F99B41C842AAFBE9ED71E70ABA44F068@grfint2.intern.adiscon.com> From: "Joseph Salowey (jsalowey)" To: "Rainer Gerhards" , =?iso-8859-1?Q?Martin_Sch=FCtte?= , X-OriginalArrivalTime: 02 Sep 2008 04:09:40.0563 (UTC) FILETIME=[B8C80230:01C90CB1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3806; t=1220328580; x=1221192580; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Syslog]=20Need=20your=20input=20on=20f inalissueson=09draft-ietf-syslog-transport-tls |Sender:=20; bh=s/bO2bvpTkuS4XcMF+DmRhGpwKLXtRLEs41YlKM9OUk=; b=tEGIeUEGOLrk6BB5bJ9z8vZqkqpVEY+4PlPwVNcgf6EOX3wmXDdYyw/oyI jEy7U8eRmJIjGBII8+129G9V4dBPixHOw3KxP6bHquoBdYqGqzqyTPkLI9rU TYOKZ30HajYacONQvJYBpAhay8RJkWslzzF6PiQfofW5h1HeLsGuE=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Syslog] Need your input on finalissueson draft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org = > -----Original Message----- > From: Rainer Gerhards [mailto:rgerhards@hq.adiscon.com] = > Sent: Monday, September 01, 2008 8:27 AM > To: Joseph Salowey (jsalowey); Martin Sch=FCtte; syslog@ietf.org > Subject: RE: [Syslog] Need your input on finalissueson = > draft-ietf-syslog-transport-tls > = > > = > > -----Original Message----- > > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On = > > Behalf Of Joseph Salowey (jsalowey) > > Sent: Thursday, August 28, 2008 7:59 AM > > To: Martin Sch=FCtte; syslog@ietf.org > > Subject: Re: [Syslog] Need your input on finalissueson draft-ietf- = > > syslog-transport-tls > > = > > = > > = > > > -----Original Message----- > > > From: syslog-bounces@ietf.org > > > [mailto:syslog-bounces@ietf.org] On Behalf Of Martin Sch=FCtte > > > Sent: Wednesday, August 27, 2008 10:04 PM > > > To: syslog@ietf.org > > > Subject: Re: [Syslog] Need your input on final issueson = > > > draft-ietf-syslog-transport-tls > > > > > > Chris Lonvick schrieb: > > > > have comments, please send them in. If you read these and > > > agree with > > > > the changes, please comment to the WG list as well so = > we know that = > > > > we're getting an adequate review. > > > > > > Looks good to me. Only one question: > > > > > > > =3D=3D=3D 1 =3D=3D=3D > > > > The '*' (ASCII 42) wildcard character is allowed in > > > subjectAltName > > > > values of type dNSName (and in Common Name, if used), > > > and then only > > > > as the left-most (least significant) DNS label in = > that value. > > > > This > > > > > > Is this a MAY or a MUST? > > > > > [Joe] I think it is a MUST or RECOMMENDED. Other = > applications allow = > > wildcards to appear in certificates so it might be surprising for = > > deployers if it is not supported in Syslog TLS. > = > Mhh... I'd say it should be a RECOMMENDED at most. Otherwise, = > we are back to the policy decision discussion we had earlier = > this year. > = > As a side-note, I find it quite counter-productive to allow = > this at all. IMHO "MAY" is even too strong. This opens up a = > can of worms, which leads to non-identification of the remote = > peer. So far, we had a very strong position that the peer's = > *identity* must be known but "our" instance can decide = > whether or not it accepts the peer's identity. With wildcards = > inside the certificate, that choice is partly moved over to = > the remote peer. If we make it a MUST, I already see users = > asking for a way to "turn off accepting wildcard = > certificates". So in my opinion this is a bad choice. = > Comparing to other protocols makes only sense if the share = > the same security concerns, and I think syslog's are quite = > unique (as has been stressed several times before by others = > on this list when it came to requesting support for anonymous = > peers;)). > = [Joe] Today, there are CA's that issue certificates with wildcards in the h= ostname. It would be good if Syslog implementations could be configured to= work with these CA's. It is not required that this support always be enab= led. Would the addition help: "The '*' (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName (and in Common Name, if used), and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations SHOULD provide the ability to enable support for = these types of wildcards within the host name in the certificate. " > Rauber > = _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Sep 1 23:17:34 2008 Return-Path: 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 86D053A68DE; Mon, 1 Sep 2008 23:17:34 -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 62F263A68DF for ; Mon, 1 Sep 2008 23:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.869 X-Spam-Level: X-Spam-Status: No, score=-5.869 tagged_above=-999 required=5 tests=[AWL=0.730, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 AQFRlhuBdMWU for ; Mon, 1 Sep 2008 23:17:32 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 4BF353A67D2 for ; Mon, 1 Sep 2008 23:17:31 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m826HF9h017696; Tue, 2 Sep 2008 09:17:33 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Sep 2008 09:17:28 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Sep 2008 09:17:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Sep 2008 09:17:27 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720180DD7D@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Need your input onfinalissueson draft-ietf-syslog-transport-tls Thread-Index: AckIy47NvV7xzenQQDKNc41GXr+xoAABwRNQANzwHLAAGmyaQAAE0I9A References: <48B631D1.4050206@mschuette.name><577465F99B41C842AAFBE9ED71E70ABA44F068@grfint2.intern.adiscon.com> From: To: , X-OriginalArrivalTime: 02 Sep 2008 06:17:28.0050 (UTC) FILETIME=[92F5AD20:01C90CC3] X-Nokia-AV: Clean Subject: Re: [Syslog] Need your input onfinalissueson draft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Joseph Salowey wrote: > [Joe] Today, there are CA's that issue certificates with wildcards > in the hostname. It would be good if Syslog implementations could > be configured to work with these CA's. It is not required that this > support always be enabled. Would the addition help: > > "The '*' (ASCII 42) wildcard character is allowed in subjectAltName > values of type dNSName (and in Common Name, if used), and then only > as the left-most (least significant) DNS label in that value. This > wildcard matches any left-most DNS label in the server name. That > is, the subject *.example.com matches the server names a.example.com > and b.example.com, but does not match example.com or > a.b.example.com. Implementations SHOULD provide the ability to > enable support for these types of wildcards within the host name in > the certificate. " I think this needs to be "Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them." Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Sep 1 23:22:03 2008 Return-Path: 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 F11233A68B3; Mon, 1 Sep 2008 23:22: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 493273A6847 for ; Mon, 1 Sep 2008 23:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.352 X-Spam-Level: X-Spam-Status: No, score=-1.352 tagged_above=-999 required=5 tests=[AWL=1.247, 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 tKDTh9vVU0-L for ; Mon, 1 Sep 2008 23:22:00 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 26BD13A6836 for ; Mon, 1 Sep 2008 23:22:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id C1B627AC0D1; Tue, 2 Sep 2008 08:21: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 P0Nd7QRmfQY0; Tue, 2 Sep 2008 08:21: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 728E67AC052; Tue, 2 Sep 2008 08:21:07 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Sep 2008 08:21:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F069@grfint2.intern.adiscon.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB720180DD7D@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Need your inputonfinalissueson draft-ietf-syslog-transport-tls Thread-Index: AckIy47NvV7xzenQQDKNc41GXr+xoAABwRNQANzwHLAAGmyaQAAE0I9AAAAfWPA= References: <48B631D1.4050206@mschuette.name><577465F99B41C842AAFBE9ED71E70ABA44F068@grfint2.intern.adiscon.com> <1696498986EFEC4D9153717DA325CB720180DD7D@vaebe104.NOE.Nokia.com> From: "Rainer Gerhards" To: , , Subject: Re: [Syslog] Need your inputonfinalissueson draft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf Of Pasi.Eronen@nokia.com > Sent: Tuesday, September 02, 2008 8:17 AM > To: jsalowey@cisco.com; syslog@ietf.org > Subject: Re: [Syslog] Need your inputonfinalissueson draft-ietf-syslog- > transport-tls > > Joseph Salowey wrote: > > > [Joe] Today, there are CA's that issue certificates with wildcards > > in the hostname. It would be good if Syslog implementations could > > be configured to work with these CA's. It is not required that this > > support always be enabled. Would the addition help: > > > > "The '*' (ASCII 42) wildcard character is allowed in subjectAltName > > values of type dNSName (and in Common Name, if used), and then only > > as the left-most (least significant) DNS label in that value. This > > wildcard matches any left-most DNS label in the server name. That > > is, the subject *.example.com matches the server names a.example.com > > and b.example.com, but does not match example.com or > > a.b.example.com. Implementations SHOULD provide the ability to > > enable support for these types of wildcards within the host name in > > the certificate. " > > I think this needs to be "Implementations MUST support wildcards in > certificates as specified above, but MAY provide a configuration > option to disable them." So we require an application to support certificates to identify the remote peer, go great length to prevent anonymous peers ... and then we introduce anon peers by allowing wildcards inside the certificate? Well... if that's really our intension, I'll no longer object it. I just wonder why we don't simply allow plain anon peers as was suggested by others and me several times... Rainer > > Best regards, > Pasi > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Sep 1 23:27:40 2008 Return-Path: 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 767B23A6847; Mon, 1 Sep 2008 23:27:40 -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 AEBAC3A6847 for ; Mon, 1 Sep 2008 23:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.915 X-Spam-Level: X-Spam-Status: No, score=-5.915 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 XHhev2l7dGW7 for ; Mon, 1 Sep 2008 23:27:38 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id AAB0E3A6821 for ; Mon, 1 Sep 2008 23:27:37 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m826RTph018414; Tue, 2 Sep 2008 09:27:33 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Sep 2008 09:27:12 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Sep 2008 09:27:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Sep 2008 09:27:06 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720180DD97@vaebe104.NOE.Nokia.com> In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F069@grfint2.intern.adiscon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Need your inputonfinalissueson draft-ietf-syslog-transport-tls Thread-Index: AckIy47NvV7xzenQQDKNc41GXr+xoAABwRNQANzwHLAAGmyaQAAE0I9AAAAfWPAAACZhEA== References: <48B631D1.4050206@mschuette.name><577465F99B41C842AAFBE9ED71E70ABA44F068@grfint2.intern.adiscon.com> <1696498986EFEC4D9153717DA325CB720180DD7D@vaebe104.NOE.Nokia.com> <577465F99B41C842AAFBE9ED71E70ABA44F069@grfint2.intern.adiscon.com> From: To: , , X-OriginalArrivalTime: 02 Sep 2008 06:27:08.0535 (UTC) FILETIME=[ECF4A870:01C90CC4] X-Nokia-AV: Clean Subject: Re: [Syslog] Need your inputonfinalissueson draft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Rainer Gerhards wrote: > So we require an application to support certificates to identify the > remote peer, go great length to prevent anonymous peers ... and > then we introduce anon peers by allowing wildcards inside the > certificate? Well... if that's really our intension, I'll no longer > object it. I just wonder why we don't simply allow plain anon peers > as was suggested by others and me several times... Wildcards in certificates aren't anonymous peers; they're a shorthand for specifying that the subject of the certificate is the valid "owner" of (large set of) multiple different names. Plain anonymous peers are allowed by the specification, but the text about them is in a different subsection than we're discussing now. Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue Sep 2 08:41:04 2008 Return-Path: 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 6E7C028C199; Tue, 2 Sep 2008 08:41: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 B5E5F28C171 for ; Tue, 2 Sep 2008 08:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=1.245, 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 1CXOZk5TASou for ; Tue, 2 Sep 2008 08:40:58 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id E19B328C199 for ; Tue, 2 Sep 2008 08:40:57 -0700 (PDT) X-Trace: 131095477/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.50.132 X-SBRS: None X-RemoteIP: 213.116.50.132 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAGH7vEjVdDKE/2dsb2JhbACDRziIDKd/A4Fm X-IronPort-AV: E=Sophos;i="4.32,317,1217804400"; d="scan'208";a="131095477" X-IP-Direction: IN Received: from 1cust132.tnt101.lnd4.gbr.da.uu.net (HELO allison) ([213.116.50.132]) by smtp.pipex.tiscali.co.uk with SMTP; 02 Sep 2008 16:40:59 +0100 Message-ID: <01f301c90d08$f72275e0$0601a8c0@allison> From: "tom.petch" To: "Joseph Salowey \(jsalowey\)" , "Chris Lonvick \(clonvick\)" , "syslog" References: <009201c9092e$3e587560$0601a8c0@allison> <003801c90ac0$2c1bfc80$0601a8c0@allison> Date: Tue, 2 Sep 2008 15:20:19 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Syslog] Need your input on finalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org ----- Original Message ----- From: "Joseph Salowey (jsalowey)" To: "tom.petch" ; "Chris Lonvick (clonvick)" ; Sent: Tuesday, September 02, 2008 5:57 AM Subject: RE: [Syslog] Need your input on finalissuesondraft-ietf-syslog-transport-tls So many of these issues existed with draft-13, not that they aren't valid, however I am worried we may start going around in circles with this. Well I did raise some of them before without seeing a response:-) > -----Original Message----- > From: syslog-bounces@ietf.org > Sent: Saturday, August 30, 2008 9:43 AM > To: Chris Lonvick (clonvick); syslog@ietf.org > Subject: Re: [Syslog] Need your input on > finalissuesondraft-ietf-syslog-transport-tls > > Just to be clear, lest it be buried in my suggested text, my > objections to this text are threefold. > > a) the structure of the first sentence, which I think leads > the reader astray; I think the reference to certificate path > needs taking out into a separate section since the following > paragraphs seem unrelated to it. > [Joe] I agree that the first sentence is a bit awkward. I don't think the section needs to be split. "Implementations MUST support certification path validation [RFC5280]. In addition they MUST support specifying the authorized peers using locally configured host names and matching the name against the certificate as follows:" yes, fixes it for me > b) Technically, I think it the wrong direction to allow a > common name to override a subjectAltName, I believe the world > is going the other way; and I am unclear from this how much > wildcarding is permitted in a locally configured name (seems > to be unconstrained ). > [Joe] SubjectAltName is no more or less valid of an identity than Subject Name. Common Name is only a portion of the Subject Name and it may not be unique, however it is commonly assumed to be unique. While the use of SubjectAltName for host names is preferred, there are still many deployments which rely upon the use of Common Name. Given this I really think implementations SHOULD support common name. We can remove the text about matching more than one identity. "Implementations MUST support matching the locally configured name against a SubjectAltName field with a type of dNSName and SHOULD support checking the name against the Common Name portion of the Subject Distinguished Name." Perhaps we should remove text on locally configured wildcard matching since it is a matter of local implementation. I'll wait to see what others think > c) Terminology is inconsistent and at variance with that of > RFC5280; I assume that this cannot be implemented without a > familiarity with RFC5280 and that its terminology is thus the > only one we should be using. > [Joe] I agree we should be in line with RFC 5280. Which terminology do you think is inconsistent? 'type iPAddress' is an oxymoron and may raise hackles (does mine - iPAddress is of type OCTET STRING:-) RFC5280 classifies it as a field, name form, component but never type. 'type ipAddress' see above and in addition 'ipAddress' does not exist. 'subjectAltName' is an extension and is always referred to as such. 'SubjectAltName' is a type, I think that 'subjectAltName' is meant. 'Common Name' is not used in RFC5280, rather 'common name', likewise 'subject distinguished name' is preferred to 'Subject Distinguished Name'. As I said, I regard familiarity with RFC5280 to be a prerequisite for this work, and so expect (some) readers of this I-D to notice these differences, and think the less of this I-D that they should exist. Tom Petch > > ----- Original Message ----- > From: "tom.petch" > To: "Chris Lonvick" ; > Sent: Thursday, August 28, 2008 6:15 PM > Subject: Re: [Syslog] Need your input on final > issuesondraft-ietf-syslog-transport-tls _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue Sep 2 22:10:01 2008 Return-Path: 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 44BEE3A6BE8; Tue, 2 Sep 2008 22:10: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 B68613A6BE8 for ; Tue, 2 Sep 2008 22:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Kh5eIq4noPew for ; Tue, 2 Sep 2008 22:09:58 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 775FB3A6BD8 for ; Tue, 2 Sep 2008 22:09:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,320,1217808000"; d="scan'208";a="151554455" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Sep 2008 05:10:05 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m835A5SG019602; Tue, 2 Sep 2008 22:10:05 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m835A5IR005910; Wed, 3 Sep 2008 05:10:05 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Sep 2008 22:10:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Sep 2008 22:10:11 -0700 Message-ID: In-Reply-To: <01f301c90d08$f72275e0$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Need your input on finalissuesondraft-ietf-syslog-transport-tls thread-index: AckNElEZPuXqStNeSDKBOpr1LgypEAAbOVwQ References: <009201c9092e$3e587560$0601a8c0@allison> <003801c90ac0$2c1bfc80$0601a8c0@allison> <01f301c90d08$f72275e0$0601a8c0@allison> From: "Joseph Salowey (jsalowey)" To: "tom.petch" , "Chris Lonvick (clonvick)" , "syslog" X-OriginalArrivalTime: 03 Sep 2008 05:10:05.0124 (UTC) FILETIME=[5399E040:01C90D83] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3346; t=1220418605; x=1221282605; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Syslog]=20Need=20your=20input=20on=20f inalissuesondraft-ietf-syslog-transport-tls |Sender:=20; bh=F+fs4SpVpiOFqZk8h/381mgOKYZPJQzBLzEufM1Dq24=; b=aQjqmMmUPsfQh8vSdY1yD3VymDMhx3HEnAbmXnjdunlFnvmJIBL/1XCiqQ 3tukpw3YaQAyHTG+h3bfdaEBhZcQyllxdWbiwF2R06jDYbFrYgBAOTMWVfWC HG86KHWsRW; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Syslog] Need your input on finalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org > > c) Terminology is inconsistent and at variance with that of > RFC5280; I > > assume that this cannot be implemented without a familiarity with > > RFC5280 and that its terminology is thus the only one we should be > > using. > > > [Joe] I agree we should be in line with RFC 5280. Which > terminology do you think is inconsistent? > > > > 'type iPAddress' is an oxymoron and may raise hackles (does > mine - iPAddress is of type OCTET STRING:-) RFC5280 > classifies it as a field, name form, component but never type. > > 'type ipAddress' see above and in addition 'ipAddress' does not exist. > > 'subjectAltName' is an extension and is always referred to as such. > > 'SubjectAltName' is a type, I think that 'subjectAltName' is meant. > > 'Common Name' is not used in RFC5280, rather 'common name', > likewise 'subject distinguished name' is preferred to > 'Subject Distinguished Name'. > > As I said, I regard familiarity with RFC5280 to be a > prerequisite for this work, and so expect (some) readers of > this I-D to notice these differences, and think the less of > this I-D that they should exist. > [Joe] OK, thanks. Here is a revision of the text. It probably still needs some work, but hopefully it is in the right direction. "Implementations MUST support certification path validation [RFC5280]. In addition they MUST support specifying the authorized peers using locally configured host names and matching the name against the certificate as follows: Implementations MUST support matching the locally configured host name against a dNSName in the subjectAltName extension field and SHOULD support checking the name against the common name portion of the subject distinguished name. If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format as specified in Section 7 of RFC 5280. The '*' (ASCII 42) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them. Implementations MAY support matching a locally configured IP address against an iPAddress stored in the subjectAltName extension. In this case, the locally configured IP address is converted to an octet string as specified in RFC 5280, Section 4.2.1.6. A match occurs if this octet string is equal to the value of iPAddress in the subjectAltName extension." > Tom Petch > > > > > ----- Original Message ----- > > From: "tom.petch" > > To: "Chris Lonvick" ; > > Sent: Thursday, August 28, 2008 6:15 PM > > Subject: Re: [Syslog] Need your input on final > > issuesondraft-ietf-syslog-transport-tls > > > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Sep 3 13:24:58 2008 Return-Path: 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 C65B53A6D2B; Wed, 3 Sep 2008 13:24:58 -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 4F3743A6D02 for ; Wed, 3 Sep 2008 13:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 b54BZBNAcg4H for ; Wed, 3 Sep 2008 13:24:56 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4FC283A6D23 for ; Wed, 3 Sep 2008 13:24:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,320,1217808000"; d="scan'208";a="99030500" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 03 Sep 2008 20:25:03 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m83KP3ph022616; Wed, 3 Sep 2008 13:25:03 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m83KP36e010004; Wed, 3 Sep 2008 20:25:03 GMT Date: Wed, 3 Sep 2008 13:25:03 -0700 (PDT) From: Chris Lonvick To: Rainer Gerhards In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44F069@grfint2.intern.adiscon.com> Message-ID: References: <48B631D1.4050206@mschuette.name><577465F99B41C842AAFBE9ED71E70ABA44F068@grfint2.intern.adiscon.com> <1696498986EFEC4D9153717DA325CB720180DD7D@vaebe104.NOE.Nokia.com> <577465F99B41C842AAFBE9ED71E70ABA44F069@grfint2.intern.adiscon.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2199; t=1220473503; x=1221337503; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Re=3A=20[Syslog]=20Need=20your=20inputonfinalis sueson=09draft-ietf-syslog-transport-tls |Sender:=20; bh=w58PDIlN08tm9OUNPHjKLAXDB4WGUu0Vntl4eG62rgs=; b=RCcCdc+3iUwObY77qTWYZmQxgzLaUTlyQypgdjZGH/GPS3FWxVjV/X+WDF JUKAGRHRZpjcWuckJbVaoxcoZyqLTT/WIKMei7kj6aaix05m1OkR4jt9+llp qO19GurcuVzQX2J2iIMKryZRrfdPgD+j+TYWu8SG5BeUwdBjMVXtw=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] Need your inputonfinalissueson draft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi Rainer, On Tue, 2 Sep 2008, Rainer Gerhards wrote: >> -----Original Message----- >> From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On >> Behalf Of Pasi.Eronen@nokia.com >> Sent: Tuesday, September 02, 2008 8:17 AM >> To: jsalowey@cisco.com; syslog@ietf.org >> Subject: Re: [Syslog] Need your inputonfinalissueson > draft-ietf-syslog- >> transport-tls >> >> Joseph Salowey wrote: >> >>> [Joe] Today, there are CA's that issue certificates with wildcards >>> in the hostname. It would be good if Syslog implementations could >>> be configured to work with these CA's. It is not required that this >>> support always be enabled. Would the addition help: >>> >>> "The '*' (ASCII 42) wildcard character is allowed in subjectAltName >>> values of type dNSName (and in Common Name, if used), and then only >>> as the left-most (least significant) DNS label in that value. This >>> wildcard matches any left-most DNS label in the server name. That >>> is, the subject *.example.com matches the server names a.example.com >>> and b.example.com, but does not match example.com or >>> a.b.example.com. Implementations SHOULD provide the ability to >>> enable support for these types of wildcards within the host name in >>> the certificate. " >> >> I think this needs to be "Implementations MUST support wildcards in >> certificates as specified above, but MAY provide a configuration >> option to disable them." > > So we require an application to support certificates to identify the > remote peer, go great length to prevent anonymous peers ... and then we > introduce anon peers by allowing wildcards inside the certificate? > Well... if that's really our intension, I'll no longer object it. I just > wonder why we don't simply allow plain anon peers as was suggested by > others and me several times... We have the following for unathenticated sessions: Section 5.3 for Unauthenticated Transport Sender Sectoin 5.4 for Unauthenticated Transport Receiver Section 5.5 for Unauthenticated Transport Receiver and Sender These sections are where we allow for anonymous peers but still use tls as the transport. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Sep 3 13:37:59 2008 Return-Path: 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 8DE503A68B7; Wed, 3 Sep 2008 13:37:59 -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 0DC3D3A6814 for ; Wed, 3 Sep 2008 13:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[AWL=0.579, 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 qh2wzetP0osl for ; Wed, 3 Sep 2008 13:37:57 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 2A97E3A68B7 for ; Wed, 3 Sep 2008 13:37:57 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id ACqL1a0410cQ2SLA8LdvVS; Wed, 03 Sep 2008 20:37:55 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id ALdt1a0024HwxpC8WLdtF2; Wed, 03 Sep 2008 20:37:54 +0000 X-Authority-Analysis: v=1.0 c=1 a=k4N9UQNaqRgA:10 a=Gx2I96sHXfwA:10 a=82P1xELRTHjmohfWtfkA:9 a=5_O0qtRn3m2YlFlijJMcaGd9eEUA:4 a=4rq7TwIXcRUA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: "'syslog'" References: <009201c9092e$3e587560$0601a8c0@allison><003801c90ac0$2c1bfc80$0601a8c0@allison><01f301c90d08$f72275e0$0601a8c0@allison> Date: Wed, 3 Sep 2008 16:37:52 -0400 Message-ID: <017b01c90e04$f132dbf0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AckNElEZPuXqStNeSDKBOpr1LgypEAAbOVwQACEL2tA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Subject: Re: [Syslog] Need your input onfinalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi, (speaking as a technical contributor) > [Joe] OK, thanks. Here is a revision of the text. It probably still > needs some work, but hopefully it is in the right direction. > > "Implementations MUST support certification path validation [RFC5280]. > In addition they MUST support specifying the authorized peers using > locally configured host names and matching the name against the > certificate as follows: > > Implementations MUST support matching the locally configured host name > against a dNSName in the subjectAltName extension field and SHOULD > support checking the name against the common name portion of the > subject distinguished name. > > If the locally configured name is an internationalized domain name, > conforming implementations MUST convert it to the ASCII Compatible > Encoding (ACE) format as specified in Section 7 of RFC 5280. Do we need to be clear about when (i.e. for what usages) this translation needs to be done? Is this necessary before string comparisons, for example? > > The '*' (ASCII 42) wildcard character is allowed in the dNSName of the > subjectAltName extension (and in common name, if used to store the > host name), and then only as the left-most (least significant) DNS > label in that value. This wildcard matches any left-most DNS label > in the server name. That is, the subject *.example.com matches the > server names a.example.com and b.example.com, but does not match > example.com or a.b.example.com. Implementations MUST support wildcards > in certificates as specified above, but MAY provide a configuration > option to disable them. shouldn't we make the ability to disable wildcards a MUST-implement, so we can be sure the strong-security option will be available if an operator wants to disable them for security reasons? That would seem to be consistent with BCP61. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Sep 3 13:43:52 2008 Return-Path: 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 5E4EC3A6B3B; Wed, 3 Sep 2008 13:43:52 -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 A30C13A6B46 for ; Wed, 3 Sep 2008 13:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 giIjoAPh73Fg for ; Wed, 3 Sep 2008 13:43:49 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 70D183A6860 for ; Wed, 3 Sep 2008 13:43:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,320,1217808000"; d="scan'208";a="80143894" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 03 Sep 2008 20:43:56 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m83KhuBA031689; Wed, 3 Sep 2008 13:43:56 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m83KhueU028546; Wed, 3 Sep 2008 20:43:56 GMT Date: Wed, 3 Sep 2008 13:43:50 -0700 (PDT) From: Chris Lonvick To: "Joseph Salowey (jsalowey)" In-Reply-To: Message-ID: References: <009201c9092e$3e587560$0601a8c0@allison> <003801c90ac0$2c1bfc80$0601a8c0@allison> <01f301c90d08$f72275e0$0601a8c0@allison> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2098; t=1220474636; x=1221338636; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20revised=205.2=20text=20=3A=20please=20comment=2 0was=3A=20RE=3A=20[Syslog]=20Need=20your=20input=0A=20on=20f inalissuesondraft-ietf-syslog-transport-tls |Sender:=20; bh=Ab/1SUvYZrlGG1PM/FgVCAN3ZB/YSOdCP0eS4lQeTsI=; b=XIirpzLzyVnjEJ4cwCyvbxezQ5S7h3AXZ+9SFNZMUyzxh7hnmGwpeAa9Gw 7lKNxwl2lDiP8vZ1uwTgT8Z/L+xo3NSD0fECGL9uIIrJgtLER4vVuLwUtNCC g9mnkewFHu; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: syslog Subject: [Syslog] revised 5.2 text : please comment was: RE: Need your input on finalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi, I'm going to take a stab at word smithing. I think there's still some ambiguity in the section that Joe just proposed and we may be able to resolve by putting in bullets. Please look at this and give feedback. === Implementations MUST support certification path validation [RFC5280]. In addition they MUST support specifying the authorized peers using locally configured host names and matching the name against the certificate as follows. o Implementations MUST support matching the locally configured host name against a dNSName in the subjectAltName extension field and SHOULD support checking the name against the common name portion of the subject distinguished name. o Implementations MAY support matching a locally configured IP address against an iPAddress stored in the subjectAltName extension. In this case, the locally configured IP address is converted to an octet string as specified in RFC 5280, Section 4.2.1.6. A match occurs if this octet string is equal to the value of iPAddress in the subjectAltName extension. o The '*' (ASCII 42) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them. o If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format as specified in Section 7 of RFC 5280. === Does this work for anyone? :-) Thanks, Chris _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Sep 3 13:48:31 2008 Return-Path: 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 119FF3A67DB; Wed, 3 Sep 2008 13:48:31 -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 D734A3A67DB for ; Wed, 3 Sep 2008 13:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 IjIOoi-P68jU for ; Wed, 3 Sep 2008 13:48:28 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B67853A65A6 for ; Wed, 3 Sep 2008 13:48:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,320,1217808000"; d="scan'208";a="80145891" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 03 Sep 2008 20:48:36 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m83Kmanf003487 for ; Wed, 3 Sep 2008 13:48:36 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m83Kmanr003045 for ; Wed, 3 Sep 2008 20:48:36 GMT Date: Wed, 3 Sep 2008 13:48:35 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5096; t=1220474916; x=1221338916; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Issues=202,=203,=20and=204=20-=20was=3A=20Re=3A =20[Syslog]=20Need=20your=20input=20on=20final=0A=20issues=2 0on=20draft-ietf-syslog-transport-tls |Sender:=20; bh=k/iwdQ1wFlIlpmGLYa3EVyo1kpx/VQR7tBV4UxlfvF0=; b=u6UMhVtNpU5LwCwjkS6AgLAzQ5HPP1yKdFBEAVP3fZDJfYsTljHfhNLwwr FFmvpiBZHGYshAbLEnhm6WQgnGey5gZtLM4qz3V7dn6tgkKVxsk3s+o0d3Ur zzRWUKBQ6k8qrGBDBsx+6RPXng/uAKF5KM5uBA2aVgXTMVfUwkfTg=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Syslog] Issues 2, 3, and 4 - was: Re: Need your input on final issues on draft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi, We seem to be having a great time discussing issue 1 (below). I think Joe is on top of it and we need some feedback to make sure. I'm going to declare issues 2, 3, and 4 (below) to be resolved. I know people have read them and have not sent in any negative comments or proposed revisions so I'm going to assume that everyone is OK with them. Thanks, Chris On Wed, 27 Aug 2008, Chris Lonvick wrote: > Hi Folks, > > The DISCUSSes and COMMENTs are here: > https://datatracker.ietf.org/idtracker/ballot/2334/ > > Joe, Pasi and Chris Newman have been having a discussion to come up with > modifications to address them. We want to bring these things to the WG to > make sure that implementors are comfortable with these changes. If you > have comments, please send them in. If you read these and agree with the > changes, please comment to the WG list as well so we know that we're > getting an adequate review. > > === 1 === > We have a proposed change to Section 5.2, Subject Name Authorization, > which are the first three paragraphs of Chris Newman's DISCUSS. > > Implementations MUST support specifying the authorized peers using > locally configured host names, MUST support certification path > validation [RFC5280] and matching the name with the certificate as > follows: > > Implementations MUST support matching the locally configured name > against a SubjectAltName field with a type of dNSName and SHOULD > support checking the name against the Common Name portion of the > Subject Distinguished Name. If more than one identity is present > in the certificate, a match in any one of the set is considered > acceptable. > > If the locally configured name is an internationalized domain name, > conforming implementations MUST convert it to the ASCII Compatible > Encoding (ACE) format as specified in Section 7 of RFC 5280. > > The '*' (ASCII 42) wildcard character is allowed in subjectAltName > values of type dNSName (and in Common Name, if used), and then only > as the left-most (least significant) DNS label in that value. This > wildcard matches any left-most DNS label in the server name. That > is, the subject *.example.com matches the server names a.example.com > and b.example.com, but does not match example.com or a.b.example.com. > > Implementations also MAY support wildcards in locally configured > names to match a range of values. Using wildcards makes it > possible to deploy trust-root-based authorization where all > credentials issued by a particular CA trust root are authorized. > > Implementations MAY support matching a locally configured > IP address against a SubjectAltName of type ipAddress. In this > case, the locally configured IP address is converted to an octet > string as specified in RFC 5280, Section 4.2.1.6. A match occurs > if this octet string is equal to the value of subjectAltName of > type iPAddress. > > ==== 2 === > > Joe also wrote for the fourth paragraph of Chris Newman's DISCUSS: > I think the last outstanding issue in the Discuss with using an IANA > registry for hash function names. I think we could use the registry for > RFC 4572. The allocation is tied to PKIX documents, which is probably OK. > The one question is whether someone would adopt a hash function that > become common convention for naming, but was not adopted by PKIX. I think > the risk is very low here. It would change the label in the draft from > "SHA1" to "sha-1". > > The mechanism to generate a fingerprint is to take the hash of > the DER-encoded certificate using a cryptographically strong > algorithm and convert the result into colon separated, > hexadecimal bytes, each represented by 2 uppercase ASCII > characters. When a fingerprint value is displayed or configured > the fingerprint is prepended with an ASCII label identifying the > hash function followed by a colon. The ASCII label is take from > the IANA registry for Hash Function Textual > Names. Implementations MUST support SHA-1 as the hash algorithm > and use the ASCII label "sha-1" from the registry to identify the > SHA-1 algorithm. The length of a SHA-1 hash is 20 bytes and the > length of the corresponding fingerprint string is 64 characters. > An example certificate fingerprint is: > > sha-1:E1:2D:53:2B:7C:6B:8A:29:A2:76:C8:64:36:0B:08:4B:7A:F1:9E:9D > > === 3 === > > We have already cleared Lars' DISCUSS on the system port. > > === 4 === > > I'd like to get a "me too" for Tim's COMMENT: > s/(as described in Sections 5.2 and 5.3)/(as described in Sections 5.3 and > 5.4)/ > > ========= > > > Please comment on these proposed changes. > > Actually, please comment _NOW_ as these are the last things holding up the > three core IDs. :-) > > Thanks, > Chris > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Sep 3 17:35:59 2008 Return-Path: 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 6E0C33A688B; Wed, 3 Sep 2008 17:35:59 -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 34F0C3A688B for ; Wed, 3 Sep 2008 17:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 fZjMzBihtHew for ; Wed, 3 Sep 2008 17:35:57 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 1C99D3A6882 for ; Wed, 3 Sep 2008 17:35:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,320,1217808000"; d="scan'208";a="80227162" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 04 Sep 2008 00:36:02 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m840a27Z018421; Wed, 3 Sep 2008 17:36:02 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m840a2MF000284; Thu, 4 Sep 2008 00:36:02 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 Sep 2008 17:36:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Sep 2008 17:36:07 -0700 Message-ID: In-Reply-To: <017b01c90e04$f132dbf0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Need your inputonfinalissuesondraft-ietf-syslog-transport-tls thread-index: AckNElEZPuXqStNeSDKBOpr1LgypEAAbOVwQACEL2tAAAhNGkA== References: <009201c9092e$3e587560$0601a8c0@allison><003801c90ac0$2c1bfc80$0601a8c0@allison><01f301c90d08$f72275e0$0601a8c0@allison> <017b01c90e04$f132dbf0$0600a8c0@china.huawei.com> From: "Joseph Salowey (jsalowey)" To: "David Harrington" , "syslog" X-OriginalArrivalTime: 04 Sep 2008 00:36:02.0317 (UTC) FILETIME=[355663D0:01C90E26] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3304; t=1220488562; x=1221352562; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Syslog]=20Need=20your=20inputonfinalis suesondraft-ietf-syslog-transport-tls |Sender:=20; bh=qSYmiXzCTSDyM+yoImq0wOmQIrkrhiXk/W20ReQsoK8=; b=YliL8xGpIgNOeAbocIyYFYDygeUbWXZWbZix58/4zv+fXS9LoKh7bfvaST S+zT6svj12nqrx4WqIw+ikJorjvhyk4e9bhW50sgeHF+WksRDwhtHLPTVRlw 0pvAijZV0G; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Syslog] Need your inputonfinalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of David Harrington > Sent: Wednesday, September 03, 2008 1:38 PM > To: 'syslog' > Subject: Re: [Syslog] Need your > inputonfinalissuesondraft-ietf-syslog-transport-tls > > Hi, > > (speaking as a technical contributor) > > > [Joe] OK, thanks. Here is a revision of the text. It probably > still > > needs some work, but hopefully it is in the right direction. > > > > "Implementations MUST support certification path validation > [RFC5280]. > > In addition they MUST support specifying the authorized peers using > > locally configured host names and matching the name against the > > certificate as follows: > > > > Implementations MUST support matching the locally configured host > name > > against a dNSName in the subjectAltName extension field and SHOULD > > support checking the name against the common name portion of the > > subject distinguished name. > > > > If the locally configured name is an internationalized domain name, > > conforming implementations MUST convert it to the ASCII Compatible > > Encoding (ACE) format as specified in Section 7 of RFC 5280. > > Do we need to be clear about when (i.e. for what usages) this > translation needs to be done? Is this necessary before string > comparisons, for example? > [Joe] Yes, I think this section is missing some context: "If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons as specified in Section 7 of RFC 5280." > > The '*' (ASCII 42) wildcard character is allowed in the dNSName of > the > > subjectAltName extension (and in common name, if used to store the > > host name), and then only as the left-most (least significant) DNS > > label in that value. This wildcard matches any left-most > DNS label in > > the server name. That is, the subject *.example.com matches the > > server names a.example.com and b.example.com, but does not match > > example.com or a.b.example.com. Implementations MUST support > wildcards > > in certificates as specified above, but MAY provide a configuration > > option to disable them. > > shouldn't we make the ability to disable wildcards a > MUST-implement, so we can be sure the strong-security option > will be available if an operator wants to disable them for > security reasons? That would seem to be consistent with BCP61. > [Joe] In many cases this policy is left up to the CA as to whether to issue certificates of this type or not, however it has been pointed out on the list that there is a concern that the syslog administrator may not control the CA and may have some different policies than the CA. In this case a control would be necessary. I'd be ok with changing this to a MUST (or a SHOULD). > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu Sep 4 03:11:25 2008 Return-Path: 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 520493A69C1; Thu, 4 Sep 2008 03:11:25 -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 9CC4C3A680D for ; Thu, 4 Sep 2008 03:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.118 X-Spam-Level: X-Spam-Status: No, score=-4.118 tagged_above=-999 required=5 tests=[AWL=-1.519, 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 yAXstg8h+JsR for ; Thu, 4 Sep 2008 03:11:23 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id 214063A68FC for ; Thu, 4 Sep 2008 03:11:14 -0700 (PDT) Received: from mgw-mx09.nokia.com ([192.100.105.134]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m84ABD74001989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 4 Sep 2008 13:11:16 +0300 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m84AAuiZ014390; Thu, 4 Sep 2008 05:11:09 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Sep 2008 13:10:33 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Sep 2008 13:10:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Sep 2008 13:10:35 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201861B7C@vaebe104.NOE.Nokia.com> In-Reply-To: <017b01c90e04$f132dbf0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Need your inputonfinalissuesondraft-ietf-syslog-transport-tls Thread-Index: AckNElEZPuXqStNeSDKBOpr1LgypEAAbOVwQACEL2tAAHKOXkA== References: <009201c9092e$3e587560$0601a8c0@allison><003801c90ac0$2c1bfc80$0601a8c0@allison><01f301c90d08$f72275e0$0601a8c0@allison> <017b01c90e04$f132dbf0$0600a8c0@china.huawei.com> From: "Pasi.Eronen@nokia.com" To: , X-OriginalArrivalTime: 04 Sep 2008 10:10:32.0890 (UTC) FILETIME=[776669A0:01C90E76] X-Nokia-AV: Clean Subject: Re: [Syslog] Need your inputonfinalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org David Harrington wrote: > > If the locally configured name is an internationalized domain name, > > conforming implementations MUST convert it to the ASCII Compatible > > Encoding (ACE) format as specified in Section 7 of RFC 5280. > > Do we need to be clear about when (i.e. for what usages) this > translation needs to be done? Is this necessary before string > comparisons, for example? Could perhaps add "before comparing it with the certificate"? > > The '*' (ASCII 42) wildcard character is allowed in the dNSName of > > the subjectAltName extension (and in common name, if used to store > > the host name), and then only as the left-most (least significant) > > DNS label in that value. This wildcard matches any left-most DNS > > label in the server name. That is, the subject *.example.com > > matches the server names a.example.com and b.example.com, but does > > not match example.com or a.b.example.com. Implementations MUST > > support wildcards in certificates as specified above, but MAY > > provide a configuration option to disable them. > > shouldn't we make the ability to disable wildcards a MUST-implement, > so we can be sure the strong-security option will be available if an > operator wants to disable them for security reasons? That would seem > to be consistent with BCP61. Hmm... IMHO wildcards in certificates are compatible with strong security -- they're just convenient shorthand for multiple names. Disabling wildcards basically makes sense if the operator doesn't trust the CA to issue certificates properly (and IMHO in this case, you have worse problems), so I don't think anything stronger than MAY is needed here. Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu Sep 4 03:12:38 2008 Return-Path: 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 DBD543A68FC; Thu, 4 Sep 2008 03:12:38 -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 96D163A680D for ; Thu, 4 Sep 2008 03:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.069 X-Spam-Level: X-Spam-Status: No, score=-6.069 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 zlYsNqX-XzbT for ; Thu, 4 Sep 2008 03:12:36 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 557ED3A67D0 for ; Thu, 4 Sep 2008 03:12:36 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m84ACOZ9019632; Thu, 4 Sep 2008 13:12:39 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Sep 2008 13:12:35 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Sep 2008 13:12:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 4 Sep 2008 13:12:33 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201861B80@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] revised 5.2 text : please comment was: RE: Need your input on finalissuesondraft-ietf-syslog-transport-tls Thread-Index: AckOBc9yOEWEMKziQ3ymmuFdhVEOjgAcMTgQ References: <009201c9092e$3e587560$0601a8c0@allison><003801c90ac0$2c1bfc80$0601a8c0@allison><01f301c90d08$f72275e0$0601a8c0@allison> From: To: , X-OriginalArrivalTime: 04 Sep 2008 10:12:34.0839 (UTC) FILETIME=[C0165A70:01C90E76] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] revised 5.2 text : please comment was: RE: Need your input on finalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Looks good, but the text about wildcards in locally configured names was lost. Best regards, Pasi > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of ext Chris Lonvick > Sent: 03 September, 2008 23:44 > To: Joseph Salowey (jsalowey) > Cc: syslog > Subject: [Syslog] revised 5.2 text : please comment was: RE: > Need your input on finalissuesondraft-ietf-syslog-transport-tls > > Hi, > > I'm going to take a stab at word smithing. I think there's still some > ambiguity in the section that Joe just proposed and we may be able to > resolve by putting in bullets. Please look at this and give feedback. > > === > Implementations MUST support certification path > validation [RFC5280]. > In addition they MUST support specifying the authorized > peers using > locally configured host names and matching the name against the > certificate as follows. > o Implementations MUST support matching the locally > configured host > name against a dNSName in the subjectAltName > extension field and > SHOULD support checking the name against the common > name portion of > the subject distinguished name. > o Implementations MAY support matching a locally configured IP > address against an iPAddress stored in the subjectAltName > extension. In this case, the locally configured IP address is > converted to an octet string as specified in RFC 5280, Section > 4.2.1.6. A match occurs if this octet string is > equal to the value > of iPAddress in the subjectAltName extension. > o The '*' (ASCII 42) wildcard character is allowed in > the dNSName of > the subjectAltName extension (and in common name, if > used to store > the host name), and then only as the left-most (least > significant) > DNS label in that value. This wildcard matches any > left-most DNS > label in the server name. That is, the subject *.example.com > matches the server names a.example.com and > b.example.com, but does > not match example.com or a.b.example.com. Implementations MUST > support wildcards in certificates as specified above, but MAY > provide a configuration option to disable them. > o If the locally configured name is an internationalized domain > name, conforming implementations MUST convert it to the ASCII > Compatible Encoding (ACE) format as specified in > Section 7 of RFC > 5280. > > === > > Does this work for anyone? :-) > > Thanks, > Chris > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu Sep 4 10:41:25 2008 Return-Path: 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 AACDF3A6800; Thu, 4 Sep 2008 10:41:25 -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 007A93A6800 for ; Thu, 4 Sep 2008 10:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.380, 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 m-a1efLlew3L for ; Thu, 4 Sep 2008 10:41:23 -0700 (PDT) Received: from mk-outboundfilter-5.mail.uk.tiscali.com (mk-outboundfilter-5.mail.uk.tiscali.com [212.74.114.1]) by core3.amsl.com (Postfix) with ESMTP id 52F973A67AE for ; Thu, 4 Sep 2008 10:41:23 -0700 (PDT) X-Trace: 78537558/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.138.220 X-SBRS: None X-RemoteIP: 62.188.138.220 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAFG6v0g+vIrc/2dsb2JhbACDRzmIFaw9A4Fk X-IronPort-AV: E=Sophos;i="4.32,320,1217804400"; d="scan'208";a="78537558" X-IP-Direction: IN Received: from 1cust220.tnt9.lnd4.gbr.da.uu.net (HELO allison) ([62.188.138.220]) by smtp.pipex.tiscali.co.uk with SMTP; 04 Sep 2008 18:41:20 +0100 Message-ID: <004901c90eac$1a14bbe0$0601a8c0@allison> From: "tom.petch" To: "Joseph Salowey \(jsalowey\)" , "Chris Lonvick \(clonvick\)" , "syslog" References: <009201c9092e$3e587560$0601a8c0@allison> <003801c90ac0$2c1bfc80$0601a8c0@allison> <01f301c90d08$f72275e0$0601a8c0@allison> Date: Thu, 4 Sep 2008 18:17:14 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Re: [Syslog] Need your input on finalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Joe Yes, this fixes my comments about the terminology. In case anyone else wonders, 'certification path validation' may read oddly but it is what RFC5280 uses. Tom Petch ----- Original Message ----- From: "Joseph Salowey (jsalowey)" To: "tom.petch" ; "Chris Lonvick (clonvick)" ; "syslog" Sent: Wednesday, September 03, 2008 7:10 AM Subject: RE: [Syslog] Need your input on finalissuesondraft-ietf-syslog-transport-tls > > c) Terminology is inconsistent and at variance with that of > RFC5280; I > > assume that this cannot be implemented without a familiarity with > > RFC5280 and that its terminology is thus the only one we should be > > using. > > > [Joe] I agree we should be in line with RFC 5280. Which > terminology do you think is inconsistent? > > > > 'type iPAddress' is an oxymoron and may raise hackles (does > mine - iPAddress is of type OCTET STRING:-) RFC5280 > classifies it as a field, name form, component but never type. > > 'type ipAddress' see above and in addition 'ipAddress' does not exist. > > 'subjectAltName' is an extension and is always referred to as such. > > 'SubjectAltName' is a type, I think that 'subjectAltName' is meant. > > 'Common Name' is not used in RFC5280, rather 'common name', > likewise 'subject distinguished name' is preferred to > 'Subject Distinguished Name'. > > As I said, I regard familiarity with RFC5280 to be a > prerequisite for this work, and so expect (some) readers of > this I-D to notice these differences, and think the less of > this I-D that they should exist. > [Joe] OK, thanks. Here is a revision of the text. It probably still needs some work, but hopefully it is in the right direction. "Implementations MUST support certification path validation [RFC5280]. In addition they MUST support specifying the authorized peers using locally configured host names and matching the name against the certificate as follows: Implementations MUST support matching the locally configured host name against a dNSName in the subjectAltName extension field and SHOULD support checking the name against the common name portion of the subject distinguished name. If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format as specified in Section 7 of RFC 5280. The '*' (ASCII 42) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them. Implementations MAY support matching a locally configured IP address against an iPAddress stored in the subjectAltName extension. In this case, the locally configured IP address is converted to an octet string as specified in RFC 5280, Section 4.2.1.6. A match occurs if this octet string is equal to the value of iPAddress in the subjectAltName extension." > Tom Petch > > > > > ----- Original Message ----- > > From: "tom.petch" > > To: "Chris Lonvick" ; > > Sent: Thursday, August 28, 2008 6:15 PM > > Subject: Re: [Syslog] Need your input on final > > issuesondraft-ietf-syslog-transport-tls > > > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri Sep 5 09:07:50 2008 Return-Path: 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 2BEA33A68BE; Fri, 5 Sep 2008 09:07:50 -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 C62333A69EB for ; Fri, 5 Sep 2008 09:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Vu3XT-imSA8x for ; Fri, 5 Sep 2008 09:07:44 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id D63D13A6908 for ; Fri, 5 Sep 2008 09:07:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,320,1217808000"; d="scan'208";a="81357595" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 05 Sep 2008 16:07:37 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m85G7bPS007450 for ; Fri, 5 Sep 2008 09:07:37 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m85G7aBZ024935 for ; Fri, 5 Sep 2008 16:07:36 GMT Date: Fri, 5 Sep 2008 09:07:36 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1726; t=1220630857; x=1221494857; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20IETF=20Mailing=20List=20Issue=20(fwd) |Sender:=20; bh=AwdYVS60xkr8rYFNjZRzrW+JdZcT16kSIbFIrR+oB9I=; b=KIWP3ywZm5sZHVmmaHp6Y/KbdPg0mDzv7wb69f4ckxaER7r7PZBmtJT+86 h/kSfBh+FlqYFXtlZKUP4lqApt30S2hXK8RoxeZ2C9XI/COQQ62xlmFNmlba 0/33+1YFG14iT6Ip9YXE/0ti9oS/n5bs8DTfxiF2/T/U+O4TOybkg=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Syslog] IETF Mailing List Issue (fwd) X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi Folks, Please resend if you sent anything to the list in the last 16 hours. Thanks, Chris ---------- Forwarded message ---------- Date: Fri, 05 Sep 2008 09:02:52 -0700 From: Alexa Morris To: "ietf-announce@ietf.org" Cc: Working Group Chairs , IETF Discussion , The IESG Subject: IETF Mailing List Issue Last night, after a server reboot, the postconfirm spam checker that was recently put in front of IETF mailing lists failed to start. Unfortunately, this resulted in a huge influx of spam to the IETF ticket system, and a simultaneous failure of IETF list email. Everything is back online now and functioning; however, email messages sent to IETF lists in the last 16 hours were lost, and will need to be resent. We have now installed a direct watcher on postconfirm, to force a restart of it when it fails. In addition, Henrik is working on the system now to find out why it failed to start in the first place, and why its failure caused mail loss rather than mail deferral. I apologize for any inconvenience this may have caused you. As always, please feel free to contact me if you have any questions or concerns. Regards, Alexa ----------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri Sep 5 15:12:48 2008 Return-Path: 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 036AA3A696A; Fri, 5 Sep 2008 15:12:48 -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 7798A3A696A for ; Fri, 5 Sep 2008 15:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.301 X-Spam-Level: X-Spam-Status: No, score=-6.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ERJrsLhc83pn for ; Fri, 5 Sep 2008 15:12:45 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3CB8D3A6833 for ; Fri, 5 Sep 2008 15:12:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,342,1217808000"; d="scan'208";a="73550756" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 05 Sep 2008 22:10:48 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m85MAmq5006216; Fri, 5 Sep 2008 15:10:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m85MAmxa012903; Fri, 5 Sep 2008 22:10:48 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 Sep 2008 15:10:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 5 Sep 2008 15:10:52 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: revised 5.2 text : please comment was: RE: [Syslog] Need your input on finalissuesondraft-ietf-syslog-transport-tls thread-index: AckOBclM1Vy3wACTQUeLMbdxB6ncxQBmT53w References: <009201c9092e$3e587560$0601a8c0@allison> <003801c90ac0$2c1bfc80$0601a8c0@allison> <01f301c90d08$f72275e0$0601a8c0@allison> From: "Joseph Salowey (jsalowey)" To: "Chris Lonvick (clonvick)" X-OriginalArrivalTime: 05 Sep 2008 22:10:47.0765 (UTC) FILETIME=[3FE2C850:01C90FA4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5176; t=1220652648; x=1221516648; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20revised=205.2=20text=20=3A=20please=20c omment=20was=3A=20RE=3A=20[Syslog]=20Need=20your=20input=20o n=20finalissuesondraft-ietf-syslog-transport-tls |Sender:=20; bh=UCFLX2Wp/UCg/oWQyjwrBaRLtzrdaajahQn2YudCdAc=; b=EEK7+3O3n08sBxBPycJIV5+6zSqm3rAKYIYL/tYcf1akt7VCQaTZdphwBN xrLLZiFI7b8bUK81G8mtiTmjoS+ceZM+N1UcPYM+B2N/huluyuM7klyfZvkO I4ZUE884a/; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: syslog Subject: Re: [Syslog] revised 5.2 text : please comment was: RE: Need your input on finalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org I added information on locally configured names with wildcards, clarified the ACE conversion is for comparison, and change the ordering of the bullets. I think this text should be pretty close now. Implementations MUST support certification path validation [RFC5280]. In addition they MUST support specifying the authorized peers using locally configured host names and matching the name against the certificate as follows. o The '*' (ASCII 42) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them. o Implementations MUST support matching the locally configured host name against a dNSName in the subjectAltName extension field and SHOULD support checking the name against the common name portion of the subject distinguished name. Locally configured names MAY contain the wildcard character to match a range of values. The types of wildcards supported MAY be more flexible than what is allowed in certificate subjects to make it possible to support various policies for different environments. For example, a policy could allow for a trust-root-based authorization where all credentials issued by a particular CA trust root are authorized. o If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons as specified in Section 7 of RFC 5280. o Implementations MAY support matching a locally configured IP address against an iPAddress stored in the subjectAltName extension. In this case, the locally configured IP address is converted to an octet string as specified in RFC 5280, Section 4.2.1.6. A match occurs if this octet string is equal to the value of iPAddress in the subjectAltName extension. Cheers, Joe > -----Original Message----- > From: Chris Lonvick (clonvick) > Sent: Wednesday, September 03, 2008 1:44 PM > To: Joseph Salowey (jsalowey) > Cc: tom.petch; syslog > Subject: revised 5.2 text : please comment was: RE: [Syslog] > Need your input on finalissuesondraft-ietf-syslog-transport-tls > > Hi, > > I'm going to take a stab at word smithing. I think there's > still some ambiguity in the section that Joe just proposed > and we may be able to resolve by putting in bullets. Please > look at this and give feedback. > > === > Implementations MUST support certification path > validation [RFC5280]. > In addition they MUST support specifying the authorized > peers using > locally configured host names and matching the name against the > certificate as follows. > o Implementations MUST support matching the locally > configured host > name against a dNSName in the subjectAltName > extension field and > SHOULD support checking the name against the common > name portion of > the subject distinguished name. > o Implementations MAY support matching a locally configured IP > address against an iPAddress stored in the subjectAltName > extension. In this case, the locally configured IP address is > converted to an octet string as specified in RFC 5280, Section > 4.2.1.6. A match occurs if this octet string is > equal to the value > of iPAddress in the subjectAltName extension. > o The '*' (ASCII 42) wildcard character is allowed in > the dNSName of > the subjectAltName extension (and in common name, if > used to store > the host name), and then only as the left-most (least > significant) > DNS label in that value. This wildcard matches any > left-most DNS > label in the server name. That is, the subject *.example.com > matches the server names a.example.com and > b.example.com, but does > not match example.com or a.b.example.com. Implementations MUST > support wildcards in certificates as specified above, but MAY > provide a configuration option to disable them. > o If the locally configured name is an internationalized domain > name, conforming implementations MUST convert it to the ASCII > Compatible Encoding (ACE) format as specified in > Section 7 of RFC > 5280. > > === > > Does this work for anyone? :-) > > Thanks, > Chris > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Sep 8 08:06:14 2008 Return-Path: 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 422B83A6C17; Mon, 8 Sep 2008 08:06:14 -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 C92723A6C12 for ; Mon, 8 Sep 2008 08:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] 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 UhTKXMx9wHuV for ; Mon, 8 Sep 2008 08:06:11 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 3CCA13A6B61 for ; Mon, 8 Sep 2008 08:06:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,358,1217808000"; d="scan'208";a="82699162" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 08 Sep 2008 15:06:14 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m88F6DCm024026 for ; Mon, 8 Sep 2008 08:06:13 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m88F6DqN016729 for ; Mon, 8 Sep 2008 15:06:13 GMT Date: Mon, 8 Sep 2008 08:06:13 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org Message-ID: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3084; t=1220886373; x=1221750373; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20RE=3A=20revised=205.2=20text=20=3A=20please=20c omment=20was=3A=20RE=3A=20[Syslog]=20Need=20your=0A=20input= 20on=20finalissuesondraft-ietf-syslog-transport-tls=20(fwd) |Sender:=20; bh=WVNwOM421+kP7xlL/1HM5SD7wDOWN9jLLjAklRUzmaU=; b=pooha/NFj1S6OyVSs/s401eozh/Ofc64PHdF9DOOVfrz6J7Oiq+gapXejI 7jIPUKrZtXlrWwMG4GWHLc0dhoq9PmI9gRlknSDRZDlZtqhxD4BMMvoq2ZgP rxOuffe4Hq; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Syslog] revised 5.2 text : please comment was: RE: Need your input on finalissuesondraft-ietf-syslog-transport-tls (fwd) X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi All, I'd like to get feedback in the next day or so. I believe that this addresses all of the open issues with this section. Thanks, Chris ---------- Forwarded message ---------- Date: Fri, 5 Sep 2008 15:10:52 -0700 From: "Joseph Salowey (jsalowey)" To: "Chris Lonvick (clonvick)" Cc: tom.petch , syslog Subject: RE: revised 5.2 text : please comment was: RE: [Syslog] Need your input on finalissuesondraft-ietf-syslog-transport-tls I added information on locally configured names with wildcards, clarified the ACE conversion is for comparison, and change the ordering of the bullets. I think this text should be pretty close now. === Implementations MUST support certification path validation [RFC5280]. In addition they MUST support specifying the authorized peers using locally configured host names and matching the name against the certificate as follows. o The '*' (ASCII 42) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them. o Implementations MUST support matching the locally configured host name against a dNSName in the subjectAltName extension field and SHOULD support checking the name against the common name portion of the subject distinguished name. Locally configured names MAY contain the wildcard character to match a range of values. The types of wildcards supported MAY be more flexible than what is allowed in certificate subjects to make it possible to support various policies for different environments. For example, a policy could allow for a trust-root-based authorization where all credentials issued by a particular CA trust root are authorized. o If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons as specified in Section 7 of RFC 5280. o Implementations MAY support matching a locally configured IP address against an iPAddress stored in the subjectAltName extension. In this case, the locally configured IP address is converted to an octet string as specified in RFC 5280, Section 4.2.1.6. A match occurs if this octet string is equal to the value of iPAddress in the subjectAltName extension. === Cheers, Joe _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue Sep 9 02:40:38 2008 Return-Path: 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 DF12E3A6C15; Tue, 9 Sep 2008 02:40:38 -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 2F1003A6A0A for ; Tue, 9 Sep 2008 02:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.052 X-Spam-Level: X-Spam-Status: No, score=-6.052 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DG8lYJuGJW1M for ; Tue, 9 Sep 2008 02:40:36 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 67F7F3A6965 for ; Tue, 9 Sep 2008 02:40:36 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m899e10e018563; Tue, 9 Sep 2008 04:40:37 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Sep 2008 12:40:36 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Sep 2008 12:40:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Sep 2008 12:40:35 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720191E36A@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] revised 5.2 text : please comment was: RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls Thread-Index: AckOBclM1Vy3wACTQUeLMbdxB6ncxQBmT53wALA6RsA= References: <009201c9092e$3e587560$0601a8c0@allison><003801c90ac0$2c1bfc80$0601a8c0@allison><01f301c90d08$f72275e0$0601a8c0@allison> From: To: , X-OriginalArrivalTime: 09 Sep 2008 09:40:36.0272 (UTC) FILETIME=[1C990300:01C91260] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] revised 5.2 text : please comment was: RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Switching the order of the 1st (wildcards) and 2nd (subjectaltname) bullets would IMHO make the flow more logical. Otherwise, looks good. Best regards, Pasi > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of ext Joseph > Salowey (jsalowey) > Sent: 06 September, 2008 01:11 > To: Chris Lonvick (clonvick) > Cc: syslog > Subject: Re: [Syslog] revised 5.2 text : please comment was: > RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls > > I added information on locally configured names with wildcards, > clarified the ACE conversion is for comparison, and change > the ordering > of the bullets. I think this text should be pretty close now. > > Implementations MUST support certification path validation > [RFC5280]. > In addition they MUST support specifying the authorized > peers using > locally configured host names and matching the name against the > certificate as follows. > > o The '*' (ASCII 42) wildcard character is allowed in > the dNSName > of > the subjectAltName extension (and in common name, if used to > store > the host name), and then only as the left-most (least > significant) > DNS label in that value. This wildcard matches any left-most > DNS > label in the server name. That is, the subject *.example.com > matches the server names a.example.com and b.example.com, but > does > not match example.com or a.b.example.com. Implementations MUST > support wildcards in certificates as specified above, but MAY > provide a configuration option to disable them. > > o Implementations MUST support matching the locally configured > host > name against a dNSName in the subjectAltName > extension field and > SHOULD support checking the name against the common > name portion > of > the subject distinguished name. Locally configured names MAY > contain > the wildcard character to match a range of values. > The types of > > wildcards supported MAY be more flexible than what is > allowed in > > certificate subjects to make it possible to support various > policies > for different environments. For example, a policy could allow > for a > trust-root-based authorization where all credentials > issued by a > > particular CA trust root are authorized. > > o If the locally configured name is an internationalized domain > name, conforming implementations MUST convert it to the ASCII > Compatible Encoding (ACE) format for performing > comparisons as > specified in Section 7 of RFC 5280. > > o Implementations MAY support matching a locally configured IP > address against an iPAddress stored in the subjectAltName > extension. In this case, the locally configured IP address is > converted to an octet string as specified in RFC 5280, Section > 4.2.1.6. A match occurs if this octet string is equal to the > value > of iPAddress in the subjectAltName extension. > > Cheers, > > Joe > > > -----Original Message----- > > From: Chris Lonvick (clonvick) > > Sent: Wednesday, September 03, 2008 1:44 PM > > To: Joseph Salowey (jsalowey) > > Cc: tom.petch; syslog > > Subject: revised 5.2 text : please comment was: RE: [Syslog] > > Need your input on finalissuesondraft-ietf-syslog-transport-tls > > > > Hi, > > > > I'm going to take a stab at word smithing. I think there's > > still some ambiguity in the section that Joe just proposed > > and we may be able to resolve by putting in bullets. Please > > look at this and give feedback. > > > > === > > Implementations MUST support certification path > > validation [RFC5280]. > > In addition they MUST support specifying the authorized > > peers using > > locally configured host names and matching the name against the > > certificate as follows. > > o Implementations MUST support matching the locally > > configured host > > name against a dNSName in the subjectAltName > > extension field and > > SHOULD support checking the name against the common > > name portion of > > the subject distinguished name. > > o Implementations MAY support matching a locally configured IP > > address against an iPAddress stored in the subjectAltName > > extension. In this case, the locally configured IP > address is > > converted to an octet string as specified in RFC > 5280, Section > > 4.2.1.6. A match occurs if this octet string is > > equal to the value > > of iPAddress in the subjectAltName extension. > > o The '*' (ASCII 42) wildcard character is allowed in > > the dNSName of > > the subjectAltName extension (and in common name, if > > used to store > > the host name), and then only as the left-most (least > > significant) > > DNS label in that value. This wildcard matches any > > left-most DNS > > label in the server name. That is, the subject > *.example.com > > matches the server names a.example.com and > > b.example.com, but does > > not match example.com or a.b.example.com. > Implementations MUST > > support wildcards in certificates as specified > above, but MAY > > provide a configuration option to disable them. > > o If the locally configured name is an > internationalized domain > > name, conforming implementations MUST convert it to > the ASCII > > Compatible Encoding (ACE) format as specified in > > Section 7 of RFC > > 5280. > > > > === > > > > Does this work for anyone? :-) > > > > Thanks, > > Chris > > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue Sep 9 06:58:24 2008 Return-Path: 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 B59C13A6C80; Tue, 9 Sep 2008 06:58:24 -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 B5F6228C1B6 for ; Tue, 9 Sep 2008 06:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 HOiAel2yXdRB for ; Tue, 9 Sep 2008 06:58:21 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 78B9028C1A3 for ; Tue, 9 Sep 2008 06:58:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,365,1217808000"; d="scan'208";a="83644568" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 09 Sep 2008 13:57:58 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m89Dvwmr012692; Tue, 9 Sep 2008 06:57:58 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m89DvwXI023551; Tue, 9 Sep 2008 13:57:58 GMT Date: Tue, 9 Sep 2008 06:57:58 -0700 (PDT) From: Chris Lonvick To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB720191E36A@vaebe104.NOE.Nokia.com> Message-ID: References: <009201c9092e$3e587560$0601a8c0@allison><003801c90ac0$2c1bfc80$0601a8c0@allison><01f301c90d08$f72275e0$0601a8c0@allison> <1696498986EFEC4D9153717DA325CB720191E36A@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6711; t=1220968678; x=1221832678; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20RE=3A=20[Syslog]=20revised=205.2=20text=20=3A=2 0please=20comment=20was=3A=20RE=3A=20Need=20yourinput=0A=20o n=20finalissuesondraft-ietf-syslog-transport-tls |Sender:=20; bh=GwpQWh61dg1Yqz6lQPQgYSu1JxPTihzEytxstTqtE1c=; b=TwMzjbZ3j8Ao2CqgSCfJYByk6vjD3wTmPLW3uEE6MAQJIZGibLkAtYERZe pAOUM7WEeG4023ilcQ0acZHzLA8FEdeeEpDDvptpnizRohfu53SjOJOgg+1g 8sdvjA5FYn; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] revised 5.2 text : please comment was: RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi Pasi, On Tue, 9 Sep 2008, Pasi.Eronen@nokia.com wrote: > Switching the order of the 1st (wildcards) and 2nd (subjectaltname) > bullets would IMHO make the flow more logical. Otherwise, looks good. > I see your point but that would create a forward reference. The second bullet (subjectAltName) contains the line, "Locally configured names MAY contain the wildcard character to...". I'm thinking that the wildcard character should be defined before that. It could be swapped with a reference such as the following placed into the subjectAltName bullet, "Locally configured names MAY contain the wildcard character (see next bullet) to...". What does everyone think about this? Thanks, Chris > Best regards, > Pasi > >> -----Original Message----- >> From: syslog-bounces@ietf.org >> [mailto:syslog-bounces@ietf.org] On Behalf Of ext Joseph >> Salowey (jsalowey) >> Sent: 06 September, 2008 01:11 >> To: Chris Lonvick (clonvick) >> Cc: syslog >> Subject: Re: [Syslog] revised 5.2 text : please comment was: >> RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls >> >> I added information on locally configured names with wildcards, >> clarified the ACE conversion is for comparison, and change >> the ordering >> of the bullets. I think this text should be pretty close now. >> >> Implementations MUST support certification path validation >> [RFC5280]. >> In addition they MUST support specifying the authorized >> peers using >> locally configured host names and matching the name against the >> certificate as follows. >> >> o The '*' (ASCII 42) wildcard character is allowed in >> the dNSName >> of >> the subjectAltName extension (and in common name, if used to >> store >> the host name), and then only as the left-most (least >> significant) >> DNS label in that value. This wildcard matches any left-most >> DNS >> label in the server name. That is, the subject *.example.com >> matches the server names a.example.com and b.example.com, but >> does >> not match example.com or a.b.example.com. Implementations MUST >> support wildcards in certificates as specified above, but MAY >> provide a configuration option to disable them. >> >> o Implementations MUST support matching the locally configured >> host >> name against a dNSName in the subjectAltName >> extension field and >> SHOULD support checking the name against the common >> name portion >> of >> the subject distinguished name. Locally configured names MAY >> contain >> the wildcard character to match a range of values. >> The types of >> >> wildcards supported MAY be more flexible than what is >> allowed in >> >> certificate subjects to make it possible to support various >> policies >> for different environments. For example, a policy could allow >> for a >> trust-root-based authorization where all credentials >> issued by a >> >> particular CA trust root are authorized. >> >> o If the locally configured name is an internationalized domain >> name, conforming implementations MUST convert it to the ASCII >> Compatible Encoding (ACE) format for performing >> comparisons as >> specified in Section 7 of RFC 5280. >> >> o Implementations MAY support matching a locally configured IP >> address against an iPAddress stored in the subjectAltName >> extension. In this case, the locally configured IP address is >> converted to an octet string as specified in RFC 5280, Section >> 4.2.1.6. A match occurs if this octet string is equal to the >> value >> of iPAddress in the subjectAltName extension. >> >> Cheers, >> >> Joe >> >>> -----Original Message----- >>> From: Chris Lonvick (clonvick) >>> Sent: Wednesday, September 03, 2008 1:44 PM >>> To: Joseph Salowey (jsalowey) >>> Cc: tom.petch; syslog >>> Subject: revised 5.2 text : please comment was: RE: [Syslog] >>> Need your input on finalissuesondraft-ietf-syslog-transport-tls >>> >>> Hi, >>> >>> I'm going to take a stab at word smithing. I think there's >>> still some ambiguity in the section that Joe just proposed >>> and we may be able to resolve by putting in bullets. Please >>> look at this and give feedback. >>> >>> === >>> Implementations MUST support certification path >>> validation [RFC5280]. >>> In addition they MUST support specifying the authorized >>> peers using >>> locally configured host names and matching the name against the >>> certificate as follows. >>> o Implementations MUST support matching the locally >>> configured host >>> name against a dNSName in the subjectAltName >>> extension field and >>> SHOULD support checking the name against the common >>> name portion of >>> the subject distinguished name. >>> o Implementations MAY support matching a locally configured IP >>> address against an iPAddress stored in the subjectAltName >>> extension. In this case, the locally configured IP >> address is >>> converted to an octet string as specified in RFC >> 5280, Section >>> 4.2.1.6. A match occurs if this octet string is >>> equal to the value >>> of iPAddress in the subjectAltName extension. >>> o The '*' (ASCII 42) wildcard character is allowed in >>> the dNSName of >>> the subjectAltName extension (and in common name, if >>> used to store >>> the host name), and then only as the left-most (least >>> significant) >>> DNS label in that value. This wildcard matches any >>> left-most DNS >>> label in the server name. That is, the subject >> *.example.com >>> matches the server names a.example.com and >>> b.example.com, but does >>> not match example.com or a.b.example.com. >> Implementations MUST >>> support wildcards in certificates as specified >> above, but MAY >>> provide a configuration option to disable them. >>> o If the locally configured name is an >> internationalized domain >>> name, conforming implementations MUST convert it to >> the ASCII >>> Compatible Encoding (ACE) format as specified in >>> Section 7 of RFC >>> 5280. >>> >>> === >>> >>> Does this work for anyone? :-) >>> >>> Thanks, >>> Chris >>> >> _______________________________________________ >> Syslog mailing list >> Syslog@ietf.org >> https://www.ietf.org/mailman/listinfo/syslog >> > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue Sep 9 07:31:12 2008 Return-Path: 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 E37D328C17B; Tue, 9 Sep 2008 07:31:12 -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 7AED03A6B26 for ; Tue, 9 Sep 2008 07:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.095 X-Spam-Level: X-Spam-Status: No, score=-6.095 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 YGjefgdGiUY5 for ; Tue, 9 Sep 2008 07:31:03 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 4904028C17B for ; Tue, 9 Sep 2008 07:31:03 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m89EUvIf016279; Tue, 9 Sep 2008 17:31:02 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Sep 2008 17:30:46 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Sep 2008 17:30:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Sep 2008 17:30:39 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720195BC1B@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] revised 5.2 text : please comment was: RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls Thread-Index: AckShCYIxmVgoSwwTlOnp1vBKY157AABBCGA References: <009201c9092e$3e587560$0601a8c0@allison><003801c90ac0$2c1bfc80$0601a8c0@allison><01f301c90d08$f72275e0$0601a8c0@allison> <1696498986EFEC4D9153717DA325CB720191E36A@vaebe104.NOE.Nokia.com> From: To: X-OriginalArrivalTime: 09 Sep 2008 14:30:40.0987 (UTC) FILETIME=[A29DC2B0:01C91288] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] revised 5.2 text : please comment was: RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Perhaps the text should be split to three bullets, describing the normal case first, and special cases (wildcards in cert, wildcards in local name) next? Like these (just rearranging the text, not changing the words): o Implementations MUST support matching the locally configured host name against a dNSName in the subjectAltName extension field and SHOULD support checking the name against the common name portion of the subject distinguished name. o The '*' (ASCII 42) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them. o Locally configured names MAY contain the wildcard character to match a range of values. The types of wildcards supported MAY be more flexible than what is allowed in certificate subjects to make it possible to support various policies for different environments. For example, a policy could allow for a trust-root-based authorization where all credentials issued by a particular CA trust root are authorized. Best regards, Pasi > -----Original Message----- > From: ext Chris Lonvick [mailto:clonvick@cisco.com] > Sent: 09 September, 2008 16:58 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: jsalowey@cisco.com; syslog@ietf.org > Subject: RE: [Syslog] revised 5.2 text : please comment was: > RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls > > Hi Pasi, > > On Tue, 9 Sep 2008, Pasi.Eronen@nokia.com wrote: > > > Switching the order of the 1st (wildcards) and 2nd (subjectaltname) > > bullets would IMHO make the flow more logical. Otherwise, > looks good. > > > > I see your point but that would create a forward reference. > The second > bullet (subjectAltName) contains the line, "Locally configured > names MAY contain the wildcard character to...". I'm > thinking that the > wildcard character should be defined before that. > > It could be swapped with a reference such as the following > placed into the > subjectAltName bullet, "Locally configured names MAY contain > the wildcard > character (see next bullet) to...". > > What does everyone think about this? > > Thanks, > Chris > > > > Best regards, > > Pasi > > > >> -----Original Message----- > >> From: syslog-bounces@ietf.org > >> [mailto:syslog-bounces@ietf.org] On Behalf Of ext Joseph > >> Salowey (jsalowey) > >> Sent: 06 September, 2008 01:11 > >> To: Chris Lonvick (clonvick) > >> Cc: syslog > >> Subject: Re: [Syslog] revised 5.2 text : please comment was: > >> RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls > >> > >> I added information on locally configured names with wildcards, > >> clarified the ACE conversion is for comparison, and change > >> the ordering > >> of the bullets. I think this text should be pretty close now. > >> > >> Implementations MUST support certification path validation > >> [RFC5280]. > >> In addition they MUST support specifying the authorized > >> peers using > >> locally configured host names and matching the name against the > >> certificate as follows. > >> > >> o The '*' (ASCII 42) wildcard character is allowed in > >> the dNSName > >> of > >> the subjectAltName extension (and in common name, > if used to > >> store > >> the host name), and then only as the left-most (least > >> significant) > >> DNS label in that value. This wildcard matches > any left-most > >> DNS > >> label in the server name. That is, the subject > *.example.com > >> matches the server names a.example.com and > b.example.com, but > >> does > >> not match example.com or a.b.example.com. > Implementations MUST > >> support wildcards in certificates as specified > above, but MAY > >> provide a configuration option to disable them. > >> > >> o Implementations MUST support matching the locally > configured > >> host > >> name against a dNSName in the subjectAltName > >> extension field and > >> SHOULD support checking the name against the common > >> name portion > >> of > >> the subject distinguished name. Locally configured > names MAY > >> contain > >> the wildcard character to match a range of values. > >> The types of > >> > >> wildcards supported MAY be more flexible than what is > >> allowed in > >> > >> certificate subjects to make it possible to support various > >> policies > >> for different environments. For example, a policy > could allow > >> for a > >> trust-root-based authorization where all credentials > >> issued by a > >> > >> particular CA trust root are authorized. > >> > >> o If the locally configured name is an > internationalized domain > >> name, conforming implementations MUST convert it > to the ASCII > >> Compatible Encoding (ACE) format for performing > >> comparisons as > >> specified in Section 7 of RFC 5280. > >> > >> o Implementations MAY support matching a locally > configured IP > >> address against an iPAddress stored in the subjectAltName > >> extension. In this case, the locally configured > IP address is > >> converted to an octet string as specified in RFC > 5280, Section > >> 4.2.1.6. A match occurs if this octet string is > equal to the > >> value > >> of iPAddress in the subjectAltName extension. > >> > >> Cheers, > >> > >> Joe > >> > >>> -----Original Message----- > >>> From: Chris Lonvick (clonvick) > >>> Sent: Wednesday, September 03, 2008 1:44 PM > >>> To: Joseph Salowey (jsalowey) > >>> Cc: tom.petch; syslog > >>> Subject: revised 5.2 text : please comment was: RE: [Syslog] > >>> Need your input on finalissuesondraft-ietf-syslog-transport-tls > >>> > >>> Hi, > >>> > >>> I'm going to take a stab at word smithing. I think there's > >>> still some ambiguity in the section that Joe just proposed > >>> and we may be able to resolve by putting in bullets. Please > >>> look at this and give feedback. > >>> > >>> === > >>> Implementations MUST support certification path > >>> validation [RFC5280]. > >>> In addition they MUST support specifying the authorized > >>> peers using > >>> locally configured host names and matching the name > against the > >>> certificate as follows. > >>> o Implementations MUST support matching the locally > >>> configured host > >>> name against a dNSName in the subjectAltName > >>> extension field and > >>> SHOULD support checking the name against the common > >>> name portion of > >>> the subject distinguished name. > >>> o Implementations MAY support matching a locally > configured IP > >>> address against an iPAddress stored in the subjectAltName > >>> extension. In this case, the locally configured IP > >> address is > >>> converted to an octet string as specified in RFC > >> 5280, Section > >>> 4.2.1.6. A match occurs if this octet string is > >>> equal to the value > >>> of iPAddress in the subjectAltName extension. > >>> o The '*' (ASCII 42) wildcard character is allowed in > >>> the dNSName of > >>> the subjectAltName extension (and in common name, if > >>> used to store > >>> the host name), and then only as the left-most (least > >>> significant) > >>> DNS label in that value. This wildcard matches any > >>> left-most DNS > >>> label in the server name. That is, the subject > >> *.example.com > >>> matches the server names a.example.com and > >>> b.example.com, but does > >>> not match example.com or a.b.example.com. > >> Implementations MUST > >>> support wildcards in certificates as specified > >> above, but MAY > >>> provide a configuration option to disable them. > >>> o If the locally configured name is an > >> internationalized domain > >>> name, conforming implementations MUST convert it to > >> the ASCII > >>> Compatible Encoding (ACE) format as specified in > >>> Section 7 of RFC > >>> 5280. > >>> > >>> === > >>> > >>> Does this work for anyone? :-) > >>> > >>> Thanks, > >>> Chris > >>> > >> _______________________________________________ > >> Syslog mailing list > >> Syslog@ietf.org > >> https://www.ietf.org/mailman/listinfo/syslog > >> > > > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Sep 10 07:21:22 2008 Return-Path: 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 2F5A23A6B7C; Wed, 10 Sep 2008 07:21:22 -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 15F583A6B7C for ; Wed, 10 Sep 2008 07:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.493 X-Spam-Level: X-Spam-Status: No, score=-1.493 tagged_above=-999 required=5 tests=[AWL=1.107, 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 AO2Dpdfi3NIs for ; Wed, 10 Sep 2008 07:21:19 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 296613A6997 for ; Wed, 10 Sep 2008 07:21:19 -0700 (PDT) X-Trace: 25603763/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.60.199 X-SBRS: None X-RemoteIP: 213.116.60.199 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQFADh0x0jVdDzH/2dsb2JhbACDSTyIIKwnA4Fh X-IronPort-AV: E=Sophos;i="4.32,372,1217804400"; d="scan'208";a="25603763" X-IP-Direction: IN Received: from 1cust199.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.199]) by smtp.pipex.tiscali.co.uk with SMTP; 10 Sep 2008 15:21:19 +0100 Message-ID: <009201c91347$21de6ac0$0601a8c0@allison> From: "tom.petch" To: , References: <009201c9092e$3e587560$0601a8c0@allison><003801c90ac0$2c1bfc80$0601a8c0@allison><01f301c90d08$f72275e0$0601a8c0@allison><1696498986EFEC4D9153717DA325CB720191E36A@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB720195BC1B@vaebe104.NOE.Nokia.com> Date: Wed, 10 Sep 2008 15:02:55 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: syslog@ietf.org Subject: Re: [Syslog] revised 5.2 text : please comment was: RE: Needyourinput on finalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Yeees, I think so but ... Have we just introduced 'certificate subjects' where previously we have used 'subject names' eg as in the heading of this section? I assume that both refer to the same concept, in which case I would prefer 'than that which is allowed in subject names'. Tom Petch ----- Original Message ----- From: To: Cc: Sent: Tuesday, September 09, 2008 4:30 PM Subject: Re: [Syslog] revised 5.2 text : please comment was: RE: Needyourinput on finalissuesondraft-ietf-syslog-transport-tls > > Perhaps the text should be split to three bullets, describing the > normal case first, and special cases (wildcards in cert, wildcards > in local name) next? > > Like these (just rearranging the text, not changing the words): > > o Implementations MUST support matching the locally configured host > name against a dNSName in the subjectAltName extension field and > SHOULD support checking the name against the common name portion of > the subject distinguished name. > > o The '*' (ASCII 42) wildcard character is allowed in the dNSName of > the subjectAltName extension (and in common name, if used to store the > host name), and then only as the left-most (least significant) DNS > label in that value. This wildcard matches any left-most DNS label in > the server name. That is, the subject *.example.com matches the > server names a.example.com and b.example.com, but does not match > example.com or a.b.example.com. Implementations MUST support > wildcards in certificates as specified above, but MAY provide a > configuration option to disable them. > > o Locally configured names MAY contain the wildcard character to match > a range of values. The types of wildcards supported MAY be more > flexible than what is allowed in certificate subjects to make it > possible to support various policies for different environments. For > example, a policy could allow for a trust-root-based authorization > where all credentials issued by a particular CA trust root are > authorized. > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Chris Lonvick [mailto:clonvick@cisco.com] > > Sent: 09 September, 2008 16:58 > > To: Eronen Pasi (Nokia-NRC/Helsinki) > > Cc: jsalowey@cisco.com; syslog@ietf.org > > Subject: RE: [Syslog] revised 5.2 text : please comment was: > > RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls > > > > Hi Pasi, > > > > On Tue, 9 Sep 2008, Pasi.Eronen@nokia.com wrote: > > > > > Switching the order of the 1st (wildcards) and 2nd (subjectaltname) > > > bullets would IMHO make the flow more logical. Otherwise, > > looks good. > > > > > > > I see your point but that would create a forward reference. > > The second > > bullet (subjectAltName) contains the line, "Locally configured > > names MAY contain the wildcard character to...". I'm > > thinking that the > > wildcard character should be defined before that. > > > > It could be swapped with a reference such as the following > > placed into the > > subjectAltName bullet, "Locally configured names MAY contain > > the wildcard > > character (see next bullet) to...". > > > > What does everyone think about this? > > > > Thanks, > > Chris > > > > > > > Best regards, > > > Pasi > > > > > >> -----Original Message----- > > >> From: syslog-bounces@ietf.org > > >> [mailto:syslog-bounces@ietf.org] On Behalf Of ext Joseph > > >> Salowey (jsalowey) > > >> Sent: 06 September, 2008 01:11 > > >> To: Chris Lonvick (clonvick) > > >> Cc: syslog > > >> Subject: Re: [Syslog] revised 5.2 text : please comment was: > > >> RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls > > >> > > >> I added information on locally configured names with wildcards, > > >> clarified the ACE conversion is for comparison, and change > > >> the ordering > > >> of the bullets. I think this text should be pretty close now. > > >> > > >> Implementations MUST support certification path validation > > >> [RFC5280]. > > >> In addition they MUST support specifying the authorized > > >> peers using > > >> locally configured host names and matching the name against the > > >> certificate as follows. > > >> > > >> o The '*' (ASCII 42) wildcard character is allowed in > > >> the dNSName > > >> of > > >> the subjectAltName extension (and in common name, > > if used to > > >> store > > >> the host name), and then only as the left-most (least > > >> significant) > > >> DNS label in that value. This wildcard matches > > any left-most > > >> DNS > > >> label in the server name. That is, the subject > > *.example.com > > >> matches the server names a.example.com and > > b.example.com, but > > >> does > > >> not match example.com or a.b.example.com. > > Implementations MUST > > >> support wildcards in certificates as specified > > above, but MAY > > >> provide a configuration option to disable them. > > >> > > >> o Implementations MUST support matching the locally > > configured > > >> host > > >> name against a dNSName in the subjectAltName > > >> extension field and > > >> SHOULD support checking the name against the common > > >> name portion > > >> of > > >> the subject distinguished name. Locally configured > > names MAY > > >> contain > > >> the wildcard character to match a range of values. > > >> The types of > > >> > > >> wildcards supported MAY be more flexible than what is > > >> allowed in > > >> > > >> certificate subjects to make it possible to support various > > >> policies > > >> for different environments. For example, a policy > > could allow > > >> for a > > >> trust-root-based authorization where all credentials > > >> issued by a > > >> > > >> particular CA trust root are authorized. > > >> > > >> o If the locally configured name is an > > internationalized domain > > >> name, conforming implementations MUST convert it > > to the ASCII > > >> Compatible Encoding (ACE) format for performing > > >> comparisons as > > >> specified in Section 7 of RFC 5280. > > >> > > >> o Implementations MAY support matching a locally > > configured IP > > >> address against an iPAddress stored in the subjectAltName > > >> extension. In this case, the locally configured > > IP address is > > >> converted to an octet string as specified in RFC > > 5280, Section > > >> 4.2.1.6. A match occurs if this octet string is > > equal to the > > >> value > > >> of iPAddress in the subjectAltName extension. > > >> > > >> Cheers, > > >> > > >> Joe > > >> > > >>> -----Original Message----- > > >>> From: Chris Lonvick (clonvick) > > >>> Sent: Wednesday, September 03, 2008 1:44 PM > > >>> To: Joseph Salowey (jsalowey) > > >>> Cc: tom.petch; syslog > > >>> Subject: revised 5.2 text : please comment was: RE: [Syslog] > > >>> Need your input on finalissuesondraft-ietf-syslog-transport-tls > > >>> > > >>> Hi, > > >>> > > >>> I'm going to take a stab at word smithing. I think there's > > >>> still some ambiguity in the section that Joe just proposed > > >>> and we may be able to resolve by putting in bullets. Please > > >>> look at this and give feedback. > > >>> > > >>> === > > >>> Implementations MUST support certification path > > >>> validation [RFC5280]. > > >>> In addition they MUST support specifying the authorized > > >>> peers using > > >>> locally configured host names and matching the name > > against the > > >>> certificate as follows. > > >>> o Implementations MUST support matching the locally > > >>> configured host > > >>> name against a dNSName in the subjectAltName > > >>> extension field and > > >>> SHOULD support checking the name against the common > > >>> name portion of > > >>> the subject distinguished name. > > >>> o Implementations MAY support matching a locally > > configured IP > > >>> address against an iPAddress stored in the subjectAltName > > >>> extension. In this case, the locally configured IP > > >> address is > > >>> converted to an octet string as specified in RFC > > >> 5280, Section > > >>> 4.2.1.6. A match occurs if this octet string is > > >>> equal to the value > > >>> of iPAddress in the subjectAltName extension. > > >>> o The '*' (ASCII 42) wildcard character is allowed in > > >>> the dNSName of > > >>> the subjectAltName extension (and in common name, if > > >>> used to store > > >>> the host name), and then only as the left-most (least > > >>> significant) > > >>> DNS label in that value. This wildcard matches any > > >>> left-most DNS > > >>> label in the server name. That is, the subject > > >> *.example.com > > >>> matches the server names a.example.com and > > >>> b.example.com, but does > > >>> not match example.com or a.b.example.com. > > >> Implementations MUST > > >>> support wildcards in certificates as specified > > >> above, but MAY > > >>> provide a configuration option to disable them. > > >>> o If the locally configured name is an > > >> internationalized domain > > >>> name, conforming implementations MUST convert it to > > >> the ASCII > > >>> Compatible Encoding (ACE) format as specified in > > >>> Section 7 of RFC > > >>> 5280. > > >>> > > >>> === > > >>> > > >>> Does this work for anyone? :-) > > >>> > > >>> Thanks, > > >>> Chris > > >>> > > >> _______________________________________________ > > >> Syslog mailing list > > >> Syslog@ietf.org > > >> https://www.ietf.org/mailman/listinfo/syslog > > >> > > > > > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri Sep 12 10:20:02 2008 Return-Path: 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 7F2FF28C143; Fri, 12 Sep 2008 10:20: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 557A628C0F5 for ; Fri, 12 Sep 2008 10:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.523, 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 fyu4LuIH--2m for ; Fri, 12 Sep 2008 10:20:00 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 60BC328C0ED for ; Fri, 12 Sep 2008 10:20:00 -0700 (PDT) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA02.westchester.pa.mail.comcast.net with comcast id DnEm1a0060Fqzac52tKeAn; Fri, 12 Sep 2008 17:19:38 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA08.westchester.pa.mail.comcast.net with comcast id DtKf1a0174HwxpC3UtKgZw; Fri, 12 Sep 2008 17:19:41 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=vvoU6SaGYS5h0m2rz7sA:9 a=mfNSYk8RpEsvF9zMxK0A:7 a=a2_n85NUSBD1VlZpnTIkV2_ebdUA:4 a=lZB815dzVvQA:10 a=chC_agHSu74A:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: , Date: Fri, 12 Sep 2008 13:19:39 -0400 Message-ID: <02f401c914fb$bdbfcbe0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckU+UOUEPgryPeoRYOD5uHir7pLkQAAnJ4A Subject: [Syslog] FW: Nomcom call for candidates X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Friday, September 12, 2008 12:48 PM To: Working Group Chairs Subject: Nomcom call for candidates The message below was just sent to the IETF-Annoucne list. However, it order to get to as many people as possible, I am asking WG chairs a favor. Please forward the message to your working groups. Thank you, Joel M. Halpern The 2008-9 IETF Nominating Committee needs your help. We have started getting candidates. If we are going to do our job in time, we have only 3 more weeks to get enough candidates to have a reasonable pool for all the jobs. At the moment, we do not have a reasonable pool for any jobs. If you are willing to serve, please nominate yourself. If there is someone you think would do a good job, please nominate them. The web site at: http://wiki.tools.ietf.org/group/nomcom/08 Has the list of positions we are seeking people for, as well as tools for providing both nominations and feedback. Alternatively, you can submit nominations by sending email to me. Please help us. Thank you, Joel M. Halpern jmh@joelhalpern.com nomcom-chair@ietf.org _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Sep 15 15:43:59 2008 Return-Path: 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 4E98D3A6A62; Mon, 15 Sep 2008 15:43:59 -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 EC8F53A6A62 for ; Mon, 15 Sep 2008 15:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.95 X-Spam-Level: X-Spam-Status: No, score=-5.95 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] 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 l5UajCMWfe98 for ; Mon, 15 Sep 2008 15:43:56 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 617E03A69D5 for ; Mon, 15 Sep 2008 15:43:56 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 15 Sep 2008 22:44:07 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m8FMi7vr026794; Mon, 15 Sep 2008 15:44:07 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8FMi7sY021868; Mon, 15 Sep 2008 22:44:07 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Sep 2008 15:44:07 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 Sep 2008 15:44:07 -0700 Message-ID: In-Reply-To: <009201c91347$21de6ac0$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] revised 5.2 text : please comment was: RE:Needyourinput on finalissuesondraft-ietf-syslog-transport-tls thread-index: AckTUIr0stJC//7EQdar2sK91C0TMAEMgeLg References: <009201c9092e$3e587560$0601a8c0@allison><003801c90ac0$2c1bfc80$0601a8c0@allison><01f301c90d08$f72275e0$0601a8c0@allison><1696498986EFEC4D9153717DA325CB720191E36A@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB720195BC1B@vaebe104.NOE.Nokia.com> <009201c91347$21de6ac0$0601a8c0@allison> From: "Joseph Salowey (jsalowey)" To: "tom.petch" , , "Chris Lonvick (clonvick)" X-OriginalArrivalTime: 15 Sep 2008 22:44:07.0815 (UTC) FILETIME=[9023B170:01C91784] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13772; t=1221518647; x=1222382647; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Syslog]=20revised=205.2=20text=20=3A=2 0please=20comment=20was=3A=20RE=3ANeedyourinput=20on=20final issuesondraft-ietf-syslog-transport-tls |Sender:=20; bh=17i0dL64ETqLBUJxE97zpYtZnqez2i8UDVXTHc7IuBA=; b=T2JYkdNu13tNryymSkl1o8hEEKDaRQi4npfFAm5jVjt0UW3GGn+6l0n8lc WnIjZig7IMPXYY1Sypv30+upYIb+6dp9egI6d163HQ9sog7Lemr5J59NKBJ1 6nQIoyVAiv; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] revised 5.2 text : please comment was: RE:Needyourinput on finalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Here is the text I will put in the revised draft for this section: Implementations MUST support certification path validation [RFC5280]. In addition they MUST support specifying the authorized peers using locally configured host names and matching the name against the certificate as follows. o Implementations MUST support matching the locally configured host name against a dNSName in the subjectAltName extension field and SHOULD support checking the name against the common name portion of the subject distinguished name. o The '*' (ASCII 42) wildcard character is allowed in the dNSName of the subjectAltName extension (and in common name, if used to store the host name), and then only as the left-most (least significant) DNS label in that value. This wildcard matches any left-most DNS label in the server name. That is, the subject *.example.com matches the server names a.example.com and b.example.com, but does not match example.com or a.b.example.com. Implementations MUST support wildcards in certificates as specified above, but MAY provide a configuration option to disable them. o Locally configured names MAY contain the wildcard character to match a range of values. The types of wildcards supported MAY be more flexible than that which is allowed in subject names to make it possible to support various policies for different environments. For example, a policy could allow for a trust-root-based authorization where all credentials issued by a particular CA trust root are authorized. o If the locally configured name is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format for performing comparisons as specified in Section 7 of RFC 5280. o Implementations MAY support matching a locally configured IP address against an iPAddress stored in the subjectAltName extension. In this case, the locally configured IP address is converted to an octet string as specified in RFC 5280, Section 4.2.1.6. A match occurs if this octet string is equal to the value of iPAddress in the subjectAltName extension. Thanks, Joe > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of tom.petch > Sent: Wednesday, September 10, 2008 6:03 AM > To: Pasi.Eronen@nokia.com; Chris Lonvick (clonvick) > Cc: syslog@ietf.org > Subject: Re: [Syslog] revised 5.2 text : please comment was: > RE:Needyourinput on finalissuesondraft-ietf-syslog-transport-tls > > Yeees, I think so but ... > > Have we just introduced 'certificate subjects' where > previously we have used 'subject names' eg as in the heading > of this section? I assume that both refer to the same > concept, in which case I would prefer 'than that which is > allowed in subject names'. > > Tom Petch > > > ----- Original Message ----- > From: > To: > Cc: > Sent: Tuesday, September 09, 2008 4:30 PM > Subject: Re: [Syslog] revised 5.2 text : please comment was: > RE: Needyourinput on finalissuesondraft-ietf-syslog-transport-tls > > > > > > Perhaps the text should be split to three bullets, describing the > > normal case first, and special cases (wildcards in cert, > wildcards in > > local name) next? > > > > Like these (just rearranging the text, not changing the words): > > > > o Implementations MUST support matching the locally configured host > > name against a dNSName in the subjectAltName extension field and > > SHOULD support checking the name against the common name portion of > > the subject distinguished name. > > > > o The '*' (ASCII 42) wildcard character is allowed in the > dNSName of > > the subjectAltName extension (and in common name, if used > to store the > > host name), and then only as the left-most (least significant) DNS > > label in that value. This wildcard matches any left-most > DNS label in > > the server name. That is, the subject *.example.com matches the > > server names a.example.com and b.example.com, but does not match > > example.com or a.b.example.com. Implementations MUST support > > wildcards in certificates as specified above, but MAY provide a > > configuration option to disable them. > > > > o Locally configured names MAY contain the wildcard > character to match > > a range of values. The types of wildcards supported MAY be more > > flexible than what is allowed in certificate subjects to make it > > possible to support various policies for different > environments. For > > example, a policy could allow for a trust-root-based authorization > > where all credentials issued by a particular CA trust root are > > authorized. > > > > Best regards, > > Pasi > > > > > -----Original Message----- > > > From: ext Chris Lonvick [mailto:clonvick@cisco.com] > > > Sent: 09 September, 2008 16:58 > > > To: Eronen Pasi (Nokia-NRC/Helsinki) > > > Cc: jsalowey@cisco.com; syslog@ietf.org > > > Subject: RE: [Syslog] revised 5.2 text : please comment was: > > > RE: Need yourinput on finalissuesondraft-ietf-syslog-transport-tls > > > > > > Hi Pasi, > > > > > > On Tue, 9 Sep 2008, Pasi.Eronen@nokia.com wrote: > > > > > > > Switching the order of the 1st (wildcards) and 2nd > > > > (subjectaltname) bullets would IMHO make the flow more logical. > > > > Otherwise, > > > looks good. > > > > > > > > > > I see your point but that would create a forward reference. > > > The second > > > bullet (subjectAltName) contains the line, "Locally > configured names > > > MAY contain the wildcard character to...". I'm thinking that the > > > wildcard character should be defined before that. > > > > > > It could be swapped with a reference such as the following placed > > > into the subjectAltName bullet, "Locally configured names MAY > > > contain the wildcard character (see next bullet) to...". > > > > > > What does everyone think about this? > > > > > > Thanks, > > > Chris > > > > > > > > > > Best regards, > > > > Pasi > > > > > > > >> -----Original Message----- > > > >> From: syslog-bounces@ietf.org > > > >> [mailto:syslog-bounces@ietf.org] On Behalf Of ext > Joseph Salowey > > > >> (jsalowey) > > > >> Sent: 06 September, 2008 01:11 > > > >> To: Chris Lonvick (clonvick) > > > >> Cc: syslog > > > >> Subject: Re: [Syslog] revised 5.2 text : please comment was: > > > >> RE: Need yourinput on > > > >> finalissuesondraft-ietf-syslog-transport-tls > > > >> > > > >> I added information on locally configured names with > wildcards, > > > >> clarified the ACE conversion is for comparison, and change the > > > >> ordering of the bullets. I think this text should be > pretty close > > > >> now. > > > >> > > > >> Implementations MUST support certification path validation > > > >> [RFC5280]. > > > >> In addition they MUST support specifying the > authorized peers > > > >> using > > > >> locally configured host names and matching the > name against the > > > >> certificate as follows. > > > >> > > > >> o The '*' (ASCII 42) wildcard character is > allowed in the > > > >> dNSName of > > > >> the subjectAltName extension (and in common name, > > > if used to > > > >> store > > > >> the host name), and then only as the left-most (least > > > >> significant) > > > >> DNS label in that value. This wildcard matches > > > any left-most > > > >> DNS > > > >> label in the server name. That is, the subject > > > *.example.com > > > >> matches the server names a.example.com and > > > b.example.com, but > > > >> does > > > >> not match example.com or a.b.example.com. > > > Implementations MUST > > > >> support wildcards in certificates as specified > > > above, but MAY > > > >> provide a configuration option to disable them. > > > >> > > > >> o Implementations MUST support matching the locally > > > configured > > > >> host > > > >> name against a dNSName in the subjectAltName extension > > > >> field and > > > >> SHOULD support checking the name against the > common name > > > >> portion of > > > >> the subject distinguished name. Locally configured > > > names MAY > > > >> contain > > > >> the wildcard character to match a range of values. > > > >> The types of > > > >> > > > >> wildcards supported MAY be more flexible than what is > > > >> allowed in > > > >> > > > >> certificate subjects to make it possible to support > > > >> various policies > > > >> for different environments. For example, a policy > > > could allow > > > >> for a > > > >> trust-root-based authorization where all credentials > > > >> issued by a > > > >> > > > >> particular CA trust root are authorized. > > > >> > > > >> o If the locally configured name is an > > > internationalized domain > > > >> name, conforming implementations MUST convert it > > > to the ASCII > > > >> Compatible Encoding (ACE) format for performing > > > >> comparisons as > > > >> specified in Section 7 of RFC 5280. > > > >> > > > >> o Implementations MAY support matching a locally > > > configured IP > > > >> address against an iPAddress stored in the > subjectAltName > > > >> extension. In this case, the locally configured > > > IP address is > > > >> converted to an octet string as specified in RFC > > > 5280, Section > > > >> 4.2.1.6. A match occurs if this octet string is > > > equal to the > > > >> value > > > >> of iPAddress in the subjectAltName extension. > > > >> > > > >> Cheers, > > > >> > > > >> Joe > > > >> > > > >>> -----Original Message----- > > > >>> From: Chris Lonvick (clonvick) > > > >>> Sent: Wednesday, September 03, 2008 1:44 PM > > > >>> To: Joseph Salowey (jsalowey) > > > >>> Cc: tom.petch; syslog > > > >>> Subject: revised 5.2 text : please comment was: RE: [Syslog] > > > >>> Need your input on > finalissuesondraft-ietf-syslog-transport-tls > > > >>> > > > >>> Hi, > > > >>> > > > >>> I'm going to take a stab at word smithing. I think > there's still > > > >>> some ambiguity in the section that Joe just proposed > and we may > > > >>> be able to resolve by putting in bullets. Please > look at this > > > >>> and give feedback. > > > >>> > > > >>> === > > > >>> Implementations MUST support certification path > validation > > > >>> [RFC5280]. > > > >>> In addition they MUST support specifying the authorized > > > >>> peers using > > > >>> locally configured host names and matching the name > > > against the > > > >>> certificate as follows. > > > >>> o Implementations MUST support matching the locally > > > >>> configured host > > > >>> name against a dNSName in the subjectAltName > extension > > > >>> field and > > > >>> SHOULD support checking the name against the > common name > > > >>> portion of > > > >>> the subject distinguished name. > > > >>> o Implementations MAY support matching a locally > > > configured IP > > > >>> address against an iPAddress stored in the > subjectAltName > > > >>> extension. In this case, the locally configured IP > > > >> address is > > > >>> converted to an octet string as specified in RFC > > > >> 5280, Section > > > >>> 4.2.1.6. A match occurs if this octet string > is equal > > > >>> to the value > > > >>> of iPAddress in the subjectAltName extension. > > > >>> o The '*' (ASCII 42) wildcard character is > allowed in the > > > >>> dNSName of > > > >>> the subjectAltName extension (and in common name, if > > > >>> used to store > > > >>> the host name), and then only as the left-most (least > > > >>> significant) > > > >>> DNS label in that value. This wildcard matches any > > > >>> left-most DNS > > > >>> label in the server name. That is, the subject > > > >> *.example.com > > > >>> matches the server names a.example.com and > > > >>> b.example.com, but does > > > >>> not match example.com or a.b.example.com. > > > >> Implementations MUST > > > >>> support wildcards in certificates as specified > > > >> above, but MAY > > > >>> provide a configuration option to disable them. > > > >>> o If the locally configured name is an > > > >> internationalized domain > > > >>> name, conforming implementations MUST convert it to > > > >> the ASCII > > > >>> Compatible Encoding (ACE) format as specified > in Section > > > >>> 7 of RFC > > > >>> 5280. > > > >>> > > > >>> === > > > >>> > > > >>> Does this work for anyone? :-) > > > >>> > > > >>> Thanks, > > > >>> Chris > > > >>> > > > >> _______________________________________________ > > > >> Syslog mailing list > > > >> Syslog@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/syslog > > > >> > > > > > > > > > _______________________________________________ > > Syslog mailing list > > Syslog@ietf.org > > https://www.ietf.org/mailman/listinfo/syslog > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue Sep 16 01:57:20 2008 Return-Path: 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 DE0483A6BB0; Tue, 16 Sep 2008 01:57:20 -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 0ED1328C0E5 for ; Tue, 16 Sep 2008 01:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.468 X-Spam-Level: X-Spam-Status: No, score=-1.468 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] 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 b2t2Y+HqtYFe for ; Tue, 16 Sep 2008 01:57:18 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id D9ACF3A68D8 for ; Tue, 16 Sep 2008 01:57:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id B9AAF7AF7CA; Tue, 16 Sep 2008 10:54:36 +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 45HAFPighrmk; Tue, 16 Sep 2008 10:54:36 +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 419E27AF7C7; Tue, 16 Sep 2008 10:54:36 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 Sep 2008 10:57:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44F14D@grfint2.intern.adiscon.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] revised 5.2 text : please comment was:RE:Needyourinput on finalissuesondraft-ietf-syslog-transport-tls Thread-Index: AckTUIr0stJC//7EQdar2sK91C0TMAEMgeLgABXqPIA= References: <009201c9092e$3e587560$0601a8c0@allison><003801c90ac0$2c1bfc80$0601a8c0@allison><01f301c90d08$f72275e0$0601a8c0@allison><1696498986EFEC4D9153717DA325CB720191E36A@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB720195BC1B@vaebe104.NOE.Nokia.com><009201c91347$21de6ac0$0601a8c0@allison> From: "Rainer Gerhards" To: "Joseph Salowey (jsalowey)" , "tom.petch" , , "Chris Lonvick (clonvick)" Cc: syslog@ietf.org Subject: Re: [Syslog] revised 5.2 text : please comment was:RE:Needyourinput on finalissuesondraft-ietf-syslog-transport-tls X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Fine with me. Rainer > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf Of Joseph Salowey (jsalowey) > Sent: Tuesday, September 16, 2008 12:44 AM > To: tom.petch; Pasi.Eronen@nokia.com; Chris Lonvick (clonvick) > Cc: syslog@ietf.org > Subject: Re: [Syslog] revised 5.2 text : please comment > was:RE:Needyourinput on finalissuesondraft-ietf-syslog-transport-tls > > Here is the text I will put in the revised draft for this section: > > Implementations MUST support certification path validation [RFC5280]. > In > addition they MUST support specifying the authorized peers using > locally > configured host names and matching the name against the certificate as > follows. > > o Implementations MUST support matching the locally configured host > name > against a dNSName in the subjectAltName extension field and SHOULD > support checking the name against the common name portion of the > subject > distinguished name. > > o The '*' (ASCII 42) wildcard character is allowed in the dNSName of > the > subjectAltName extension (and in common name, if used to store the host > name), and then only as the left-most (least significant) DNS label in > that value. This wildcard matches any left-most DNS label in the > server > name. That is, the subject *.example.com matches the server names > a.example.com and b.example.com, but does not match example.com or > a.b.example.com. Implementations MUST support wildcards in > certificates > as specified above, but MAY provide a configuration option to disable > them. > > o Locally configured names MAY contain the wildcard character to match > a > range of values. The types of wildcards supported MAY be more flexible > than that which is allowed in subject names to make it possible to > support various policies for different environments. For example, a > policy could allow for a trust-root-based authorization where all > credentials issued by a particular CA trust root are authorized. > > o If the locally configured name is an internationalized domain name, > conforming implementations MUST convert it to the ASCII Compatible > Encoding (ACE) format for performing comparisons as specified in > Section > 7 of RFC 5280. > > o Implementations MAY support matching a locally configured IP address > against an iPAddress stored in the subjectAltName extension. In this > case, the locally configured IP address is converted to an octet string > as specified in RFC 5280, Section 4.2.1.6. A match occurs if this > octet > string is equal to the value of iPAddress in the subjectAltName > extension. > > Thanks, > > Joe > > -----Original Message----- > > From: syslog-bounces@ietf.org > > [mailto:syslog-bounces@ietf.org] On Behalf Of tom.petch > > Sent: Wednesday, September 10, 2008 6:03 AM > > To: Pasi.Eronen@nokia.com; Chris Lonvick (clonvick) > > Cc: syslog@ietf.org > > Subject: Re: [Syslog] revised 5.2 text : please comment was: > > RE:Needyourinput on finalissuesondraft-ietf-syslog-transport-tls > > > > Yeees, I think so but ... > > > > Have we just introduced 'certificate subjects' where > > previously we have used 'subject names' eg as in the heading > > of this section? I assume that both refer to the same > > concept, in which case I would prefer 'than that which is > > allowed in subject names'. > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: > > To: > > Cc: > > Sent: Tuesday, September 09, 2008 4:30 PM > > Subject: Re: [Syslog] revised 5.2 text : please comment was: > > RE: Needyourinput on finalissuesondraft-ietf-syslog-transport-tls > > > > > > > > > > Perhaps the text should be split to three bullets, describing the > > > normal case first, and special cases (wildcards in cert, > > wildcards in > > > local name) next? > > > > > > Like these (just rearranging the text, not changing the words): > > > > > > o Implementations MUST support matching the locally configured host > > > name against a dNSName in the subjectAltName extension field and > > > SHOULD support checking the name against the common name portion of > > > the subject distinguished name. > > > > > > o The '*' (ASCII 42) wildcard character is allowed in the > > dNSName of > > > the subjectAltName extension (and in common name, if used > > to store the > > > host name), and then only as the left-most (least significant) DNS > > > label in that value. This wildcard matches any left-most > > DNS label in > > > the server name. That is, the subject *.example.com matches the > > > server names a.example.com and b.example.com, but does not match > > > example.com or a.b.example.com. Implementations MUST support > > > wildcards in certificates as specified above, but MAY provide a > > > configuration option to disable them. > > > > > > o Locally configured names MAY contain the wildcard > > character to match > > > a range of values. The types of wildcards supported MAY be more > > > flexible than what is allowed in certificate subjects to make it > > > possible to support various policies for different > > environments. For > > > example, a policy could allow for a trust-root-based authorization > > > where all credentials issued by a particular CA trust root are > > > authorized. > > > > > > Best regards, > > > Pasi > > > > > > > -----Original Message----- > > > > From: ext Chris Lonvick [mailto:clonvick@cisco.com] > > > > Sent: 09 September, 2008 16:58 > > > > To: Eronen Pasi (Nokia-NRC/Helsinki) > > > > Cc: jsalowey@cisco.com; syslog@ietf.org > > > > Subject: RE: [Syslog] revised 5.2 text : please comment was: > > > > RE: Need yourinput on finalissuesondraft-ietf-syslog-transport- > tls > > > > > > > > Hi Pasi, > > > > > > > > On Tue, 9 Sep 2008, Pasi.Eronen@nokia.com wrote: > > > > > > > > > Switching the order of the 1st (wildcards) and 2nd > > > > > (subjectaltname) bullets would IMHO make the flow more logical. > > > > > Otherwise, > > > > looks good. > > > > > > > > > > > > > I see your point but that would create a forward reference. > > > > The second > > > > bullet (subjectAltName) contains the line, "Locally > > configured names > > > > MAY contain the wildcard character to...". I'm thinking that the > > > > wildcard character should be defined before that. > > > > > > > > It could be swapped with a reference such as the following placed > > > > into the subjectAltName bullet, "Locally configured names MAY > > > > contain the wildcard character (see next bullet) to...". > > > > > > > > What does everyone think about this? > > > > > > > > Thanks, > > > > Chris > > > > > > > > > > > > > Best regards, > > > > > Pasi > > > > > > > > > >> -----Original Message----- > > > > >> From: syslog-bounces@ietf.org > > > > >> [mailto:syslog-bounces@ietf.org] On Behalf Of ext > > Joseph Salowey > > > > >> (jsalowey) > > > > >> Sent: 06 September, 2008 01:11 > > > > >> To: Chris Lonvick (clonvick) > > > > >> Cc: syslog > > > > >> Subject: Re: [Syslog] revised 5.2 text : please comment was: > > > > >> RE: Need yourinput on > > > > >> finalissuesondraft-ietf-syslog-transport-tls > > > > >> > > > > >> I added information on locally configured names with > > wildcards, > > > > >> clarified the ACE conversion is for comparison, and change the > > > > >> ordering of the bullets. I think this text should be > > pretty close > > > > >> now. > > > > >> > > > > >> Implementations MUST support certification path validation > > > > >> [RFC5280]. > > > > >> In addition they MUST support specifying the > > authorized peers > > > > >> using > > > > >> locally configured host names and matching the > > name against the > > > > >> certificate as follows. > > > > >> > > > > >> o The '*' (ASCII 42) wildcard character is > > allowed in the > > > > >> dNSName of > > > > >> the subjectAltName extension (and in common name, > > > > if used to > > > > >> store > > > > >> the host name), and then only as the left-most (least > > > > >> significant) > > > > >> DNS label in that value. This wildcard matches > > > > any left-most > > > > >> DNS > > > > >> label in the server name. That is, the subject > > > > *.example.com > > > > >> matches the server names a.example.com and > > > > b.example.com, but > > > > >> does > > > > >> not match example.com or a.b.example.com. > > > > Implementations MUST > > > > >> support wildcards in certificates as specified > > > > above, but MAY > > > > >> provide a configuration option to disable them. > > > > >> > > > > >> o Implementations MUST support matching the locally > > > > configured > > > > >> host > > > > >> name against a dNSName in the subjectAltName extension > > > > >> field and > > > > >> SHOULD support checking the name against the > > common name > > > > >> portion of > > > > >> the subject distinguished name. Locally configured > > > > names MAY > > > > >> contain > > > > >> the wildcard character to match a range of values. > > > > >> The types of > > > > >> > > > > >> wildcards supported MAY be more flexible than what is > > > > >> allowed in > > > > >> > > > > >> certificate subjects to make it possible to support > > > > >> various policies > > > > >> for different environments. For example, a policy > > > > could allow > > > > >> for a > > > > >> trust-root-based authorization where all credentials > > > > >> issued by a > > > > >> > > > > >> particular CA trust root are authorized. > > > > >> > > > > >> o If the locally configured name is an > > > > internationalized domain > > > > >> name, conforming implementations MUST convert it > > > > to the ASCII > > > > >> Compatible Encoding (ACE) format for performing > > > > >> comparisons as > > > > >> specified in Section 7 of RFC 5280. > > > > >> > > > > >> o Implementations MAY support matching a locally > > > > configured IP > > > > >> address against an iPAddress stored in the > > subjectAltName > > > > >> extension. In this case, the locally configured > > > > IP address is > > > > >> converted to an octet string as specified in RFC > > > > 5280, Section > > > > >> 4.2.1.6. A match occurs if this octet string is > > > > equal to the > > > > >> value > > > > >> of iPAddress in the subjectAltName extension. > > > > >> > > > > >> Cheers, > > > > >> > > > > >> Joe > > > > >> > > > > >>> -----Original Message----- > > > > >>> From: Chris Lonvick (clonvick) > > > > >>> Sent: Wednesday, September 03, 2008 1:44 PM > > > > >>> To: Joseph Salowey (jsalowey) > > > > >>> Cc: tom.petch; syslog > > > > >>> Subject: revised 5.2 text : please comment was: RE: [Syslog] > > > > >>> Need your input on > > finalissuesondraft-ietf-syslog-transport-tls > > > > >>> > > > > >>> Hi, > > > > >>> > > > > >>> I'm going to take a stab at word smithing. I think > > there's still > > > > >>> some ambiguity in the section that Joe just proposed > > and we may > > > > >>> be able to resolve by putting in bullets. Please > > look at this > > > > >>> and give feedback. > > > > >>> > > > > >>> === > > > > >>> Implementations MUST support certification path > > validation > > > > >>> [RFC5280]. > > > > >>> In addition they MUST support specifying the authorized > > > > >>> peers using > > > > >>> locally configured host names and matching the name > > > > against the > > > > >>> certificate as follows. > > > > >>> o Implementations MUST support matching the locally > > > > >>> configured host > > > > >>> name against a dNSName in the subjectAltName > > extension > > > > >>> field and > > > > >>> SHOULD support checking the name against the > > common name > > > > >>> portion of > > > > >>> the subject distinguished name. > > > > >>> o Implementations MAY support matching a locally > > > > configured IP > > > > >>> address against an iPAddress stored in the > > subjectAltName > > > > >>> extension. In this case, the locally configured IP > > > > >> address is > > > > >>> converted to an octet string as specified in RFC > > > > >> 5280, Section > > > > >>> 4.2.1.6. A match occurs if this octet string > > is equal > > > > >>> to the value > > > > >>> of iPAddress in the subjectAltName extension. > > > > >>> o The '*' (ASCII 42) wildcard character is > > allowed in the > > > > >>> dNSName of > > > > >>> the subjectAltName extension (and in common name, if > > > > >>> used to store > > > > >>> the host name), and then only as the left-most (least > > > > >>> significant) > > > > >>> DNS label in that value. This wildcard matches any > > > > >>> left-most DNS > > > > >>> label in the server name. That is, the subject > > > > >> *.example.com > > > > >>> matches the server names a.example.com and > > > > >>> b.example.com, but does > > > > >>> not match example.com or a.b.example.com. > > > > >> Implementations MUST > > > > >>> support wildcards in certificates as specified > > > > >> above, but MAY > > > > >>> provide a configuration option to disable them. > > > > >>> o If the locally configured name is an > > > > >> internationalized domain > > > > >>> name, conforming implementations MUST convert it to > > > > >> the ASCII > > > > >>> Compatible Encoding (ACE) format as specified > > in Section > > > > >>> 7 of RFC > > > > >>> 5280. > > > > >>> > > > > >>> === > > > > >>> > > > > >>> Does this work for anyone? :-) > > > > >>> > > > > >>> Thanks, > > > > >>> Chris > > > > >>> > > > > >> _______________________________________________ > > > > >> Syslog mailing list > > > > >> Syslog@ietf.org > > > > >> https://www.ietf.org/mailman/listinfo/syslog > > > > >> > > > > > > > > > > > > _______________________________________________ > > > Syslog mailing list > > > Syslog@ietf.org > > > https://www.ietf.org/mailman/listinfo/syslog > > > > _______________________________________________ > > Syslog mailing list > > Syslog@ietf.org > > https://www.ietf.org/mailman/listinfo/syslog > > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue Sep 16 11:00:26 2008 Return-Path: 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 361693A6B4F; Tue, 16 Sep 2008 11:00:26 -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 82C093A6B25 for ; Tue, 16 Sep 2008 11:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 V5tVtsaSmGLC for ; Tue, 16 Sep 2008 11:00:24 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 968363A6A30 for ; Tue, 16 Sep 2008 11:00:24 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 16 Sep 2008 18:00:36 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8GI0a5p027608; Tue, 16 Sep 2008 11:00:36 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8GI0aSj022225; Tue, 16 Sep 2008 18:00:36 GMT Date: Tue, 16 Sep 2008 11:00:36 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org, Pasi.Eronen@nokia.com Message-ID: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1088; t=1221588036; x=1222452036; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20stuff=20I'm=20going=20to=20send=20to=20the=20WG |Sender:=20; bh=NzeNXweMVv/CFmUjGO/3oCYWIXa69L42bWniygi34Sg=; b=hamVGaA+mHoomB0s7ElDE6p/RyRFK6/ORRDajiEk8scqwYKqViqUFJ1LHq H8L/UPPCXmps/js9x79SiFPS8rqzYPAExvlL4HYMt7wltJoNmshR2YOQXzGd gp8EaU9WgQ; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Syslog] stuff I'm going to send to the WG X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi, Below is what I'm planning on sending to the WG to let them know that we're done. === Hi Folks, I'm satisfied that we've had adequate review and discussion on the issues around draft-ietf-syslog-transport-tls. Many thanks to those who reviewed and submitted their suggestions for making the text clearer and more accurate. We've addressed the IESG issues of: - changes requested for Section 5.2 for IDNs and matching http://www.ietf.org/mail-archive/web/syslog/current/msg02113.html - Tim Polk's comment about a reference pointer http://www.ietf.org/mail-archive/web/syslog/current/msg02082.html (I never did get a "me too".) - system v. registered port http://www.ietf.org/mail-archive/web/syslog/current/msg02070.html (Follow the thread.) - the use of an IANA registry http://www.ietf.org/mail-archive/web/syslog/current/msg02082.html and the GEN-ART review issues here: http://www.ietf.org/mail-archive/web/syslog/current/msg02063.html === I think that if you deal with these, we can wrap it up. :-) Thanks, Chris _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue Sep 16 11:05:55 2008 Return-Path: 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 D64403A694A; Tue, 16 Sep 2008 11:05:55 -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 D2BB63A694A for ; Tue, 16 Sep 2008 11:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 RgjIlRPgzps7 for ; Tue, 16 Sep 2008 11:05:53 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6DD063A68CD for ; Tue, 16 Sep 2008 11:05:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,409,1217808000"; d="scan'208";a="156556738" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 16 Sep 2008 18:05:57 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m8GI5vkI009299; Tue, 16 Sep 2008 11:05:57 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.20.39]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m8GI5vff029443; Tue, 16 Sep 2008 18:05:57 GMT Date: Tue, 16 Sep 2008 11:05:56 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org, Pasi.Eronen@nokia.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1847; t=1221588357; x=1222452357; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Ooops=3A=20was=20-=20Re=3A=20[Syslog]=20stuff=2 0I'm=20going=20to=20send=20to=20the=20WG |Sender:=20; bh=YEE1JR3TzH0Al6TnyroWx6YOAw6l9pYDP5NGR5haheM=; b=FZ3eVz5aKeyg0i1sLVLyXWx46tpWetW8z25tSTLzsxOD5WwF6imp5k+IPw dVIXRyao7rtQEvEaMI2wK7HWucF6eIcBxaqTAc2BidSL8iIm+h+WbrAQ5dCe 8bw0T6oYh/; Authentication-Results: sj-dkim-3; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Syslog] Ooops: was - Re: stuff I'm going to send to the WG X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi Folks, Sorry - I jumped the gun on this. Joe is working on the final changes to syslog-transport-tls to address the changes we've discussed since IESG and GEN-ART reviews and I meant to send this just to him. Instead, I sent it to everyone I was planning on sending it to - my bad. We're making sure that we're in synch on this before sending out notices that we've completed the work. ...umm, please delete this and wait for the really big announcement coming real soon. :-) Thanks, Chris On Tue, 16 Sep 2008, Chris Lonvick wrote: > Hi, > > Below is what I'm planning on sending to the WG to let them know that > we're done. > > === > Hi Folks, > > I'm satisfied that we've had adequate review and discussion on the issues > around draft-ietf-syslog-transport-tls. Many thanks to those who reviewed > and submitted their suggestions for making the text clearer and more > accurate. > > We've addressed the IESG issues of: > - changes requested for Section 5.2 for IDNs and matching > http://www.ietf.org/mail-archive/web/syslog/current/msg02113.html > - Tim Polk's comment about a reference pointer > http://www.ietf.org/mail-archive/web/syslog/current/msg02082.html (I > never did get a "me too".) > - system v. registered port > http://www.ietf.org/mail-archive/web/syslog/current/msg02070.html > (Follow the thread.) > - the use of an IANA registry > http://www.ietf.org/mail-archive/web/syslog/current/msg02082.html > and the GEN-ART review issues here: > http://www.ietf.org/mail-archive/web/syslog/current/msg02063.html > > === > > I think that if you deal with these, we can wrap it up. :-) > > Thanks, > Chris > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From eekwapen1974@hercules.com Wed Sep 17 03:10:59 2008 Return-Path: X-Original-To: ietfarch-syslog-archive@core3.amsl.com Delivered-To: ietfarch-syslog-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B62173A6C80 for ; Wed, 17 Sep 2008 03:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.17 X-Spam-Level: X-Spam-Status: No, score=-15.17 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_CPE=0.5, HOST_EQ_CPE=0.979, HTML_MESSAGE=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_ADULT2=1.42, SARE_MLH_Stock1=0.87, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] 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 1IK6+rBHtorE for ; Wed, 17 Sep 2008 03:10:59 -0700 (PDT) Received: from cpe-065-188-255-037.triad.res.rr.com (cpe-065-188-255-037.triad.res.rr.com [65.188.255.37]) by core3.amsl.com (Postfix) with ESMTP id CF4E73A6C64 for ; Wed, 17 Sep 2008 03:10:58 -0700 (PDT) Date: Wed, 17 Sep 2008 06:11:09 -0400 From: Franz User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: syslog-archive@lists.ietf.org Subject: Don't be the laughing stock Content-Type: multipart/alternative; boundary="------------060306050305030605040600" Message-Id: <20080917101058.CF4E73A6C64@core3.amsl.com> --------------060306050305030605040600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Never be flaccid again with this miracle solution - always ready, always rock hard. http://www.kerofit.com/ --------------060306050305030605040600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Never be flaccid again with this miracle solution - always ready, always rock hard.
http://www.kerofit.com/
--------------060306050305030605040600-- From syslog-bounces@ietf.org Mon Sep 29 12:55:09 2008 Return-Path: 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 C709C3A6B41; Mon, 29 Sep 2008 12:55:09 -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 50AC03A6B41 for ; Mon, 29 Sep 2008 12:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[AWL=0.150, 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 YiBIT0Kl9BIu for ; Mon, 29 Sep 2008 12:55:08 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 4FAD23A6B3D for ; Mon, 29 Sep 2008 12:55:07 -0700 (PDT) X-Trace: 141648592/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.131.156 X-SBRS: None X-RemoteIP: 62.188.131.156 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqoEALDP4Eg+vIOc/2dsb2JhbACDQ4kPr2cDgWQ X-IronPort-AV: E=Sophos;i="4.33,333,1220223600"; d="scan'208";a="141648592" X-IP-Direction: IN Received: from 1cust156.tnt2.lnd4.gbr.da.uu.net (HELO allison) ([62.188.131.156]) by smtp.pipex.tiscali.co.uk with SMTP; 29 Sep 2008 20:55:25 +0100 Message-ID: <000c01c92263$e51a9100$0601a8c0@allison> From: "tom.petch" To: "Chris Lonvick" , , "Joe Salowey \(jsalowey\)" References: Date: Mon, 29 Sep 2008 19:17:05 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Syslog] oops? X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Chris, Joe >From syslog-transport-tls-13 "When the client has received the close_notify alert from the server and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert." >From RFC4346 " The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. " Tom Petch _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Sep 29 14:06:53 2008 Return-Path: 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 CB5AE3A69F2; Mon, 29 Sep 2008 14:06:53 -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 292313A693C for ; Mon, 29 Sep 2008 14:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] 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 BY5CHtlCgyHg for ; Mon, 29 Sep 2008 14:06:51 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 551AD3A67A5 for ; Mon, 29 Sep 2008 14:06:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,334,1220227200"; d="scan'208";a="90583734" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 29 Sep 2008 21:07:00 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m8TL70Bq006125; Mon, 29 Sep 2008 14:07:00 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m8TL6xM4014466; Mon, 29 Sep 2008 21:06:59 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Sep 2008 14:06:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 29 Sep 2008 14:06:44 -0700 Message-ID: In-Reply-To: <000c01c92263$e51a9100$0601a8c0@allison> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: oops? thread-index: AckibVWbdNjMZ0DQQYCpT71NYu0EnwACZhXw References: <000c01c92263$e51a9100$0601a8c0@allison> From: "Joseph Salowey (jsalowey)" To: "tom.petch" , "Chris Lonvick (clonvick)" , X-OriginalArrivalTime: 29 Sep 2008 21:06:59.0694 (UTC) FILETIME=[501780E0:01C92277] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=828; t=1222722420; x=1223586420; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20oops? |Sender:=20; bh=K48iBIaFH15el+04rJNLV2iVrHs9BuijJCtVpzUKOlg=; b=PSIs2sJbCXJBSfnNonkA4k2uBsvaSPiDVTT44ZtDd9VcZXpUn7Ti7Y8Cww /1dTTiOhr8/BoYmmYPoVkjL7P5hAPWGONe/pziqhcOu6gQdhv+D/eEfKY8+m 7eGPI0oKaY; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Syslog] oops? X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Same text is in RFC 5246. Looks like we should delete the cited text in syslog-transport-tls-13. Joe > -----Original Message----- > From: tom.petch [mailto:cfinss@dial.pipex.com] > Sent: Monday, September 29, 2008 10:17 AM > To: Chris Lonvick (clonvick); syslog@ietf.org; Joseph Salowey > (jsalowey) > Subject: oops? > > Chris, Joe > > From syslog-transport-tls-13 > > "When the client has received > the close_notify alert from the server and still has > pending data to > send, it SHOULD send the pending data before sending the > close_notify > alert." > > From RFC4346 > > " The other party MUST respond with a close_notify > alert of its own and close down the connection immediately, > discarding any pending writes. " > > Tom Petch > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Sep 29 14:19:43 2008 Return-Path: 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 332DF3A6AFF; Mon, 29 Sep 2008 14:19:43 -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 D0D623A6AFF for ; Mon, 29 Sep 2008 14:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6] 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 DyM2byhiucXx for ; Mon, 29 Sep 2008 14:19:41 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by core3.amsl.com (Postfix) with ESMTP id 969443A6AEF for ; Mon, 29 Sep 2008 14:19:40 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so2214333fkq.5 for ; Mon, 29 Sep 2008 14:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=M4QIEPCxyARIyrKu0riT5LU+EDswsfUmfeh+72FOIV0=; b=eM38t2tt21GSSTuNNrdo5c/IQ4Mm5GJOnL9M/ZnAQmho5sd3tOvLQdbqq6LuZ33tCh QyRg25JvtRqXsrn2GHc9ABzEa7izHt7W7ff2U/DtdWwQEu5K61cJ5miSPrKzauqcIr0o 0OOrTJbKpqBIatCyVadvbm8vkBapNa7SdKKKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=SfkQw4+Mh8SBTIRpsPeO5x5s7Xz9T06mHP3DK1kg929hgqCvuLrzYhu7/cuQNk85eq hsqg8GDO8xHJ5d2J4wuIpLsE2CmO9cFJdsPKPaF97XBIIpbz/IyCO1tZK7IZpiHFZHg/ 2us6rcvOdsklahAPzBcQKsOWt4h86LXvRClDs= Received: by 10.181.22.8 with SMTP id z8mr2839009bki.78.1222723197120; Mon, 29 Sep 2008 14:19:57 -0700 (PDT) Received: by 10.180.251.9 with HTTP; Mon, 29 Sep 2008 14:19:57 -0700 (PDT) Message-ID: Date: Mon, 29 Sep 2008 23:19:57 +0200 From: Badra To: "Joseph Salowey (jsalowey)" In-Reply-To: MIME-Version: 1.0 References: <000c01c92263$e51a9100$0601a8c0@allison> Cc: syslog@ietf.org Subject: Re: [Syslog] oops? X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0602763033==" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org --===============0602763033== Content-Type: multipart/alternative; boundary="----=_Part_44974_31619567.1222723197117" ------=_Part_44974_31619567.1222723197117 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Joe, We are discussing the same issue on the Netconf mailing list and there are two questions from: washam.fan@huawei.com I wanna ask why immediately instead of sending pening writes before close down the connection. j.schoenwaelder@jacobs-university.de: And I like to add whether it is normal practice that the TLS teardown procedure is application protocol specific. RFC 5246 section 7.2.1 discusses closure alerts in TLS 1.2 and I like to understand why we need additional text for NETCONF over TLS. //or syslog-tls. Best regards, Badra On Mon, Sep 29, 2008 at 11:06 PM, Joseph Salowey (jsalowey) < jsalowey@cisco.com> wrote: > Same text is in RFC 5246. Looks like we should delete the cited text > in syslog-transport-tls-13. > > > Joe > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Monday, September 29, 2008 10:17 AM > > To: Chris Lonvick (clonvick); syslog@ietf.org; Joseph Salowey > > (jsalowey) > > Subject: oops? > > > > Chris, Joe > > > > From syslog-transport-tls-13 > > > > "When the client has received > > the close_notify alert from the server and still has > > pending data to > > send, it SHOULD send the pending data before sending the > > close_notify > > alert." > > > > From RFC4346 > > > > " The other party MUST respond with a close_notify > > alert of its own and close down the connection immediately, > > discarding any pending writes. " > > > > Tom Petch > > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > ------=_Part_44974_31619567.1222723197117 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi Joe,
 
We are discussing the same issue on the Netconf mailing list and there are two questions from:
 
I wanna ask why immediately instead of sending pening writes before close down the connection.
And I like to add whether it is normal practice that the TLS teardown procedure is application protocol specific. RFC 5246 section 7.2.1 discusses closure alerts in TLS 1.2 and I like to understand why we need additional text for NETCONF over TLS. //or syslog-tls.
Best regards,
Badra

 
On Mon, Sep 29, 2008 at 11:06 PM, Joseph Salowey (jsalowey) <jsalowey@cisco.com> wrote:
Same text is in RFC 5246.   Looks like we should delete the cited text
in syslog-transport-tls-13.


Joe
> -----Original Message-----
> From: tom.petch [mailto:cfinss@dial.pipex.com]
> Sent: Monday, September 29, 2008 10:17 AM
> To: Chris Lonvick (clonvick); syslog@ietf.org; Joseph Salowey
> (jsalowey)
> Subject: oops?
>
> Chris, Joe
>
> From syslog-transport-tls-13
>
> "When the client has received
>    the close_notify alert from the server and still has
> pending data to
>    send, it SHOULD send the pending data before sending the
> close_notify
>    alert."
>
> From RFC4346
>
> " The other party MUST respond with a close_notify
>    alert of its own and close down the connection immediately,
>    discarding any pending writes.  "
>
> Tom Petch
>
_______________________________________________
Syslog mailing list
Syslog@ietf.org
https://www.ietf.org/mailman/listinfo/syslog
------=_Part_44974_31619567.1222723197117-- --===============0602763033== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog --===============0602763033==-- From syslog-bounces@ietf.org Mon Sep 29 19:48:12 2008 Return-Path: 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 E6A283A6824; Mon, 29 Sep 2008 19:48:12 -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 74D103A67D0 for ; Mon, 29 Sep 2008 19:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4] 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 3y-0c54sHNBX for ; Mon, 29 Sep 2008 19:48:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id DC3223A6824 for ; Mon, 29 Sep 2008 19:48:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.33,334,1220227200"; d="scan'208";a="84452776" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 30 Sep 2008 02:48:30 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m8U2lavH024600; Mon, 29 Sep 2008 19:48:30 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m8U2emaM019939; Tue, 30 Sep 2008 02:43:50 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 Sep 2008 19:43:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 29 Sep 2008 19:43:41 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] oops? thread-index: AckieSD+YgOZjoVYTd6d5qKLN5AFUQAK45QQ References: <000c01c92263$e51a9100$0601a8c0@allison> From: "Joseph Salowey (jsalowey)" To: "Badra" X-OriginalArrivalTime: 30 Sep 2008 02:43:42.0871 (UTC) FILETIME=[5A1FAA70:01C922A6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2469; t=1222742910; x=1223606910; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Syslog]=20oops? |Sender:=20; bh=kbpEUcnV5LLO/5uX2ihatVh1M6bmA/kv2gkQSoXnaUE=; b=D0FVA/Dsi9IE3u9KHHKMhSLg4cZmL7WSUK3q/ZUH3dGLv17b3eRnZX5Fnq vXWLfP1txPBQE/odp5YFJNxQnFc2y3Wnt9lmKN2HsY3cXKIsjcRjYfRSJyEM iaCxiMf7zBXZd9ucP2znNl/WFUTV2iqAuNxNO2KoV0a2Q2K5nWBXo=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] oops? X-BeenThere: syslog@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Issues in Network Event Logging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org In general TLS session tear down process is part of TLS and what happens after TLS is torn down is part of the application. The application also describes application related conditions that result in the closure of the session. In this regard there probably is more text than necessary in section 4.4 in syslog TLS. Joe > -----Original Message----- > From: Badra [mailto:mbadra@gmail.com] > Sent: Monday, September 29, 2008 2:20 PM > To: Joseph Salowey (jsalowey) > Cc: tom. petch; Chris Lonvick (clonvick); > j.schoenwaelder@jacobs-university.de; washam.fan@huawei.com; > syslog@ietf.org > Subject: Re: [Syslog] oops? > > Hi Joe, > > We are discussing the same issue on the Netconf mailing list > and there are two questions from: > > washam.fan@huawei.com > I wanna ask why immediately instead of sending pening writes > before close down the connection. > > j.schoenwaelder@jacobs-university.de: > And I like to add whether it is normal practice that the TLS > teardown procedure is application protocol specific. RFC 5246 > section 7.2.1 discusses closure alerts in TLS 1.2 and I like > to understand why we need additional text for NETCONF over > TLS. //or syslog-tls. > > Best regards, > Badra > > > On Mon, Sep 29, 2008 at 11:06 PM, Joseph Salowey (jsalowey) > wrote: > > > Same text is in RFC 5246. Looks like we should delete > the cited text > in syslog-transport-tls-13. > > > Joe > > > -----Original Message----- > > From: tom.petch [mailto:cfinss@dial.pipex.com] > > Sent: Monday, September 29, 2008 10:17 AM > > To: Chris Lonvick (clonvick); syslog@ietf.org; Joseph Salowey > > (jsalowey) > > Subject: oops? > > > > Chris, Joe > > > > From syslog-transport-tls-13 > > > > "When the client has received > > the close_notify alert from the server and still has > > pending data to > > send, it SHOULD send the pending data before sending the > > close_notify > > alert." > > > > From RFC4346 > > > > " The other party MUST respond with a close_notify > > alert of its own and close down the connection immediately, > > discarding any pending writes. " > > > > Tom Petch > > > _______________________________________________ > Syslog mailing list > Syslog@ietf.org > https://www.ietf.org/mailman/listinfo/syslog > > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog