From agentx-bounces@ietf.org Thu Jun 5 10:49:49 2008 Return-Path: X-Original-To: agentx-archive@megatron.ietf.org Delivered-To: ietfarch-agentx-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF1B63A6A61; Thu, 5 Jun 2008 10:49:49 -0700 (PDT) X-Original-To: agentx@core3.amsl.com Delivered-To: agentx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50EE93A6A2B; Thu, 5 Jun 2008 10:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 1s3fIbxABkh1; Thu, 5 Jun 2008 10:49:48 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 8880F28C158; Thu, 5 Jun 2008 10:46:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=r7opjOVoms4qRsmXNhEDxP5A+SNO8ppoOhEYWMjP3IU4d5F7mPwmpA8wghd+efYF; h=Received:Message-ID:From:To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.84.214] (helo=oemcomputer) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1K4JXy-00061U-2R; Thu, 05 Jun 2008 13:46:46 -0400 Message-ID: <001201c8c734$34c658a0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "LTRU Working Group" , "Disman" , Date: Thu, 5 Jun 2008 10:47:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3b442e1eafe600d0c8042303872afb414350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.84.214 Subject: [Agentx] Fw: Mailing List Filters X-BeenThere: agentx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SNMP Agent Extensibility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: agentx-bounces@ietf.org Errors-To: agentx-bounces@ietf.org Hi - As mailing list administrator for ltru, disman, and agentx, I'm forwarding this update on the handling of ietf.org mailing lists. Randy > From: "Alexa Morris" > To: > Cc: "ietf" > Sent: Thursday, June 05, 2008 8:03 AM > Subject: Mailing List Filters > > Several weeks ago, we removed some spam filtering rules from the IETF email > lists because there were concerns that, in a few very specific > circumstances, the rules were preventing legitimate mail from getting > through. Unfortunately, the removal of those spam rules has resulted in a > huge increase in spam sent to the lists, which has in turn greatly increased > the burden for all list moderators. > > Because of this, we are planning to reinstitute two of those spam rules on > Monday of next week. For the vast majority of you, this will not even be > noticeable. However, if after Monday of next week you begin to experience > difficulty when you try to send mail to the IETF -- either to the > Secretariat or to a mailing list -- we have created a form that will enable > you to report your problem (the form bypasses the spam filters). Once we > know that you are experiencing difficulty, we can create an exception that > will enable you to send email again. > > The form is accessible under the "IETF Secretariat" link from the home page, > at the bottom of the Secretariat contact page under "To Report Problems." A > direct link is here: http://www.ietf.org/contactform.html. > > If you are curious to know what spam rules we are reinstating on Monday, > they are: > > Rule A. This rule insists that, when a machine makes a HELO greeting, and > claims to be a certain machine, the name it claims exists in its appropriate > zone file, as either an "A" or an "MX" record. > > Rule B. This rule does a reverse lookup on the client's IP address, and > makes sure that we can identify it as being IN-REV'ed by someone. > > Please feel free to contact me if you have any questions or concerns. > > Regards, > Alexa > > ----------- > Alexa Morris / Executive Director / IETF > 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 > Phone: +1.510.492.4089 / Fax: +1.510.492.4001 > Email: amorris@amsl.com > > Managed by Association Management Solutions (AMS) > Forum Management, Meeting and Event Planning > www.amsl.com From agentx-bounces@ietf.org Fri Jun 13 07:53:27 2008 Return-Path: X-Original-To: agentx-archive@megatron.ietf.org Delivered-To: ietfarch-agentx-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40E443A698B; Fri, 13 Jun 2008 07:53:27 -0700 (PDT) X-Original-To: agentx@core3.amsl.com Delivered-To: agentx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D2403A697C for ; Fri, 13 Jun 2008 07:53:26 -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 DB+AU-j-lT4P for ; Fri, 13 Jun 2008 07:53:22 -0700 (PDT) Received: from mgkyb2.nw.wakwak.com (mgkyb2.nw.wakwak.com [211.9.231.193]) by core3.amsl.com (Postfix) with ESMTP id 4C1293A698B for ; Fri, 13 Jun 2008 07:53:22 -0700 (PDT) Received: from vckyb1.nw.wakwak.com (postfix@vckyb1.nw.wakwak.com [211.9.230.144]) by mgkyb2.nw.wakwak.com (8.14.2/8.14.2/2007-12-27) with SMTP id m5DEroPp082284 for ; Fri, 13 Jun 2008 23:53:51 +0900 (JST) (envelope-from wbenton@aa.aeonnet.ne.jp) Received: from aa.aeonnet.ne.jp (aa.aeonnet.ne.jp [211.9.230.92]) by vckyb1.nw.wakwak.com (Postfix) with ESMTP id 3A12230060 for ; Fri, 13 Jun 2008 23:53:50 +0900 (JST) Received: from aa.aeonnet.ne.jp (z206.58-98-120.ppp.wakwak.ne.jp [58.98.120.206]) (user=wbenton mech=CRAM-MD5)(pbs=7cj6hq) by aa.aeonnet.ne.jp (8.14.2/8.14.2/2007-12-26) with ESMTP/inet id m5DErnaj004894 for ; Fri, 13 Jun 2008 23:53:50 +0900 (JST) (envelope-from wbenton@aa.aeonnet.ne.jp) Message-ID: <48528A12.3020800@aa.aeonnet.ne.jp> Date: Fri, 13 Jun 2008 23:54:10 +0900 From: "wbenton@aa.aeonnet.ne.jp" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: agentx@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [Agentx] SNMP v3 Security Considerations X-BeenThere: agentx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SNMP Agent Extensibility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: agentx-bounces@ietf.org Errors-To: agentx-bounces@ietf.org After having read all of the latest RFC's concerning SNMP v3, I've notice that there is no mention about one possible weakness when using a combination of SNMP v3 or SNMP v3 in combination with v2 and/or v1 in a single device. Devices such as Cisco Switches and Routers as well as many other vendor's devices often allow the ability to specify several types of SNMP support in their configuration. In that concern, I think a WARNING should be added for the following combinatoric usage: 1) If SNMP v3 AuthPriv is used in combination with AuthNoPriv 2) If SNMP v3 AuthPriv is used in combination with NoAuthNoPriv 3) If SNMP v3 AuthPriv is used in combination with SNMP v2c 4) If SNMP v3 AuthPriv is used in combination with SNMP v1 All 4 of the above combinations include Encrypted data as well as PlainText data. If any device is configured simultaneously with any one or more of the above combinations, they will be virtually giving away their Encryption Key because if a device is configured with any PlainText along side Encrypted text, it will make it very easy to crack the key! As such, a WARNING against such usage should be included in one or more of the latest SNMP v3 RFC's where Encryption is mentioned. Sincerely, Walter Benton From agentx-bounces@ietf.org Fri Jun 13 10:35:20 2008 Return-Path: X-Original-To: agentx-archive@megatron.ietf.org Delivered-To: ietfarch-agentx-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37A93A69A9; Fri, 13 Jun 2008 10:35:20 -0700 (PDT) X-Original-To: agentx@core3.amsl.com Delivered-To: agentx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1153A69A9 for ; Fri, 13 Jun 2008 10:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 8TOppQWS3dI3 for ; Fri, 13 Jun 2008 10:35:19 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id 5200F3A68CE for ; Fri, 13 Jun 2008 10:35:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=PaxgbchXeIRYx3VAWq8anv3mw8Iv4L4Embbm6QY4W5OUTsfllQyoMDQaMC1Bt2TH; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.164.89.67] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1K7DBn-0006QE-2l for agentx@ietf.org; Fri, 13 Jun 2008 13:35:51 -0400 Message-ID: <000a01c8cd7c$0bc29740$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <48528A12.3020800@aa.aeonnet.ne.jp> Date: Fri, 13 Jun 2008 10:36:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888a63b7957ab9b23b3b32461e5e5ec879708ad851ead50f695350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.89.67 Subject: Re: [Agentx] SNMP v3 Security Considerations X-BeenThere: agentx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SNMP Agent Extensibility List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: agentx-bounces@ietf.org Errors-To: agentx-bounces@ietf.org Hi - Though slightly off-topic for this list.... > From: > To: > Sent: Friday, June 13, 2008 7:54 AM > Subject: [Agentx] SNMP v3 Security Considerations ... > In that concern, I think a WARNING should be added for the following > combinatoric usage: > > 1) If SNMP v3 AuthPriv is used in combination with AuthNoPriv > 2) If SNMP v3 AuthPriv is used in combination with NoAuthNoPriv > 3) If SNMP v3 AuthPriv is used in combination with SNMP v2c > 4) If SNMP v3 AuthPriv is used in combination with SNMP v1 > > All 4 of the above combinations include Encrypted data as well as > PlainText data. > > If any device is configured simultaneously with any one or more of the > above combinations, they will be virtually giving away their Encryption > Key because if a device is configured with any PlainText along side > Encrypted text, it will make it very easy to crack the key! It may be "very easy to crack the key" (for differing opinions of "very easy"), but having some unencrypted messages available doesn't really make the job significantly "easier." First, the queries coming from most management systems are rather predictable, except perhaps for the request-id. Furthermore, ASN.1 BER encoding is predictable enough to allow an automated brute-force attack to determine whether it has found the key. Having access to other request/response pairs which are not encrypted doesn't provide the attacker with a plaintext that is better known. Secondly, and more importantly, having a plaintext is not all that helpful in figuring out the key for CBC-DES - it just provides a way of verifying that one has found the correct key. However, BER encoding is brittle enough that if the result of decrypting with an attack key passes the parse unscathed, the key is likely to be the right one. RFC 3826 could also be used if you wanted a different value for "very easy". Randy