From syslog-bounces@ietf.org Fri Aug 1 14:50:07 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 991D23A6ADA; Fri, 1 Aug 2008 14:50:07 -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 83DEF3A6AD8 for ; Fri, 1 Aug 2008 14:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.461 X-Spam-Level: X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 UU8WLluBbe8F for ; Fri, 1 Aug 2008 14:50:05 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id A57743A677E for ; Fri, 1 Aug 2008 14:50:05 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 4E72F857E4 for ; Fri, 1 Aug 2008 23:50:25 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id X2lGr2zAr8Vi for ; Fri, 1 Aug 2008 23:50:09 +0200 (CEST) Received: from cordelia.mschuette.name (BAA6605.baa.pppool.de [77.128.102.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 2C3CC857E0 for ; Fri, 1 Aug 2008 23:50:08 +0200 (CEST) Message-ID: <48938517.9070002@mschuette.name> Date: Fri, 01 Aug 2008 23:50:15 +0200 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: syslog@ietf.org References: <1696498986EFEC4D9153717DA325CB720134FF58@vaebe104.NOE.Nokia.com> <488C5270.3010403@mschuette.name> <34A02E87-89BC-4716-BA45-89B2AFD23DB5@callas.org> In-Reply-To: <34A02E87-89BC-4716-BA45-89B2AFD23DB5@callas.org> Subject: Re: [Syslog] Syslog-sign: RSA support? 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Jon Callas schrieb: > Nonetheless, if you're going to do syslog-sign over udp, there's a real > need to keep the signatures small. Good point. > That is why it is DSA. It's also why the encoding is the OpenPGP > encoding, and not DER. It's all to keep things as tight as possible. That should be more explicit. For key blob types 'C' (PKIX) and 'P' (OpenPGP certificates) I would assume a 'usual' encoding in DER and OpenPGP Key Packet format respectively. But there has to be be a better specification for blob type 'K' (public key) -- "raw key data" is not really well-defined. > Obviously, if you're going to do it over TCP, or even TLS, the tightness > is not needed as much. However, it's still nice to have a protocol that > is parsimonious on data. I think ECDSA makes much more sense than RSA > for it. I think this is mainly a compatibility concern for users who have existing PKIX certificates with RSA keys and want to use them for TLS and for signing. When creating new keys for syslog-sign then DSA or ECDSA are clearly preferable. -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri Aug 1 14:51:49 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 1D05728C122; Fri, 1 Aug 2008 14:51:49 -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 8D98E3A677E for ; Fri, 1 Aug 2008 14:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Gl9bSQRdjbWf for ; Fri, 1 Aug 2008 14:51:45 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id 5FE833A6B14 for ; Fri, 1 Aug 2008 14:51:45 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 0A491857E7 for ; Fri, 1 Aug 2008 23:52:01 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id 36tW7i+5KIj0 for ; Fri, 1 Aug 2008 23:51:49 +0200 (CEST) Received: from cordelia.mschuette.name (BAA6605.baa.pppool.de [77.128.102.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id EA0E8857E3 for ; Fri, 1 Aug 2008 23:51:48 +0200 (CEST) Message-ID: <4893857C.5090808@mschuette.name> Date: Fri, 01 Aug 2008 23:51:56 +0200 From: =?ISO-8859-15?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: syslog@ietf.org Subject: [Syslog] Syslog-sign: 6.2. Flexibility 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hello, is section 6.2. (Flexibility) still relevant? I have the impression all of its statements refer to older versions and are obsolete in the current protocol. An originator may change many things about the makeup of Signature and Certificate Blocks in a given reboot session. The things it cannot change are: * The version * The number or arrangements of Signature Groups Question 1: Is there anything left that can be changed inside a reboot session? Only the redundancy, but that is always discussed in 6.1. Question 2: Is there any reason to prevent any change? IMO no. I would say a Signature Group is defined by the values of HOSTNAME, VER, RSID, SG, and SPRI. So if an originator has only one signature group and suddenly uses different values for some Blocks then these Blocks simply will not belong to the same signature group. No need to introduce the concept of change only to forbid it. It is legitimate for an originator to send short Signature Blocks to allow the collector to verify messages quickly. Signature Blocks are variable in length. Allowing a short one is meaningless. -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri Aug 1 14:52:06 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 2AF9D3A6AD0; Fri, 1 Aug 2008 14:52:06 -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 B7E8028C142 for ; Fri, 1 Aug 2008 14:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 8uj5vhZQwG+2 for ; Fri, 1 Aug 2008 14:52:02 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id 339F43A677E for ; Fri, 1 Aug 2008 14:52:02 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 88465857EB for ; Fri, 1 Aug 2008 23:52:15 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id BfBeh5jmXql8 for ; Fri, 1 Aug 2008 23:52:03 +0200 (CEST) Received: from cordelia.mschuette.name (BAA6605.baa.pppool.de [77.128.102.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 7D727857E9 for ; Fri, 1 Aug 2008 23:52:03 +0200 (CEST) Message-ID: <4893858B.8030008@mschuette.name> Date: Fri, 01 Aug 2008 23:52:11 +0200 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: syslog@ietf.org References: <1696498986EFEC4D9153717DA325CB7201350302@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB7201350302@vaebe104.NOE.Nokia.com> Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 2 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Pasi.Eronen@nokia.com schrieb: > Is it possible to sign the same set of messages with multiple > algorithms (by sending multiple Payload and Signature Blocks) to > provide smooth algorithm transition? I think it should be possible. A message can belong to multiple signature groups, so an originator could e.g. use one signature group with SG="0" and VER="0111" and a second one with SG="0" and VER="0121". This leads me to a problem in 4.2.3.: "In all cases, no more than 192 distinct Signature Groups (0-191) are permitted." IMHO that should be removed or changed to "In all cases, no more than 192 distinct SPRI values (0-191) are permitted." Such a limit would clearly prevent using parallel versions for SG="1". Or in another scenario: my syslogd uses SG="3" to assign one signature group per destination. So that limit would prevent the use of more than 192 destinations. > Section 4.2.5: When counting messages for the "First Message Number" > field, are Signature Blocks and Certificate Blocks also counted? Whether the FMN counts syslog-sign messages depends on whether these are hashed and included in Signature Blocks. > Should earlier Signature Block and/or Certificate Block messages > be included in Hash Blocks? 4.1: The syslog messages defined as part of syslog-sign themselves (Signature Block messages and Certificate Block messages) do not need to be signed by a Signature Block. Collectors that implement syslog- sign know to distinguish syslog messages that are associated with syslog-sign from those that are subjected to signing and process them differently. I guess there are arguments for both positions but IMHO syslog-sign messages should not be hashed and included because a) I see syslog-sign as a kind of session-layer that should disappear after the verification is done and some log-analyzer (=application layer) takes over, and b) the verifier will have to know to treat them differently anyway and leaving them out avoids several problems and special cases. Either way the standard has to decide for one position to ensure interoperability. Otherwise one might have a sender that does include hashes of syslog-sign messages in its Signature Blocks and a verifier that will not check them but report lost messages. -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri Aug 1 18:11: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 0257728C16C; Fri, 1 Aug 2008 18:11: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 69F2228C16C for ; Fri, 1 Aug 2008 18:11:56 -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=[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 y9ri5-Uln3yP for ; Fri, 1 Aug 2008 18:11:54 -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 3BD573A6B7A for ; Fri, 1 Aug 2008 18:11:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,296,1215388800"; d="scan'208";a="134719448" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 02 Aug 2008 01:12:14 +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 m721CEVY015517; Fri, 1 Aug 2008 18:12:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m721CEBP017743; Sat, 2 Aug 2008 01:12:14 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 18:12:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 18:12:12 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB0620D1A9@xmb-sjc-236.amer.cisco.com> In-Reply-To: <488C7C58.7040807@mschuette.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Minor clarifications, part 1 Thread-Index: Acjv70hiET8s7V/zSU66qsqbWp9xpgESgadg References: <1696498986EFEC4D9153717DA325CB720134FF6C@vaebe104.NOE.Nokia.com> <488C7C58.7040807@mschuette.name> From: "Alexander Clemm (alex)" To: =?iso-8859-1?Q?Martin_Sch=FCtte?= , X-OriginalArrivalTime: 02 Aug 2008 01:12:13.0463 (UTC) FILETIME=[CBCF3A70:01C8F43C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5112; t=1217639534; x=1218503534; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Syslog]=20Syslog-sign=3A=20Minor=20cla rifications,=20part=201 |Sender:=20; bh=uCWuptXTvHEdVw0B5TBu3cKGZc36jNoCD2P3l3cqNDg=; b=MT/+0e/4FXTXTtiNcwQ60C5a0AL4t45Pr/ZknXAHswHC//eQ2FR8lnlcxT nvjhFkvK/wHvOfa54vJ2ilARovqBBE1nGFe8sPdjknYLYJHrTvjvp6G7M4fM 7/XCByrIa2P5MWZT64gZUoY8Z1J4I4RT9+DahDc07vzg0tO9RaS4k=; Authentication-Results: sj-dkim-1; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 1 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 Hi, couple of responses: = Regarding the exact data that is to be signed: The intent is in essence to = sign the entire message, minus the SDE containing the signature itself. If= the phrase of omission of spaces is confusing, we should omit. So basical= ly I agree with Martin; the example given would then be correct. = Would the resulting text work better: = "The signature is calcluated over the completely formatted Signature Block = message, excluding the signature field (SD Pameter Name and the space befor= e it [" SIGN"], "=3D", and corresponding value)". (in 4.2.8; in 5.3.2.8 re= place "Signature Block" with "Certificate Block") Regarding the order of SD parameters within and SDE: I looked at syslog pro= tocol and didn't see specific statements regarding this. I don't see a nee= d for flexibility in the order - not sure what the benefits of that would b= e; interoperability might be easier to facilitate with a set order. So I w= ould suggest including a statement that the order does matter. = For extending the SDE, I would argue that while this can be extended, an ex= tension would imply a new version (so within -01 the SDE is to be used as i= s). Even within -01, it is not prohibited to carry additional information = (e.g. other SDEs) although it is recommended not to do so (states that the = syslog message SHOULD NOT carry other Structured Data, and that the MSG par= t SHOULD be empty) Regarding SDEs occurring only once, this is actually mandated per the syslo= g protocol. I don't think further clarification is required. = --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of= Martin Sch=FCtte Sent: Sunday, July 27, 2008 6:47 AM To: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 1 Pasi.Eronen@nokia.com schrieb: [...] > Section 4.2.8 and 5.3.2.8: The text needs to be clearer about the = > exact data which is signed. Does this mean a complete SYSLOG-MSG = > (including MSG and other structured data after "ssign", if any), IMHO this is the desired behaviour. > except that STRUCTURED-DATA does not yet contain the SIGN parameter = > (and the space separating it from the previous parameter)? Also, = > excluding spaces here seems really strange -- after all, they're = > included when calculating hashes -- and would seem to complicate = > implementation (also, it's not totally obvious what spaces exactly = > would be excluded). I have no idea what is meant with "excluding spaces between fields". -- Whi= ch fields are referred to? And why should that be useful? I would prefer just to omit the SIGN parameter (and the space). So for example this line is signed: <110>1 2008-07-27T14:54:11.020331+02:00 host.example.com syslogd - - [ssign= VER=3D"0121" RSID=3D"1217163210" SG=3D"3" SPRI=3D"0" GBC=3D"39" FMN=3D"381= " = CNT=3D"10" HB=3D"hsal3vls9LYYmILWrRMmDCfXZyNiPZZftv1pCq99SFk=3D D9aHiwq402fGcQZbJvJokhYWcneWypmdQN5lzlEUe4k=3D u0PrH7zDcNaQxnTZw1qu5yuE7MmPpGsh2pPMhyWJlMA=3D 1jcrmsNxVFqn1hYAhdKhZKC2iRibECdqQXwSeR6rfnM=3D Rg9xSrmaRZgDbQIyTIN8F9kwMAZsOWk7JDy3vZBshlI=3D Cbf5sknv2zW/pT/OQ+yFh1Ge2Hnn9vaiAU8NeQlwTbA=3D = Kl+hnkGOVcMp+iTQ2StbG3g1Sa4sUS6fcBR3z6+/eqY=3D MgOdm1ad/Gkm/emuyPNyKThYQVT9s6W8fk7yqJoid+Y=3D FUY1mt13kFPyoA7yyiR/kIX1dWXXRSahxUMn8rxfunI=3D az/IpvjG1egbXr2xj0hPfCxKGWpAwbdHMkTjcznOpxQ=3D"] And after inserting the signature this will be sent: <110>1 2008-07-27T14:54:11.020331+02:00 host.example.com syslogd - - [ssign= VER=3D"0121" RSID=3D"1217163210" SG=3D"3" SPRI=3D"0" GBC=3D"39" FMN=3D"381= " = CNT=3D"10" HB=3D"hsal3vls9LYYmILWrRMmDCfXZyNiPZZftv1pCq99SFk=3D D9aHiwq402fGcQZbJvJokhYWcneWypmdQN5lzlEUe4k=3D u0PrH7zDcNaQxnTZw1qu5yuE7MmPpGsh2pPMhyWJlMA=3D 1jcrmsNxVFqn1hYAhdKhZKC2iRibECdqQXwSeR6rfnM=3D Rg9xSrmaRZgDbQIyTIN8F9kwMAZsOWk7JDy3vZBshlI=3D Cbf5sknv2zW/pT/OQ+yFh1Ge2Hnn9vaiAU8NeQlwTbA=3D = Kl+hnkGOVcMp+iTQ2StbG3g1Sa4sUS6fcBR3z6+/eqY=3D MgOdm1ad/Gkm/emuyPNyKThYQVT9s6W8fk7yqJoid+Y=3D FUY1mt13kFPyoA7yyiR/kIX1dWXXRSahxUMn8rxfunI=3D az/IpvjG1egbXr2xj0hPfCxKGWpAwbdHMkTjcznOpxQ=3D" = SIGN=3D"39tqZ4p5aWaUs4IOhTRfVT2f95E=3D"] > Section 4.2 and 5.3.2: Are the SD-PARAMs always in this order, or can = > they be in any order? I had the impression that the order of SD-PARAMs (and SD-ELEMENTs) should a= lways be considered arbitrary and irrelevant for interpretation, but now th= at I am looking for it I do not find that in syslog-protocol :-/ > Is it possible that some extension > will later add new SD-PARAMs to these SD-IDs -- if so, how old = > implementations should handle them? I think it should be possible to extend the SDs and the exact set of SD-PAR= AMs should depend on the VERsion. BTW, should it be explicitly required that every SD-PARAM occurs once? = It seems obvious, but syslog-protocol allows repeated parameters... -- Martin _______________________________________________ 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 Aug 1 18:32:33 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 8C5C228C1B1; Fri, 1 Aug 2008 18:32:33 -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 8C7BE28C16D for ; Fri, 1 Aug 2008 18:32:32 -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=[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 igF0MOlzpCnH for ; Fri, 1 Aug 2008 18:32:31 -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 A509E28C1A6 for ; Fri, 1 Aug 2008 18:32:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,296,1215388800"; d="scan'208";a="134724862" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 02 Aug 2008 01:32:34 +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 m721WYLh019687; Fri, 1 Aug 2008 18:32:34 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m721WY0a000587; Sat, 2 Aug 2008 01:32:34 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 18:32:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 18:32:33 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB0620D1B0@xmb-sjc-236.amer.cisco.com> In-Reply-To: <4893857C.5090808@mschuette.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: 6.2. Flexibility Thread-Index: Acj0IPzOZjq2buHdTNmn8nqBmWPyIwAHE5kA References: <4893857C.5090808@mschuette.name> From: "Alexander Clemm (alex)" To: =?iso-8859-1?Q?Martin_Sch=FCtte?= , X-OriginalArrivalTime: 02 Aug 2008 01:32:34.0269 (UTC) FILETIME=[A37770D0:01C8F43F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2768; t=1217640754; x=1218504754; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Syslog]=20Syslog-sign=3A=206.2.=20Flex ibility |Sender:=20; bh=4AQHzigk42tlqMHTKH/zlL55S9t4Cn+u1KXKIJ+2EGo=; b=eZc65wIP0nFJjy8Uo5QWIrmUIv+SoWSaTkX0GNxucbIKJjz4zCoK0rnP/k npWO/NEGoDAEXVF9FyMdAxX07MX+kCAlCafLJLlgfiW8emQGopHKxYr6asiC SDbyvJipmj; Authentication-Results: sj-dkim-3; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Syslog] Syslog-sign: 6.2. Flexibility 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 Martin, to clarify what you are suggesting - are you suggesting to strike section 6= .2 and change the title of 6 to "Redundancy"? I think the entire section i= s in essence informational; per se I would have no issues taking it out. = Now, regarding question 2: I am not clear about what you are asking. How = a signature group is defined is ultimately up to an administrator (specific= ally if SG fields are 2 or 3). It is probably not a good idea to change th= ese on the fly, although it probably does not need to be prohibited. Shoul= d this issue be discussed in a separate statement somewhere? (Basically, i= t would state something along the lines that while it is possible to change= how Signature Groups are configured, adminstrators need to be aware of the= implications.) = The statement at the end of 6.2 states that it is legitimate for an origina= tor to send short Signature Blocks to allow the collector to verify message= s quickly (and not have to wait until a Signature Block is "filled up"). P= recisely because the block are variable in length this is possible. So, I = am not clear what the issue would be with that statement? --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of= Martin Sch=FCtte Sent: Friday, August 01, 2008 2:52 PM To: syslog@ietf.org Subject: [Syslog] Syslog-sign: 6.2. Flexibility Hello, is section 6.2. (Flexibility) still relevant? I have the impression all of its statements refer to older versions and are= obsolete in the current protocol. An originator may change many things about the makeup of Signature and Certificate Blocks in a given reboot session. The things it cannot change are: * The version * The number or arrangements of Signature Groups Question 1: Is there anything left that can be changed inside a reboot sess= ion? Only the redundancy, but that is always discussed in 6.1. Question 2: Is there any reason to prevent any change? IMO no. I would say a Signature Group is defined by the values of HOSTNAME, VER, RS= ID, SG, and SPRI. So if an originator has only one signature group and suddenly uses differen= t values for some Blocks then these Blocks simply will not belong to the sa= me signature group. No need to introduce the concept of change only to forbid it. It is legitimate for an originator to send short Signature Blocks to allow the collector to verify messages quickly. Signature Blocks are variable in length. Allowing a short one is meaningles= s. -- Martin _______________________________________________ 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 Aug 1 18:46:23 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 3B5E93A6B54; Fri, 1 Aug 2008 18:46:23 -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 D723428C1C8 for ; Fri, 1 Aug 2008 18:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 A9bwIfjA1zlB for ; Fri, 1 Aug 2008 18:46:22 -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 F298C3A6B04 for ; Fri, 1 Aug 2008 18:46:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,296,1215388800"; d="scan'208";a="60694354" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 02 Aug 2008 01:46:42 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m721kg7A027685; Fri, 1 Aug 2008 18:46:42 -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 m721kg2q001848; Sat, 2 Aug 2008 01:46:42 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 18:46:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 18:46:41 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB0620D1BB@xmb-sjc-236.amer.cisco.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB7201350200@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Overlapping signature blocks Thread-Index: Acjs4ShbwcwSHqOyRa65GMOdCJS5nQAhZ26wAbZX3WA= References: <1696498986EFEC4D9153717DA325CB720134FF5C@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB7201350200@vaebe104.NOE.Nokia.com> From: "Alexander Clemm (alex)" To: , X-OriginalArrivalTime: 02 Aug 2008 01:46:42.0466 (UTC) FILETIME=[9D080820:01C8F441] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1421; t=1217641602; x=1218505602; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Syslog]=20Syslog-sign=3A=20Overlapping =20signature=20blocks |Sender:=20; bh=mGMhlcgJAl7Wxqtn+ksjQTUXMqb+Nc9kJQk4db3sf7o=; b=r+tpSWem/xguUZe48BDVXNRL9Dm8m5PQEmQXU9W0hsY6l/BlcXcewABoQW faiGgAwqjpmbV/izUNCK57I/yULo/bmPUVUJVizxtlme/C6R1lqauoKPAkVc QsALAFM8CE; Authentication-Results: sj-dkim-3; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Overlapping signature blocks 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 don't see anything that would prohibit sliding windows? Then again, I don't see it mentioned particularly. Would probably not hurt to mention it explicitly. Perhaps some text in section 4.2.5, in conjunction with discussion of First Message Number? Similarly, in section 7.1, when describing the algorithm, can include something along the line that we need to maintain a cursor, indicating the highest message number that was processed so far, and if the subsequent Signature Block message has a smaller FMN, we "skip forward" accordingly. --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Thursday, July 24, 2008 1:34 AM To: jon@callas.org Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Overlapping signature blocks Jon Callas wrote: > Overlap of sliding windows is a feature, not a bug. If anything, we > should reverse the polarity on your comment and more explicitly > mention its utility. I asked about this because some parts of the draft need small changes if overlapping sliding windows are allowed (and I agree that they could be useful). In particular, Sections 7.1 and 7.2 seem to assume no overlap. 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 Fri Aug 1 19:26: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 35C533A695A; Fri, 1 Aug 2008 19:26: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 79DEE3A695A for ; Fri, 1 Aug 2008 19:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 wAnV-Uzky+GH for ; Fri, 1 Aug 2008 19:26:01 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 36F333A68E7 for ; Fri, 1 Aug 2008 19:26:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,296,1215388800"; d="scan'208";a="39668954" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 02 Aug 2008 02:25:30 +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 m722PTgj008664; Fri, 1 Aug 2008 19:25:29 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m722PTL1020476; Sat, 2 Aug 2008 02:25:29 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 19:25:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 19:25:26 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB0620D1BD@xmb-sjc-236.amer.cisco.com> In-Reply-To: <4893858B.8030008@mschuette.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Minor clarifications, part 2 Thread-Index: Acj0IOrv8b89PLCgREusHDLxcm3C7gAIWpBQ References: <1696498986EFEC4D9153717DA325CB7201350302@vaebe104.NOE.Nokia.com> <4893858B.8030008@mschuette.name> From: "Alexander Clemm (alex)" To: =?iso-8859-1?Q?Martin_Sch=FCtte?= , X-OriginalArrivalTime: 02 Aug 2008 02:25:29.0116 (UTC) FILETIME=[07D2A5C0:01C8F447] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4441; t=1217643930; x=1218507930; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Syslog]=20Syslog-sign=3A=20Minor=20cla rifications,=20part=202 |Sender:=20; bh=rSVN69n4DRv1nQ8iobjJa+IAcLgDNb8XJtht3wkOdXk=; b=M17MqV139PYxobYbFn6uSuzMEAicVRlge0GT+4LRGghV6kRd2xjIxpp85W uCpY6P+CSK5I3F3IrcKjkjKKjfTcUdldcF0Bt9fFmidBChFTCXYeWzl4sSda oijsOJ8vTH; Authentication-Results: sj-dkim-2; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 2 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 Hi, please see inline, delimited --- Alex = -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of= Martin Sch=FCtte Sent: Friday, August 01, 2008 2:52 PM To: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 2 Pasi.Eronen@nokia.com schrieb: > Is it possible to sign the same set of messages with multiple = > algorithms (by sending multiple Payload and Signature Blocks) to = > provide smooth algorithm transition? I think it should be possible. A message can belong to multiple signature groups, so an originator could e= .g. use one signature group with SG=3D"0" and VER=3D"0111" and a second one= with SG=3D"0" and VER=3D"0121". = The same message can be in multiple signature groups and hence be signed mu= ltiple times. It is also possible to define multiple signature groups so t= hat each contain exactly the same messages (e.g. SG=3D"3", which basically = means administrator-defined which would be anything). = This leaves the question whether it should be possible to sign the *same* s= ignature group with multiple algorithms. There are currently no provisions= for that. The spec also states that a payload block (containing the certi= ficate information) is valid for the entire reboot session - we currently d= o not allow to change it during a reboot session. If this is an issue, it = will have some ramifications. One way to deal with it would be to change t= he way a "reboot session" is defined. = Thoughts? = This leads me to a problem in 4.2.3.: "In all cases, no more than 192 disti= nct Signature Groups (0-191) are permitted." IMHO that should be removed or changed to "In all cases, no more than 192 distinct SPRI values (0-191) are permitted." Such a limit would clearly prevent using parallel versions for SG=3D"1". Or in another scenario: my syslogd uses SG=3D"3" to assign one signature gr= oup per destination. So that limit would prevent the use of more than 192 destinations. I am not sure I understand the issue? The fact that the SPRI parameter may= take only values from 0-191 inclusive already implies there can be no more= than 192 values? I think the statement is correct as is - the signature g= roup refers to a set of syslog messages while the SPRI value defines what m= essages that set contains - we do however want to call out that there can b= e no more than 192 such sets. = > Section 4.2.5: When counting messages for the "First Message Number" > field, are Signature Blocks and Certificate Blocks also counted? Whether the FMN counts syslog-sign messages depends on whether these are ha= shed and included in Signature Blocks. > Should earlier Signature Block and/or Certificate Block messages be = > included in Hash Blocks? 4.1: The syslog messages defined as part of syslog-sign themselves (Signature Block messages and Certificate Block messages) do not need to be signed by a Signature Block. Collectors that implement syslog- sign know to distinguish syslog messages that are associated with syslog-sign from those that are subjected to signing and process them differently. I guess there are arguments for both positions but IMHO syslog-sign message= s should not be hashed and included because a) I see syslog-sign as a kind of session-layer that should disappear after= the verification is done and some log-analyzer (=3Dapplication layer) takes over, and b) the verifier will have to know to treat them differently anyway and leav= ing them out avoids several problems and special cases. Either way the standard has to decide for one position to ensure interopera= bility. Otherwise one might have a sender that does include hashes of syslo= g-sign messages in its Signature Blocks and a verifier that will not check = them but report lost messages. Section 4.1 states that syslog-sign messages are not counted and not signed= , so I think the current position is clear. Martin, I agree with your reas= oning and argumentation. Essentially, the purpose is to sign a stream of m= essages, not alter that stream of messages. = -- Martin _______________________________________________ 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 Aug 1 19:34:11 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 88D9C3A6B04; Fri, 1 Aug 2008 19:34:11 -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 6AD013A6B04 for ; Fri, 1 Aug 2008 19:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.337 X-Spam-Level: X-Spam-Status: No, score=-6.337 tagged_above=-999 required=5 tests=[AWL=-0.037, 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 sxnFy4KA-A+D for ; Fri, 1 Aug 2008 19:34: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 7FCF63A68E7 for ; Fri, 1 Aug 2008 19:34:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,296,1215388800"; d="scan'208";a="60699444" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 02 Aug 2008 02:33:18 +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 m722XIJW006871; Fri, 1 Aug 2008 19:33:18 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m722XIMu021384; Sat, 2 Aug 2008 02:33:18 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Aug 2008 19:32:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 1 Aug 2008 19:32:24 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB0620D1BE@xmb-sjc-236.amer.cisco.com> In-Reply-To: <488C530F.3090101@mschuette.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Multiple signers on host? Thread-Index: Acjv158wlELGfTgTQBS/ehxc5kHEMwEb+Aow References: <1696498986EFEC4D9153717DA325CB72013502F1@vaebe104.NOE.Nokia.com> <488C530F.3090101@mschuette.name> From: "Alexander Clemm (alex)" To: =?iso-8859-1?Q?Martin_Sch=FCtte?= , X-OriginalArrivalTime: 02 Aug 2008 02:32:27.0670 (UTC) FILETIME=[014CEB60:01C8F448] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1656; t=1217644398; x=1218508398; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Syslog]=20Syslog-sign=3A=20Multiple=20 signers=20on=20host? |Sender:=20; bh=BeL8iAF+FHXUurQjI7/AUDzy7q2tlzngpOJRfMSdNtw=; b=sAhHIfSbkX8RmD5Wo150OJ5oJ5rODl8tGjlbZI/y9vO8esrdFB/93rseIX R9Rt09UWmI06+2fFz43obYr0rc8ayby3H8G1mOaPf0lzj82INqkqtjBjWzhe HPAkb8CgR7; Authentication-Results: sj-dkim-4; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Syslog] Syslog-sign: Multiple signers on host? 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 That a valid APP-NAME and PROCID need to be included is a given. Currently,= the statement is that originators SHOULD use the same values for those fie= ld for every message to be consistent (e.g. section 4.1 and 5.3.1). Should= this "SHOULD" be changed to "MUST" and a statement be added that APP-NAME = and PROCID are supposed to uniquely identify a signer on HOSTNAME? = --- Alex = -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of= Martin Sch=FCtte Sent: Sunday, July 27, 2008 3:51 AM To: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Multiple signers on host? Pasi.Eronen@nokia.com schrieb: > Or maybe something else? Are the APP-NAME/PROCID of any use here? IMHO the easiest solution would be a requirement for every sender to provid= e APP-NAME/PROCID information. Then every originator is determined by the triple (HOSTNAME, APP-NAME, PROCID) and every signature group by (HOSTNAME, APP-NAME, PROCID, SG, SPRI). > Section 4.2.2 (about the reboot session ID) also assumes a central = > syslog process that's tightly coupled with host reboots -- it should = > be described in terms that make sense in other models, too. Is it acceptable to use the time(), i.e. seconds since the epoch, as a rebo= ot session ID? This does "increase whenever an originator reboots" even without the need "= to retain the previous Reboot Session ID across reboots" and without any re= lation to host reboots. -- Martin _______________________________________________ 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 Aug 4 06:49:11 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 6A49E28C297; Mon, 4 Aug 2008 06:49:11 -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 6980728C297 for ; Mon, 4 Aug 2008 06:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 faAZgh2LrYuq for ; Mon, 4 Aug 2008 06:49:09 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id 6E0BE28C28C for ; Mon, 4 Aug 2008 06:49:09 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 7307F85D6A for ; Mon, 4 Aug 2008 15:49:35 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id FYgDV8zqea0D for ; Mon, 4 Aug 2008 15:49:23 +0200 (CEST) Received: from cordelia.mschuette.name (BAA4339.baa.pppool.de [77.128.67.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 8C47785D5A for ; Mon, 4 Aug 2008 15:49:22 +0200 (CEST) Message-ID: <489708E8.80400@mschuette.name> Date: Mon, 04 Aug 2008 15:49:28 +0200 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: syslog@ietf.org References: <1696498986EFEC4D9153717DA325CB72013502F1@vaebe104.NOE.Nokia.com> <488C530F.3090101@mschuette.name> <85B2F271FDF6B949B3672BA5A7BB62FB0620D1BE@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB0620D1BE@xmb-sjc-236.amer.cisco.com> Subject: Re: [Syslog] Syslog-sign: Multiple signers on host? 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Alexander Clemm (alex) schrieb: > That a valid APP-NAME and PROCID need to be included is a given. Are NILVALUEs valid? > Currently, the statement is that originators SHOULD use the same > values for those field for every message to be consistent (e.g. > section 4.1 and 5.3.1). Should this "SHOULD" be changed to "MUST" > and a statement be added that APP-NAME and PROCID are supposed to > uniquely identify a signer on HOSTNAME? Yes; if we use these values to distingiush different originators on the same host then they MUST be consistent. I would suggest: This specification does not mandate particular values for these fields; however, for consistency, originators MUST use the same values for APP-NAME, PROCID, and MSGID fields for every Certificate Block and Signature Block message that is sent for one Signature Group, whichever values are chosen. To allow multiple originators per host, these values MUST be unique for the duration of the Signature Group. Intention here: a) if there is only one originator per hostname possible (use case: on a printer) then NILVALUEs are ok, because (together with the HOSTNAME) they still identify one originator. b) I think some time duration is necessary and chosen to impose the least restrictions. So the values have to stay the same for one Signature Group. That makes sure they can be used as identifiers for that Signature Group but leaves enough room for implementations. It is then possible to - restart the daemon, thus changing RSID and PROCID - use another program, thus changing RSID, APP-NAME, and PROCID - use different PROCIDs in parallel (use case: one process per Signature Group). One more thing: Except for the APP-NAME alone basically all selections from (APP-NAME, PROCID, MSGID) could be used. APP-NAME and PROCID would identify one orginator just as well. So if it seems like there could be other uses for a MSGID then that does not have to be fixed. -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Aug 4 06:49:23 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 8D8E528C29D; Mon, 4 Aug 2008 06:49:23 -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 D4CB128C296 for ; Mon, 4 Aug 2008 06:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.961 X-Spam-Level: X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_05=-1.11, HELO_EQ_DE=0.35, 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 L3EUiSPOYTIH for ; Mon, 4 Aug 2008 06:49:22 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id A695128C29F for ; Mon, 4 Aug 2008 06:49:21 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id E735F85D6A for ; Mon, 4 Aug 2008 15:49:48 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id Bj2IeuTWi2ug for ; Mon, 4 Aug 2008 15:49:36 +0200 (CEST) Received: from cordelia.mschuette.name (BAA4339.baa.pppool.de [77.128.67.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 848B785D6B for ; Mon, 4 Aug 2008 15:49:36 +0200 (CEST) Message-ID: <489708F6.8070104@mschuette.name> Date: Mon, 04 Aug 2008 15:49:42 +0200 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: syslog@ietf.org References: <1696498986EFEC4D9153717DA325CB7201350302@vaebe104.NOE.Nokia.com> <4893858B.8030008@mschuette.name> <85B2F271FDF6B949B3672BA5A7BB62FB0620D1BD@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB0620D1BD@xmb-sjc-236.amer.cisco.com> Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 2 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Alexander Clemm (alex) schrieb: > This leaves the question whether it should be possible to sign the > *same* signature group with multiple algorithms. There are currently > no provisions for that. The spec also states that a payload block > (containing the certificate information) is valid for the entire > reboot session - we currently do not allow to change it during a > reboot session. If this is an issue, it will have some > ramifications. One way to deal with it would be to change the way a > "reboot session" is defined. > > Thoughts? To allow multiple algorithms inside one signature group then one could use multiple SIGN params with prefixes to identify their algorithm. E.g. [ssign ... SIGN="1;" SIGN="2;"]. But I do not like the concept. Just using two Signature Groups in parallel allows the same thing with greater flexibility and simpler implementations. (Maybe with more messages, but that is not negative for a protocol that has to be redundant by design,) > This leads me to a problem in 4.2.3.: "In all cases, no more than 192 > distinct Signature Groups (0-191) are permitted." > > I am not sure I understand the issue? I think the problem is we have different concepts of a "Signature Group". A definition would be useful. The Introduction states "A Signature Group identifies a group of messages that are all kept together for signing purposes by the originator." I would add the list of attributes that I consider the actual identifiers: (HOSTNAME, APP-NAME, PROCID, MSGID, VER, RSID, SG, SPRI). It follows: Two syslog-sign messages with the same values for these fields belong to the same Signature Group. Two syslog-sign messages which values differ in any of these fields do not belong to the same Signature Group. > The fact that the SPRI > parameter may take only values from 0-191 inclusive already implies > there can be no more than 192 values? Yes, indeed. But that makes the sencence only more confusing, because what do the given numbers 0-191 mean if they do not refer to SPRI values? I think the statement is > correct as is - the signature group refers to a set of syslog > messages while the SPRI value defines what messages that set contains > - we do however want to call out that there can be no more than 192 > such sets. I am sorry if this appears like nit-picking, but do you say - There can be no more (=follows logically from the definitions/construction)? or - There should be no more (=there could be, but we set an arbitrary upper limit for interoperability)? Maybe we can use an example to test the limits: Say I want to use VER="0111" and VER="0121" in parallel so I have every message signed twice. And I also want to use SG="1". Then I have 384 concurrent Signature Groups. Ennumerating with the identifies as above (HOSTNAME, APP-NAME, PROCID, MSGID are constant) gives the list: 1. (..., VER="0111", RSID="123", SG="1", SPRI="0") 2. (..., VER="0111", RSID="123", SG="1", SPRI="1") ... 192. (..., VER="0111", RSID="123", SG="1", SPRI="191") 193. (..., VER="0121", RSID="123", SG="1", SPRI="0") 194. (..., VER="0121", RSID="123", SG="1", SPRI="1") ... 384. (..., VER="0121", RSID="123", SG="1", SPRI="191") Should this be a valid protocol use or not? > Section 4.1 states that syslog-sign messages are not counted > and not signed, so I think the current position is clear. Martin, I > agree with your reasoning and argumentation. Essentially, the > purpose is to sign a stream of messages, not alter that stream of > messages. Could we replace "do not need to be signed" by "MUST not be signed" then? -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Aug 4 07:04:32 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 D21D93A69FC; Mon, 4 Aug 2008 07:04:32 -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 EC9183A6A86 for ; Mon, 4 Aug 2008 07:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[AWL=-0.630, BAYES_20=-0.74, HELO_EQ_DE=0.35, 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 zbUesyUpy-HJ for ; Mon, 4 Aug 2008 07:04:27 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id 16B533A69FC for ; Mon, 4 Aug 2008 07:04:27 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 4509A85DA0 for ; Mon, 4 Aug 2008 16:04:54 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id oCKiF7E3SQSL for ; Mon, 4 Aug 2008 16:04:39 +0200 (CEST) Received: from cordelia.mschuette.name (BAA4339.baa.pppool.de [77.128.67.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 540C885C97 for ; Mon, 4 Aug 2008 16:04:39 +0200 (CEST) Message-ID: <48970C7D.3090805@mschuette.name> Date: Mon, 04 Aug 2008 16:04:45 +0200 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: syslog@ietf.org References: <1696498986EFEC4D9153717DA325CB720134FF6C@vaebe104.NOE.Nokia.com> <488C7C58.7040807@mschuette.name> <85B2F271FDF6B949B3672BA5A7BB62FB0620D1A9@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB0620D1A9@xmb-sjc-236.amer.cisco.com> Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 1 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Alexander Clemm (alex) schrieb: > Would the resulting text work better: "The signature is calcluated > over the completely formatted Signature Block message, excluding the > signature field (SD Pameter Name and the space before it [" SIGN"], > "=", and corresponding value)". (in 4.2.8; in 5.3.2.8 replace > "Signature Block" with "Certificate Block") Yes, that's better. -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Aug 4 07:04: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 0140E3A6CBC; Mon, 4 Aug 2008 07:04: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 36B6C3A6CBC for ; Mon, 4 Aug 2008 07:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 lNslPVcYdiI6 for ; Mon, 4 Aug 2008 07:04:41 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id 097133A6CB8 for ; Mon, 4 Aug 2008 07:04:41 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 45DF985C96 for ; Mon, 4 Aug 2008 16:05:08 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id q2kJb-zzLokg for ; Mon, 4 Aug 2008 16:04:43 +0200 (CEST) Received: from cordelia.mschuette.name (BAA4339.baa.pppool.de [77.128.67.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 0149185D94 for ; Mon, 4 Aug 2008 16:04:42 +0200 (CEST) Message-ID: <48970C81.2060605@mschuette.name> Date: Mon, 04 Aug 2008 16:04:49 +0200 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: syslog@ietf.org References: <4893857C.5090808@mschuette.name> <85B2F271FDF6B949B3672BA5A7BB62FB0620D1B0@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB0620D1B0@xmb-sjc-236.amer.cisco.com> Subject: Re: [Syslog] Syslog-sign: 6.2. Flexibility 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Alexander Clemm (alex) schrieb: > to clarify what you are suggesting - are you suggesting to strike > section 6.2 and change the title of 6 to "Redundancy"? I think the > entire section is in essence informational; per se I would have no > issues taking it out. Yes. > Now, regarding question 2: I am not clear about what you are asking. > How a signature group is defined is ultimately up to an administrator > (specifically if SG fields are 2 or 3). It is probably not a good > idea to change these on the fly, although it probably does not need > to be prohibited. Should this issue be discussed in a separate > statement somewhere? (Basically, it would state something along the > lines that while it is possible to change how Signature Groups are > configured, adminstrators need to be aware of the implications.) Of course every change will require a new reboot session and the sending of new Certificate Blocks, so the receiver/verifier will be able to notice. Given that I do not see a difference between a config change "on the fly" and restarting the server/daemon with the new configuration. > The statement at the end of 6.2 states that it is legitimate for an > originator to send short Signature Blocks to allow the collector to > verify messages quickly (and not have to wait until a Signature Block > is "filled up"). Precisely because the block are variable in length > this is possible. So, I am not clear what the issue would be with > that statement? It is no big deal. I just found it irritating and wondered if there were also long blocks. Maybe it would be better to add a remark to section 4 (Signature Blocks) stating that the originator is free to decide when to send Signature Blocks, how many hashes they contain and if/how he adds redundancy. -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Aug 4 09:56:54 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 955B03A6A87; Mon, 4 Aug 2008 09:56:54 -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 553043A695F for ; Mon, 4 Aug 2008 09:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 tI9NqXNz6nHi for ; Mon, 4 Aug 2008 09:56:52 -0700 (PDT) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id 8168B3A6783 for ; Mon, 4 Aug 2008 09:56:52 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id yBQf1Z00316AWCUA6Gx1E7; Mon, 04 Aug 2008 16:57:01 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id yGwy1Z0174HwxpC8SGwzj0; Mon, 04 Aug 2008 16:57:00 +0000 X-Authority-Analysis: v=1.0 c=1 a=48vgC7mUAAAA:8 a=VNYC8flkFltC6d80pfAA:9 a=j2VOTPdjG19n3IQgbIgA:7 a=0rM0CPe42MXhKtBDvcxgzUG4NksA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=4GGKM1rHjQwA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , Date: Mon, 4 Aug 2008 12:56:58 -0400 Message-ID: <00bf01c8f653$1c7fb8b0$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: Acj2TDlWcKLN99WQTb+UpdVM0cpb0QABhz5g Subject: [Syslog] FW: Please ask your 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, It is nomcom time again. The selection process for those who steer and provide architectural guidance for the IETF is obviously very important. We really need volunteers to help make those selections. As a member of this community, you are uniquely qualified to help choose these leaders. Please consider being a volunteer to help in the selection process. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com -----Original Message----- From: wgchairs-bounces@ietf.org [mailto:wgchairs-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Sunday, August 03, 2008 10:43 AM To: Working Group Chairs Subject: Please ask your WG... To volunteer for the nomcom. The nomcom process is (in my opinion) better served by a large pool of volunteers drawn from a wide spectrum of IETF attendees. As such, please ask on your individual mailing lists for folks to volunteer. Obviously, the exact method for doing so is up to you. The most recent call for volunteers can be reference here: https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1617 Whether you copy that message, or reference is probably up to you and the habits of your working group mailing list. If you want to reference or copy the status message I sent out, that can be found at: https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1618 Thank you, Joel M. Halpern Nomcom Chair jmh@joelahlpern.com nomcom-chair@ietf.org _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Aug 4 16:16:11 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 B11843A6A26; Mon, 4 Aug 2008 16:16:11 -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 4E0773A6941 for ; Mon, 4 Aug 2008 16:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.329 X-Spam-Level: X-Spam-Status: No, score=-6.329 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 Nr797jkxWjzf for ; Mon, 4 Aug 2008 16:16: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 D4A083A6978 for ; Mon, 4 Aug 2008 16:16:08 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2008 23:16:38 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m74NGcbJ025384; Mon, 4 Aug 2008 16:16:38 -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 m74NGc0g027429; Mon, 4 Aug 2008 23:16:38 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 16:16:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 16:16:34 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB062692A8@xmb-sjc-236.amer.cisco.com> In-Reply-To: <489708E8.80400@mschuette.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Multiple signers on host? Thread-Index: Acj2OPJgLRhnAZ7zR0O+dVYIJ5xXuAAS1YPQ References: <1696498986EFEC4D9153717DA325CB72013502F1@vaebe104.NOE.Nokia.com><488C530F.3090101@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB0620D1BE@xmb-sjc-236.amer.cisco.com> <489708E8.80400@mschuette.name> From: "Alexander Clemm (alex)" To: =?iso-8859-1?Q?Martin_Sch=FCtte?= , X-OriginalArrivalTime: 04 Aug 2008 23:16:35.0439 (UTC) FILETIME=[23AA07F0:01C8F688] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3969; t=1217891798; x=1218755798; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Syslog]=20Syslog-sign=3A=20Multiple=20 signers=20on=20host? |Sender:=20; bh=Ei2ArjXOnc+/OB6kSSQPDUNvUzgQsQ+Mk6XSX5vpdQw=; b=RkexkBCd4CUuix0UpQIotlllw1yV56/TsPuRBkXHjII36LfFz6jW9y3qYz GxWvEi/PH4okjlNkTjJAx0WHsUvu0sQ5kQERMFdK/+THypYwV9Ih7SW+ozWp HvsEUtvreP; Authentication-Results: sj-dkim-4; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Syslog] Syslog-sign: Multiple signers on host? 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 NILVALUEs - as is, they should be valid - actually, this should be stated e= xplicitly in the draft. The point is that so far they have essentially bee= n "ignored". = It is possible to differentiate different signers by saying APP-NAME and PR= OCID are relevant and MUST be used consistently. It would then also imply = that different signers can "reuse" the same SPRI, providing they indicate S= G=3D3 when establishing the signature group. = Not sure if it was intentional, but you bring up a notion of a duration of = a signature group. This is a different notion than what we have right now.= We only have a notion of a reboot session. At the beginning of the reboo= t session, the payload blocks are sent for the various signature groups. S= o, the duration is "global" for an originator, not differentiated between s= ignature groups. Now, in principle it is certainly possible to change the s= emantics of "reboot session" to that of "signature group session". It does= open up a lot of other questions and add complexity, as now a multitude of= reboot sessions needs to be kept track of. Is this really required? It w= ould seem that we should stick to the simple semantics of reboot session. = Different signers can of course have their own reboot sessions. So, your t= ext is basically okay, but I would argue that the last sentence must read "= To allow multiple originators per host, the values of APP-NAME and PROCID MUST be unique for the duration of the reboot sessio= n." --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of= Martin Sch=FCtte Sent: Monday, August 04, 2008 6:49 AM To: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Multiple signers on host? Alexander Clemm (alex) schrieb: > That a valid APP-NAME and PROCID need to be included is a given. Are NILVALUEs valid? > Currently, the statement is that originators SHOULD use the same = > values for those field for every message to be consistent (e.g. > section 4.1 and 5.3.1). Should this "SHOULD" be changed to "MUST" > and a statement be added that APP-NAME and PROCID are supposed to = > uniquely identify a signer on HOSTNAME? Yes; if we use these values to distingiush different originators on the sam= e host then they MUST be consistent. I would suggest: This specification does not mandate particular values for these fields; however, for consistency, originators MUST use the same values for APP-NAME, PROCID, and MSGID fields for every Certificate Block and Signature Block message that is sent for one Signature Group, whichever values are chosen. To allow multiple originators per host, these values MUST be unique for the duration of the Signature Group. Intention here: a) if there is only one originator per hostname possible (use case: on a printer) then NILVALUEs are ok, because (together with the HOSTNAME) they s= till identify one originator. b) I think some time duration is necessary and chosen to impose the least r= estrictions. So the values have to stay the same for one Signature Group. T= hat makes sure they can be used as identifiers for that Signature Group but= leaves enough room for implementations. It is then possible to - restart the daemon, thus changing RSID and PROCID - use another program, thus changing RSID, APP-NAME, and PROCID - use different PROCIDs in parallel (use case: one process per Signature Gr= oup). One more thing: Except for the APP-NAME alone basically all selections from= (APP-NAME, PROCID, MSGID) could be used. APP-NAME and PROCID would identif= y one orginator just as well. So if it seems like there could be other uses= for a MSGID then that does not have to be fixed. -- Martin _______________________________________________ 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 Aug 4 16:25:10 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 990013A68AB; Mon, 4 Aug 2008 16:25:10 -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 3BDA03A68AB for ; Mon, 4 Aug 2008 16:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.324 X-Spam-Level: X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 Qb3cer-0RY8O for ; Mon, 4 Aug 2008 16:25:08 -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 F1F7F3A6960 for ; Mon, 4 Aug 2008 16:25:07 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2008 23:25:26 +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 m74NPQ5d011991; Mon, 4 Aug 2008 16:25:26 -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 m74NPQLg004306; Mon, 4 Aug 2008 23:25:26 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 16:25:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 16:25:25 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB062692BB@xmb-sjc-236.amer.cisco.com> In-Reply-To: <489708F6.8070104@mschuette.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Minor clarifications, part 2 Thread-Index: Acj2OQkXQfk20E07TWep5EpQo7dlPgATyqCw References: <1696498986EFEC4D9153717DA325CB7201350302@vaebe104.NOE.Nokia.com><4893858B.8030008@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB0620D1BD@xmb-sjc-236.amer.cisco.com> <489708F6.8070104@mschuette.name> From: "Alexander Clemm (alex)" To: =?iso-8859-1?Q?Martin_Sch=FCtte?= , X-OriginalArrivalTime: 04 Aug 2008 23:25:26.0581 (UTC) FILETIME=[603FDE50:01C8F689] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5331; t=1217892326; x=1218756326; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Syslog]=20Syslog-sign=3A=20Minor=20cla rifications,=20part=202 |Sender:=20; bh=kc4ZcS8lPwL6LrhaaRcWTklrt5KN8ISp3eJgKLWv8+E=; b=lQ0TFyUTgMyFmOVN8JAfEbU23dAWUEaBZ+0jVn1FTBp7l2HPcFLMRr7Hmt XItU8vYDRROfMe6ODRRH6sYz+hqGDNJbaE6l0tbssiRdbeQ7c7Y9z2b4FurU WNgvdQOzLB; Authentication-Results: sj-dkim-2; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 2 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 Thinking a little more about it, I am not sure if we the requirement to sig= n the same signature group with multiple algorithms by the same originator.= If we allow for multiple originators on the same host as I think we are s= aying we would, they each can have their own definitions of the same signat= ure group and use a different algorithm. Likewise, a single originator ca= n define two signature groups with separate SPRIs that include the same mes= sages, and sign each of them with a different algorithm. With those capabi= lities, the space should be well covered, and in practice should be able to= accomplish everything that we could by allowing multiple algorithms for th= e same signature group using the same identifier from the same originator o= n the same host, without requiring the associated completiy. With this, I = think the remainder of the issues you bring up are moot. = On the last item, agree, let's make it "MUST NOT be signed". = --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of= Martin Sch=FCtte Sent: Monday, August 04, 2008 6:50 AM To: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 2 Alexander Clemm (alex) schrieb: > This leaves the question whether it should be possible to sign the > *same* signature group with multiple algorithms. There are currently = > no provisions for that. The spec also states that a payload block = > (containing the certificate information) is valid for the entire = > reboot session - we currently do not allow to change it during a = > reboot session. If this is an issue, it will have some ramifications. = > One way to deal with it would be to change the way a "reboot session" = > is defined. > = > Thoughts? To allow multiple algorithms inside one signature group then one could use = multiple SIGN params with prefixes to identify their algorithm. E.g. = [ssign ... SIGN=3D"1;" SIGN=3D"2;"]. But I do not like the concept. Just using two Signature Groups in parallel allows the same thing with grea= ter flexibility and simpler implementations. (Maybe with more messages, but= that is not negative for a protocol that has to be redundant by design,) > This leads me to a problem in 4.2.3.: "In all cases, no more than 192 = > distinct Signature Groups (0-191) are permitted." > = > I am not sure I understand the issue? I think the problem is we have different concepts of a "Signature Group". A= definition would be useful. The Introduction states "A Signature Group identifies a group of messages t= hat are all kept together for signing purposes by the originator." I would add the list of attributes that I consider the actual identifiers: (HOSTNAME, APP-NAME, PROCID, MSGID, VER, RSID, SG, SPRI). It follows: Two syslog-sign messages with the same values for these fields = belong to the same Signature Group. Two syslog-sign messages which values d= iffer in any of these fields do not belong to the same Signature Group. > The fact that the SPRI > parameter may take only values from 0-191 inclusive already implies = > there can be no more than 192 values? Yes, indeed. But that makes the sencence only more confusing, because what do the given = numbers 0-191 mean if they do not refer to SPRI values? I think the statement is > correct as is - the signature group refers to a set of syslog messages = > while the SPRI value defines what messages that set contains > - we do however want to call out that there can be no more than 192 = > such sets. I am sorry if this appears like nit-picking, but do you say - There can be no more (=3Dfollows logically from the definitions/construct= ion)? or - There should be no more (=3Dthere could be, but we set an arbitrary upper= limit for interoperability)? Maybe we can use an example to test the limits: Say I want to use VER=3D"0111" and VER=3D"0121" in parallel so I have every= message signed twice. And I also want to use SG=3D"1". Then I have 384 con= current Signature Groups. Ennumerating with the identifies as above (HOSTN= AME, APP-NAME, PROCID, MSGID are constant) gives the list: 1. (..., VER=3D"0111", RSID=3D"123", SG=3D"1", SPRI=3D"0") 2. (..., VER=3D"0111", RSID=3D"123", SG=3D"1", SPRI=3D"1") ... 192. (..., VER=3D"0111", RSID=3D"123", SG=3D"1", SPRI=3D"191") 193. (..., V= ER=3D"0121", RSID=3D"123", SG=3D"1", SPRI=3D"0") 194. (..., VER=3D"0121", R= SID=3D"123", SG=3D"1", SPRI=3D"1") ... 384. (..., VER=3D"0121", RSID=3D"123", SG=3D"1", SPRI=3D"191") Should this be a valid protocol use or not? > Section 4.1 states that syslog-sign messages are not counted > and not signed, so I think the current position is clear. Martin, I = > agree with your reasoning and argumentation. Essentially, the purpose = > is to sign a stream of messages, not alter that stream of messages. = > Could we replace "do not need to be signed" by "MUST not be signed" then? -- Martin _______________________________________________ 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 Aug 4 16:29:49 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 5BE1C3A68B2; Mon, 4 Aug 2008 16:29:49 -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 F2DA03A6850 for ; Mon, 4 Aug 2008 16:29:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.32 X-Spam-Level: X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 zFNoSkkJDFjL for ; Mon, 4 Aug 2008 16:29:47 -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 D312A3A68B2 for ; Mon, 4 Aug 2008 16:29:46 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2008 23:29:38 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m74NTcMd009779; Mon, 4 Aug 2008 16:29:38 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m74NTciN020709; Mon, 4 Aug 2008 23:29:38 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Aug 2008 16:29:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 16:29:37 -0700 Message-ID: <85B2F271FDF6B949B3672BA5A7BB62FB062692C3@xmb-sjc-236.amer.cisco.com> In-Reply-To: <48970C81.2060605@mschuette.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: 6.2. Flexibility Thread-Index: Acj2OyBUWeIHUKr0ShCaqm7LtvXl5wATlbIw References: <4893857C.5090808@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB0620D1B0@xmb-sjc-236.amer.cisco.com> <48970C81.2060605@mschuette.name> From: "Alexander Clemm (alex)" To: =?iso-8859-1?Q?Martin_Sch=FCtte?= , X-OriginalArrivalTime: 04 Aug 2008 23:29:38.0028 (UTC) FILETIME=[F61FA2C0:01C8F689] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2712; t=1217892578; x=1218756578; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=alex@cisco.com; z=From:=20=22Alexander=20Clemm=20(alex)=22=20 |Subject:=20RE=3A=20[Syslog]=20Syslog-sign=3A=206.2.=20Flex ibility |Sender:=20; bh=XmbtnJ6PqwWkwigVv35Cd9NnR7BE2I7bc64d5BFWEpQ=; b=pW4Slqphj4ONRo7/VUltya477zcmozUz2wjShTyeFk0YFnTpy84Ju5bceA Io0sb+jaULbVnk6GUqYDf/NvG0eUmJgD3Xmtwys4y7Uks4EdEW8Vaz3weuaZ HZO5qXk1xK; Authentication-Results: sj-dkim-4; header.From=alex@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Syslog] Syslog-sign: 6.2. Flexibility 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 Hi Martin, ok, unless others raise objections I'll change title of 6 to redundancy and= strike 6.2. I'll retain mention of the fact somewhere that the originator = is free to decide when to send signature blocks, something that might even = be subject to configuration. I'll also have a statement somewhere about th= at change in configuration of signature groups needs to coincide with start= of new reboot sessions. = --- Alex -----Original Message----- From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On Behalf Of= Martin Sch=FCtte Sent: Monday, August 04, 2008 7:05 AM To: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: 6.2. Flexibility Alexander Clemm (alex) schrieb: > to clarify what you are suggesting - are you suggesting to strike = > section 6.2 and change the title of 6 to "Redundancy"? I think the = > entire section is in essence informational; per se I would have no = > issues taking it out. Yes. > Now, regarding question 2: I am not clear about what you are asking. > How a signature group is defined is ultimately up to an administrator = > (specifically if SG fields are 2 or 3). It is probably not a good = > idea to change these on the fly, although it probably does not need to = > be prohibited. Should this issue be discussed in a separate statement = > somewhere? (Basically, it would state something along the lines that = > while it is possible to change how Signature Groups are configured, = > adminstrators need to be aware of the implications.) Of course every change will require a new reboot session and the sending of= new Certificate Blocks, so the receiver/verifier will be able to notice. Given that I do not see a difference between a config change "on the fly" a= nd restarting the server/daemon with the new configuration. > The statement at the end of 6.2 states that it is legitimate for an = > originator to send short Signature Blocks to allow the collector to = > verify messages quickly (and not have to wait until a Signature Block = > is "filled up"). Precisely because the block are variable in length = > this is possible. So, I am not clear what the issue would be with = > that statement? It is no big deal. I just found it irritating and wondered if there were also long blocks. Maybe it would be better to add a remark to section 4 (Signature Blocks) st= ating that the originator is free to decide when to send Signature Blocks, = how many hashes they contain and if/how he adds redundancy. -- Martin _______________________________________________ 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 Aug 4 16:36: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 B2B0D3A6978; Mon, 4 Aug 2008 16:36: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 989A63A6978 for ; Mon, 4 Aug 2008 16:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.412 X-Spam-Level: X-Spam-Status: No, score=-0.412 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_40=-0.185, HELO_EQ_DE=0.35, 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 ZArhcI-Fesb9 for ; Mon, 4 Aug 2008 16:36:07 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id C8C943A690F for ; Mon, 4 Aug 2008 16:36:06 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id DCF1786087 for ; Tue, 5 Aug 2008 01:36:29 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id W8Bwfj+nUg0I for ; Tue, 5 Aug 2008 01:36:17 +0200 (CEST) Received: from cordelia.mschuette.name (BAA3f36.baa.pppool.de [77.128.63.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 9C92F79D6B for ; Tue, 5 Aug 2008 01:36:17 +0200 (CEST) Message-ID: <48979279.3050003@mschuette.name> Date: Tue, 05 Aug 2008 01:36:25 +0200 From: =?ISO-8859-15?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: syslog@ietf.org Subject: [Syslog] Syslog-sign: Implementation 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hello, I am currently implementing the new syslog protocols for the NetBSD syslogd. My syslog-sign implementation is now complete and you might want to take a look at it. A general description and sample output is online at: http://netbsd-soc.sourceforge.net/projects/syslogd/sign.html -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Aug 4 18:58: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 673DD3A68F2; Mon, 4 Aug 2008 18:58: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 DECD43A6922 for ; Mon, 4 Aug 2008 18:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 yfeRBRIO9LEs for ; Mon, 4 Aug 2008 18:58:39 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id CF9313A68F2 for ; Mon, 4 Aug 2008 18:58:38 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id B5AB985AB4 for ; Tue, 5 Aug 2008 03:59:06 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id rseqN4zuR+qc for ; Tue, 5 Aug 2008 03:58:49 +0200 (CEST) Received: from cordelia.mschuette.name (BAA091a.baa.pppool.de [77.128.9.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id DB9C786104 for ; Tue, 5 Aug 2008 03:58:47 +0200 (CEST) Message-ID: <4897B3E1.4090604@mschuette.name> Date: Tue, 05 Aug 2008 03:58:57 +0200 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: syslog@ietf.org References: <1696498986EFEC4D9153717DA325CB7201350302@vaebe104.NOE.Nokia.com><4893858B.8030008@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB0620D1BD@xmb-sjc-236.amer.cisco.com> <489708F6.8070104@mschuette.name> <85B2F271FDF6B949B3672BA5A7BB62FB062692BB@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB062692BB@xmb-sjc-236.amer.cisco.com> Subject: Re: [Syslog] Syslog-sign: Minor clarifications, part 2 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Alexander Clemm (alex) schrieb: > completiy. With this, I think the remainder of the issues you bring > up are moot. I'm sorry, but only my first few lines were about the multiple signatures. The definition of a "signature group" and a possible limit of their number is a fundamental issue and should be discussed. Especially with our obviously different conceptions based on the same specification. -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Aug 4 18:58:57 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 EB37F3A6949; Mon, 4 Aug 2008 18:58:56 -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 E90953A6A0A for ; Mon, 4 Aug 2008 18:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 a2mEmn2MFZBq for ; Mon, 4 Aug 2008 18:58:54 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id 378DD3A6949 for ; Mon, 4 Aug 2008 18:58:54 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 2C7998610C for ; Tue, 5 Aug 2008 03:59:22 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id 7ZcnT8Fy1FYX for ; Tue, 5 Aug 2008 03:59:09 +0200 (CEST) Received: from cordelia.mschuette.name (BAA091a.baa.pppool.de [77.128.9.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 0F33D86085 for ; Tue, 5 Aug 2008 03:59:08 +0200 (CEST) Message-ID: <4897B3F6.9050705@mschuette.name> Date: Tue, 05 Aug 2008 03:59:18 +0200 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: syslog@ietf.org References: <1696498986EFEC4D9153717DA325CB72013502F1@vaebe104.NOE.Nokia.com><488C530F.3090101@mschuette.name><85B2F271FDF6B949B3672BA5A7BB62FB0620D1BE@xmb-sjc-236.amer.cisco.com> <489708E8.80400@mschuette.name> <85B2F271FDF6B949B3672BA5A7BB62FB062692A8@xmb-sjc-236.amer.cisco.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB062692A8@xmb-sjc-236.amer.cisco.com> Subject: Re: [Syslog] Syslog-sign: Multiple signers on host? 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Alexander Clemm (alex) schrieb: > It is possible to differentiate different signers by saying APP-NAME > and PROCID are relevant and MUST be used consistently. It would then > also imply that different signers can "reuse" the same SPRI, > providing they indicate SG=3 when establishing the signature group. Different signers can also use the same SG. Otherwise it would be impossible to have a central log server for many clients (=signers) ;) > Not sure if it was intentional, but you bring up a notion of a > duration of a signature group. This is a different notion than what > we have right now. We only have a notion of a reboot session. At > the beginning of the reboot session, the payload blocks are sent for > the various signature groups. So, the duration is "global" for an > originator, not differentiated between signature groups. Now, in > principle it is certainly possible to change the semantics of "reboot > session" to that of "signature group session". It does open up a lot > of other questions and add complexity, as now a multitude of reboot > sessions needs to be kept track of. Is this really required? It > would seem that we should stick to the simple semantics of reboot > session. Different signers can of course have their own reboot It was unintentional. From the perspective of the originator I implicitly assumed the RSID is a global state and a "reboot event" affects all signature groups. But now that I think of it I do not see that it makes a big difference whether "signature group session" were allowed. The sender can use whatever it wants, so the focus has to be on the receiver/verifier and the protocol has to limit its complexity. Our receiver already has to process different message streams, keep track of multiple signature groups from different originators, check every signature block's attributes for validity, and recognize new reboot sessions from a sender. Now what constraints do we have when we have when assuming a "sender-global" reboot session? And which constraints disappear when we allow "signature group sessions"? I see only the difference between a) finding the signature group and comparing the RSID and b) using the RSID as part of the identifier to find the signature group. That certainly does not change the overall complexity. --- Just to make my position clear: I think a "sender-global" reboot session is just fine; I do not see a serious use case for "signature group sessions" and have no intent to 'push' this into the standard. But on the other hand I do not I do not see a reason to limit the possible options without an apparent reason. --- With regard to the notion of a reboot session I would like to revise my previous definition of signature group identifiers to use a more hierarchical approach: ORIGINATOR := (HOSTNAME, APP-NAME, PROCID) REBOOT_SESSION := (ORIGINATOR, VER, RSID) signature group := (REBOOT_SESSION, SG, SPRI) Is that closer to your conception? I am only a bit undecided whether VER identifies a REBOOT_SESSION or a signature group inside the REBOOT_SESSION. > sessions. So, your text is basically okay, but I would argue that > the last sentence must read "To allow multiple originators per host, > the values of APP-NAME and PROCID MUST be unique for the duration of > the reboot session." That's fine with me. -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Aug 4 19:26:49 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 12D1D3A6A7C; Mon, 4 Aug 2008 19:26:49 -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 307143A6CE2; Thu, 31 Jul 2008 09:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 RkGcqzRL4g3S; Thu, 31 Jul 2008 09:00:06 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id AC8DD3A6CD7; Thu, 31 Jul 2008 09:00:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,287,1215388800"; d="scan'208";a="16112330" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 31 Jul 2008 15:58:40 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m6VFwe2G013378; Thu, 31 Jul 2008 11:58:40 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m6VFwekG029934; Thu, 31 Jul 2008 15:58:40 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 11:58:40 -0400 Received: from sbrim-mbp.meeting.ietf.org ([161.44.11.166]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 31 Jul 2008 11:58:39 -0400 Message-ID: <4891E12A.2050207@employees.org> Date: Thu, 31 Jul 2008 16:58:34 +0100 From: Scott Brim User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: draft-ietf-syslog-transport-tls@tools.ietf.org, syslog@ietf.org, gen-art@ietf.org, Pasi.Eronen@nokia.com X-OriginalArrivalTime: 31 Jul 2008 15:58:39.0498 (UTC) FILETIME=[4C549EA0:01C8F326] Authentication-Results: rtp-dkim-1; header.From=swb@employees.org; dkim=neutral X-Mailman-Approved-At: Mon, 04 Aug 2008 19:26:47 -0700 Subject: [Syslog] gen-art review of draft-ietf-syslog-transport-tls-13.txt 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-syslog-tls-13.txt Reviewer: Scott Brim Review Date: 30 July 2008 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: There is only one item that is significant, which is the last of the SHOULD comments (just below). As for the rest, they are not showstoppers but imho if you take them into consideration you'll have a better draft. First, MUST/SHOULD ------------------ > TLS typically uses certificates [RFC5280] to authenticate peers. > Implementations MUST support TLS 1.2 [I-D.ietf-tls-rfc4346-bis] and > are REQUIRED to support the mandatory to implement cipher suite, Small: Change "are REQUIRED to" to "MUST". > The transport receiver and transport sender SHOULD provide > mechanisms to record the end-entity certificate for the purpose of > correlating it with the sent or received data. Medium: In general it's good to explain the conditions under which a SHOULD is not expected. Otherwise you get some implementations that treat it as a MUST and many others that just ignore it. What happens if the sender or receiver does not record the end-entity certificate? Under what conditions is that a problem? > If the peer does not meet the requirements of the security policy, > the TLS handshake SHOULD be aborted with an appropriate TLS alert. Medium-Large: This SHOULD surprises me. You allow the peer not to abort the handshake under some conditions? What could those conditions be? I think you should explain this SHOULD carefully so as to avoid a security hole through lack of documentation. Second, terminology ------------------- You have Transport sender Transport receiver Server Client Peer Peer These terms overlap. I can't tell if the first two pairs are synonymous or not. I can see reasons to use all of these, based on different relationships and functions, but you seem to mix and match sometimes. Sometimes limiting your terminology can make your spec tighter and clearer, so consider getting rid of one pair. Here are some examples: > 1.1 Terminology > > o A "TLS client" is an application that can initiate a TLS > connection by sending a Client Hello to a peer. > > o A "TLS server" is an application that can receive a Client > Hello from a peer and reply with a Server Hello. Small: If you're going to use client, then use server, and vice versa. A TLS client initiates a Client Hello to a *server*, and a server receives a Client Hello from a *client*. > 4.1 Port Assignment > > A syslog transport sender is always a TLS client and a transport > receiver is always a TLS server. I would have thought that since a server occasionally sends a message to the client (for example a close_notify), that the server could be a "transport sender" too ... and similarly the client receiving packets could be a "transport receiver". > 4.2 Initiation > > The transport sender should initiate a connection to the > transport receiver and then send the TLS Client Hello to begin > the TLS handshake. When the TLS handshake has finished the > transport sender MAY then send the first syslog message. There are two actions here, "initiate a connection" and then have a TLS handshake. It would make more sense to me to use the terms client/server than sender/receiver. > A TLS client MUST close the associated TLS connection if the > connection is not expected to deliver any syslog messages later. Just above, the "transport sender" was told to set the message length, but here the "TLS client" is told to close the TLS connection. That feels inconsistent. _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Aug 6 17:15: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 932923A6AAA; Wed, 6 Aug 2008 17:15: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 49E3A3A6BAC; Wed, 6 Aug 2008 17:15:23 -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 dywEbp1PTNpQ; Wed, 6 Aug 2008 17:15:22 -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 EA0883A6877; Wed, 6 Aug 2008 17:15:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,317,1215388800"; d="scan'208";a="62478071" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 07 Aug 2008 00:15:56 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m770FuE8031690; Wed, 6 Aug 2008 17:15:56 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m770Fue5024928; Thu, 7 Aug 2008 00:15:56 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, 6 Aug 2008 17:15:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Aug 2008 17:16:30 -0700 Message-ID: In-Reply-To: <4891E12A.2050207@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] gen-art review of draft-ietf-syslog-transport-tls-13.txt thread-index: Acj2osmf8mJXyOWlS2CQybyQ2giskgBfghnQ References: <4891E12A.2050207@employees.org> From: "Joseph Salowey (jsalowey)" To: "Scott Brim" , , , , X-OriginalArrivalTime: 07 Aug 2008 00:15:56.0184 (UTC) FILETIME=[C2DC1980:01C8F822] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8547; t=1218068156; x=1218932156; 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]=20gen-art=20review=20of=20draf t-ietf-syslog-transport-tls-13.txt |Sender:=20; bh=19HPMsBMvBh3u6owNcEJQkwCdj9QCd232VHw2cvB71E=; b=hoKgRFLm1dq54cUDfHxKU68dNT6nuS7sBArCFMOyFBgp8zY6alPBL5OMEk ysigLlqH35BBTljdiXiLmnsgQ6OTX6Bq3eWXOPg147U2hEwkeaRVcCiDX0+R ApTa5st2Kr; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [Syslog] gen-art review of draft-ietf-syslog-transport-tls-13.txt 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 Thanks for reviewing the document, the comments are very useful. I'm including some comments and proposed resolutions below. Cheers, Joe > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Scott Brim > Sent: Thursday, July 31, 2008 8:59 AM > To: draft-ietf-syslog-transport-tls@tools.ietf.org; > syslog@ietf.org; gen-art@ietf.org; Pasi.Eronen@nokia.com > Subject: [Syslog] gen-art review of > draft-ietf-syslog-transport-tls-13.txt > > I have been selected as the General Area Review Team > (Gen-ART) reviewer for this draft (for background on Gen-ART, > please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd or AD > before posting a new version of the draft. > > Document: draft-ietf-syslog-tls-13.txt > Reviewer: Scott Brim > Review Date: 30 July 2008 > > Summary: > > This draft is basically ready for publication, but has nits > that should be fixed before publication. > > Comments: > > There is only one item that is significant, which is the last > of the SHOULD comments (just below). As for the rest, they > are not showstoppers but imho if you take them into > consideration you'll have a better draft. > > First, MUST/SHOULD > ------------------ > > > TLS typically uses certificates [RFC5280] to authenticate peers. > > Implementations MUST support TLS 1.2 > [I-D.ietf-tls-rfc4346-bis] and > > are REQUIRED to support the mandatory to implement cipher suite, > > Small: Change "are REQUIRED to" to "MUST". > > > The transport receiver and transport sender SHOULD provide > > mechanisms to record the end-entity certificate for the > purpose of > > correlating it with the sent or received data. > > Medium: In general it's good to explain the conditions under > which a SHOULD is not expected. Otherwise you get some > implementations that treat it as a MUST and many others that > just ignore it. What happens if the sender or receiver does > not record the end-entity certificate? > Under what conditions is that a problem? > [Joe] Perhaps this SHOULD should not be capitalized. I think the purpose for the should is described, but perhaps it can be clarified: "The transport receiver and transport sender should provide a mechanism to record the end-entity certificate to correlate the authenticated party with the sent or received data in the case that it is necessary to meet traceability requirements." > > If the peer does not meet the requirements of the > security policy, > > the TLS handshake SHOULD be aborted with an appropriate > TLS alert. > > Medium-Large: This SHOULD surprises me. You allow the peer > not to abort the handshake under some conditions? What could > those conditions be? I think you should explain this SHOULD > carefully so as to avoid a security hole through lack of > documentation. > [Joe] The intent here is that a peer could accept a connection that does not meet a specific policy so it can continue operation. This does have some security implications. I think it is warranted to add explanatory some text along the lines of: "In traditional syslog using UDP as the transport, network administrators regularly set up syslog transport senders without performing any administrative tasks on the corresponding transport receivers. This behavior would be replicated by permitting a transport sender that may not meet the requirements of the security policy to send messages to a transport receiver so that the event messages may still be received. Of course accepting connections outside of policy increases the risk of compromise from the various threats that the use of TLS is attempting to mitigate. This must only be done when there are other mechanisms in place to manage the associated risks." > > Second, terminology > ------------------- > > You have > > Transport sender Transport receiver > Server Client > Peer Peer > > These terms overlap. I can't tell if the first two pairs are > synonymous or not. I can see reasons to use all of these, > based on different relationships and functions, but you seem > to mix and match sometimes. Sometimes limiting your > terminology can make your spec tighter and clearer, so > consider getting rid of one pair. Here are some > examples: [Joe] The intent here was to align with the syslog terminology, while mapping to the appropriate TLS terminology when discussing TLS specific details. Peer is used when describing behavior that is independent of client and server roles. More below. > > 1.1 Terminology > > > > o A "TLS client" is an application that can initiate a TLS > > connection by sending a Client Hello to a peer. > > > > o A "TLS server" is an application that can receive a Client > > Hello from a peer and reply with a Server Hello. > > Small: If you're going to use client, then use server, and vice versa. > A TLS client initiates a Client Hello to a *server*, and a > server receives a Client Hello from a *client*. [Joe] OK makes sense. > > 4.1 Port Assignment > > > > A syslog transport sender is always a TLS client and a transport > > receiver is always a TLS server. > > I would have thought that since a server occasionally sends a > message to the client (for example a close_notify), that the > server could be a "transport sender" too ... and similarly > the client receiving packets could be a "transport receiver". > [Joe] Transport receiver and transport sender roles are with respect to syslog messages. TLS introduces its own signaling (close_notify and others), but this does not change the roles of the syslog entities. > > 4.2 Initiation > > > > The transport sender should initiate a connection to the > > transport receiver and then send the TLS Client Hello to begin > > the TLS handshake. When the TLS handshake has finished the > > transport sender MAY then send the first syslog message. > > There are two actions here, "initiate a connection" and then > have a TLS handshake. It would make more sense to me to use > the terms client/server than sender/receiver. > [Joe] In the above cases the use of transport sender and transport receiver are consistent with their use in the syslog protocol. > > A TLS client MUST close the associated TLS connection if the > > connection is not expected to deliver any syslog messages later. > > Just above, the "transport sender" was told to set the > message length, but here the "TLS client" is told to close > the TLS connection. That feels inconsistent. [Joe] OK, I think it would make sense to use the syslog terminology here to be consistent so this section should read: A transport sender MUST close the associated TLS connection if the connection is not expected to deliver any syslog messages later. It MUST send a TLS close_notify alert before closing the connection. A sender MAY choose to not wait for the receiver's close_notify alert and simply close the connection, thus generating an incomplete close on the receiver side. Once the receiver gets a close_notify from the sender, it MUST reply with a close_notify unless it becomes aware that the connection has already been closed by the sender (e.g., the closure was indicated by TCP). When no data is received from a connection for a long time (where the application decides what "long" means), a receiver MAY close the connection. The receiver MUST attempt to initiate an exchange of close_notify alerts with the sender before closing the connection. Receivers that are unprepared to receive any more data MAY close the connection after sending the close_notify alert, thus generating an incomplete close on the sender side. When the sender has received the close_notify alert from the receiver and still has pending data to send, it SHOULD send the pending data before sending the close_notify alert. > > > _______________________________________________ > 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 Aug 7 05:28:51 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 2FDBA28C176; Thu, 7 Aug 2008 05:28:51 -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 6D65328C136; Thu, 7 Aug 2008 05:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.763 X-Spam-Level: X-Spam-Status: No, score=-5.763 tagged_above=-999 required=5 tests=[AWL=0.836, 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 aO1p99CjpnUZ; Thu, 7 Aug 2008 05:28:48 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 7B76528C153; Thu, 7 Aug 2008 05:28:48 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m77CRkNe012278; Thu, 7 Aug 2008 07:28:33 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 15:28:28 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 15:28:27 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 15:28:27 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C607D@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] gen-art review of draft-ietf-syslog-transport-tls-13.txt Thread-Index: Acj2osmf8mJXyOWlS2CQybyQ2giskgBfghnQABmuPqA= References: <4891E12A.2050207@employees.org> From: To: , , , , X-OriginalArrivalTime: 07 Aug 2008 12:28:27.0075 (UTC) FILETIME=[17A1D930:01C8F889] X-Nokia-AV: Clean Subject: Re: [Syslog] gen-art review of draft-ietf-syslog-transport-tls-13.txt 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: > > > The transport receiver and transport sender SHOULD provide > > > mechanisms to record the end-entity certificate for the > > > purpose of > > > correlating it with the sent or received data. > > > > Medium: In general it's good to explain the conditions under > > which a SHOULD is not expected. Otherwise you get some > > implementations that treat it as a MUST and many others that > > just ignore it. What happens if the sender or receiver does > > not record the end-entity certificate? > > Under what conditions is that a problem? > > > [Joe] Perhaps this SHOULD should not be capitalized. I think the > purpose for the should is described, but perhaps it can be > clarified: > > "The transport receiver and transport sender should provide a > mechanism to record the end-entity certificate to correlate the > authenticated party with the sent or received data in the case that > it is necessary to meet traceability requirements." FWIW, I think capitalized "SHOULD" is correct usage here. > > > If the peer does not meet the requirements of the > > > security policy, > > > the TLS handshake SHOULD be aborted with an appropriate > > > TLS alert. > > > > Medium-Large: This SHOULD surprises me. You allow the peer > > not to abort the handshake under some conditions? What could > > those conditions be? I think you should explain this SHOULD > > carefully so as to avoid a security hole through lack of > > documentation. > > > [Joe] The intent here is that a peer could accept a connection that > does not meet a specific policy so it can continue operation. This > does have some security implications. I think it is warranted to > add explanatory some text along the lines of: Well, if the peer continues the connection, it *does* have a policy that allows this (i.e. requirements of the policy are in fact met, to some degree at least). > "In traditional syslog using UDP as the transport, network > administrators regularly set up syslog transport senders without > performing any administrative tasks on the corresponding transport > receivers. This behavior would be replicated by permitting a > transport sender that may not meet the requirements of the security > policy to send messages to a transport receiver so that the event > messages may still be received. Of course accepting connections > outside of policy increases the risk of compromise from the various > threats that the use of TLS is attempting to mitigate. This must > only be done when there are other mechanisms in place to manage the > associated risks." I think the correct fix would be to say that you MUST follow your policy (instead of SHOULD), but you're allowed to have a policy that permits unauthenticated transport senders (this kind of policy is described in Section 5.3). Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu Aug 7 12:32: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 C937F3A6803; Thu, 7 Aug 2008 12:32: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 D616B3A6872 for ; Thu, 7 Aug 2008 12:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 UIHuZB7MHzEp for ; Thu, 7 Aug 2008 12:32:03 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A8E283A6803 for ; Thu, 7 Aug 2008 12:31:59 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m77JVgjo024246; Thu, 7 Aug 2008 22:31:56 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 22:31:45 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 22:31:45 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 22:31:44 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C628F@vaebe104.NOE.Nokia.com> In-Reply-To: <48938517.9070002@mschuette.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: RSA support? Thread-Index: Acj0IJ/Oe0NFupWvQpK3cJEOBorc+wEovOsg References: <1696498986EFEC4D9153717DA325CB720134FF58@vaebe104.NOE.Nokia.com><488C5270.3010403@mschuette.name><34A02E87-89BC-4716-BA45-89B2AFD23DB5@callas.org> <48938517.9070002@mschuette.name> From: To: , X-OriginalArrivalTime: 07 Aug 2008 19:31:45.0164 (UTC) FILETIME=[3A12ACC0:01C8F8C4] X-Nokia-AV: Clean Subject: Re: [Syslog] Syslog-sign: RSA support? 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 Martin Sch=FCtte wrote: > I think this is mainly a compatibility concern for users who have > existing PKIX certificates with RSA keys and want to use them for > TLS and for signing. When creating new keys for syslog-sign then > DSA or ECDSA are clearly preferable. Or existing *CAs* (inside enterprises etc.) that certify only RSA = keys (not because there's anything wrong with DSA, but because they = thought nobody would need it). Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu Aug 7 12:40:33 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 6986D3A696A; Thu, 7 Aug 2008 12:40:33 -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 BED423A696A for ; Thu, 7 Aug 2008 12:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 8MSKKpR4Il6m for ; Thu, 7 Aug 2008 12:40:31 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id BC5583A688F for ; Thu, 7 Aug 2008 12:40:30 -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 m77JeECY032290; Thu, 7 Aug 2008 22:40:20 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 22:40:14 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 7 Aug 2008 22:40:13 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 22:40:12 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C6290@vaebe104.NOE.Nokia.com> In-Reply-To: <85B2F271FDF6B949B3672BA5A7BB62FB0620D1BB@xmb-sjc-236.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: Overlapping signature blocks Thread-Index: Acjs4ShbwcwSHqOyRa65GMOdCJS5nQAhZ26wAbZX3WABIQmGsA== References: <1696498986EFEC4D9153717DA325CB720134FF5C@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB7201350200@vaebe104.NOE.Nokia.com> <85B2F271FDF6B949B3672BA5A7BB62FB0620D1BB@xmb-sjc-236.amer.cisco.com> From: To: , X-OriginalArrivalTime: 07 Aug 2008 19:40:13.0870 (UTC) FILETIME=[69490CE0:01C8F8C5] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: Overlapping signature blocks 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 Alexander Clemm wrote: > I don't see anything that would prohibit sliding windows? Then > again, I don't see it mentioned particularly. Would probably not > hurt to mention it explicitly. Perhaps some text in section 4.2.5, > in conjunction with discussion of First Message Number? Similarly, > in section 7.1, when describing the algorithm, can include something > along the line that we need to maintain a cursor, indicating the > highest message number that was processed so far, and if the > subsequent Signature Block message has a smaller FMN, we "skip > forward" accordingly. The step "Skip all other Signature Blocks with the same First Message Number" in the algorithm doesn't work well with overlap. For example, a sliding-window implementation with rule "send signature block after every 5 messages, and include at most 15 hashes in one block" would, after rebooting, send signature blocks FMN="1" CNT="5" FMN="1" CNT="10" FMN="1" CNT="15" FMN="6" CNT="15" FMN="11" CNT="15" ...where skipping the second and third signature block isn't the correct behavior. Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu Aug 7 13:16:11 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 1DB103A6976; Thu, 7 Aug 2008 13:16:11 -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 606703A6976 for ; Thu, 7 Aug 2008 13:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COfst2BMYB-L for ; Thu, 7 Aug 2008 13:16:09 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 75F323A6936 for ; Thu, 7 Aug 2008 13:16:09 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id zS941Z00U16AWCUA2YG3pH; Thu, 07 Aug 2008 20:16:03 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id zYFz1Z00Z4HwxpC8SYG0de; Thu, 07 Aug 2008 20:16:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=xMYHkciWJ_8A:10 a=utSSGetkdk8A:10 a=48vgC7mUAAAA:8 a=0uYkxFT2BlnTOhVySWIA:9 a=hgvEnVE6Q7t18T2hmfkA:7 a=IDr58AtBQ9eAAcLQeBmLVRUPQc0A:4 a=lZB815dzVvQA:10 a=1pxjJC3EenQA:10 a=JfD0Fch1gWkA:10 a=AcfM5mlqjyQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , , , , , References: <4891E12A.2050207@employees.org> <1696498986EFEC4D9153717DA325CB72014C607D@vaebe104.NOE.Nokia.com> Date: Thu, 7 Aug 2008 16:15:59 -0400 Message-ID: <034801c8f8ca$69d443a0$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C607D@vaebe104.NOE.Nokia.com> Thread-Index: Acj2osmf8mJXyOWlS2CQybyQ2giskgBfghnQABmuPqAAEGg+oA== Subject: Re: [Syslog] gen-art review ofdraft-ietf-syslog-transport-tls-13.txt 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, > -----Original Message----- > From: syslog-bounces@ietf.org > [mailto:syslog-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com > Sent: Thursday, August 07, 2008 8:28 AM > To: jsalowey@cisco.com; swb@employees.org; > draft-ietf-syslog-transport-tls@tools.ietf.org; > syslog@ietf.org; gen-art@ietf.org > Subject: Re: [Syslog] gen-art review > ofdraft-ietf-syslog-transport-tls-13.txt > > Joseph Salowey wrote: > > > > > The transport receiver and transport sender SHOULD provide > > > > mechanisms to record the end-entity certificate for the > > > > purpose of > > > > correlating it with the sent or received data. > > > > > > Medium: In general it's good to explain the conditions under > > > which a SHOULD is not expected. Otherwise you get some > > > implementations that treat it as a MUST and many others that > > > just ignore it. What happens if the sender or receiver does > > > not record the end-entity certificate? > > > Under what conditions is that a problem? > > > > > [Joe] Perhaps this SHOULD should not be capitalized. I think the > > purpose for the should is described, but perhaps it can be > > clarified: > > > > "The transport receiver and transport sender should provide a > > mechanism to record the end-entity certificate to correlate the > > authenticated party with the sent or received data in the case that > > it is necessary to meet traceability requirements." > > FWIW, I think capitalized "SHOULD" is correct usage here. I agree. The implementation SHOULD provide the mechanism. If there is an issue of whether this is interoperable, then I could accept a MUST implement, but then we should probably describe the mechanism. > > > > > If the peer does not meet the requirements of the > > > > security policy, > > > > the TLS handshake SHOULD be aborted with an appropriate > > > > TLS alert. > > > > > > Medium-Large: This SHOULD surprises me. You allow the peer > > > not to abort the handshake under some conditions? What could > > > those conditions be? I think you should explain this SHOULD > > > carefully so as to avoid a security hole through lack of > > > documentation. > > > > > [Joe] The intent here is that a peer could accept a connection that > > does not meet a specific policy so it can continue operation. This > > does have some security implications. I think it is warranted to > > add explanatory some text along the lines of: > > Well, if the peer continues the connection, it *does* have a policy > that allows this (i.e. requirements of the policy are in fact > met, to some degree at least). Agreed. > > > "In traditional syslog using UDP as the transport, network > > administrators regularly set up syslog transport senders without > > performing any administrative tasks on the corresponding transport > > receivers. This behavior would be replicated by permitting a > > transport sender that may not meet the requirements of the security > > policy to send messages to a transport receiver so that the event > > messages may still be received. Of course accepting connections > > outside of policy increases the risk of compromise from the various > > threats that the use of TLS is attempting to mitigate. This must > > only be done when there are other mechanisms in place to manage the > > associated risks." > > I think the correct fix would be to say that you MUST follow your > policy (instead of SHOULD), but you're allowed to have a policy > that permits unauthenticated transport senders (this kind of > policy is described in Section 5.3). I am just a bit concered about the use of RFC2119 terminology. MUST is for implementers; SHOULD is for deployers. Is that MUST directed at implementers or deployers? I agree that following the policy is important, and the implementation MUST abide by the policy. The deployer SHOULD be able to define a policy that permits unauthenticated senders. dbh > > 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 Thu Aug 7 13:26:33 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 E887D28C140; Thu, 7 Aug 2008 13:26:33 -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 A3BD228C140; Thu, 7 Aug 2008 13:26:32 -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 oVYdMOfvAFN9; Thu, 7 Aug 2008 13:26:31 -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 A168E3A6765; Thu, 7 Aug 2008 13:26:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,322,1215388800"; d="scan'208";a="93489366" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 07 Aug 2008 20:26:31 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m77KQVQA022548; Thu, 7 Aug 2008 13:26:31 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m77KQVPS026055; Thu, 7 Aug 2008 20:26:31 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); Thu, 7 Aug 2008 13:26:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 13:27:03 -0700 Message-ID: In-Reply-To: <034801c8f8ca$69d443a0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] gen-art review ofdraft-ietf-syslog-transport-tls-13.txt thread-index: Acj2osmf8mJXyOWlS2CQybyQ2giskgBfghnQABmuPqAAEGg+oAAAYoJA References: <4891E12A.2050207@employees.org> <1696498986EFEC4D9153717DA325CB72014C607D@vaebe104.NOE.Nokia.com> <034801c8f8ca$69d443a0$0600a8c0@china.huawei.com> From: "Joseph Salowey (jsalowey)" To: "David Harrington" , , , , , X-OriginalArrivalTime: 07 Aug 2008 20:26:31.0055 (UTC) FILETIME=[E09DD9F0:01C8F8CB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5331; t=1218140791; x=1219004791; 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]=20gen-art=20review=20ofdraft-i etf-syslog-transport-tls-13.txt |Sender:=20; bh=5HpK75vASiPBiB8C+3kFdazXn8fjdbHwFKNmL3jdyvg=; b=XyI6HblpSMMFxkggwscmj1MINFJ+zipgQUIOfZqwU6Qj+IifCVcY5yqs/R TdRCS5Pval2eDBaRFA2zIa1WTNzftQb1HcxaETpSmK2xoiuKY5dw68uPB8f2 2rMt0VddMGFJ/lDPZNBSLpEbQnPu0NPtpU6GDlyPBbUqAXszy1GMQ=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Syslog] gen-art review ofdraft-ietf-syslog-transport-tls-13.txt 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: David Harrington [mailto:ietfdbh@comcast.net] > Sent: Thursday, August 07, 2008 1:16 PM > To: Pasi.Eronen@nokia.com; Joseph Salowey (jsalowey); > swb@employees.org; > draft-ietf-syslog-transport-tls@tools.ietf.org; > syslog@ietf.org; gen-art@ietf.org > Subject: RE: [Syslog] gen-art review > ofdraft-ietf-syslog-transport-tls-13.txt > > Hi, > > > -----Original Message----- > > From: syslog-bounces@ietf.org > > [mailto:syslog-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com > > Sent: Thursday, August 07, 2008 8:28 AM > > To: jsalowey@cisco.com; swb@employees.org; > > draft-ietf-syslog-transport-tls@tools.ietf.org; > > syslog@ietf.org; gen-art@ietf.org > > Subject: Re: [Syslog] gen-art review > > ofdraft-ietf-syslog-transport-tls-13.txt > > > > Joseph Salowey wrote: > > > > > > > The transport receiver and transport sender SHOULD provide > > > > > mechanisms to record the end-entity certificate for the > > > > > purpose of > > > > > correlating it with the sent or received data. > > > > > > > > Medium: In general it's good to explain the conditions > under which > > > > a SHOULD is not expected. Otherwise you get some > implementations > > > > that treat it as a MUST and many others that just > ignore it. What > > > > happens if the sender or receiver does not record the > end-entity > > > > certificate? > > > > Under what conditions is that a problem? > > > > > > > [Joe] Perhaps this SHOULD should not be capitalized. I think the > > > purpose for the should is described, but perhaps it can be > > > clarified: > > > > > > "The transport receiver and transport sender should provide a > > > mechanism to record the end-entity certificate to correlate the > > > authenticated party with the sent or received data in the case > that > > > it is necessary to meet traceability requirements." > > > > FWIW, I think capitalized "SHOULD" is correct usage here. > > I agree. The implementation SHOULD provide the mechanism. > If there is an issue of whether this is interoperable, then I > could accept a MUST implement, but then we should probably > describe the mechanism. > > > > > > > > If the peer does not meet the requirements of the > > > > > security policy, > > > > > the TLS handshake SHOULD be aborted with an appropriate > > > > > TLS alert. > > > > > > > > Medium-Large: This SHOULD surprises me. You allow the > peer not to > > > > abort the handshake under some conditions? What could those > > > > conditions be? I think you should explain this SHOULD > carefully > > > > so as to avoid a security hole through lack of documentation. > > > > > > > [Joe] The intent here is that a peer could accept a connection > that > > > does not meet a specific policy so it can continue operation. > This > > > does have some security implications. I think it is warranted to > > > add explanatory some text along the lines of: > > > > Well, if the peer continues the connection, it *does* have a policy > > that allows this (i.e. requirements of the policy are in > fact met, to > > some degree at least). > > Agreed. > > > > > > "In traditional syslog using UDP as the transport, network > > > administrators regularly set up syslog transport senders without > > > performing any administrative tasks on the corresponding > transport > > > receivers. This behavior would be replicated by permitting a > > > transport sender that may not meet the requirements of the > security > > > policy to send messages to a transport receiver so that the event > > > messages may still be received. Of course accepting connections > > > outside of policy increases the risk of compromise from the > various > > > threats that the use of TLS is attempting to mitigate. This must > > > only be done when there are other mechanisms in place to manage > the > > > associated risks." > > > > I think the correct fix would be to say that you MUST follow your > > policy (instead of SHOULD), but you're allowed to have a > policy that > > permits unauthenticated transport senders (this kind of policy is > > described in Section 5.3). > > I am just a bit concered about the use of RFC2119 terminology. > MUST is for implementers; SHOULD is for deployers. > Is that MUST directed at implementers or deployers? > > I agree that following the policy is important, and the > implementation MUST abide by the policy. The deployer SHOULD > be able to define a policy that permits unauthenticated senders. > [Joe] The implementation MUST abide by the configured policy. The implementation can allow for many different types of policies including ones that permit unauthenticated transport senders or receivers in sections 5.3 - 5.5. Implementations MUST support the policies defined in 5.1 and 5.2. > dbh > > > > > 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 Thu Aug 7 13:58: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 810D83A6967; Thu, 7 Aug 2008 13:58: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 611B93A6967 for ; Thu, 7 Aug 2008 13:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 SixnaEnsQvN1 for ; Thu, 7 Aug 2008 13:58:23 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by core3.amsl.com (Postfix) with ESMTP id BB92B3A6943 for ; Thu, 7 Aug 2008 13:58:23 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 83EC111E9568; Thu, 7 Aug 2008 13:58:23 -0700 (PDT) Received: from [10.0.230.251] ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Thu, 07 Aug 2008 13:58:20 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 07 Aug 2008 13:58:20 -0700 Message-Id: <48AF3913-34E4-461F-B16E-7BBE8D73D748@callas.org> From: Jon Callas To: In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C628F@vaebe104.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 7 Aug 2008 13:58:20 -0700 References: <1696498986EFEC4D9153717DA325CB720134FF58@vaebe104.NOE.Nokia.com><488C5270.3010403@mschuette.name><34A02E87-89BC-4716-BA45-89B2AFD23DB5@callas.org> <48938517.9070002@mschuette.name> <1696498986EFEC4D9153717DA325CB72014C628F@vaebe104.NOE.Nokia.com> X-Mailer: Apple Mail (2.928.1) Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: RSA support? 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org On Aug 7, 2008, at 12:31 PM, wrote: > Martin Sch=FCtte wrote: > >> I think this is mainly a compatibility concern for users who have >> existing PKIX certificates with RSA keys and want to use them for >> TLS and for signing. When creating new keys for syslog-sign then >> DSA or ECDSA are clearly preferable. > > Or existing *CAs* (inside enterprises etc.) that certify only RSA > keys (not because there's anything wrong with DSA, but because they > thought nobody would need it). Yes, but. The existing design and consensus on syslog-sign is that's a = DSA system, and doesn't require a CA. The rationale, as I said before = comes from the days when syslog meant UDP, and size truly mattered. = That may not matter so much today, especially if you're using TLS as a = transport. But that's what the existing consensus is. Do we have to, at this late = date, throw out the existing consensus and put in RSA and CAs? Jon _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu Aug 7 14:12: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 AA2403A696D; Thu, 7 Aug 2008 14:12: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 0495B28C197 for ; Thu, 7 Aug 2008 14:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.779 X-Spam-Level: X-Spam-Status: No, score=-5.779 tagged_above=-999 required=5 tests=[AWL=0.820, 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 EPCzG8vjHKr6 for ; Thu, 7 Aug 2008 14:12:24 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id EAD9628C18F for ; Thu, 7 Aug 2008 14:12:23 -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 m77LBu7k017147; Fri, 8 Aug 2008 00:12:18 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 00:12:07 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 00:12:03 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 8 Aug 2008 00:12:07 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72014C62A0@vaebe104.NOE.Nokia.com> In-Reply-To: <48AF3913-34E4-461F-B16E-7BBE8D73D748@callas.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Syslog-sign: RSA support? Thread-Index: Acj40FeTiQLhFmggQHO6HPJLEeUOlgAAW/7g References: <1696498986EFEC4D9153717DA325CB720134FF58@vaebe104.NOE.Nokia.com><488C5270.3010403@mschuette.name><34A02E87-89BC-4716-BA45-89B2AFD23DB5@callas.org> <48938517.9070002@mschuette.name> <1696498986EFEC4D9153717DA325CB72014C628F@vaebe104.NOE.Nokia.com> <48AF3913-34E4-461F-B16E-7BBE8D73D748@callas.org> From: To: X-OriginalArrivalTime: 07 Aug 2008 21:12:03.0495 (UTC) FILETIME=[3D471B70:01C8F8D2] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: RSA support? 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 Jon Callas wrote: > Yes, but. The existing design and consensus on syslog-sign is that's > a DSA system, and doesn't require a CA. The rationale, as I said > before comes from the days when syslog meant UDP, and size truly > mattered. That may not matter so much today, especially if you're > using TLS as a transport. > > But that's what the existing consensus is. Do we have to, at this > late date, throw out the existing consensus and put in RSA and CAs? Doesn't *require* a CA, or doesn't *support* CAs? (BTW, to me, RSA vs. DSA seems totally orthogonal to CA vs. no CA issue). Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu Aug 7 14:24:49 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 450953A68A3; Thu, 7 Aug 2008 14:24:49 -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 010EE3A6983 for ; Thu, 7 Aug 2008 14:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 Wviq2+rD43g9 for ; Thu, 7 Aug 2008 14:24:47 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by core3.amsl.com (Postfix) with ESMTP id 560DC3A6933 for ; Thu, 7 Aug 2008 14:24:47 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 7571611E99A5; Thu, 7 Aug 2008 14:24:47 -0700 (PDT) Received: from [10.0.230.251] ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Thu, 07 Aug 2008 14:24:44 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Thu, 07 Aug 2008 14:24:44 -0700 Message-Id: <48C73B57-FDBD-4D52-8C49-AD74701C50D3@callas.org> From: Jon Callas To: In-Reply-To: <1696498986EFEC4D9153717DA325CB72014C62A0@vaebe104.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Thu, 7 Aug 2008 14:24:43 -0700 References: <1696498986EFEC4D9153717DA325CB720134FF58@vaebe104.NOE.Nokia.com><488C5270.3010403@mschuette.name><34A02E87-89BC-4716-BA45-89B2AFD23DB5@callas.org> <48938517.9070002@mschuette.name> <1696498986EFEC4D9153717DA325CB72014C628F@vaebe104.NOE.Nokia.com> <48AF3913-34E4-461F-B16E-7BBE8D73D748@callas.org> <1696498986EFEC4D9153717DA325CB72014C62A0@vaebe104.NOE.Nokia.com> X-Mailer: Apple Mail (2.928.1) Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: RSA support? 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org On Aug 7, 2008, at 2:12 PM, wrote: > > Doesn't *require* a CA, or doesn't *support* CAs? > > (BTW, to me, RSA vs. DSA seems totally orthogonal to CA vs. no CA > issue). Require. What consenting endpoints do in the privacy of their own SA is no concern of ours. :) There's no reason you can't any key-centric system and send the keys off to a CA to be certified; similarly there's no reason you can't pry the key out of a certificate and use it in a key-centric system. (As an aside, DKIM is another key-centric system that defines RSA only, but similarly does not require certificates.) Jon _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri Aug 8 08:25:10 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 682433A68E1; Fri, 8 Aug 2008 08:25:10 -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 E1BF228C15B; Thu, 7 Aug 2008 05:17:15 -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 oPhNelW9hb+n; Thu, 7 Aug 2008 05:17:14 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 35CC528C0FC; Thu, 7 Aug 2008 05:17:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,319,1215388800"; d="scan'208";a="16757837" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Aug 2008 12:17:45 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m77CHiMX018829; Thu, 7 Aug 2008 08:17:44 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m77CHhwP016072; Thu, 7 Aug 2008 12:17:44 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 08:14:42 -0400 Received: from sbrim-mbp.local ([10.86.250.146]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 08:14:42 -0400 Message-ID: <489AE731.7040603@employees.org> Date: Thu, 07 Aug 2008 08:14:41 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <4891E12A.2050207@employees.org> In-Reply-To: X-OriginalArrivalTime: 07 Aug 2008 12:14:42.0331 (UTC) FILETIME=[2C0BE6B0:01C8F887] Authentication-Results: rtp-dkim-2; header.From=swb@employees.org; dkim=neutral X-Mailman-Approved-At: Fri, 08 Aug 2008 08:25:09 -0700 Cc: syslog@ietf.org, gen-art@ietf.org, draft-ietf-syslog-transport-tls@tools.ietf.org Subject: Re: [Syslog] gen-art review of draft-ietf-syslog-transport-tls-13.txt 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org On 8/6/08 8:16 PM, Joseph Salowey (jsalowey) allegedly wrote: > Thanks for reviewing the document, the comments are very useful. I'm > including some comments and proposed resolutions below. > > Cheers, > > Joe > >> -----Original Message----- >> From: syslog-bounces@ietf.org >> [mailto:syslog-bounces@ietf.org] On Behalf Of Scott Brim >> Sent: Thursday, July 31, 2008 8:59 AM >> To: draft-ietf-syslog-transport-tls@tools.ietf.org; >> syslog@ietf.org; gen-art@ietf.org; Pasi.Eronen@nokia.com >> Subject: [Syslog] gen-art review of >> draft-ietf-syslog-transport-tls-13.txt >> >> I have been selected as the General Area Review Team >> (Gen-ART) reviewer for this draft (for background on Gen-ART, >> please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >> >> Please wait for direction from your document shepherd or AD >> before posting a new version of the draft. >> >> Document: draft-ietf-syslog-tls-13.txt >> Reviewer: Scott Brim >> Review Date: 30 July 2008 >> >> Summary: >> >> This draft is basically ready for publication, but has nits >> that should be fixed before publication. >> >> Comments: >> >> There is only one item that is significant, which is the last >> of the SHOULD comments (just below). As for the rest, they >> are not showstoppers but imho if you take them into >> consideration you'll have a better draft. >> >> First, MUST/SHOULD >> ------------------ >> >> > TLS typically uses certificates [RFC5280] to authenticate peers. >> > Implementations MUST support TLS 1.2 >> [I-D.ietf-tls-rfc4346-bis] and >> > are REQUIRED to support the mandatory to implement cipher suite, >> >> Small: Change "are REQUIRED to" to "MUST". >> >> > The transport receiver and transport sender SHOULD provide >> > mechanisms to record the end-entity certificate for the >> purpose of >> > correlating it with the sent or received data. >> >> Medium: In general it's good to explain the conditions under >> which a SHOULD is not expected. Otherwise you get some >> implementations that treat it as a MUST and many others that >> just ignore it. What happens if the sender or receiver does >> not record the end-entity certificate? >> Under what conditions is that a problem? >> > [Joe] Perhaps this SHOULD should not be capitalized. I think the purpose > for the should is described, but perhaps it can be clarified: > > "The transport receiver and transport sender should provide a mechanism > to record the end-entity certificate to correlate the authenticated > party with the sent or received data in the case that it is necessary to > meet traceability requirements." If something is "necessary to meet ... requirements", isn't it a MUST? My original question was just for a little clarification, but I would guess you're better off with the original sentence. :-) The point of all this is to avoid ambiguity for implementers. Most implementers seem to reflexively treat a SHOULD as a MAY, i.e. they don't bother ... unless they are authors of the draft, in which case they understand the implications much better and they make an informed decision. So the point is to make it possible for a new reader to make an informed decision. Everything below looks good. >> > If the peer does not meet the requirements of the >> security policy, >> > the TLS handshake SHOULD be aborted with an appropriate >> TLS alert. >> >> Medium-Large: This SHOULD surprises me. You allow the peer >> not to abort the handshake under some conditions? What could >> those conditions be? I think you should explain this SHOULD >> carefully so as to avoid a security hole through lack of >> documentation. >> > [Joe] The intent here is that a peer could accept a connection that does > not meet a specific policy so it can continue operation. This does have > some security implications. I think it is warranted to add explanatory > some text along the lines of: > > "In traditional syslog using UDP as the transport, network > administrators regularly set up syslog transport senders without > performing any administrative tasks on the corresponding transport > receivers. This behavior would be replicated by permitting a transport > sender that may not meet the requirements of the security policy to send > messages to a transport receiver so that the event messages may still be > received. Of course accepting connections outside of policy increases > the risk of compromise from the various threats that the use of TLS is > attempting to mitigate. This must only be done when there are other > mechanisms in place to manage the associated risks." > >> Second, terminology >> ------------------- >> >> You have >> >> Transport sender Transport receiver >> Server Client >> Peer Peer >> >> These terms overlap. I can't tell if the first two pairs are >> synonymous or not. I can see reasons to use all of these, >> based on different relationships and functions, but you seem >> to mix and match sometimes. Sometimes limiting your >> terminology can make your spec tighter and clearer, so >> consider getting rid of one pair. Here are some >> examples: > > [Joe] The intent here was to align with the syslog terminology, while > mapping to the appropriate TLS terminology when discussing TLS specific > details. Peer is used when describing behavior that is independent of > client and server roles. More below. > >> > 1.1 Terminology >> > >> > o A "TLS client" is an application that can initiate a TLS >> > connection by sending a Client Hello to a peer. >> > >> > o A "TLS server" is an application that can receive a Client >> > Hello from a peer and reply with a Server Hello. >> >> Small: If you're going to use client, then use server, and vice versa. >> A TLS client initiates a Client Hello to a *server*, and a >> server receives a Client Hello from a *client*. > > [Joe] OK makes sense. > >> > 4.1 Port Assignment >> > >> > A syslog transport sender is always a TLS client and a transport >> > receiver is always a TLS server. >> >> I would have thought that since a server occasionally sends a >> message to the client (for example a close_notify), that the >> server could be a "transport sender" too ... and similarly >> the client receiving packets could be a "transport receiver". >> > > [Joe] Transport receiver and transport sender roles are with respect to > syslog messages. TLS introduces its own signaling (close_notify and > others), but this does not change the roles of the syslog entities. > >> > 4.2 Initiation >> > >> > The transport sender should initiate a connection to the >> > transport receiver and then send the TLS Client Hello to begin >> > the TLS handshake. When the TLS handshake has finished the >> > transport sender MAY then send the first syslog message. >> >> There are two actions here, "initiate a connection" and then >> have a TLS handshake. It would make more sense to me to use >> the terms client/server than sender/receiver. >> > [Joe] In the above cases the use of transport sender and transport > receiver are consistent with their use in the syslog protocol. > >> > A TLS client MUST close the associated TLS connection if the >> > connection is not expected to deliver any syslog messages later. >> >> Just above, the "transport sender" was told to set the >> message length, but here the "TLS client" is told to close >> the TLS connection. That feels inconsistent. > [Joe] OK, I think it would make sense to use the syslog terminology here > to be consistent so this section should read: > > A transport sender MUST close the associated TLS connection if the > connection is not expected to deliver any syslog messages later. It > MUST send a TLS close_notify alert before closing the connection. A > sender MAY choose to not wait for the receiver's close_notify alert > and > simply close the connection, thus generating an incomplete close on > the receiver side. Once the receiver gets a close_notify from the > sender, it MUST reply with a close_notify unless it becomes aware > that the connection has already been closed by the sender (e.g., the > closure was indicated by TCP). > > When no data is received from a connection for a long time (where the > application decides what "long" means), a receiver MAY close the > connection. The receiver MUST attempt to initiate an exchange of > close_notify alerts with the sender before closing the connection. > Receivers that are unprepared to receive any more data MAY close the > connection after sending the close_notify alert, thus generating an > incomplete close on the sender side. When the sender has received > the close_notify alert from the receiver and still has pending data > to > send, it SHOULD send the pending data before sending the close_notify > alert. Thanks ... Scott _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From MAILER-DAEMON Sat Aug 9 07:24:26 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 E76AF3A6ABD for ; Sat, 9 Aug 2008 07:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.793 X-Spam-Level: * X-Spam-Status: No, score=1.793 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2, HTML_EXTRA_CLOSE=2.809, HTML_FONT_SIZE_HUGE=0.057, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SARE_UNI=0.591] 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 7JoLs4ZILyzZ for ; Sat, 9 Aug 2008 07:24:25 -0700 (PDT) Received: from ironport.layer42.net (ironport.layer42.net [69.36.224.22]) by core3.amsl.com (Postfix) with ESMTP id 42ECB3A6C50 for ; Sat, 9 Aug 2008 07:24:25 -0700 (PDT) Received: from localhost by ironport.layer42.net; 09 Aug 2008 07:24:26 -0700 Date: 09 Aug 2008 07:24:26 -0700 To: syslog-archive@lists.ietf.org From: "Mail Delivery System" Subject: Delivery Status Notification (Failure) MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="pWo0.4L0UjyH4a.QlglQ.7/wOxDY" Message-Id: <20080809142425.42ECB3A6C50@core3.amsl.com> --pWo0.4L0UjyH4a.QlglQ.7/wOxDY content-type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The following message to was undeliverable. The reason for the problem: 5.x.0 - Message bounced by administrator --pWo0.4L0UjyH4a.QlglQ.7/wOxDY content-type: message/delivery-status Reporting-MTA: dns; ironport.layer42.net Final-Recipient: rfc822;syslog-sec@employees.org Action: failed Status: 5.0.0 (permanent failure) Diagnostic-Code: smtp; 5.x.0 - Message bounced by administrator (delivery attempts: 0) --pWo0.4L0UjyH4a.QlglQ.7/wOxDY content-type: message/rfc822 Received: from unknown (HELO group-4f6fabc12) ([89.218.129.196]) by ironport.employees.org with SMTP; 09 Aug 2008 07:24:26 -0700 Received: from unknown (HELO group-4f6fabc12) ([89.218.129.196]) by ironport.employees.org with SMTP; 09 Aug 2008 07:24:25 -0700 Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Return-Path: communications_msn_cs_enus@cimail15.msn.com Message-Id: <20080809142417.2972.qmail@group-4f6fabc12> To: Subject: Internet Explorer 7 From: admin@microsoft.com MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit
Download the latest version!

About this mailing:
You are receiving this e-mail because you subscribed to MSN Featured Offers. Microsoft respects your privacy. If you do not wish to receive this MSN Featured Offers e-mail, please click the "Unsubscribe" link below. This will not unsubscribe you from e-mail communications from third-party advertisers that may appear in MSN Feature Offers. This shall not constitute an offer by MSN. MSN shall not be responsible or liable for the advertisers' content nor any of the goods or service advertised. Prices and item availability subject to change without notice.

©2008 Microsoft | Unsubscribe | More Newsletters | Privacy

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052
--pWo0.4L0UjyH4a.QlglQ.7/wOxDY-- From syslog-bounces@ietf.org Mon Aug 11 05:49: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 89B313A6D1B; Mon, 11 Aug 2008 05:49: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 21E383A6D1B for ; Mon, 11 Aug 2008 05:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.651 X-Spam-Level: X-Spam-Status: No, score=0.651 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, 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 fosoqL81arER for ; Mon, 11 Aug 2008 05:49:24 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id 1AB393A6B13 for ; Mon, 11 Aug 2008 05:49:23 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 5906688415 for ; Mon, 11 Aug 2008 14:49:24 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id AqD4gvBwSCSv for ; Mon, 11 Aug 2008 14:49:12 +0200 (CEST) Received: from cordelia.mschuette.name (BAA19a0.baa.pppool.de [77.128.25.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 5C4D288412 for ; Mon, 11 Aug 2008 14:49:11 +0200 (CEST) Message-ID: <48A03553.3040509@mschuette.name> Date: Mon, 11 Aug 2008 14:49:23 +0200 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.14 (X11/20080511) MIME-Version: 1.0 To: syslog@ietf.org References: <1696498986EFEC4D9153717DA325CB720134FF58@vaebe104.NOE.Nokia.com><488C5270.3010403@mschuette.name><34A02E87-89BC-4716-BA45-89B2AFD23DB5@callas.org> <48938517.9070002@mschuette.name> <1696498986EFEC4D9153717DA325CB72014C628F@vaebe104.NOE.Nokia.com> <48AF3913-34E4-461F-B16E-7BBE8D73D748@callas.org> In-Reply-To: <48AF3913-34E4-461F-B16E-7BBE8D73D748@callas.org> Subject: Re: [Syslog] Syslog-sign: RSA support? 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Jon Callas schrieb: > But that's what the existing consensus is. Do we have to, at this late > date, throw out the existing consensus and put in RSA and CAs? I think we can agree not to have any notion of CAs in syslog-sign, besides the simple fact that users of PKIX and OpenPGP keys might use one witout affecting syslog-sign. But what would be necessary to include RSA and ECDSA? As far as I see we just had to assign two additional VERsion digits values for the Signature Scheme. So I suggest for 4.2.1: Signature Scheme - 1 octet, where, in conjunction with Protocol Version 01, a value of "1" denotes OpenPGP DSA [RFC4880, FIPS 186-3], a value of "2" denotes RSA [RFC4880, FIPS 186-3], and a value of "3" denotes ECDSA [FIPS 186-3]. The version, hash algorithm [...unchanged paragraph...] marks). For interoperability all implementations MUST support Version "0111" (DSA with SHA-1). Updated references: [RFC4880] Callas, J., Donnerhacke, L., Finney, H., D. Shaw, and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [FIPS 186-3] Federal Information Processing Standards Publication (FIPS PUB) 186-3, Digital Signature Standard (DSS), (draft) March 2006. -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Aug 11 14:47: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 C618C3A69B9; Mon, 11 Aug 2008 14:47: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 BB59B3A69B9 for ; Mon, 11 Aug 2008 14:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Wtp0ne4TmiwB for ; Mon, 11 Aug 2008 14:47:23 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by core3.amsl.com (Postfix) with ESMTP id 026F33A67B6 for ; Mon, 11 Aug 2008 14:47:22 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 5AE9B120661D; Mon, 11 Aug 2008 14:47:25 -0700 (PDT) Received: from [10.0.23.32] ([66.93.68.160]) by keys.merrymeet.com (PGP Universal service); Mon, 11 Aug 2008 14:47:22 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 11 Aug 2008 14:47:22 -0700 Message-Id: From: Jon Callas To: =?ISO-8859-1?Q?Martin_Sch=FCtte?= In-Reply-To: <48A03553.3040509@mschuette.name> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 11 Aug 2008 14:47:23 -0700 References: <1696498986EFEC4D9153717DA325CB720134FF58@vaebe104.NOE.Nokia.com><488C5270.3010403@mschuette.name><34A02E87-89BC-4716-BA45-89B2AFD23DB5@callas.org> <48938517.9070002@mschuette.name> <1696498986EFEC4D9153717DA325CB72014C628F@vaebe104.NOE.Nokia.com> <48AF3913-34E4-461F-B16E-7BBE8D73D748@callas.org> <48A03553.3040509@mschuette.name> X-Mailer: Apple Mail (2.928.1) Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: RSA support? 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org On Aug 11, 2008, at 5:49 AM, Martin Sch=FCtte wrote: > Jon Callas schrieb: >> But that's what the existing consensus is. Do we have to, at this = >> late date, throw out the existing consensus and put in RSA and CAs? > > I think we can agree not to have any notion of CAs in syslog-sign, > besides the simple fact that users of PKIX and OpenPGP keys might = > use one witout affecting syslog-sign. > > > But what would be necessary to include RSA and ECDSA? As far as I = > see we just had to assign two additional VERsion digits values for = > the Signature Scheme. I agree that it's not all that difficult to add it in, but the draft = has gone this far with WG consensus that it is not needed. I don't = think we can add it without pulling it out of last call and re-opening = it up. I might be wrong, but nonetheless, Pasi Eronen asked the = question of why it was DSA-only, and we answered. I don't believe we = have to add in RSA. During last call, ADs ask a number of good, tough = questions that don't require negating the WG consensus. And since the = document in its present state is a product of WG consensus, we need a = semblance of that to add in a major new feature like a new public key = algorithm. Jon _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Mon Aug 11 17:22:06 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 20BBF3A69F5; Mon, 11 Aug 2008 17:22:06 -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 E14593A69F5 for ; Mon, 11 Aug 2008 17:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+snxttuEOlI for ; Mon, 11 Aug 2008 17:22:05 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by core3.amsl.com (Postfix) with ESMTP id 03CF83A6912 for ; Mon, 11 Aug 2008 17:22:04 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 37so2030480wra.17 for ; Mon, 11 Aug 2008 17:21:55 -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 :content-transfer-encoding:content-disposition:references; bh=pAzvTBgRGdNMFU3C1c8EXks6h6LtMQhMQ4wed5a5ATw=; b=AfnJ5O1HrGZr5mN2z4mHvlZdMwESjAgsk6xdy/3ywz7LFbclyZfQjpF5whjQbhX+tZ zTjKWYOVgBEBDsg9S++ybe3eCr2UBCNZK+mc9pp3/ZZQzDZBGllRyqDWpwyfWVJ3TKIC FMT5aYLmCXngTypdnbuoJW1AaYF+0QLKNOuCs= 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:content-transfer-encoding:content-disposition :references; b=elqI6zWQ7wMi4OjcYWf2hzYmptscuG9+U9Jn5PgbJHQ6vBWoo8w1C2x0JqFf4h2fg9 CzRLG92d+yFv9subb7ina6nyxL0uThI8maLgjvfaeFkAIwxrHEOPzg6VJNw1tdodDarU 3RAJEevn4nJ1nyUKVZ8XT/Vr0i0Rch+bKEG7Q= Received: by 10.90.31.6 with SMTP id e6mr11540295age.90.1218500515641; Mon, 11 Aug 2008 17:21:55 -0700 (PDT) Received: by 10.90.65.17 with HTTP; Mon, 11 Aug 2008 17:21:55 -0700 (PDT) Message-ID: <45c8c21a0808111721h7619593lb2c6314de3a7bcf0@mail.gmail.com> Date: Mon, 11 Aug 2008 20:21:55 -0400 From: "Richard Graveman" To: "Jon Callas" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB720134FF58@vaebe104.NOE.Nokia.com> <488C5270.3010403@mschuette.name> <34A02E87-89BC-4716-BA45-89B2AFD23DB5@callas.org> <48938517.9070002@mschuette.name> <1696498986EFEC4D9153717DA325CB72014C628F@vaebe104.NOE.Nokia.com> <48AF3913-34E4-461F-B16E-7BBE8D73D748@callas.org> <48A03553.3040509@mschuette.name> Cc: syslog@ietf.org Subject: Re: [Syslog] Syslog-sign: RSA support? 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 I agree with Jon on all counts. A good reason for the choice exists, the draft has been stable for years, no security issue is raised, keep it simple, and who wants to start discussing which of the three are MUST, SHOULD, or MAY? Richard Graveman On Mon, Aug 11, 2008 at 5:47 PM, Jon Callas wrote: > > On Aug 11, 2008, at 5:49 AM, Martin Sch=FCtte wrote: > >> Jon Callas schrieb: >>> >>> But that's what the existing consensus is. Do we have to, at this late >>> date, throw out the existing consensus and put in RSA and CAs? >> >> I think we can agree not to have any notion of CAs in syslog-sign, >> besides the simple fact that users of PKIX and OpenPGP keys might use one >> witout affecting syslog-sign. >> >> >> But what would be necessary to include RSA and ECDSA? As far as I see we >> just had to assign two additional VERsion digits values for the Signature >> Scheme. > > I agree that it's not all that difficult to add it in, but the draft has > gone this far with WG consensus that it is not needed. I don't think we c= an > add it without pulling it out of last call and re-opening it up. I might = be > wrong, but nonetheless, Pasi Eronen asked the question of why it was > DSA-only, and we answered. I don't believe we have to add in RSA. During > last call, ADs ask a number of good, tough questions that don't require > negating the WG consensus. And since the document in its present state is= a > product of WG consensus, we need a semblance of that to add in a major new > feature like a new public key algorithm. > > Jon > > > _______________________________________________ > 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 Aug 12 09:07:54 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 63ED628C16A; Tue, 12 Aug 2008 09:07:54 -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 6CFF328C15C for ; Tue, 12 Aug 2008 09:07:52 -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 44D70rhOp3Mv for ; Tue, 12 Aug 2008 09:07:51 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E289E28C173 for ; Tue, 12 Aug 2008 09:07:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,196,1217808000"; d="scan'208";a="41087291" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 12 Aug 2008 16:07:39 +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 m7CG7dhs009222 for ; Tue, 12 Aug 2008 09:07:39 -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 m7CG7d17010565 for ; Tue, 12 Aug 2008 16:07:39 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); Tue, 12 Aug 2008 09:07:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Aug 2008 09:08:04 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use of system port vs. regular port thread-index: Acj8lZpJnHL9yct4R4OFJgGm0AqX2Q== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 12 Aug 2008 16:07:39.0105 (UTC) FILETIME=[8AEB1D10:01C8FC95] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=467; t=1218557259; x=1219421259; 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:=20Use=20of=20system=20port=20vs.=20regular=20port |Sender:=20; bh=X2rPUVB/0TTVMpM4CBseLksSyvuPmin3AOz8bsjSIaw=; b=h5SccTKcNxadOoEbFLYmtnYfkGmF6icDlJ+zzMAec4lDj7O/fJjVZ4qtnI sLKdf3mHq03lguwmJb56Touvm3qKDKZ1Yw3ywQpFu4G6iBpd6WNZ9x7HO5M3 DRO5YzGmUWzennfZChCnNsfzqze4yJMdfe4liWiCe24TSOeoBlNsY=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Syslog] Use of system port vs. regular port 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 Lars Eggert has entered a DISCUSS on draft-ietf-syslog-transport-tls asking "What is the justification for allocating a system port? Why wouldn't a registered port suffice? (Note that IANA is changing procedures such that system ports are becoming more difficult to obtain, because we're running out of them.)" Is there a reason why we require a system port? Was this discussed previously? Would a registered port be acceptable? Thanks, Joe _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Aug 13 01:20:39 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 077F93A69D2; Wed, 13 Aug 2008 01:20:39 -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 219E83A6A01 for ; Wed, 13 Aug 2008 01:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.497 X-Spam-Level: X-Spam-Status: No, score=0.497 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_50=0.001, DATE_IN_PAST_12_24=0.992] 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 M5t4LRV9zWxt for ; Wed, 13 Aug 2008 01:20:33 -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 0817C3A68CF for ; Wed, 13 Aug 2008 01:20:32 -0700 (PDT) X-Trace: 68408784/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.138.167 X-SBRS: None X-RemoteIP: 62.188.138.167 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgFAJg1okg+vIqn/2dsb2JhbABCgn81h22rWwOBUg X-IronPort-AV: E=Sophos;i="4.32,200,1217804400"; d="scan'208";a="68408784" X-IP-Direction: IN Received: from 1cust167.tnt9.lnd4.gbr.da.uu.net (HELO allison) ([62.188.138.167]) by smtp.pipex.tiscali.co.uk with SMTP; 13 Aug 2008 09:20:05 +0100 Message-ID: <000801c8fd14$1e06e240$0601a8c0@allison> From: "tom.petch" To: "Joseph Salowey \(jsalowey\)" , References: Date: Tue, 12 Aug 2008 19:08:13 +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] Use of system port vs. regular port 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: Sent: Tuesday, August 12, 2008 6:08 PM Subject: [Syslog] Use of system port vs. regular port > Lars Eggert has entered a DISCUSS on draft-ietf-syslog-transport-tls > asking > > "What is the justification for allocating a system port? Why wouldn't a > registered port suffice? > (Note that IANA is changing procedures such that system ports are > becoming more difficult to obtain, because we're running out of them.)" > > Is there a reason why we require a system port? Was this discussed > previously? Would a registered port be acceptable? > See [Syslog] Other syslog-tls Issues---Issue0 20 March 2006 This was then incorporated in draft-ietf-syslog-transport-tls-02.txt Tom Petch > Thanks, > > Joe > _______________________________________________ > 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 Aug 13 06:38: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 4A9D63A69E7; Wed, 13 Aug 2008 06:38: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 DE69A3A67AF for ; Wed, 13 Aug 2008 06:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 18tKCKhBCIKS for ; Wed, 13 Aug 2008 06:37:58 -0700 (PDT) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 7F9BA3A6876 for ; Wed, 13 Aug 2008 06:37:58 -0700 (PDT) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id 1o0P1a00A0lTkoCA2pdGEJ; Wed, 13 Aug 2008 13:37:16 +0000 Received: from Harrington73653 ([24.128.66.199]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id 1pdE1a00m4HwxpC8QpdFu9; Wed, 13 Aug 2008 13:37:16 +0000 X-Authority-Analysis: v=1.0 c=1 a=EPyU-kwg7fMA:10 a=BUDEctdkfsIA:10 a=o7y3b6cNqHzPIPJtB4QA:9 a=kfsOaKteoYK2cG5UFTwA:7 a=rZnZ0Z22wa005j9MrgzZFnwy3zwA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=1pxjJC3EenQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: Date: Wed, 13 Aug 2008 09:37:14 -0400 Message-ID: <060e01c8fd49$b32fe6c0$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: Acj9EVwC/jFMEsaoTZqG+sA/XtQGgAAN8SbA Subject: [Syslog] FW: DISCUSS: 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, There is a question of whether we need a system port or just a registered port. As co-chair, I think the WG should be involved in this discussion. The document is scheduled to be discussed by the IESG on Thursday, so quick responses are important. Would a registered port be adequate for syslog/tls, or is there a compelling reason why it MUST be a system port? David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com -----Original Message----- From: Lars Eggert [mailto:lars.eggert@nokia.com] Sent: Wednesday, August 13, 2008 2:53 AM To: ext Joseph Salowey (jsalowey) Subject: Re: DISCUSS: draft-ietf-syslog-transport-tls Hi, On 2008-8-13, at 9:05, ext Joseph Salowey (jsalowey) wrote: > This was discussed in the working group. The following is a list of > reasons that were given in support of a system port (somewhat > paraphrased): > > 1. We expect syslog-tls to become widespread adopted (if we would not > expect this, we could simply drop the effort - this is why the WG has > been rechartered). Sure, but widely adopted != needs a port < 1024. Lots of widely- adopted protocols use a registered port in the 1024-49151 range. > 2. Syslog traditionally has been assigned a dedicated port in the > system > range (514 and 601). > > 3. Syslog was considered important enough to assign a dedicated port > in > the past (601 with RFC 3195) - the same should apply to this effort We've been continuing to run out of system port space since those ports were allocated. If there is no technical reason for a low port number, I'd like to push back a bit on historic consistency as an argument. > 4. The syslog daemon is considered an essential system service and > part > of many important operating systems True, but see my answer to 1. > 5. Operators expect a dedicated port for an essential protocol > > 6. A dedicated port greatly reduces the likelihood of syslogd startup > errors due to port being used by another process > > 7. A dedicated port greatly reduces ambiguity, which is especially > important as a number of SOHO deceives/applications is expected to > implement the protocol. For low-knowledge, "nearly plug-and-play" > scenarios, senders and receivers need a universal understanding of the > port number to use. As for 5-7, syslog will get a dedicated port, but in the 1024-49151 range instead of one < 1024. > 8. (derived argument) Combining argument #1 and #4, there will be a > very large number of systems utilizing that port, thus justifying > assigning a scarce resource. > > I think these arguments are convincing, but I am unsure as to the > criteria for assigning a system port. draft-ietf-tsvwg-iana-ports has some text on this. Basically, the difference between the well-known and registered port ranges has been diminishing to the point where it has become irrelevant. For example, on a few operating systems, only root can bind to well known ports. This is not a security feature, quite the opposite - most system daemons only become root to bind to the port and then drop privileges to run as a regular user and sometimes even in a sandbox, as to not become an attack vector. If they used a registered port, they'd not even need to jump through these hoops. Al that said, I agree that this change in IANA policy hasn't been widely communicated and the corresponding document hasn't gotten IETF consensus yet. If the WG and the rest of the IETF thinks that we shouldn't strictly apply it for this reason at this time, I can live with that and will clear the DISCUSS on the call Thursday. (There are only around 200 system ports left, however, so at some point we do need to start raising the bar.) Lars _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Aug 13 06:59:39 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 04E5A3A6C5D; Wed, 13 Aug 2008 06:59:39 -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 730363A6D0B for ; Wed, 13 Aug 2008 06:59:03 -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 04p+jcrNOFfF for ; Wed, 13 Aug 2008 06:58:58 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 75B8528C16E for ; Wed, 13 Aug 2008 06:52:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,201,1217808000"; d="scan'208";a="17051185" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 13 Aug 2008 13:51:41 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7DDpfIc020040; Wed, 13 Aug 2008 15:51:41 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7DDpfui024865; Wed, 13 Aug 2008 13:51:41 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Aug 2008 15:51:41 +0200 Received: from adsl-247-5-fixip.tiscali.ch ([10.61.81.67]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Aug 2008 15:51:40 +0200 Message-ID: <48A2E6EC.5030404@cisco.com> Date: Wed, 13 Aug 2008 15:51:40 +0200 From: Eliot Lear User-Agent: Thunderbird/3.0b1pre (Macintosh; 20080812030823) MIME-Version: 1.0 To: David Harrington References: <060e01c8fd49$b32fe6c0$0600a8c0@china.huawei.com> In-Reply-To: <060e01c8fd49$b32fe6c0$0600a8c0@china.huawei.com> X-OriginalArrivalTime: 13 Aug 2008 13:51:40.0810 (UTC) FILETIME=[B69BD6A0:01C8FD4B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=636; t=1218635501; x=1219499501; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[Syslog]=20FW=3A=20DISCUSS=3A=20draft-i etf-syslog-transport-tls |Sender:=20; bh=Dldp6+bm8YT+S5JmrXinQ2bwbCtMitsHq2hfkml+Ino=; b=sMwfyAj5AjX1sQtIjuakRUMTT0ydsNAid62Cp7xPADhjgmtOcg7ffLf7rM 6DipWiDRdKY+KwUSG+Zyp8EsRnovsnasIC3oHAUg891ugvl2nTT0VQ0KfVC3 j9O07W0UTM; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: syslog@ietf.org Subject: Re: [Syslog] FW: DISCUSS: 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi Dave, > Would a registered port be adequate for syslog/tls, or is there a > compelling reason why it MUST be a system port? > The system port mechanism is largely an artifact of a different age, which would today be based on a flawed assumption that the other ports somehow don't need protection from local processes. Whether they do or not is strictly an implementation matter and not really within this organization's purview. In other words, there's probably a compelling reason that the system port distinction be dropped entirely, and hence no need or desire for its use in this specific case. Eliot _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Aug 13 07:03: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 B46773A6982; Wed, 13 Aug 2008 07:03: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 6B05A3A6982 for ; Wed, 13 Aug 2008 07:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BJSvvKHgdbT for ; Wed, 13 Aug 2008 07:03:35 -0700 (PDT) Received: from mailin.adiscon.com (hetzner.adiscon.com [85.10.198.18]) by core3.amsl.com (Postfix) with ESMTP id 7BA3F3A68C7 for ; Wed, 13 Aug 2008 07:03:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailin.adiscon.com (Postfix) with ESMTP id 565ED7AF006; Wed, 13 Aug 2008 15:59:29 +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 eu3-pulvQxqe; Wed, 13 Aug 2008 15:59:29 +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 82C3D7AD0B7; Wed, 13 Aug 2008 15:59:28 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 13 Aug 2008 16:03:02 +0200 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44EFCC@grfint2.intern.adiscon.com> In-Reply-To: <060e01c8fd49$b32fe6c0$0600a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] FW: DISCUSS: draft-ietf-syslog-transport-tls Thread-Index: Acj9EVwC/jFMEsaoTZqG+sA/XtQGgAAN8SbAAAD4LkA= References: <060e01c8fd49$b32fe6c0$0600a8c0@china.huawei.com> From: "Rainer Gerhards" To: "David Harrington" , Subject: Re: [Syslog] FW: DISCUSS: 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 You may cast it as vote for "registered port is adequate" but... what is " compelling reason why it MUST be a system port?" What is this for other protocols? Why, for example, must http run over port 80 and not some other port? IMHO it would work equally well if any other port were used... Rainer > -----Original Message----- > From: syslog-bounces@ietf.org [mailto:syslog-bounces@ietf.org] On > Behalf Of David Harrington > Sent: Wednesday, August 13, 2008 3:37 PM > To: syslog@ietf.org > Subject: [Syslog] FW: DISCUSS: draft-ietf-syslog-transport-tls > > Hi, > > There is a question of whether we need a system port or just a > registered port. > > As co-chair, I think the WG should be involved in this discussion. > The document is scheduled to be discussed by the IESG on Thursday, so > quick responses are important. > > Would a registered port be adequate for syslog/tls, or is there a > compelling reason why it MUST be a system port? > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: Wednesday, August 13, 2008 2:53 AM > To: ext Joseph Salowey (jsalowey) > Subject: Re: DISCUSS: draft-ietf-syslog-transport-tls > > Hi, > > On 2008-8-13, at 9:05, ext Joseph Salowey (jsalowey) wrote: > > This was discussed in the working group. The following is a list of > > reasons that were given in support of a system port (somewhat > > paraphrased): > > > > 1. We expect syslog-tls to become widespread adopted (if we would > not > > expect this, we could simply drop the effort - this is why the WG > has > > been rechartered). > > Sure, but widely adopted != needs a port < 1024. Lots of widely- > adopted protocols use a registered port in the 1024-49151 range. > > > 2. Syslog traditionally has been assigned a dedicated port in the > > system > > range (514 and 601). > > > > 3. Syslog was considered important enough to assign a dedicated port > > > in > > the past (601 with RFC 3195) - the same should apply to this effort > > We've been continuing to run out of system port space since those > ports were allocated. If there is no technical reason for a low port > number, I'd like to push back a bit on historic consistency as an > argument. > > > 4. The syslog daemon is considered an essential system service and > > part > > of many important operating systems > > True, but see my answer to 1. > > > 5. Operators expect a dedicated port for an essential protocol > > > > 6. A dedicated port greatly reduces the likelihood of syslogd > startup > > errors due to port being used by another process > > > > 7. A dedicated port greatly reduces ambiguity, which is especially > > important as a number of SOHO deceives/applications is expected to > > implement the protocol. For low-knowledge, "nearly plug-and-play" > > scenarios, senders and receivers need a universal understanding of > the > > port number to use. > > As for 5-7, syslog will get a dedicated port, but in the 1024-49151 > range instead of one < 1024. > > > 8. (derived argument) Combining argument #1 and #4, there will be a > > very large number of systems utilizing that port, thus justifying > > assigning a scarce resource. > > > > I think these arguments are convincing, but I am unsure as to the > > criteria for assigning a system port. > > draft-ietf-tsvwg-iana-ports has some text on this. > > Basically, the difference between the well-known and registered port > ranges has been diminishing to the point where it has become > irrelevant. For example, on a few operating systems, only root can > bind to well known ports. This is not a security feature, quite the > opposite - most system daemons only become root to bind to the port > and then drop privileges to run as a regular user and sometimes even > in a sandbox, as to not become an attack vector. If they used a > registered port, they'd not even need to jump through these hoops. > > Al that said, I agree that this change in IANA policy hasn't been > widely communicated and the corresponding document hasn't gotten IETF > > consensus yet. If the WG and the rest of the IETF thinks that we > shouldn't strictly apply it for this reason at this time, I can live > with that and will clear the DISCUSS on the call Thursday. (There are > > only around 200 system ports left, however, so at some point we do > need to start raising the bar.) > > Lars > > _______________________________________________ > 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 Aug 13 11:00:23 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 816CA3A6C1D; Wed, 13 Aug 2008 11:00:23 -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 456D73A683E for ; Wed, 13 Aug 2008 11:00:22 -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 OgHdEPF8Yytc for ; Wed, 13 Aug 2008 11:00:21 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 38F903A6A01 for ; Wed, 13 Aug 2008 11:00:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,202,1217808000"; d="scan'208";a="19893671" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 13 Aug 2008 18:00:18 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m7DI0IDR017867 for ; Wed, 13 Aug 2008 11:00:18 -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 m7DI0I1p002574 for ; Wed, 13 Aug 2008 18:00:18 GMT Date: Wed, 13 Aug 2008 11:00:17 -0700 (PDT) From: Chris Lonvick To: syslog@ietf.org In-Reply-To: <060e01c8fd49$b32fe6c0$0600a8c0@china.huawei.com> Message-ID: References: <060e01c8fd49$b32fe6c0$0600a8c0@china.huawei.com> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4330; t=1218650418; x=1219514418; 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:=20URGENT=3A=20-=20Re=3A=20FW=3A=20DISCUSS=3A=20dr aft-ietf-syslog-transport-tls=20 |Sender:=20; bh=6w9/5dXuNInjxcTsT0l9uzBAOh0ybRN7Lm9eON0UKUs=; b=0m+wu8x4VqFRssE6V4Y2i1PpXobHHICOccSmw2fu/bAq4bgy/2GsXrkAUr Pm6WHhU4kBTfcebbCIsepZZcQRs+WrgPmTZzdUwdP1gAhxI5Yon+ClAMSDeP 9QlOWn+nrc; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Syslog] URGENT: - Re: FW: DISCUSS: 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi Folks, We have two people who have said that we don't need a system port. I'd like to have an answer back to the IESG later today (Wednesday) so they can move forward with it tomorrow (Thursday telechat). If we don't hear anything else back we'll assume that's the consensus of the WG. Many thanks, Chris On Wed, 13 Aug 2008, David Harrington wrote: > Hi, > > There is a question of whether we need a system port or just a > registered port. > > As co-chair, I think the WG should be involved in this discussion. > The document is scheduled to be discussed by the IESG on Thursday, so > quick responses are important. > > Would a registered port be adequate for syslog/tls, or is there a > compelling reason why it MUST be a system port? > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > dharrington@huawei.com > > > -----Original Message----- > From: Lars Eggert [mailto:lars.eggert@nokia.com] > Sent: Wednesday, August 13, 2008 2:53 AM > To: ext Joseph Salowey (jsalowey) > Subject: Re: DISCUSS: draft-ietf-syslog-transport-tls > > Hi, > > On 2008-8-13, at 9:05, ext Joseph Salowey (jsalowey) wrote: >> This was discussed in the working group. The following is a list of >> reasons that were given in support of a system port (somewhat >> paraphrased): >> >> 1. We expect syslog-tls to become widespread adopted (if we would > not >> expect this, we could simply drop the effort - this is why the WG > has >> been rechartered). > > Sure, but widely adopted != needs a port < 1024. Lots of widely- > adopted protocols use a registered port in the 1024-49151 range. > >> 2. Syslog traditionally has been assigned a dedicated port in the >> system >> range (514 and 601). >> >> 3. Syslog was considered important enough to assign a dedicated port > >> in >> the past (601 with RFC 3195) - the same should apply to this effort > > We've been continuing to run out of system port space since those > ports were allocated. If there is no technical reason for a low port > number, I'd like to push back a bit on historic consistency as an > argument. > >> 4. The syslog daemon is considered an essential system service and >> part >> of many important operating systems > > True, but see my answer to 1. > >> 5. Operators expect a dedicated port for an essential protocol >> >> 6. A dedicated port greatly reduces the likelihood of syslogd > startup >> errors due to port being used by another process >> >> 7. A dedicated port greatly reduces ambiguity, which is especially >> important as a number of SOHO deceives/applications is expected to >> implement the protocol. For low-knowledge, "nearly plug-and-play" >> scenarios, senders and receivers need a universal understanding of > the >> port number to use. > > As for 5-7, syslog will get a dedicated port, but in the 1024-49151 > range instead of one < 1024. > >> 8. (derived argument) Combining argument #1 and #4, there will be a >> very large number of systems utilizing that port, thus justifying >> assigning a scarce resource. >> >> I think these arguments are convincing, but I am unsure as to the >> criteria for assigning a system port. > > draft-ietf-tsvwg-iana-ports has some text on this. > > Basically, the difference between the well-known and registered port > ranges has been diminishing to the point where it has become > irrelevant. For example, on a few operating systems, only root can > bind to well known ports. This is not a security feature, quite the > opposite - most system daemons only become root to bind to the port > and then drop privileges to run as a regular user and sometimes even > in a sandbox, as to not become an attack vector. If they used a > registered port, they'd not even need to jump through these hoops. > > Al that said, I agree that this change in IANA policy hasn't been > widely communicated and the corresponding document hasn't gotten IETF > > consensus yet. If the WG and the rest of the IETF thinks that we > shouldn't strictly apply it for this reason at this time, I can live > with that and will clear the DISCUSS on the call Thursday. (There are > > only around 200 system ports left, however, so at some point we do > need to start raising the bar.) > > Lars > > _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Aug 13 12:09:05 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 0610F3A6C21; Wed, 13 Aug 2008 12:09:05 -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 71EAE3A6CA3 for ; Wed, 13 Aug 2008 12:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_SORBS_WEB=0.619] 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 44kqPJG1MUDv for ; Wed, 13 Aug 2008 12:09:02 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by core3.amsl.com (Postfix) with ESMTP id A3C9C3A6C21 for ; Wed, 13 Aug 2008 12:09:02 -0700 (PDT) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 547D41218514; Wed, 13 Aug 2008 12:09:03 -0700 (PDT) Received: from jtop.corp.pgp.com ([64.1.215.241]) by keys.merrymeet.com (PGP Universal service); Wed, 13 Aug 2008 12:09:00 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 13 Aug 2008 12:09:00 -0700 Message-Id: From: Jon Callas To: Eliot Lear In-Reply-To: <48A2E6EC.5030404@cisco.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 13 Aug 2008 12:08:55 -0700 References: <060e01c8fd49$b32fe6c0$0600a8c0@china.huawei.com> <48A2E6EC.5030404@cisco.com> X-Mailer: Apple Mail (2.928.1) Cc: syslog@ietf.org Subject: Re: [Syslog] FW: DISCUSS: 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org I agree with Eliot. The idea of system ports is a quaint artifact of a bygone era. In the days of timesharing, when you'd have 100 lusers on your box, you didn't want one of the darlings to bind to port 25 (e.g.). These days, however, it causes as many problems as it might solve. A box tends to have one user, or it's a server with a collection of cooperating processes. So if a user-level process wants to bind to port 25, it has to have root privs when it would not have to ordinarily. Other systems, like a web server, have hoops to jump through to de-root themselves. So no, we don't need a system port. Getting one is as likely to cause problems as cure them. And the very concept should go away. Jon _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Thu Aug 14 00:32: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 3220128C0EC; Thu, 14 Aug 2008 00:32: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 3B8613A6851 for ; Thu, 14 Aug 2008 00:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.485 X-Spam-Level: * X-Spam-Status: No, score=1.485 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] 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 6ahc3Eqi2vpC for ; Thu, 14 Aug 2008 00:32:02 -0700 (PDT) Received: from lists.balabit.hu (support.balabit.hu [195.70.41.86]) by core3.amsl.com (Postfix) with ESMTP id 6575B3A69A3 for ; Thu, 14 Aug 2008 00:32:01 -0700 (PDT) Received: from balabit.hu (unknown [10.80.0.254]) by lists.balabit.hu (Postfix) with ESMTP id 03E4239D35B for ; Thu, 14 Aug 2008 09:32:03 +0200 (CEST) From: Balazs Scheidler To: Chris Lonvick In-Reply-To: References: <060e01c8fd49$b32fe6c0$0600a8c0@china.huawei.com> Date: Thu, 14 Aug 2008 09:31:59 +0200 Message-Id: <1218699119.11653.5.camel@bzorp.balabit> Mime-Version: 1.0 Cc: syslog@ietf.org Subject: Re: [Syslog] URGENT: - Re: FW: DISCUSS: 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 On Wed, 2008-08-13 at 11:00 -0700, Chris Lonvick wrote: > Hi Folks, > > We have two people who have said that we don't need a system port. I'd > like to have an answer back to the IESG later today (Wednesday) so they > can move forward with it tomorrow (Thursday telechat). If we don't hear > anything else back we'll assume that's the consensus of the WG. > I agree too. Having a registered port is enough. logservers are usually dedicated boxes anyway, so the chances of a collision is low. Also, the logserver process starts early in the boot process, so clients running on the same box will most probably find the port already taken. PS: any chance the port allocation can happen in a few weeks? we're about to release a syslog-ng version that supports syslog-protocol and I would like to use the final port right from the start instead of having to change it later. -- Bazsi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Fri Aug 15 04:10:23 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 2719028C1CC; Fri, 15 Aug 2008 04:10:23 -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 3202F3A6CDA for ; Fri, 15 Aug 2008 04:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_40=-0.185] 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 3I13lpQ5kyi4 for ; Fri, 15 Aug 2008 04:10:21 -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 193AC3A6930 for ; Fri, 15 Aug 2008 04:10:20 -0700 (PDT) X-Trace: 69721902/mk-outboundfilter-5.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.60.221 X-SBRS: None X-RemoteIP: 213.116.60.221 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AswEAG8ApUjVdDzd/2dsb2JhbACDRDeHdadGA4FT X-IronPort-AV: E=Sophos;i="4.32,214,1217804400"; d="scan'208";a="69721902" X-IP-Direction: IN Received: from 1cust221.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.221]) by smtp.pipex.tiscali.co.uk with SMTP; 15 Aug 2008 12:09:23 +0100 Message-ID: <019f01c8febe$17620400$0601a8c0@allison> From: "tom.petch" To: "Joseph Salowey \(jsalowey\)" , "syslog" References: <000801c8fd14$1e06e240$0601a8c0@allison> Date: Fri, 15 Aug 2008 10:58:17 +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] Use of system port vs. regular port 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 Late as ever :-(, as well as the discussion on the syslog list I alluded to there was also a lengthy discussion about this towards the end of March 2006 on the main IETF list. Netconf also debated it around that time. Tom Petch ----- Original Message ----- From: "tom.petch" To: "Joseph Salowey (jsalowey)" ; Sent: Tuesday, August 12, 2008 7:08 PM Subject: Re: [Syslog] Use of system port vs. regular port > ----- Original Message ----- > From: "Joseph Salowey (jsalowey)" > To: > Sent: Tuesday, August 12, 2008 6:08 PM > Subject: [Syslog] Use of system port vs. regular port > > > > Lars Eggert has entered a DISCUSS on draft-ietf-syslog-transport-tls > > asking > > > > "What is the justification for allocating a system port? Why wouldn't a > > registered port suffice? > > (Note that IANA is changing procedures such that system ports are > > becoming more difficult to obtain, because we're running out of them.)" > > > > Is there a reason why we require a system port? Was this discussed > > previously? Would a registered port be acceptable? > > > See > > [Syslog] Other syslog-tls Issues---Issue0 > 20 March 2006 > > This was then incorporated in > > draft-ietf-syslog-transport-tls-02.txt > > Tom Petch > > > Thanks, > > > > Joe > > _______________________________________________ > > 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 Aug 15 07:05:57 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 5CC703A6DCA; Fri, 15 Aug 2008 07:05:57 -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 143983A68A0 for ; Fri, 15 Aug 2008 07:05:56 -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 bKshLKuZr6ss for ; Fri, 15 Aug 2008 07:05:55 -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 D30083A67AB for ; Fri, 15 Aug 2008 07:05:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,216,1217808000"; d="scan'208";a="66121532" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 15 Aug 2008 14:05:06 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m7FE56xs004497 for ; Fri, 15 Aug 2008 07:05:06 -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 m7FE566V024360 for ; Fri, 15 Aug 2008 14:05:06 GMT Date: Fri, 15 Aug 2008 07:05:05 -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=1407; t=1218809106; x=1219673106; 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:=20ID=20Tracker=20State=20Update=20Notice=3A=20dra ft-ietf-syslog-transport-tls=0A=20(fwd) |Sender:=20; bh=XEH129QX62q9B1yVqSpczQfFy6hGml9SzdpnmC39UNY=; b=bKIMvc5qEeBYJGVOAfNBjVGmnbg4fv+l4KSOLThwquWLus1hnhTCbl1qaW aAb1Cgbnd0Ud1gq1D6F1wc6TdjYpe1HEDwHyp5rlIML6MCOKS6Np+fi4KbP+ gX4vt/pqq/vGKxrPp02Ps5pcrUWjSB0p5Bs5IIplcFPAi6m0S7fW4=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Syslog] ID Tracker State Update Notice: draft-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi Folks, ---------- Forwarded message ---------- Date: Thu, 14 Aug 2008 11:49:05 -0700 (PDT) From: The IESG Reply-To: ietf-secretariat-reply@ietf.org To: syslog-chairs@tools.ietf.org Subject: ID Tracker State Update Notice: draft-ietf-syslog-transport-tls 'State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14551&rfc_flag=0 ---------- Forwarded message ---------- It looks like the telechat is over and we have some DISCUSSes and COMMENTs to clear before the document becomes an RFC. The real meat is here: https://datatracker.ietf.org/idtracker/ballot/2334/ We've already cleared the issue about a system port v. a registered port. (The IESG is now debating the distinction between system and registered ports but that's clearly outside of our discussion in this WG.) We can easily clear Tim Polk's COMMENT https://datatracker.ietf.org/idtracker/draft-ietf-syslog-transport-tls/comment/84805/? (I've reviewed and agree and would like a second on this.) Joe is looking at the other issues raised by Chris Newman. https://datatracker.ietf.org/idtracker/draft-ietf-syslog-transport-tls/comment/84852/? He'll likely have some answers early next week. Please provide input on this to the list. Thanks, Chris _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Sat Aug 16 14:10: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 5EB843A6A80; Sat, 16 Aug 2008 14:10: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 CB1A63A6806 for ; Sat, 16 Aug 2008 14:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.073 X-Spam-Level: X-Spam-Status: No, score=0.073 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_40=-0.185] 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 MuZnTzKRaPTs for ; Sat, 16 Aug 2008 14:10:42 -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 AE9523A6A80 for ; Sat, 16 Aug 2008 14:10:41 -0700 (PDT) X-Trace: 14926079/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.138.43 X-SBRS: None X-RemoteIP: 62.188.138.43 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAEPfpkg+vIor/2dsb2JhbACDRDiHcqZVA4FV X-IronPort-AV: E=Sophos;i="4.32,222,1217804400"; d="scan'208";a="14926079" X-IP-Direction: IN Received: from 1cust43.tnt9.lnd4.gbr.da.uu.net (HELO allison) ([62.188.138.43]) by smtp.pipex.tiscali.co.uk with SMTP; 16 Aug 2008 22:10:42 +0100 Message-ID: <005f01c8ffdb$41c04720$0601a8c0@allison> From: "tom.petch" To: "Chris Lonvick" , References: Date: Sat, 16 Aug 2008 22:04:08 +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] ID Tracker State Update Notice: draft-ietf-syslog-transport-tls (fwd) 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 I note that draft-hodges-server-ident-check to which we are invited to contribute and from which we are invited to copy is A) expird B) gives no indication of where it might be discussed; the only thing I am sure of is that it won't be the TLS list since they have refused to take on such work - sigh. Tom Petch ----- Original Message ----- From: "Chris Lonvick" To: Sent: Friday, August 15, 2008 4:05 PM Subject: [Syslog] ID Tracker State Update Notice: draft-ietf-syslog-transport-tls (fwd) > Hi Folks, > > ---------- Forwarded message ---------- > Date: Thu, 14 Aug 2008 11:49:05 -0700 (PDT) > From: The IESG > Reply-To: ietf-secretariat-reply@ietf.org > To: syslog-chairs@tools.ietf.org > Subject: ID Tracker State Update Notice: draft-ietf-syslog-transport-tls > > 'State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan' > ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14551&rf c_flag=0 > ---------- Forwarded message ---------- > > It looks like the telechat is over and we have some DISCUSSes and COMMENTs > to clear before the document becomes an RFC. The real meat is here: > https://datatracker.ietf.org/idtracker/ballot/2334/ > > We've already cleared the issue about a system port v. a registered port. > (The IESG is now debating the distinction between system and registered > ports but that's clearly outside of our discussion in this WG.) > > We can easily clear Tim Polk's COMMENT > https://datatracker.ietf.org/idtracker/draft-ietf-syslog-transport-tls/comment/8 4805/? > (I've reviewed and agree and would like a second on this.) > > Joe is looking at the other issues raised by Chris Newman. > https://datatracker.ietf.org/idtracker/draft-ietf-syslog-transport-tls/comment/8 4852/? > He'll likely have some answers early next week. Please provide input on > this to the list. > > 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 Mon Aug 18 07:02: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 E7DA93A6C2C; Mon, 18 Aug 2008 07:02: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 35C4C3A6AE4 for ; Mon, 18 Aug 2008 07:02:04 -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 Kj7bH2J-OklJ for ; Mon, 18 Aug 2008 07:02:03 -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 2D4073A69B8 for ; Mon, 18 Aug 2008 07:01:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,228,1217808000"; d="scan'208";a="141391565" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 18 Aug 2008 14:00:57 +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 m7IE0vS9000424; Mon, 18 Aug 2008 07:00:57 -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 m7IE0vlh006262; Mon, 18 Aug 2008 14:00:57 GMT Date: Mon, 18 Aug 2008 07:00:57 -0700 (PDT) From: Chris Lonvick To: "tom.petch" In-Reply-To: <005f01c8ffdb$41c04720$0601a8c0@allison> Message-ID: References: <005f01c8ffdb$41c04720$0601a8c0@allison> MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2932; t=1219068057; x=1219932057; 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]=20ID=20Tracker=20State=20Updat e=20Notice=3A=20draft-ietf-syslog-transport-tls=0A=20(fwd) |Sender:=20; bh=DIWbJgr397ENHnIGVulVsYoEB5FvMQFpRVa5v+imt2g=; b=jnUw72fToKxA+IjE09f+u8S5vuiFAiQeewHE/CgsIpGvk6TOmlc+H6f3a1 QCI4cvfGoza1Gkk5H342eRQfUpqTAgpA3E9MA7m4TjT7wPv7S9Hs530V8QGc /V3FnM7q4Wae3Nlgs5RsHXKaKHkeGkQ1UrirHp4xJwgLv3qZ6rrB8=; 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] ID Tracker State Update Notice: draft-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: syslog-bounces@ietf.org Errors-To: syslog-bounces@ietf.org Hi Tom, I forgot to mention about draft-hodges-server-ident-check. It may be accessed here: http://tools.ietf.org/html/draft-hodges-server-ident-check-00 (I'm guessing that you already found that so I'm sending this along to those who want to take a look.) Chris Newman is working with the authors to get it revised and back in the system. You can send a note to him saying that it lacks a discussion forum. We will NOT be referencing this document as it has expired. I'll let Joe see about cutting good text and pasting it into the syslog/tls document to address Chris Newman's DISCUSS. Thanks, Chris On Sat, 16 Aug 2008, tom.petch wrote: > I note that > draft-hodges-server-ident-check > to which we are invited to contribute and from which we are invited to copy is > A) expird > B) gives no indication of where it might be discussed; the only thing I am sure > of is that it won't be the TLS list since they have refused to take on such > work - sigh. > > Tom Petch > > > ----- Original Message ----- > From: "Chris Lonvick" > To: > Sent: Friday, August 15, 2008 4:05 PM > Subject: [Syslog] ID Tracker State Update Notice: > draft-ietf-syslog-transport-tls (fwd) > > >> Hi Folks, >> >> ---------- Forwarded message ---------- >> Date: Thu, 14 Aug 2008 11:49:05 -0700 (PDT) >> From: The IESG >> Reply-To: ietf-secretariat-reply@ietf.org >> To: syslog-chairs@tools.ietf.org >> Subject: ID Tracker State Update Notice: draft-ietf-syslog-transport-tls >> >> 'State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by > Cindy Morgan' >> ID Tracker URL: > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14551&rf > c_flag=0 >> ---------- Forwarded message ---------- >> >> It looks like the telechat is over and we have some DISCUSSes and COMMENTs >> to clear before the document becomes an RFC. The real meat is here: >> https://datatracker.ietf.org/idtracker/ballot/2334/ >> >> We've already cleared the issue about a system port v. a registered port. >> (The IESG is now debating the distinction between system and registered >> ports but that's clearly outside of our discussion in this WG.) >> >> We can easily clear Tim Polk's COMMENT >> > https://datatracker.ietf.org/idtracker/draft-ietf-syslog-transport-tls/comment/8 > 4805/? >> (I've reviewed and agree and would like a second on this.) >> >> Joe is looking at the other issues raised by Chris Newman. >> > https://datatracker.ietf.org/idtracker/draft-ietf-syslog-transport-tls/comment/8 > 4852/? >> He'll likely have some answers early next week. Please provide input on >> this to the list. >> >> 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 Mon Aug 18 11:28:33 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 D07FF3A6D6C; Mon, 18 Aug 2008 11:28:33 -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 8B43D3A6D14; Mon, 18 Aug 2008 11:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.517, 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 4NTwv6eA5LfQ; Mon, 18 Aug 2008 11:28:31 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 3FBEF3A6B06; Mon, 18 Aug 2008 11:28:31 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m7IISZX3007752; Mon, 18 Aug 2008 21:28:35 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 21:28:34 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 18 Aug 2008 21:28:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Aug 2008 21:28:31 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720161CBBF@vaebe104.NOE.Nokia.com> In-Reply-To: <20080814045926.40FA13A6955@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DISCUSS and COMMENT: draft-ietf-syslog-transport-tls Thread-Index: Acj9yo4LcllrEx6dR9aY8OnOAcDkMQDkdO7Q References: <20080814045926.40FA13A6955@core3.amsl.com> From: To: , X-OriginalArrivalTime: 18 Aug 2008 18:28:32.0494 (UTC) FILETIME=[380268E0:01C90160] X-Nokia-AV: Clean Cc: syslog@ietf.org Subject: Re: [Syslog] DISCUSS and COMMENT: 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 Chris Newman wrote: > > Discuss: > This document does not discuss how to support IDN in domain names > for identity checking as required by BCP 18. I recommend copying > or referencing: > draft-hodges-server-ident-check-00 > for text on that topic. Supporting IDNs in certificates and their verification is already extensively discussed in RFC 5280, Section 7. Do you think something important is missing from there? > The current text related to wildcards could create interopreability > problems. It is not clear if wildcards are permitted in the middle > of domain names and what their meaning would be in that context. > I also believe system operators who spend the money to purchase a > wildcard certificate (which some CAs charge extra to produce) would > be extremely unhappy if they could not use their purchase with syslog > software. For interoperability and least astonishment purposes, > shouldn't wildcard matching be mandatory-to-implement? (It's fine > if it can be disabled by policy or is off-by-default). This is a tricky question, but with two different parts. The current text says implementations MAY support wildcards in the *locally* configured name (the "reference identity" in draft-hodges-server-ident-check terminology). This "MAY" was intentional, I think -- this is mostly a local implementation detail, since the other end doesn't know wildcards are being used. Some implementations might support simple wildcards, others regular expressions, etc. The text doesn't say anything about wildcards in certificates, though. It probably needs to, and whatever is said needs to be mandatory-to-implement. Do you have suggestion what that text should say? (I've understood that e.g. none of the most common web browsers do exactly what RFC 2818 says, and no two of them behave identically.) > The current text does not discuss how to compare IP addresses in an > interoperable fashion. I recommend referencing or copying text from: > draft-hodges-server-ident-check-00 I think RFC 5280 specifies all the necessary certificate processing for IP addresses. > Question: did the WG consider creating (or reusing) an IANA registry > for hash function ASCII names? In the event fingerprints algorithms > other than "SHA1" become useful in the future it would be helpful > to have such a registry for interoperability. Hmm... I took a look at the IANA pages, and found an existing registry, created in RFC 4572, that might work: http://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml > Comment: > I find it to be bad design that every time we bind TLS to a > particular protocol we have to duplicate lots of text about server > identity checks, domain name matching, etc. Often these texts vary > slightly in ways that are unimportant to the underlying problem but > will cause operator/administrator consternation for no technical > benefit. > > This particular instantiation has some very good text about > certificate handling that probably belongs in all the other > instances of this problem, so I would strongly encourage the authors > to contribute to > draft-hodges-server-ident-check I agree that having such a document would be a very good idea. > One thing that could be added to the certificate handling text to > improve it further is a requirement to support importing new trust > anchors and/or removing or disabling any built-in trust anchors. This would probably belong in draft-hodges-server-ident-check; I don't recall seeing this kind of text in any other protocol using TLS. Best regards, Pasi _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Tue Aug 19 05:56:39 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 0D0BA3A6B3C; Tue, 19 Aug 2008 05:56:39 -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 9822F3A6B33; Tue, 19 Aug 2008 05:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_15=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 B3fEs-HJYTUP; Tue, 19 Aug 2008 05:56:36 -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 B98553A6AEF; Tue, 19 Aug 2008 05:56:35 -0700 (PDT) X-Trace: 125530892/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.131.217 X-SBRS: None X-RemoteIP: 62.188.131.217 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAPtfqkg+vIPZ/2dsb2JhbACDRDiHcqknA4FV X-IronPort-AV: E=Sophos;i="4.32,235,1217804400"; d="scan'208";a="125530892" X-IP-Direction: IN Received: from 1cust217.tnt2.lnd4.gbr.da.uu.net (HELO allison) ([62.188.131.217]) by smtp.pipex.tiscali.co.uk with SMTP; 19 Aug 2008 13:56:28 +0100 Message-ID: <003401c901f1$b3d50cc0$0601a8c0@allison> From: "tom.petch" To: , , References: <20080814045926.40FA13A6955@core3.amsl.com> <1696498986EFEC4D9153717DA325CB720161CBBF@vaebe104.NOE.Nokia.com> Date: Tue, 19 Aug 2008 11:43:37 +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] DISCUSS and COMMENT: draft-ietf-syslog-transport-tls trust anchors 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 Picking up on the comment about trust anchors, probably the closest you get in current RFC is for COPS in RFC4261 Tom Petch ----- Original Message ----- From: To: ; Cc: Sent: Monday, August 18, 2008 8:28 PM Subject: Re: [Syslog] DISCUSS and COMMENT: draft-ietf-syslog-transport-tls > Chris Newman wrote: > > > > Discuss: > > This document does not discuss how to support IDN in domain names > > for identity checking as required by BCP 18. I recommend copying > > or referencing: > > draft-hodges-server-ident-check-00 > > for text on that topic. > > Supporting IDNs in certificates and their verification is already > extensively discussed in RFC 5280, Section 7. Do you think something > important is missing from there? > > > The current text related to wildcards could create interopreability > > problems. It is not clear if wildcards are permitted in the middle > > of domain names and what their meaning would be in that context. > > I also believe system operators who spend the money to purchase a > > wildcard certificate (which some CAs charge extra to produce) would > > be extremely unhappy if they could not use their purchase with syslog > > software. For interoperability and least astonishment purposes, > > shouldn't wildcard matching be mandatory-to-implement? (It's fine > > if it can be disabled by policy or is off-by-default). > > This is a tricky question, but with two different parts. > > The current text says implementations MAY support wildcards in > the *locally* configured name (the "reference identity" in > draft-hodges-server-ident-check terminology). This "MAY" was > intentional, I think -- this is mostly a local implementation > detail, since the other end doesn't know wildcards are being used. > Some implementations might support simple wildcards, others > regular expressions, etc. > > The text doesn't say anything about wildcards in certificates, > though. It probably needs to, and whatever is said needs to be > mandatory-to-implement. > > Do you have suggestion what that text should say? (I've understood > that e.g. none of the most common web browsers do exactly what RFC > 2818 says, and no two of them behave identically.) > > > The current text does not discuss how to compare IP addresses in an > > interoperable fashion. I recommend referencing or copying text from: > > draft-hodges-server-ident-check-00 > > I think RFC 5280 specifies all the necessary certificate processing > for IP addresses. > > > Question: did the WG consider creating (or reusing) an IANA registry > > for hash function ASCII names? In the event fingerprints algorithms > > other than "SHA1" become useful in the future it would be helpful > > to have such a registry for interoperability. > > Hmm... I took a look at the IANA pages, and found an existing > registry, created in RFC 4572, that might work: > > http://www.iana.org/assignments/hash-function-text-names/hash-function-text-name s.xhtml > > > Comment: > > > I find it to be bad design that every time we bind TLS to a > > particular protocol we have to duplicate lots of text about server > > identity checks, domain name matching, etc. Often these texts vary > > slightly in ways that are unimportant to the underlying problem but > > will cause operator/administrator consternation for no technical > > benefit. > > > > This particular instantiation has some very good text about > > certificate handling that probably belongs in all the other > > instances of this problem, so I would strongly encourage the authors > > to contribute to > > draft-hodges-server-ident-check > > I agree that having such a document would be a very good idea. > > > One thing that could be added to the certificate handling text to > > improve it further is a requirement to support importing new trust > > anchors and/or removing or disabling any built-in trust anchors. > > This would probably belong in draft-hodges-server-ident-check; > I don't recall seeing this kind of text in any other protocol > using TLS. > > 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 Wed Aug 27 15:47: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 4459528C27D; Wed, 27 Aug 2008 15:47: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 46CEA28C25D for ; Wed, 27 Aug 2008 15:47:24 -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 VlwQBjKPLR9J for ; Wed, 27 Aug 2008 15:47:23 -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 A943628C272 for ; Wed, 27 Aug 2008 15:47:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,282,1217808000"; d="scan'208";a="70236163" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 27 Aug 2008 22:43:22 +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 m7RMhMaK024428 for ; Wed, 27 Aug 2008 15:43:22 -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 m7RMhMAK007179 for ; Wed, 27 Aug 2008 22:43:22 GMT Date: Wed, 27 Aug 2008 15:43:21 -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=4410; t=1219877002; x=1220741002; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=clonvick@cisco.com; z=From:=20Chris=20Lonvick=20 |Subject:=20Need=20your=20input=20on=20final=20issues=20on= 20draft-ietf-syslog-transport-tls |Sender:=20; bh=/S5UDFO4B3yAtWichgok7DXPZH74zxmqSNO4gLsbn1o=; b=no/0o+JSUZ0SHk+O6Phou07qP6tI+U1ofQ/LlVpYPP6V620tz7ZX7maZjr d8r10K1+6k8dSX9vSR8cD47veae+5TkyICoHpEWcerVb8ikEiZuPU0G1tUBJ x0YjPd/ei+; Authentication-Results: sj-dkim-4; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [Syslog] 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 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 From syslog-bounces@ietf.org Wed Aug 27 22:04: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 2D7AE3A6897; Wed, 27 Aug 2008 22:04: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 155513A683E for ; Wed, 27 Aug 2008 22:04:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 cevxh6+ZsXe3 for ; Wed, 27 Aug 2008 22:04:23 -0700 (PDT) Received: from mail.asta.uni-potsdam.de (mail.asta.uni-potsdam.de [141.89.58.198]) by core3.amsl.com (Postfix) with ESMTP id 4C6BE3A6897 for ; Wed, 27 Aug 2008 22:04:23 -0700 (PDT) Received: from localhost (mail.asta.uni-potsdam.de [141.89.58.198]) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 197D8D30E0 for ; Thu, 28 Aug 2008 07:04:17 +0200 (CEST) X-Virus-Scanned: on mail at asta.uni-potsdam.de Received: from mail.asta.uni-potsdam.de ([141.89.58.198]) by localhost (mail.asta.uni-potsdam.de [141.89.58.198]) (amavisd-new, port 10024) with ESMTP id FBSkfbCOsgZP for ; Thu, 28 Aug 2008 07:04:04 +0200 (CEST) Received: from cordelia.mschuette.name (BAA05b4.baa.pppool.de [77.128.5.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Martin Schuette", Issuer "AStA-CA" (verified OK)) by mail.asta.uni-potsdam.de (Postfix) with ESMTP id 58925D30E4 for ; Thu, 28 Aug 2008 07:04:02 +0200 (CEST) Message-ID: <48B631D1.4050206@mschuette.name> Date: Thu, 28 Aug 2008 07:04:17 +0200 From: =?ISO-8859-1?Q?Martin_Sch=FCtte?= User-Agent: Thunderbird 2.0.0.16 (X11/20080814) MIME-Version: 1.0 To: syslog@ietf.org References: In-Reply-To: Subject: Re: [Syslog] 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 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: > === 1 === > 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? -- Martin _______________________________________________ Syslog mailing list Syslog@ietf.org https://www.ietf.org/mailman/listinfo/syslog From syslog-bounces@ietf.org Wed Aug 27 22:58:56 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 ADEFA3A6996; Wed, 27 Aug 2008 22:58:56 -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 F1F4D3A6879 for ; Wed, 27 Aug 2008 22:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 BQ2RIVbJC-wO for ; Wed, 27 Aug 2008 22:58:55 -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 19C8A3A6996 for ; Wed, 27 Aug 2008 22:58:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,284,1217808000"; d="scan'208";a="148068704" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Aug 2008 05:58:36 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m7S5waNA026204; Wed, 27 Aug 2008 22:58:36 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m7S5wa3P029207; Thu, 28 Aug 2008 05:58:36 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); Wed, 27 Aug 2008 22:58:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 22:58:44 -0700 Message-ID: In-Reply-To: <48B631D1.4050206@mschuette.name> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Syslog] Need your input on final issueson draft-ietf-syslog-transport-tls thread-index: AckIy47NvV7xzenQQDKNc41GXr+xoAABwRNQ References: <48B631D1.4050206@mschuette.name> From: "Joseph Salowey (jsalowey)" To: =?iso-8859-1?Q?Martin_Sch=FCtte?= , X-OriginalArrivalTime: 28 Aug 2008 05:58:36.0433 (UTC) FILETIME=[1C65E010:01C908D3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1267; t=1219903116; x=1220767116; 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=20input=20on=20f inal=20issueson=09draft-ietf-syslog-transport-tls |Sender:=20; bh=hMNGswrIFilNNe+G1GjRWmPWdxyNTPonXqIAgndWquM=; b=p9Xftqde0Wq/ai/JWh4i5UikcbZkSUIJX8y8h3mLKo6A0Xf7n3UptSIFMR JMK/1iaCdqHwgdM3dI4LL/O++H4nayo9VY+0o5J1En51I93h1vhT/SqAIBrf F0viTEYhfq; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Syslog] Need your input on final issueson 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 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 wildca= rds to appear in certificates so it might be surprising for deployers if it= is not supported in Syslog TLS. = > = > -- > Martin > _______________________________________________ > 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 Aug 28 10:57: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 1777C3A6C9D; Thu, 28 Aug 2008 10:57: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 6FAD93A6CDC for ; Thu, 28 Aug 2008 10:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yzBvWge0zHG for ; Thu, 28 Aug 2008 10:57:55 -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 A2B363A6C9D for ; Thu, 28 Aug 2008 10:57:54 -0700 (PDT) X-Trace: 129201213/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.131.98 X-SBRS: None X-RemoteIP: 62.188.131.98 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAIaEtkg+vINi/2dsb2JhbACDR4hDrhQDgWc X-IronPort-AV: E=Sophos;i="4.32,287,1217804400"; d="scan'208";a="129201213" X-IP-Direction: IN Received: from 1cust98.tnt2.lnd4.gbr.da.uu.net (HELO allison) ([62.188.131.98]) by smtp.pipex.tiscali.co.uk with SMTP; 28 Aug 2008 18:57:40 +0100 Message-ID: <009201c9092e$3e587560$0601a8c0@allison> From: "tom.petch" To: "Chris Lonvick" , References: Date: Thu, 28 Aug 2008 18:15:48 +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 final issues ondraft-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 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 From syslog-bounces@ietf.org Sat Aug 30 06:58:29 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 291883A6AE2; Sat, 30 Aug 2008 06:58:29 -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 8DE953A6A30 for ; Sat, 30 Aug 2008 06:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[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 odXTv5Ysvklt for ; Sat, 30 Aug 2008 06:58:26 -0700 (PDT) Received: from QMTA07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by core3.amsl.com (Postfix) with ESMTP id C67C43A6ADA for ; Sat, 30 Aug 2008 06:58:26 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA07.emeryville.ca.mail.comcast.net with comcast id 8dSz1a01k1GXsucA7dyXxv; Sat, 30 Aug 2008 13:58:31 +0000 Received: from Harrington73653 ([207.190.254.69]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id 8dyJ1a0041WcgoF8TdyMoG; Sat, 30 Aug 2008 13:58:29 +0000 X-Authority-Analysis: v=1.0 c=1 a=YrOVumInG4oA:10 a=GfkeE8PIMVwA:10 a=48vgC7mUAAAA:8 a=ObcYAGGkTy_TgBLQHY0A:9 a=-abF-JMxH9fhq9mlhbep7shWywUA:4 a=lZB815dzVvQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: =?iso-8859-1?Q?'Martin_Sch=FCtte'?= , References: <48B631D1.4050206@mschuette.name> Date: Sat, 30 Aug 2008 09:58:17 -0400 Message-ID: <049001c90aa8$7ad0fd70$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <48B631D1.4050206@mschuette.name> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AckIy4zGr4KrGqgJRsaCsR72irgOeAB3HsTw Subject: Re: [Syslog] Need your input on final issueson 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 Hi, I am a little concerned by text that specifies mandatory or optional features without using the RFC2119 keywords. I would prefer tighter text that uses the RFC2119 keywords, throughout the document. Text like "is allowed" does not give clear enough directions to implementers of receivers versus senders; we need to be clear what "conservative what you send" means. dbh > -----Original Message----- > From: syslog-bounces@ietf.org = > [mailto:syslog-bounces@ietf.org] On Behalf Of Martin Sch=FCtte > Sent: Thursday, August 28, 2008 1:04 AM > 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? > = > = > -- = > Martin > _______________________________________________ > 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 Sat Aug 30 10:55:00 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 32BB128C0DD; Sat, 30 Aug 2008 10:55:00 -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 533E128C0E4 for ; Sat, 30 Aug 2008 10:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_05=-1.11] 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 PxPp+0chRqUR for ; Sat, 30 Aug 2008 10:54:58 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 6821728B56A for ; Sat, 30 Aug 2008 10:54:57 -0700 (PDT) X-Trace: 163848492/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-temporary-group/213.116.60.210 X-SBRS: None X-RemoteIP: 213.116.60.210 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIEABcmuUjVdDzS/2dsb2JhbACDRziIDKlnA4Fm X-IronPort-AV: E=Sophos;i="4.32,298,1217804400"; d="scan'208";a="163848492" X-IP-Direction: IN Received: from 1cust210.tnt106.lnd4.gbr.da.uu.net (HELO allison) ([213.116.60.210]) by smtp.pipex.tiscali.co.uk with SMTP; 30 Aug 2008 18:54:51 +0100 Message-ID: <003801c90ac0$2c1bfc80$0601a8c0@allison> From: "tom.petch" To: "Chris Lonvick" , References: <009201c9092e$3e587560$0601a8c0@allison> Date: Sat, 30 Aug 2008 18:43:00 +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 final issuesondraft-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 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. 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 ). 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. 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