From dromasca@avaya.com Mon Apr 11 04:16:46 2011 Return-Path: X-Original-To: mib-doctors@core3.amsl.com Delivered-To: mib-doctors@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58FE73A6B06; Mon, 11 Apr 2011 04:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYRBLbqw6UIO; Mon, 11 Apr 2011 04:16:45 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 644413A6A7E; Mon, 11 Apr 2011 04:16:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMtcU2HCzI1/2dsb2JhbACmZXSkeQKZFoVhBJAM X-IronPort-AV: E=Sophos;i="4.63,338,1299474000"; d="scan'208";a="241107889" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Apr 2011 07:16:36 -0400 X-IronPort-AV: E=Sophos;i="4.63,338,1299474000"; d="scan'208";a="637532205" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Apr 2011 07:16:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Apr 2011 13:16:32 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the April 14, 2011 IESG Teleconference Thread-Index: Acv1cr6Sn08ya8eYTnilUDN3oEiwSgCxqfnQ From: "Romascanu, Dan (Dan)" To: , , , , Subject: [MIB-DOCTORS] FW: PRELIMINARY Agenda and Package for the April 14, 2011 IESG Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 11:16:46 -0000 =20 Hi,=20 Please find below the preliminary agenda of the 4/14 IESG telechat. Please send me any questions, comments or concerns before 4/13 COB.=20 Thanks and Regards, Dan=20 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-rmt-bb-fec-raptorq-05 RaptorQ Forward Error Correction Scheme for Object Delivery (Proposed Standard) Note: Brian Adamson (adamson@itd.nrl.navy.mil) is the document shepherd. Token: David Harrington o draft-ietf-ipfix-structured-data-05 Export of Structured Data in IPFIX (Proposed Standard) Note: Nevil Brownlee is the document shepherd Token: Dan Romascanu o draft-ietf-avtcore-ports-for-ucast-mcast-rtp-01 Port Mapping Between Unicast and Multicast RTP Sessions (Proposed Standard) Note: Roni Even (Even.roni@huawei.com) is the document shepherd. Token: Robert Sparks o draft-ietf-dccp-tfrc-rtt-option-05 Sender RTT Estimate Option for DCCP (Proposed Standard) Note: Pasi Sarolahti (pasi.sarolahti@iki.fi) is the document shepherd. Token: Wesley Eddy 2.1.2 Returning Items NONE 2.2 Individual Submissions 2.2.1 New Items o draft-yevstifeyev-tn3270-uri-18 The 'tn3270' URI Scheme (Proposed Standard) Token: Peter Saint-Andre 2.2.2 Returning Items NONE 2.2.3 For Action o draft-ietf-netlmm-pmipv6-mib-05 Proxy Mobile IPv6 Management Information Base (Proposed Standard) Note: Jonne Soininen (Jonne.Soininen@nsn.com) is the document shepherd. Token: Jari Arkko 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-mboned-addrarch-07 Overview of the Internet Multicast Addressing Architecture (Informational) Note: Lenny Giuliano (lenny@juniper.net) is the Document Shepherd Token: Ron Bonica o draft-ietf-genarea-datatracker-community-07 Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker (Informational) Token: Russ Housley o draft-ietf-genarea-charter-tool-08 Requirements for a Working Group Charter Tool (Informational) Token: Russ Housley o draft-ietf-ledbat-survey-05 A Survey of Lower-than-Best-Effort Transport Protocols (Informational) Note: Rolf Winter (rolf.winter@neclab.eu) is the Document Shepherd. Token: Wesley Eddy 3.1.2 Returning Items NONE 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-cardona-cablelabs-urn-07 A Uniform Resource Name (URN) Namespace for CableLabs (Informational) Token: Peter Saint-Andre o draft-kanno-tls-camellia-01 Addition of the Camellia Cipher Suites to Transport Layer Security (TLS) (Informational) Note: Satoru Kanno (kanno.satoru@po.ntts.co.jp) is the document shepherd. Token: Sean Turner o draft-housley-rfc5008bis-00 Suite B in Secure/Multipurpose Internet Mail Extensions (S/MIME) (Informational) Note: Russ Housley (housley@vigilsec.com) is the document shepherd. Token: Sean Turner 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items NONE 3.3.2 Returning Items NONE 3.3.3 For Action o draft-frejborg-hipv4-13 Hierarchical IPv4 Framework (Experimental) Note: IRSG submission. Tony Li (tony.li@tony.li) is the document shepherd. Token: Russ Housley o draft-palanivelan-bfd-v2-gr-10 Bidirectional Forwarding Detection (BFD) with Graceful Restart (Historic) Note: ISE submission. Token: Russ Housley 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review o Real Time Communication on the World Wide Web (rtcweb) Token: Gonzalo o Protocol to Access WS database (paws) Token: Dan 4.1.2 Proposed for Approval NONE 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval o Softwires (softwire) Token: Ralph o Secure Inter-Domain Routing (sidr) Token: Stewart From dromasca@avaya.com Thu Apr 14 04:09:44 2011 Return-Path: X-Original-To: mib-doctors@ietfc.amsl.com Delivered-To: mib-doctors@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7FBF4E07F0 for ; Thu, 14 Apr 2011 04:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3G2272DpTSJz for ; Thu, 14 Apr 2011 04:09:43 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfc.amsl.com (Postfix) with ESMTP id C8E6DE0730 for ; Thu, 14 Apr 2011 04:09:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am4BAJgtcU2HCzI1/2dsb2JhbACYKT+NfHSkegKZF4VhBJAM X-IronPort-AV: E=Sophos;i="4.64,210,1301889600"; d="scan'208";a="184585943" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 14 Apr 2011 07:09:42 -0400 X-IronPort-AV: E=Sophos;i="4.64,210,1301889600"; d="scan'208";a="638976168" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Apr 2011 07:09:38 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Apr 2011 13:09:36 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need for an update to the "Security Guidelines for IETF MIB" boilerplate Thread-Index: Acv6giF+R9YxZfMBQPqslGOA7DP0TwAEfPeQ From: "Romascanu, Dan (Dan)" To: Cc: Vincent Roca Subject: [MIB-DOCTORS] FW: Need for an update to the "Security Guidelines for IETF MIB" boilerplate X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 11:09:44 -0000 =20 Hi MIB Doctors,=20 Please see Vincent's comments triggered by his SecDir review of http://www.ietf.org/id/draft-ietf-netlmm-pmipv6-mib-05.txt Your advice is required.=20 Thanks and Regards, Dan=20 -----Original Message----- From: Vincent Roca [mailto:vincent.roca@inrialpes.fr]=20 Sent: Thursday, April 14, 2011 11:58 AM To: Romascanu, Dan (Dan) Cc: Vincent Roca; Sean Turner; stephen.farrell@cs.tcd.ie Subject: Need for an update to the "Security Guidelines for IETF MIB" boilerplate Hello Dan, While doing the SecDir review of the pmipv6 MIB document, I've spotted two issues concerning the official "Security Considerations" boilerplate for MIB I-Ds that may require a small update. More precisely: 1- the boilerplate references a wrong section in RFC3410=20 (see my comment below) 2- section 7.8 of RFC3410, when describing the User-based Security Model, only refers to DES. It's somewhat outdated. So I suggest adding a reference to RFC3826 (AES in SNMPv3) in the boilerplate, in addition to RFC3410. (BTW I didn't search if similar, more recent RFCs exist in addition to RFC3826). I don't know what Sean/Stephen think about it. > ** Wrong reference: > It is said: > "It is RECOMMENDED that implementers consider the security features as > provided by the SNMPv3 framework (see [RFC3410], section 8) [...]" > Section 8 is not the section of interest as it only focuses on the=20 > standardization status. More interesting sections in RFC3410 > are: > - section 6.3 "SNMPv3 security and administration", and in particular > - section 7, in particular section 7.8 "user based security model". >=20 > NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an=20 > issue, now it is. The last sentence of RFC3410/section 7.8 mentions=20 > on-going work on using AES in the user-based security model. If this=20 > work gave birth to an RFC, that's probably a good document to refer=20 > too. Cheers, Vincent From bertietf@bwijnen.net Fri Apr 15 01:04:01 2011 Return-Path: X-Original-To: mib-doctors@ietfc.amsl.com Delivered-To: mib-doctors@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 957EEE0686 for ; Fri, 15 Apr 2011 01:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XC7DtBjuM4Cp for ; Fri, 15 Apr 2011 01:04:00 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfc.amsl.com (Postfix) with ESMTP id A7495E0693 for ; Fri, 15 Apr 2011 01:03:59 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1QAe0Q-0000TJ-Nb; Fri, 15 Apr 2011 10:03:56 +0200 Received: from dog.ripe.net ([193.0.1.217] helo=guest178.guestnet.ripe.net) by ayeaye.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1QAe0Q-0000Ph-KC; Fri, 15 Apr 2011 10:03:54 +0200 Message-ID: <4DA7FBEA.3060409@bwijnen.net> Date: Fri, 15 Apr 2011 10:03:54 +0200 From: "Bert (IETF) Wijnen" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd43de8d394ddb30fbcc341163f44d08a0d Cc: mib-doctors@ietf.org, Vincent Roca Subject: Re: [MIB-DOCTORS] FW: Need for an update to the "Security Guidelines for IETF MIB" boilerplate X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 08:04:01 -0000 I would leave the reference to 3410 as is. It points to the place where you can find the an explanation as to why to NOT use SNMPv1/v2c. From there, I think people will find their way to SNMP security related text. Adding a pointer to 3826 may indeed make sense. I wonder however how many implementations/deployments there are. If there are enough, then maybe the document should become DS or Full Standard. I will note, that everytime that the security template needed change... there have been looooong discussions. my 2 cts Bert On 4/14/11 1:09 PM, Romascanu, Dan (Dan) wrote: > > > > Hi MIB Doctors, > > Please see Vincent's comments triggered by his SecDir review of > http://www.ietf.org/id/draft-ietf-netlmm-pmipv6-mib-05.txt > > Your advice is required. > > Thanks and Regards, > > Dan > > -----Original Message----- > From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > Sent: Thursday, April 14, 2011 11:58 AM > To: Romascanu, Dan (Dan) > Cc: Vincent Roca; Sean Turner; stephen.farrell@cs.tcd.ie > Subject: Need for an update to the "Security Guidelines for IETF MIB" > boilerplate > > Hello Dan, > > While doing the SecDir review of the pmipv6 MIB document, I've spotted > two issues concerning the official "Security Considerations" > boilerplate for MIB I-Ds that may require a small update. > > More precisely: > > 1- the boilerplate references a wrong section in RFC3410 > (see my comment below) > > 2- section 7.8 of RFC3410, when describing the User-based Security > Model, only refers to DES. It's somewhat outdated. So I suggest > adding a reference to RFC3826 (AES in SNMPv3) in the boilerplate, > in addition to RFC3410. > (BTW I didn't search if similar, more recent RFCs exist in addition to > RFC3826). > > I don't know what Sean/Stephen think about it. > >> ** Wrong reference: >> It is said: >> "It is RECOMMENDED that implementers consider the security features > as >> provided by the SNMPv3 framework (see [RFC3410], section 8) [...]" >> Section 8 is not the section of interest as it only focuses on the >> standardization status. More interesting sections in RFC3410 >> are: >> - section 6.3 "SNMPv3 security and administration", and in particular >> - section 7, in particular section 7.8 "user based security model". >> >> NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an >> issue, now it is. The last sentence of RFC3410/section 7.8 mentions >> on-going work on using AES in the user-based security model. If this >> work gave birth to an RFC, that's probably a good document to refer >> too. > > Cheers, > > Vincent > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > From vincent.roca@inrialpes.fr Mon Apr 18 06:33:34 2011 Return-Path: X-Original-To: mib-doctors@ietfc.amsl.com Delivered-To: mib-doctors@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 96EB2E06A1 for ; Mon, 18 Apr 2011 06:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.649 X-Spam-Level: X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7kcImTz2HX5 for ; Mon, 18 Apr 2011 06:33:30 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by ietfc.amsl.com (Postfix) with ESMTP id 56B0DE0664 for ; Mon, 18 Apr 2011 06:33:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.64,232,1301868000"; d="scan'208";a="97437847" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 18 Apr 2011 15:33:28 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: <4DA7FBEA.3060409@bwijnen.net> Date: Mon, 18 Apr 2011 15:33:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5ACEACD8-F7B6-4405-8439-F9CB44A4B3B2@inrialpes.fr> References: <4DA7FBEA.3060409@bwijnen.net> To: Bert (IETF) Wijnen X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Mon, 18 Apr 2011 06:54:48 -0700 Cc: Sean Turner , Stephen Farrell , Vincent Roca , mib-doctors@ietf.org Subject: Re: [MIB-DOCTORS] FW: Need for an update to the "Security Guidelines for IETF MIB" boilerplate X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 13:33:34 -0000 Hello Bert, On Apr. 15 2012, 10:03, Bert (IETF) Wijnen wrote: > I would leave the reference to 3410 as is. It points to the place = where you can find the > an explanation as to why to NOT use SNMPv1/v2c. =46rom there, I think = people > will find their way to SNMP security related text. Of course, RFC3410 is very important for clarifying why version 1 or 2c = MUST NOT or SHOULD NOT be used. Keep this reference in the boilerplate. > Adding a pointer to 3826 may indeed make sense. > I wonder however how many implementations/deployments there are. > If there are enough, then maybe the document should become DS or Full = Standard. >=20 > I will note, that everytime that the security template needed = change... there have been > looooong discussions. Put very simply, the situation is the following. The boilerplate, today, RECOMMENDs to follow the security guidelines of RFC3410 . This latter says: "The USM utilizes MD5 [31] and the Secure Hash Algorithm [32] as keyed hashing algorithms [33] for digest computation to provide data = integrity:" "The USM uses the Data Encryption Standard (DES) [34] in the cipher block chaining mode (CBC) if disclosure protection is desired." Since the boilerplate does not reference anything else, by transitivity, I understand that it RECOMMENDS the use of both MD5 and DES!!! No IETF standard would be allowed with such recommendations, today. Whether or not there are implementations/deployments that use more recent cryptosystems (e.g. RFC3826) is a different question. The problem is more fundamental and should be treated as such IMHO. Especially as it should be easy to fix (i.e. by adding a reference). I'm CCing our Security ADs. Cheers, Vincent > my 2 cts > Bert >=20 >=20 >=20 > On 4/14/11 1:09 PM, Romascanu, Dan (Dan) wrote: >>=20 >>=20 >>=20 >> Hi MIB Doctors, >>=20 >> Please see Vincent's comments triggered by his SecDir review of >> http://www.ietf.org/id/draft-ietf-netlmm-pmipv6-mib-05.txt >>=20 >> Your advice is required. >>=20 >> Thanks and Regards, >>=20 >> Dan >>=20 >> -----Original Message----- >> From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] >> Sent: Thursday, April 14, 2011 11:58 AM >> To: Romascanu, Dan (Dan) >> Cc: Vincent Roca; Sean Turner; stephen.farrell@cs.tcd.ie >> Subject: Need for an update to the "Security Guidelines for IETF MIB" >> boilerplate >>=20 >> Hello Dan, >>=20 >> While doing the SecDir review of the pmipv6 MIB document, I've = spotted >> two issues concerning the official "Security Considerations" >> boilerplate for MIB I-Ds that may require a small update. >>=20 >> More precisely: >>=20 >> 1- the boilerplate references a wrong section in RFC3410 >> (see my comment below) >>=20 >> 2- section 7.8 of RFC3410, when describing the User-based Security >> Model, only refers to DES. It's somewhat outdated. So I suggest >> adding a reference to RFC3826 (AES in SNMPv3) in the boilerplate, >> in addition to RFC3410. >> (BTW I didn't search if similar, more recent RFCs exist in addition = to >> RFC3826). >>=20 >> I don't know what Sean/Stephen think about it. >>=20 >>> ** Wrong reference: >>> It is said: >>> "It is RECOMMENDED that implementers consider the security features >> as >>> provided by the SNMPv3 framework (see [RFC3410], section 8) [...]" >>> Section 8 is not the section of interest as it only focuses on the >>> standardization status. More interesting sections in RFC3410 >>> are: >>> - section 6.3 "SNMPv3 security and administration", and in = particular >>> - section 7, in particular section 7.8 "user based security model". >>>=20 >>> NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an >>> issue, now it is. The last sentence of RFC3410/section 7.8 mentions >>> on-going work on using AES in the user-based security model. If this >>> work gave birth to an RFC, that's probably a good document to refer >>> too. >>=20 >> Cheers, >>=20 >> Vincent >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >>=20 >=20 From turners@ieca.com Tue Apr 19 06:41:44 2011 Return-Path: X-Original-To: mib-doctors@ietfc.amsl.com Delivered-To: mib-doctors@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6EF03E06E6 for ; Tue, 19 Apr 2011 06:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQCQtNTOZV+v for ; Tue, 19 Apr 2011 06:41:43 -0700 (PDT) Received: from nm24-vm0.bullet.mail.ac4.yahoo.com (nm24-vm0.bullet.mail.ac4.yahoo.com [98.139.53.222]) by ietfc.amsl.com (Postfix) with SMTP id 63351E06A1 for ; Tue, 19 Apr 2011 06:41:43 -0700 (PDT) Received: from [98.139.52.195] by nm24.bullet.mail.ac4.yahoo.com with NNFMP; 19 Apr 2011 13:41:39 -0000 Received: from [98.139.52.143] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 19 Apr 2011 13:41:39 -0000 Received: from [127.0.0.1] by omp1026.mail.ac4.yahoo.com with NNFMP; 19 Apr 2011 13:41:39 -0000 X-Yahoo-Newman-Id: 655163.23799.bm@omp1026.mail.ac4.yahoo.com Received: (qmail 95992 invoked from network); 19 Apr 2011 13:41:39 -0000 Received: from thunderfish.local (turners@96.231.128.210 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 19 Apr 2011 06:41:39 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: iYBjmy0VM1l3V0mWMfp0k1mVJdmf32w8cMWmxCohQP3Qwkc alfSK7vPkFg8fjCYiZDwuQMH9T_5Q8CgVSAUU40Ni9X6voRHU3xTjPvdouIa zGxUxbGBM1H4eY28qQzLijy5BHlSt7zNAnOKEU8dlo3XqqlJnTGtuedDfeh9 LlGYcrT_9d55HPw.C1QPsmBqexYjCwiQxNkYHCZnoBQatBlcoYKY8GOe8jzq n5.cn6c9ruXMDh_dzR_lOu1svVJYniysnpP11tVRd5V0KYwBgyRMNqc.s32w F3Km.ptJ3QCkdtKoGBGZtJi3ewOxaFqH3JVmH_iq7IVp5TySk3lgTiBwDS23 Ta0bfgKOgVbIfIfCJXQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DAD9112.1080202@ieca.com> Date: Tue, 19 Apr 2011 09:41:38 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Vincent Roca , "Bert \(IETF\) Wijnen" , "Romascanu, Dan \(Dan\)" References: <4DA7FBEA.3060409@bwijnen.net> <5ACEACD8-F7B6-4405-8439-F9CB44A4B3B2@inrialpes.fr> In-Reply-To: <5ACEACD8-F7B6-4405-8439-F9CB44A4B3B2@inrialpes.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 19 Apr 2011 08:16:54 -0700 Cc: mib-doctors@ietf.org, Stephen Farrell Subject: Re: [MIB-DOCTORS] FW: Need for an update to the "Security Guidelines for IETF MIB" boilerplate X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 13:41:44 -0000 On 4/18/11 9:33 AM, Vincent Roca wrote: > Hello Bert, > > On Apr. 15 2012, 10:03, Bert (IETF) Wijnen wrote: >> I would leave the reference to 3410 as is. It points to the place where you can find the >> an explanation as to why to NOT use SNMPv1/v2c. From there, I think people >> will find their way to SNMP security related text. > > Of course, RFC3410 is very important for clarifying why version 1 or 2c MUST NOT > or SHOULD NOT be used. Keep this reference in the boilerplate. > > >> Adding a pointer to 3826 may indeed make sense. >> I wonder however how many implementations/deployments there are. >> If there are enough, then maybe the document should become DS or Full Standard. >> >> I will note, that everytime that the security template needed change... there have been >> looooong discussions. > > Put very simply, the situation is the following. The boilerplate, today, > RECOMMENDs to follow the security guidelines of RFC3410 . This latter > says: > > "The USM utilizes MD5 [31] and the Secure Hash Algorithm [32] as keyed > hashing algorithms [33] for digest computation to provide data integrity:" > > "The USM uses the Data Encryption Standard (DES) [34] in the cipher > block chaining mode (CBC) if disclosure protection is desired." > > Since the boilerplate does not reference anything else, by transitivity, > I understand that it RECOMMENDS the use of both MD5 and DES!!! > No IETF standard would be allowed with such recommendations, today. > > Whether or not there are implementations/deployments that use more > recent cryptosystems (e.g. RFC3826) is a different question. The problem > is more fundamental and should be treated as such IMHO. Especially as > it should be easy to fix (i.e. by adding a reference). > > I'm CCing our Security ADs. I think the bit Vincent quotes is about the USM, which "defines the Elements of Procedure for providing SNMP message-level security". RFC 5591 and 5592 provide alternatives as noted in RFC 5590: The Transport Security Model [RFC5591] and the Secure Shell Transport Model [RFC5592] utilize the Transport Subsystem. The Transport Security Model is an alternative to the existing SNMPv1 Security Model [RFC3584], the SNMPv2c Security Model [RFC3584], and the User- based Security Model [RFC3414]. The Secure Shell Transport Model is an alternative to existing transport mappings as described in [RFC3417]. Couldn't just update the following blurb in the boilerplate to point to 5591 and 5592: It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Gotta ask: why does it point to Section 8 which is Standardization Status? spt >> >> >> >> On 4/14/11 1:09 PM, Romascanu, Dan (Dan) wrote: >>> >>> >>> >>> Hi MIB Doctors, >>> >>> Please see Vincent's comments triggered by his SecDir review of >>> http://www.ietf.org/id/draft-ietf-netlmm-pmipv6-mib-05.txt >>> >>> Your advice is required. >>> >>> Thanks and Regards, >>> >>> Dan >>> >>> -----Original Message----- >>> From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] >>> Sent: Thursday, April 14, 2011 11:58 AM >>> To: Romascanu, Dan (Dan) >>> Cc: Vincent Roca; Sean Turner; stephen.farrell@cs.tcd.ie >>> Subject: Need for an update to the "Security Guidelines for IETF MIB" >>> boilerplate >>> >>> Hello Dan, >>> >>> While doing the SecDir review of the pmipv6 MIB document, I've spotted >>> two issues concerning the official "Security Considerations" >>> boilerplate for MIB I-Ds that may require a small update. >>> >>> More precisely: >>> >>> 1- the boilerplate references a wrong section in RFC3410 >>> (see my comment below) >>> >>> 2- section 7.8 of RFC3410, when describing the User-based Security >>> Model, only refers to DES. It's somewhat outdated. So I suggest >>> adding a reference to RFC3826 (AES in SNMPv3) in the boilerplate, >>> in addition to RFC3410. >>> (BTW I didn't search if similar, more recent RFCs exist in addition to >>> RFC3826). >>> >>> I don't know what Sean/Stephen think about it. >>> >>>> ** Wrong reference: >>>> It is said: >>>> "It is RECOMMENDED that implementers consider the security features >>> as >>>> provided by the SNMPv3 framework (see [RFC3410], section 8) [...]" >>>> Section 8 is not the section of interest as it only focuses on the >>>> standardization status. More interesting sections in RFC3410 >>>> are: >>>> - section 6.3 "SNMPv3 security and administration", and in particular >>>> - section 7, in particular section 7.8 "user based security model". >>>> >>>> NB: RFC3410 is from Dec 2002. At that time using MD5/DES was not an >>>> issue, now it is. The last sentence of RFC3410/section 7.8 mentions >>>> on-going work on using AES in the user-based security model. If this >>>> work gave birth to an RFC, that's probably a good document to refer >>>> too. >>> >>> Cheers, >>> >>> Vincent >>> _______________________________________________ >>> MIB-DOCTORS mailing list >>> MIB-DOCTORS@ietf.org >>> https://www.ietf.org/mailman/listinfo/mib-doctors >>> >> > > From dromasca@avaya.com Fri Apr 22 00:13:47 2011 Return-Path: X-Original-To: mib-doctors@ietfc.amsl.com Delivered-To: mib-doctors@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CEC73E0826; Fri, 22 Apr 2011 00:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.057 X-Spam-Level: X-Spam-Status: No, score=-103.057 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aurb2Q3eSuVt; Fri, 22 Apr 2011 00:13:45 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfc.amsl.com (Postfix) with ESMTP id 1F747E07FD; Fri, 22 Apr 2011 00:13:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMtcU3GmAcF/2dsb2JhbACmZXSkeQKZFoVhBJAMgwA X-IronPort-AV: E=Sophos;i="4.64,253,1301889600"; d="scan'208";a="276083978" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 22 Apr 2011 03:13:44 -0400 X-IronPort-AV: E=Sophos;i="4.64,253,1301889600"; d="scan'208";a="611835785" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Apr 2011 03:13:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 22 Apr 2011 09:13:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the April 28, 2011 IESG Teleconference Thread-Index: AcwAcpVAnQf8iea5T4ewnWO3HiM5KgASeQUQ From: "Romascanu, Dan (Dan)" To: , , , , Subject: [MIB-DOCTORS] FW: PRELIMINARY Agenda and Package for the April 28, 2011 IESG Teleconference X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2011 07:13:48 -0000 =20 Hi,=20 Please find below the preliminary agenda of the 4/28 IESG telechat. Please let me know before 4/27 COB if there are any questions, issues or concerns related to the documents and WG charters brought up for the IESG approval. Thanks and Regards, Dan=20 -----Original Message----- From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of IESG Secretary 2. Protocol Actions 2.1 WG Submissions 2.1.1 New Items o draft-ietf-ecrit-phonebcp-17 Best Current Practice for Communications Services in support of Emergency Calling (BCP) Note: Marc Linsner (mlinsner@cisco.com) is the document shepherd. Token: Robert Sparks o draft-ietf-softwire-dual-stack-lite-07 Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion (Proposed Standard) Note: Dave Ward (dward@juniper.net) is the document shepherd. Token: Jari Arkko o draft-ietf-pwe3-fc-encap-15 Encapsulation Methods for Transport of Fibre Channel Traffic over MPLS Networks (Proposed Standard) Note: Matthew Bocci (matthew.bocci@alcatel-lucent.com) is the document shepherd. Token: Stewart Bryant o draft-ietf-sidr-rpki-manifests-10 Manifests for the Resource Public Key Infrastructure (Proposed Standard) Note: Sandra Murphy (sandra.murphy@sparta.com) is the document shepherd. Token: Stewart Bryant o draft-ietf-netext-redirect-07 Runtime LMA Assignment Support for Proxy Mobile IPv6 (Proposed Standard) Note: Rajeev Koodli (rkoodli@cisco.com) is the document shepherd. Token: Jari Arkko o draft-paxson-tcpm-rfc2988bis-02 Computing TCP's Retransmission Timer (Proposed Standard) Note: Wesley Eddy (Wesley.M.Eddy@nasa.gov) is the document shepherd. Token: Wesley Eddy o draft-ietf-ipsecme-ipsecha-protocol-05 Protocol Support for High Availability of IKEv2/IPsec (Proposed Standard) Note: Yaron Sheffer (yaronf.ietf@gmail.com) is the document shepherd. Token: Sean Turner o draft-ietf-grow-unique-origin-as-00 Unique Per-Node Origin ASNs for Globally Anycasted Services (BCP) Note: Peter Schoenmaker (pds@lugs.com) is the document shepherd. Token: Ron Bonica o draft-ietf-dnsop-default-local-zones-15 Locally-served DNS Zones (BCP) Note: Peter Koch (pk@ISOC.DE) is the document shepherd. Token: Ron Bonica o draft-ietf-trill-adj-06 RBridges: Adjacency (Proposed Standard) Note: Erik Nordmark (nordmark@acm.org) is the document shepherd. Token: Ralph Droms 2.1.2 Returning Items o draft-ietf-opsawg-mpls-tp-oam-def-09 "Guidelines for the use of the OAM acronym in the IETF" (BCP) Note: Chris Liljenstolpe (ietf@cdl.asgaard.org) is the document shepherd. Token: Adrian Farrel o draft-ietf-pwe3-oam-msg-map-16 Pseudowire (PW) OAM Message Mapping (Proposed Standard) Note: Andrew Malis, andrew.g.malis@verizon.com is the document shepherd. Token: Stewart Bryant Was deferred by Tim Polk on 2011-01-06 2.2 Individual Submissions 2.2.1 New Items NONE 2.2.2 Returning Items NONE 3. Document Actions 3.1 WG Submissions 3.1.1 New Items o draft-ietf-enum-iax-10 IANA Registration for Enumservice 'iax' (Informational) Note: Bernie Hoeneisen (bernie@ietf.hoeneisen.ch) is the document shepherd. Token: Gonzalo Camarillo o draft-ietf-mif-current-practices-09 Current Practices for Multiple Interface Hosts (Informational) Note: Hui Deng (denghui02@gmail.com) is the document shepherd. Token: Jari Arkko o draft-ietf-sidr-roa-validation-10 Validation of Route Origination using the Resource Certificate PKI and ROAs (Informational) Note: Sandra Murphy (sandra.murphy@sparta.com) is the document shepherd. Token: Adrian Farrel o draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 IPv6 AAAA DNS Whitelisting Implications (Informational) Note: Joel Jaeggli (joelja@bogus.com) is the document shepherd. Token: Ron Bonica o draft-ietf-kitten-digest-to-historic-03 Moving DIGEST-MD5 to Historic (Informational) Note: Tom Yu (tlyu@mit.edu) is the document shepherd. Token: Stephen Farrell o draft-ietf-dnsop-as112-under-attack-help-help-05 I'm Being Attacked by PRISONER.IANA.ORG! (Informational) Note: Peter Koch (pk@DENIC.DE) is the document shepherd. Token: Ron Bonica o draft-ietf-dnsop-as112-ops-06 AS112 Nameserver Operations (Informational) Note: Peter Koch (pk@DENIC.DE) is the document shepherd. Token: Ron Bonica 3.1.2 Returning Items o draft-ietf-ecrit-framework-12 Framework for Emergency Calling using Internet Multimedia (Informational) Note: IETF LC ends Mar 10.Marc Linsner (mlinsner@cisco.com) is the document shepherd. Token: Robert Sparks 3.2 Individual Submissions Via AD 3.2.1 New Items o draft-ietf-sipping-sip-offeranswer-14 SIP (Session Initiation Protocol) Usage of the Offer/Answer Model (Informational) Token: Robert Sparks o draft-ietf-sipping-nat-scenarios-15 Best Current Practices for NAT Traversal for Client-Server SIP (Informational) Note: Mary Barnes is the document shepherd Token: Robert Sparks 3.2.2 Returning Items NONE 3.3 IRTF and Independent Submission Stream Documents 3.3.1 New Items NONE 3.3.2 Returning Items NONE 4. Working Group Actions 4.1 WG Creation 4.1.1 Proposed for IETF Review NONE 4.1.2 Proposed for Approval o Real Time Communication on the World Wide Web (rtcweb) Token: Gonzalo o Protocol to Access WS database (paws) Token: Dan 4.2 WG Rechartering 4.2.1 Under Evaluation for IETF Review NONE 4.2.2 Proposed for Approval o Softwires (softwire) Token: Ralph From dromasca@avaya.com Tue Apr 26 03:59:08 2011 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC8AE06B7 for ; Tue, 26 Apr 2011 03:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF1wkZ3x91jI for ; Tue, 26 Apr 2011 03:59:07 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5C2E06CA for ; Tue, 26 Apr 2011 03:59:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAJgtcU3GmAcF/2dsb2JhbACYKYpwg0t0pHoCmReFYQSQDA X-IronPort-AV: E=Sophos;i="4.64,267,1301889600"; d="scan'208";a="185777925" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 26 Apr 2011 06:59:06 -0400 X-IronPort-AV: E=Sophos;i="4.64,267,1301889600"; d="scan'208";a="612896129" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Apr 2011 06:59:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Apr 2011 12:59:04 +0200 Message-ID: In-Reply-To: <4DAD9112.1080202@ieca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] FW: Need for an update to the "Security Guidelines for IETF MIB" boilerplate Thread-Index: Acv+l4Rxf0dd0l73QRmiCCuSR6paHgFaSNwQ References: <4DA7FBEA.3060409@bwijnen.net> <5ACEACD8-F7B6-4405-8439-F9CB44A4B3B2@inrialpes.fr> <4DAD9112.1080202@ieca.com> From: "Romascanu, Dan (Dan)" To: "Sean Turner" , "Vincent Roca" , "Bert (IETF) Wijnen" Cc: mib-doctors@ietf.org, Stephen Farrell Subject: Re: [MIB-DOCTORS] FW: Need for an update to the "Security Guidelines for IETF MIB" boilerplate X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 10:59:08 -0000 > Gotta ask: why does it point to Section 8 which is=20 > Standardization Status? Because that section explains the status of SNMPv1/v2c.=20 Dan > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com]=20 > Sent: Tuesday, April 19, 2011 4:42 PM > To: Vincent Roca; Bert (IETF) Wijnen; Romascanu, Dan (Dan) > Cc: mib-doctors@ietf.org; Stephen Farrell > Subject: Re: [MIB-DOCTORS] FW: Need for an update to the=20 > "Security Guidelines for IETF MIB" boilerplate >=20 > On 4/18/11 9:33 AM, Vincent Roca wrote: > > Hello Bert, > > > > On Apr. 15 2012, 10:03, Bert (IETF) Wijnen wrote: > >> I would leave the reference to 3410 as is. It points to the place=20 > >> where you can find the an explanation as to why to NOT use=20 > >> SNMPv1/v2c. From there, I think people will find their way=20 > to SNMP security related text. > > > > Of course, RFC3410 is very important for clarifying why=20 > version 1 or=20 > > 2c MUST NOT or SHOULD NOT be used. Keep this reference in=20 > the boilerplate. > > > > > >> Adding a pointer to 3826 may indeed make sense. > >> I wonder however how many implementations/deployments there are. > >> If there are enough, then maybe the document should become=20 > DS or Full Standard. > >> > >> I will note, that everytime that the security template needed=20 > >> change... there have been looooong discussions. > > > > Put very simply, the situation is the following. The boilerplate,=20 > > today, RECOMMENDs to follow the security guidelines of=20 > RFC3410 . This=20 > > latter > > says: > > > > "The USM utilizes MD5 [31] and the Secure Hash Algorithm=20 > [32] as keyed > > hashing algorithms [33] for digest computation to=20 > provide data integrity:" > > > > "The USM uses the Data Encryption Standard (DES) [34] in=20 > the cipher > > block chaining mode (CBC) if disclosure protection is desired." > > > > Since the boilerplate does not reference anything else, by=20 > > transitivity, I understand that it RECOMMENDS the use of=20 > both MD5 and DES!!! > > No IETF standard would be allowed with such recommendations, today. > > > > Whether or not there are implementations/deployments that use more=20 > > recent cryptosystems (e.g. RFC3826) is a different question. The=20 > > problem is more fundamental and should be treated as such IMHO.=20 > > Especially as it should be easy to fix (i.e. by adding a reference). > > > > I'm CCing our Security ADs. >=20 > I think the bit Vincent quotes is about the USM, which=20 > "defines the Elements of Procedure for providing SNMP=20 > message-level security". RFC > 5591 and 5592 provide alternatives as noted in RFC 5590: >=20 > The Transport Security Model [RFC5591] and the Secure=20 > Shell Transport > Model [RFC5592] utilize the Transport Subsystem. The Transport > Security Model is an alternative to the existing SNMPv1 Security > Model [RFC3584], the SNMPv2c Security Model [RFC3584], and=20 > the User- > based Security Model [RFC3414]. The Secure Shell=20 > Transport Model is > an alternative to existing transport mappings as described in > [RFC3417]. >=20 > Couldn't just update the following blurb in the boilerplate=20 > to point to > 5591 and 5592: >=20 > It is RECOMMENDED that implementers consider the security=20 > features as > provided by the SNMPv3 framework (see [RFC3410], section 8), > including full support for the SNMPv3 cryptographic mechanisms (for > authentication and privacy). >=20 > Gotta ask: why does it point to Section 8 which is=20 > Standardization Status? >=20 > spt >=20 > >> > >> > >> > >> On 4/14/11 1:09 PM, Romascanu, Dan (Dan) wrote: > >>> > >>> > >>> > >>> Hi MIB Doctors, > >>> > >>> Please see Vincent's comments triggered by his SecDir review of=20 > >>> http://www.ietf.org/id/draft-ietf-netlmm-pmipv6-mib-05.txt > >>> > >>> Your advice is required. > >>> > >>> Thanks and Regards, > >>> > >>> Dan > >>> > >>> -----Original Message----- > >>> From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > >>> Sent: Thursday, April 14, 2011 11:58 AM > >>> To: Romascanu, Dan (Dan) > >>> Cc: Vincent Roca; Sean Turner; stephen.farrell@cs.tcd.ie > >>> Subject: Need for an update to the "Security Guidelines=20 > for IETF MIB" > >>> boilerplate > >>> > >>> Hello Dan, > >>> > >>> While doing the SecDir review of the pmipv6 MIB document, I've=20 > >>> spotted two issues concerning the official "Security=20 > Considerations" > >>> boilerplate for MIB I-Ds that may require a small update. > >>> > >>> More precisely: > >>> > >>> 1- the boilerplate references a wrong section in RFC3410 > >>> (see my comment below) > >>> > >>> 2- section 7.8 of RFC3410, when describing the User-based Security > >>> Model, only refers to DES. It's somewhat outdated. So I suggest > >>> adding a reference to RFC3826 (AES in SNMPv3) in the=20 > boilerplate, > >>> in addition to RFC3410. > >>> (BTW I didn't search if similar, more recent RFCs=20 > exist in addition to > >>> RFC3826). > >>> > >>> I don't know what Sean/Stephen think about it. > >>> > >>>> ** Wrong reference: > >>>> It is said: > >>>> "It is RECOMMENDED that implementers consider the security=20 > >>>> features > >>> as > >>>> provided by the SNMPv3 framework (see [RFC3410],=20 > section 8) [...]" > >>>> Section 8 is not the section of interest as it only=20 > focuses on the=20 > >>>> standardization status. More interesting sections in RFC3410 > >>>> are: > >>>> - section 6.3 "SNMPv3 security and administration", and in=20 > >>>> particular > >>>> - section 7, in particular section 7.8 "user based=20 > security model". > >>>> > >>>> NB: RFC3410 is from Dec 2002. At that time using MD5/DES=20 > was not an=20 > >>>> issue, now it is. The last sentence of RFC3410/section=20 > 7.8 mentions=20 > >>>> on-going work on using AES in the user-based security model. If=20 > >>>> this work gave birth to an RFC, that's probably a good=20 > document to=20 > >>>> refer too. > >>> > >>> Cheers, > >>> > >>> Vincent > >>> _______________________________________________ > >>> MIB-DOCTORS mailing list > >>> MIB-DOCTORS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mib-doctors > >>> > >> > > > > >=20 From turners@ieca.com Tue Apr 26 04:37:28 2011 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D2BE06E4 for ; Tue, 26 Apr 2011 04:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNcphXUfyZwG for ; Tue, 26 Apr 2011 04:37:27 -0700 (PDT) Received: from nm24.bullet.mail.bf1.yahoo.com (nm24.bullet.mail.bf1.yahoo.com [98.139.212.183]) by ietfa.amsl.com (Postfix) with SMTP id 66A4DE06B2 for ; Tue, 26 Apr 2011 04:37:27 -0700 (PDT) Received: from [98.139.212.144] by nm24.bullet.mail.bf1.yahoo.com with NNFMP; 26 Apr 2011 11:37:22 -0000 Received: from [98.139.212.246] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 26 Apr 2011 11:37:21 -0000 Received: from [127.0.0.1] by omp1055.mail.bf1.yahoo.com with NNFMP; 26 Apr 2011 11:37:21 -0000 X-Yahoo-Newman-Id: 888460.26688.bm@omp1055.mail.bf1.yahoo.com Received: (qmail 50997 invoked from network); 26 Apr 2011 11:37:21 -0000 Received: from thunderfish.local (turners@96.231.122.68 with plain) by smtp101.biz.mail.bf1.yahoo.com with SMTP; 26 Apr 2011 04:37:19 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: Ht7c5XsVM1mV5y5RslcVaobnhUV51wNjtm4THMlIYt_SdAK _vaolutpGJq2x0pfydT8eHVmJxbn43OglSvw8nTPsW_jOJVlwnW0T1CFqbqD n7hPcBxH42WI39oJ3rtNTya5U.HE29BTrv6iTPqrSOPfn4wuyt.TQVF_s0_x xA9ld2Mda89ipuWnZlb48rdz1mI8Y62vdDdwo6zEWp05gViGfSApI9pUFgVu z1XyMaqM91hQrytenoULC617VfMxVpzdiBb0NIia5EGUW0qeOBnqzLePOSdS ItSuv.Cac1KD88oAnZUyoy.3Z7r0q5HIqa1SSP3A31ESPmncL5kc350rttlp tRPvdN4KasXntbOqrUINRp8pUsPw- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DB6AE6E.9050207@ieca.com> Date: Tue, 26 Apr 2011 07:37:18 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" References: <4DA7FBEA.3060409@bwijnen.net> <5ACEACD8-F7B6-4405-8439-F9CB44A4B3B2@inrialpes.fr> <4DAD9112.1080202@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 26 Apr 2011 04:38:44 -0700 Cc: mib-doctors@ietf.org, Vincent Roca , Stephen Farrell Subject: Re: [MIB-DOCTORS] FW: Need for an update to the "Security Guidelines for IETF MIB" boilerplate X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 11:37:28 -0000 Dan, So maybe it's point to the wrong section? The text from the MIB boiler plate follows: It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), If it's talking about the SNMPv3 framework and the security features it supports wouldn't it seems like it ought to be pointing to section 7.8 and 7.9 of 3410 and not the standardization status of SNMP v1 and v2? spt On 4/26/11 6:59 AM, Romascanu, Dan (Dan) wrote: >> Gotta ask: why does it point to Section 8 which is >> Standardization Status? > > Because that section explains the status of SNMPv1/v2c. > > Dan > > > >> -----Original Message----- >> From: Sean Turner [mailto:turners@ieca.com] >> Sent: Tuesday, April 19, 2011 4:42 PM >> To: Vincent Roca; Bert (IETF) Wijnen; Romascanu, Dan (Dan) >> Cc: mib-doctors@ietf.org; Stephen Farrell >> Subject: Re: [MIB-DOCTORS] FW: Need for an update to the >> "Security Guidelines for IETF MIB" boilerplate >> >> On 4/18/11 9:33 AM, Vincent Roca wrote: >>> Hello Bert, >>> >>> On Apr. 15 2012, 10:03, Bert (IETF) Wijnen wrote: >>>> I would leave the reference to 3410 as is. It points to the place >>>> where you can find the an explanation as to why to NOT use >>>> SNMPv1/v2c. From there, I think people will find their way >> to SNMP security related text. >>> >>> Of course, RFC3410 is very important for clarifying why >> version 1 or >>> 2c MUST NOT or SHOULD NOT be used. Keep this reference in >> the boilerplate. >>> >>> >>>> Adding a pointer to 3826 may indeed make sense. >>>> I wonder however how many implementations/deployments there are. >>>> If there are enough, then maybe the document should become >> DS or Full Standard. >>>> >>>> I will note, that everytime that the security template needed >>>> change... there have been looooong discussions. >>> >>> Put very simply, the situation is the following. The boilerplate, >>> today, RECOMMENDs to follow the security guidelines of >> RFC3410 . This >>> latter >>> says: >>> >>> "The USM utilizes MD5 [31] and the Secure Hash Algorithm >> [32] as keyed >>> hashing algorithms [33] for digest computation to >> provide data integrity:" >>> >>> "The USM uses the Data Encryption Standard (DES) [34] in >> the cipher >>> block chaining mode (CBC) if disclosure protection is desired." >>> >>> Since the boilerplate does not reference anything else, by >>> transitivity, I understand that it RECOMMENDS the use of >> both MD5 and DES!!! >>> No IETF standard would be allowed with such recommendations, today. >>> >>> Whether or not there are implementations/deployments that use more >>> recent cryptosystems (e.g. RFC3826) is a different question. The >>> problem is more fundamental and should be treated as such IMHO. >>> Especially as it should be easy to fix (i.e. by adding a reference). >>> >>> I'm CCing our Security ADs. >> >> I think the bit Vincent quotes is about the USM, which >> "defines the Elements of Procedure for providing SNMP >> message-level security". RFC >> 5591 and 5592 provide alternatives as noted in RFC 5590: >> >> The Transport Security Model [RFC5591] and the Secure >> Shell Transport >> Model [RFC5592] utilize the Transport Subsystem. The Transport >> Security Model is an alternative to the existing SNMPv1 Security >> Model [RFC3584], the SNMPv2c Security Model [RFC3584], and >> the User- >> based Security Model [RFC3414]. The Secure Shell >> Transport Model is >> an alternative to existing transport mappings as described in >> [RFC3417]. >> >> Couldn't just update the following blurb in the boilerplate >> to point to >> 5591 and 5592: >> >> It is RECOMMENDED that implementers consider the security >> features as >> provided by the SNMPv3 framework (see [RFC3410], section 8), >> including full support for the SNMPv3 cryptographic mechanisms (for >> authentication and privacy). >> >> Gotta ask: why does it point to Section 8 which is >> Standardization Status? >> >> spt >> >>>> >>>> >>>> >>>> On 4/14/11 1:09 PM, Romascanu, Dan (Dan) wrote: >>>>> >>>>> >>>>> >>>>> Hi MIB Doctors, >>>>> >>>>> Please see Vincent's comments triggered by his SecDir review of >>>>> http://www.ietf.org/id/draft-ietf-netlmm-pmipv6-mib-05.txt >>>>> >>>>> Your advice is required. >>>>> >>>>> Thanks and Regards, >>>>> >>>>> Dan >>>>> >>>>> -----Original Message----- >>>>> From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] >>>>> Sent: Thursday, April 14, 2011 11:58 AM >>>>> To: Romascanu, Dan (Dan) >>>>> Cc: Vincent Roca; Sean Turner; stephen.farrell@cs.tcd.ie >>>>> Subject: Need for an update to the "Security Guidelines >> for IETF MIB" >>>>> boilerplate >>>>> >>>>> Hello Dan, >>>>> >>>>> While doing the SecDir review of the pmipv6 MIB document, I've >>>>> spotted two issues concerning the official "Security >> Considerations" >>>>> boilerplate for MIB I-Ds that may require a small update. >>>>> >>>>> More precisely: >>>>> >>>>> 1- the boilerplate references a wrong section in RFC3410 >>>>> (see my comment below) >>>>> >>>>> 2- section 7.8 of RFC3410, when describing the User-based Security >>>>> Model, only refers to DES. It's somewhat outdated. So I suggest >>>>> adding a reference to RFC3826 (AES in SNMPv3) in the >> boilerplate, >>>>> in addition to RFC3410. >>>>> (BTW I didn't search if similar, more recent RFCs >> exist in addition to >>>>> RFC3826). >>>>> >>>>> I don't know what Sean/Stephen think about it. >>>>> >>>>>> ** Wrong reference: >>>>>> It is said: >>>>>> "It is RECOMMENDED that implementers consider the security >>>>>> features >>>>> as >>>>>> provided by the SNMPv3 framework (see [RFC3410], >> section 8) [...]" >>>>>> Section 8 is not the section of interest as it only >> focuses on the >>>>>> standardization status. More interesting sections in RFC3410 >>>>>> are: >>>>>> - section 6.3 "SNMPv3 security and administration", and in >>>>>> particular >>>>>> - section 7, in particular section 7.8 "user based >> security model". >>>>>> >>>>>> NB: RFC3410 is from Dec 2002. At that time using MD5/DES >> was not an >>>>>> issue, now it is. The last sentence of RFC3410/section >> 7.8 mentions >>>>>> on-going work on using AES in the user-based security model. If >>>>>> this work gave birth to an RFC, that's probably a good >> document to >>>>>> refer too. >>>>> >>>>> Cheers, >>>>> >>>>> Vincent >>>>> _______________________________________________ >>>>> MIB-DOCTORS mailing list >>>>> MIB-DOCTORS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>>> >>>> >>> >>> >> > From dromasca@avaya.com Tue Apr 26 04:46:04 2011 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01963E072F for ; Tue, 26 Apr 2011 04:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StCZm37vw4KB for ; Tue, 26 Apr 2011 04:46:03 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id CD2E1E0734 for ; Tue, 26 Apr 2011 04:46:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcAAJgtcU3GmAcF/2dsb2JhbACYKYpwg0t0pHoCmReFYQSQDA X-IronPort-AV: E=Sophos;i="4.64,268,1301889600"; d="scan'208";a="185782463" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 26 Apr 2011 07:46:01 -0400 X-IronPort-AV: E=Sophos;i="4.64,268,1301889600"; d="scan'208";a="612913091" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 26 Apr 2011 07:46:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Apr 2011 13:45:59 +0200 Message-ID: In-Reply-To: <4DB6AE6E.9050207@ieca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] FW: Need for an update to the "Security Guidelines for IETF MIB" boilerplate Thread-Index: AcwEBlCC8HuE6J38T5ODzlV8UCQbmAAAFXgQ References: <4DA7FBEA.3060409@bwijnen.net> <5ACEACD8-F7B6-4405-8439-F9CB44A4B3B2@inrialpes.fr> <4DAD9112.1080202@ieca.com> <4DB6AE6E.9050207@ieca.com> From: "Romascanu, Dan (Dan)" To: "Sean Turner" Cc: mib-doctors@ietf.org, Vincent Roca , Stephen Farrell Subject: Re: [MIB-DOCTORS] FW: Need for an update to the "Security Guidelines for IETF MIB" boilerplate X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 11:46:04 -0000 Hi Sean, You are truncating the phrase - the continuation of it speaks about the full support for SNMPv3 :-)=20 > >> It is RECOMMENDED that implementers consider the security features=20 > >> as provided by the SNMPv3 framework (see [RFC3410], section 8), > >> including full support for the SNMPv3 cryptographic mechanisms (for > >> authentication and privacy). I read it as 'do SNMPv3 (first of all) because this is the only non-historic version of SNMP in town (as pointed by the referred section)' Dan=20 =20 > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com]=20 > Sent: Tuesday, April 26, 2011 2:37 PM > To: Romascanu, Dan (Dan) > Cc: Vincent Roca; Bert (IETF) Wijnen; mib-doctors@ietf.org;=20 > Stephen Farrell > Subject: Re: [MIB-DOCTORS] FW: Need for an update to the=20 > "Security Guidelines for IETF MIB" boilerplate >=20 > Dan, >=20 > So maybe it's point to the wrong section? The text from the=20 > MIB boiler plate follows: >=20 > It is RECOMMENDED that implementers consider the security > features as > provided by the SNMPv3 framework (see [RFC3410], section 8), >=20 > If it's talking about the SNMPv3 framework and the security=20 > features it supports wouldn't it seems like it ought to be=20 > pointing to section 7.8 and 7.9 of 3410 and not the=20 > standardization status of SNMP v1 and v2? >=20 > spt >=20 > On 4/26/11 6:59 AM, Romascanu, Dan (Dan) wrote: > >> Gotta ask: why does it point to Section 8 which is Standardization=20 > >> Status? > > > > Because that section explains the status of SNMPv1/v2c. > > > > Dan > > > > > > > >> -----Original Message----- > >> From: Sean Turner [mailto:turners@ieca.com] > >> Sent: Tuesday, April 19, 2011 4:42 PM > >> To: Vincent Roca; Bert (IETF) Wijnen; Romascanu, Dan (Dan) > >> Cc: mib-doctors@ietf.org; Stephen Farrell > >> Subject: Re: [MIB-DOCTORS] FW: Need for an update to the "Security=20 > >> Guidelines for IETF MIB" boilerplate > >> > >> On 4/18/11 9:33 AM, Vincent Roca wrote: > >>> Hello Bert, > >>> > >>> On Apr. 15 2012, 10:03, Bert (IETF) Wijnen wrote: > >>>> I would leave the reference to 3410 as is. It points to=20 > the place=20 > >>>> where you can find the an explanation as to why to NOT use=20 > >>>> SNMPv1/v2c. From there, I think people will find their way > >> to SNMP security related text. > >>> > >>> Of course, RFC3410 is very important for clarifying why > >> version 1 or > >>> 2c MUST NOT or SHOULD NOT be used. Keep this reference in > >> the boilerplate. > >>> > >>> > >>>> Adding a pointer to 3826 may indeed make sense. > >>>> I wonder however how many implementations/deployments there are. > >>>> If there are enough, then maybe the document should become > >> DS or Full Standard. > >>>> > >>>> I will note, that everytime that the security template needed=20 > >>>> change... there have been looooong discussions. > >>> > >>> Put very simply, the situation is the following. The boilerplate,=20 > >>> today, RECOMMENDs to follow the security guidelines of > >> RFC3410 . This > >>> latter > >>> says: > >>> > >>> "The USM utilizes MD5 [31] and the Secure Hash Algorithm > >> [32] as keyed > >>> hashing algorithms [33] for digest computation to > >> provide data integrity:" > >>> > >>> "The USM uses the Data Encryption Standard (DES) [34] in > >> the cipher > >>> block chaining mode (CBC) if disclosure protection=20 > is desired." > >>> > >>> Since the boilerplate does not reference anything else, by=20 > >>> transitivity, I understand that it RECOMMENDS the use of > >> both MD5 and DES!!! > >>> No IETF standard would be allowed with such=20 > recommendations, today. > >>> > >>> Whether or not there are implementations/deployments that=20 > use more=20 > >>> recent cryptosystems (e.g. RFC3826) is a different question. The=20 > >>> problem is more fundamental and should be treated as such IMHO. > >>> Especially as it should be easy to fix (i.e. by adding a=20 > reference). > >>> > >>> I'm CCing our Security ADs. > >> > >> I think the bit Vincent quotes is about the USM, which=20 > "defines the=20 > >> Elements of Procedure for providing SNMP message-level security". =20 > >> RFC > >> 5591 and 5592 provide alternatives as noted in RFC 5590: > >> > >> The Transport Security Model [RFC5591] and the Secure Shell=20 > >> Transport > >> Model [RFC5592] utilize the Transport Subsystem. The Transport > >> Security Model is an alternative to the existing=20 > SNMPv1 Security > >> Model [RFC3584], the SNMPv2c Security Model [RFC3584], and the=20 > >> User- > >> based Security Model [RFC3414]. The Secure Shell=20 > Transport Model=20 > >> is > >> an alternative to existing transport mappings as described in > >> [RFC3417]. > >> > >> Couldn't just update the following blurb in the=20 > boilerplate to point=20 > >> to > >> 5591 and 5592: > >> > >> It is RECOMMENDED that implementers consider the=20 > security features=20 > >> as > >> provided by the SNMPv3 framework (see [RFC3410], section 8), > >> including full support for the SNMPv3 cryptographic=20 > mechanisms (for > >> authentication and privacy). > >> > >> Gotta ask: why does it point to Section 8 which is Standardization=20 > >> Status? > >> > >> spt > >> > >>>> > >>>> > >>>> > >>>> On 4/14/11 1:09 PM, Romascanu, Dan (Dan) wrote: > >>>>> > >>>>> > >>>>> > >>>>> Hi MIB Doctors, > >>>>> > >>>>> Please see Vincent's comments triggered by his SecDir review of=20 > >>>>> http://www.ietf.org/id/draft-ietf-netlmm-pmipv6-mib-05.txt > >>>>> > >>>>> Your advice is required. > >>>>> > >>>>> Thanks and Regards, > >>>>> > >>>>> Dan > >>>>> > >>>>> -----Original Message----- > >>>>> From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] > >>>>> Sent: Thursday, April 14, 2011 11:58 AM > >>>>> To: Romascanu, Dan (Dan) > >>>>> Cc: Vincent Roca; Sean Turner; stephen.farrell@cs.tcd.ie > >>>>> Subject: Need for an update to the "Security Guidelines > >> for IETF MIB" > >>>>> boilerplate > >>>>> > >>>>> Hello Dan, > >>>>> > >>>>> While doing the SecDir review of the pmipv6 MIB document, I've=20 > >>>>> spotted two issues concerning the official "Security > >> Considerations" > >>>>> boilerplate for MIB I-Ds that may require a small update. > >>>>> > >>>>> More precisely: > >>>>> > >>>>> 1- the boilerplate references a wrong section in RFC3410 > >>>>> (see my comment below) > >>>>> > >>>>> 2- section 7.8 of RFC3410, when describing the=20 > User-based Security > >>>>> Model, only refers to DES. It's somewhat outdated.=20 > So I suggest > >>>>> adding a reference to RFC3826 (AES in SNMPv3) in the > >> boilerplate, > >>>>> in addition to RFC3410. > >>>>> (BTW I didn't search if similar, more recent RFCs > >> exist in addition to > >>>>> RFC3826). > >>>>> > >>>>> I don't know what Sean/Stephen think about it. > >>>>> > >>>>>> ** Wrong reference: > >>>>>> It is said: > >>>>>> "It is RECOMMENDED that implementers consider the security=20 > >>>>>> features > >>>>> as > >>>>>> provided by the SNMPv3 framework (see [RFC3410], > >> section 8) [...]" > >>>>>> Section 8 is not the section of interest as it only > >> focuses on the > >>>>>> standardization status. More interesting sections in RFC3410 > >>>>>> are: > >>>>>> - section 6.3 "SNMPv3 security and administration", and in=20 > >>>>>> particular > >>>>>> - section 7, in particular section 7.8 "user based > >> security model". > >>>>>> > >>>>>> NB: RFC3410 is from Dec 2002. At that time using MD5/DES > >> was not an > >>>>>> issue, now it is. The last sentence of RFC3410/section > >> 7.8 mentions > >>>>>> on-going work on using AES in the user-based security=20 > model. If=20 > >>>>>> this work gave birth to an RFC, that's probably a good > >> document to > >>>>>> refer too. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Vincent > >>>>> _______________________________________________ > >>>>> MIB-DOCTORS mailing list > >>>>> MIB-DOCTORS@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/mib-doctors > >>>>> > >>>> > >>> > >>> > >> > > >=20 From turners@ieca.com Tue Apr 26 04:57:35 2011 Return-Path: X-Original-To: mib-doctors@ietfa.amsl.com Delivered-To: mib-doctors@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBFCE073F for ; Tue, 26 Apr 2011 04:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0LqqrQG24RF for ; Tue, 26 Apr 2011 04:57:35 -0700 (PDT) Received: from nm26.bullet.mail.bf1.yahoo.com (nm26.bullet.mail.bf1.yahoo.com [98.139.212.185]) by ietfa.amsl.com (Postfix) with SMTP id A87A4E0723 for ; Tue, 26 Apr 2011 04:57:34 -0700 (PDT) Received: from [98.139.212.153] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 26 Apr 2011 11:57:31 -0000 Received: from [98.139.212.221] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 26 Apr 2011 11:57:31 -0000 Received: from [127.0.0.1] by omp1030.mail.bf1.yahoo.com with NNFMP; 26 Apr 2011 11:57:31 -0000 X-Yahoo-Newman-Id: 391668.89019.bm@omp1030.mail.bf1.yahoo.com Received: (qmail 33773 invoked from network); 26 Apr 2011 11:57:30 -0000 Received: from thunderfish.local (turners@96.231.122.68 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 26 Apr 2011 04:57:28 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: sQ_2eO8VM1nttn0kzSpG5Q5ciXUvtmy2wquwF9ghcyMaMB8 PGBXjnGQ7yFRbAwrLoXKYQfnyoyy7TNe_KZECy6onxg9Av1ttOxtopcDgspr Iio6FzZvt.HbzLOuBGcdLwtZZIKH0qRGeqJljiRPZdGloaE62t1dOJctnwI4 d5gYWtR7R9IlTKbVgb3H_MxOiuilMLUZWi.Bi.MC8sdcKVbApvwoviB9rvjY K_R4c6VkawhuYD7mDAHv4lcqsfr2E4_ZSPAx8nZ7yoecxFyiYIahojVlVUti QH6mf3FKFGsqaW4fEIyeuVrLCmp72A5KugsoDLqeXLVSgdrKJ2I.1amU9ysH _Ah0HcMtS0vnHmyzR4tb3KVKVu5f2m.HyeL1AFxBoW_Mruw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4DB6B326.8060205@ieca.com> Date: Tue, 26 Apr 2011 07:57:26 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Romascanu, Dan \(Dan\)" References: <4DA7FBEA.3060409@bwijnen.net> <5ACEACD8-F7B6-4405-8439-F9CB44A4B3B2@inrialpes.fr> <4DAD9112.1080202@ieca.com> <4DB6AE6E.9050207@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 26 Apr 2011 04:59:43 -0700 Cc: mib-doctors@ietf.org, Vincent Roca , Stephen Farrell Subject: Re: [MIB-DOCTORS] FW: Need for an update to the "Security Guidelines for IETF MIB" boilerplate X-BeenThere: mib-doctors@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: MIB Doctors list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 11:57:35 -0000 On 4/26/11 7:45 AM, Romascanu, Dan (Dan) wrote: > > Hi Sean, > > You are truncating the phrase - the continuation of it speaks about the > full support for SNMPv3 :-) > >>>> It is RECOMMENDED that implementers consider the security > features >>>> as provided by the SNMPv3 framework (see [RFC3410], section 8), >>>> including full support for the SNMPv3 cryptographic mechanisms > (for >>>> authentication and privacy). > > I read it as 'do SNMPv3 (first of all) because this is the only > non-historic version of SNMP in town (as pointed by the referred > section)' Ah I see now. I totally wasn't reading it that way. I was reading it as a pointer for the security features of the SNMPv3 framework. > Dan > > >> -----Original Message----- >> From: Sean Turner [mailto:turners@ieca.com] >> Sent: Tuesday, April 26, 2011 2:37 PM >> To: Romascanu, Dan (Dan) >> Cc: Vincent Roca; Bert (IETF) Wijnen; mib-doctors@ietf.org; >> Stephen Farrell >> Subject: Re: [MIB-DOCTORS] FW: Need for an update to the >> "Security Guidelines for IETF MIB" boilerplate >> >> Dan, >> >> So maybe it's point to the wrong section? The text from the >> MIB boiler plate follows: >> >> It is RECOMMENDED that implementers consider the security >> features as >> provided by the SNMPv3 framework (see [RFC3410], section 8), >> >> If it's talking about the SNMPv3 framework and the security >> features it supports wouldn't it seems like it ought to be >> pointing to section 7.8 and 7.9 of 3410 and not the >> standardization status of SNMP v1 and v2? >> >> spt >> >> On 4/26/11 6:59 AM, Romascanu, Dan (Dan) wrote: >>>> Gotta ask: why does it point to Section 8 which is Standardization >>>> Status? >>> >>> Because that section explains the status of SNMPv1/v2c. >>> >>> Dan >>> >>> >>> >>>> -----Original Message----- >>>> From: Sean Turner [mailto:turners@ieca.com] >>>> Sent: Tuesday, April 19, 2011 4:42 PM >>>> To: Vincent Roca; Bert (IETF) Wijnen; Romascanu, Dan (Dan) >>>> Cc: mib-doctors@ietf.org; Stephen Farrell >>>> Subject: Re: [MIB-DOCTORS] FW: Need for an update to the "Security >>>> Guidelines for IETF MIB" boilerplate >>>> >>>> On 4/18/11 9:33 AM, Vincent Roca wrote: >>>>> Hello Bert, >>>>> >>>>> On Apr. 15 2012, 10:03, Bert (IETF) Wijnen wrote: >>>>>> I would leave the reference to 3410 as is. It points to >> the place >>>>>> where you can find the an explanation as to why to NOT use >>>>>> SNMPv1/v2c. From there, I think people will find their way >>>> to SNMP security related text. >>>>> >>>>> Of course, RFC3410 is very important for clarifying why >>>> version 1 or >>>>> 2c MUST NOT or SHOULD NOT be used. Keep this reference in >>>> the boilerplate. >>>>> >>>>> >>>>>> Adding a pointer to 3826 may indeed make sense. >>>>>> I wonder however how many implementations/deployments there are. >>>>>> If there are enough, then maybe the document should become >>>> DS or Full Standard. >>>>>> >>>>>> I will note, that everytime that the security template needed >>>>>> change... there have been looooong discussions. >>>>> >>>>> Put very simply, the situation is the following. The boilerplate, >>>>> today, RECOMMENDs to follow the security guidelines of >>>> RFC3410 . This >>>>> latter >>>>> says: >>>>> >>>>> "The USM utilizes MD5 [31] and the Secure Hash Algorithm >>>> [32] as keyed >>>>> hashing algorithms [33] for digest computation to >>>> provide data integrity:" >>>>> >>>>> "The USM uses the Data Encryption Standard (DES) [34] in >>>> the cipher >>>>> block chaining mode (CBC) if disclosure protection >> is desired." >>>>> >>>>> Since the boilerplate does not reference anything else, by >>>>> transitivity, I understand that it RECOMMENDS the use of >>>> both MD5 and DES!!! >>>>> No IETF standard would be allowed with such >> recommendations, today. >>>>> >>>>> Whether or not there are implementations/deployments that >> use more >>>>> recent cryptosystems (e.g. RFC3826) is a different question. The >>>>> problem is more fundamental and should be treated as such IMHO. >>>>> Especially as it should be easy to fix (i.e. by adding a >> reference). >>>>> >>>>> I'm CCing our Security ADs. >>>> >>>> I think the bit Vincent quotes is about the USM, which >> "defines the >>>> Elements of Procedure for providing SNMP message-level security". >>>> RFC >>>> 5591 and 5592 provide alternatives as noted in RFC 5590: >>>> >>>> The Transport Security Model [RFC5591] and the Secure Shell >>>> Transport >>>> Model [RFC5592] utilize the Transport Subsystem. The Transport >>>> Security Model is an alternative to the existing >> SNMPv1 Security >>>> Model [RFC3584], the SNMPv2c Security Model [RFC3584], and the >>>> User- >>>> based Security Model [RFC3414]. The Secure Shell >> Transport Model >>>> is >>>> an alternative to existing transport mappings as described in >>>> [RFC3417]. >>>> >>>> Couldn't just update the following blurb in the >> boilerplate to point >>>> to >>>> 5591 and 5592: >>>> >>>> It is RECOMMENDED that implementers consider the >> security features >>>> as >>>> provided by the SNMPv3 framework (see [RFC3410], section 8), >>>> including full support for the SNMPv3 cryptographic >> mechanisms (for >>>> authentication and privacy). >>>> >>>> Gotta ask: why does it point to Section 8 which is Standardization >>>> Status? >>>> >>>> spt >>>> >>>>>> >>>>>> >>>>>> >>>>>> On 4/14/11 1:09 PM, Romascanu, Dan (Dan) wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Hi MIB Doctors, >>>>>>> >>>>>>> Please see Vincent's comments triggered by his SecDir review of >>>>>>> http://www.ietf.org/id/draft-ietf-netlmm-pmipv6-mib-05.txt >>>>>>> >>>>>>> Your advice is required. >>>>>>> >>>>>>> Thanks and Regards, >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Vincent Roca [mailto:vincent.roca@inrialpes.fr] >>>>>>> Sent: Thursday, April 14, 2011 11:58 AM >>>>>>> To: Romascanu, Dan (Dan) >>>>>>> Cc: Vincent Roca; Sean Turner; stephen.farrell@cs.tcd.ie >>>>>>> Subject: Need for an update to the "Security Guidelines >>>> for IETF MIB" >>>>>>> boilerplate >>>>>>> >>>>>>> Hello Dan, >>>>>>> >>>>>>> While doing the SecDir review of the pmipv6 MIB document, I've >>>>>>> spotted two issues concerning the official "Security >>>> Considerations" >>>>>>> boilerplate for MIB I-Ds that may require a small update. >>>>>>> >>>>>>> More precisely: >>>>>>> >>>>>>> 1- the boilerplate references a wrong section in RFC3410 >>>>>>> (see my comment below) >>>>>>> >>>>>>> 2- section 7.8 of RFC3410, when describing the >> User-based Security >>>>>>> Model, only refers to DES. It's somewhat outdated. >> So I suggest >>>>>>> adding a reference to RFC3826 (AES in SNMPv3) in the >>>> boilerplate, >>>>>>> in addition to RFC3410. >>>>>>> (BTW I didn't search if similar, more recent RFCs >>>> exist in addition to >>>>>>> RFC3826). >>>>>>> >>>>>>> I don't know what Sean/Stephen think about it. >>>>>>> >>>>>>>> ** Wrong reference: >>>>>>>> It is said: >>>>>>>> "It is RECOMMENDED that implementers consider the security >>>>>>>> features >>>>>>> as >>>>>>>> provided by the SNMPv3 framework (see [RFC3410], >>>> section 8) [...]" >>>>>>>> Section 8 is not the section of interest as it only >>>> focuses on the >>>>>>>> standardization status. More interesting sections in RFC3410 >>>>>>>> are: >>>>>>>> - section 6.3 "SNMPv3 security and administration", and in >>>>>>>> particular >>>>>>>> - section 7, in particular section 7.8 "user based >>>> security model". >>>>>>>> >>>>>>>> NB: RFC3410 is from Dec 2002. At that time using MD5/DES >>>> was not an >>>>>>>> issue, now it is. The last sentence of RFC3410/section >>>> 7.8 mentions >>>>>>>> on-going work on using AES in the user-based security >> model. If >>>>>>>> this work gave birth to an RFC, that's probably a good >>>> document to >>>>>>>> refer too. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Vincent >>>>>>> _______________________________________________ >>>>>>> MIB-DOCTORS mailing list >>>>>>> MIB-DOCTORS@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/mib-doctors >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >> >