From clonvick@cisco.com Mon Jun 1 12:08:12 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6922D3A6A0D; Mon, 1 Jun 2009 12:08:12 -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 scZpf+NB6Kdh; Mon, 1 Jun 2009 12:08:11 -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 BD6F93A6944; Mon, 1 Jun 2009 12:08:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,285,1241395200"; d="scan'208";a="78625217" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 01 Jun 2009 19:08:12 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n51J8Cnx012616; Mon, 1 Jun 2009 12:08:12 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n51J8Cwd012604; Mon, 1 Jun 2009 19:08:12 GMT Date: Mon, 1 Jun 2009 12:08:11 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, shollenbeck@verisign.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=922; t=1243883292; x=1244747292; 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:=20secdir=20review=20of=20draft-hollenbeck-rfc4932 bis-01 |Sender:=20; bh=/mQePsTSVRmEBTBhfhsKn/KiQLbA1NpXrbi0/mMTxdE=; b=OkfuDQUeLimUzWyh3tO2kUgZEDq33isixOC7X17azKfCyMpVJHcSq3PpAx iA3vzydICXJkhrQMkxp8eS692y1lBfeXNYB5t/phTQKH1Wx7mMo9bnj+f+JO zw8if92Iym; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [secdir] secdir review of draft-hollenbeck-rfc4932bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 19:08:12 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I found security-related problems in my review of the document. I did see, however, that the Security Considerations, which point back to ID 4930.bis, are very similar to the security considerations in RFC 4930. They hint that a secure transport is needed to thwart common mitm attacks but the section does not give any specific guidance. It has been two years since RFC 4930 was published. Have any secure transports been used? If so, I think it would be a good idea to state which one(s) and how its attributes do thwart the threats. Best regards, Chris From clonvick@cisco.com Mon Jun 1 12:42:14 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CD93A6A19; Mon, 1 Jun 2009 12:42:14 -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 lbsZ29-+Y4Kb; Mon, 1 Jun 2009 12:42:12 -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 4217A3A686D; Mon, 1 Jun 2009 12:42:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,285,1241395200"; d="scan'208";a="314497029" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 01 Jun 2009 19:42:12 +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 n51JgCYM012491; Mon, 1 Jun 2009 12:42:12 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n51JgCqF022698; Mon, 1 Jun 2009 19:42:12 GMT Date: Mon, 1 Jun 2009 12:42:12 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, shollenbeck@verisign.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1201; t=1243885332; x=1244749332; 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:=20correction=3A=20Re=3A=20secdir=20review=20of=20 draft-hollenbeck-rfc4932bis-01 |Sender:=20; bh=ktQXnZTyIC5d+bDzVn1ZDiYZ7UjBkMVY8BNO/nFxU+k=; b=fnuYUob7pjKnJD7z3hPYa16lYdhtRiLMwnE6KEbdtVQq+gJXLVjPSFo2vt njitulVvQ16AYhsYNCPUxC4jVMZjfXFGcA3orlcfH6+sOTkSNgiRiPJ8jMPn 02CYk7adXl; Authentication-Results: sj-dkim-2; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [secdir] correction: Re: secdir review of draft-hollenbeck-rfc4932bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 19:42:14 -0000 On Mon, 1 Jun 2009, Chris Lonvick wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > I found security-related problems in my review of the document. That's supposed to be: I found _no_ security-related problems in my review of the document. Apologies for the confusion, and thanks Richard for pointing that out. Regards, Chris > > I did see, however, that the Security Considerations, which point back to ID > 4930.bis, are very similar to the security considerations in RFC 4930. They > hint that a secure transport is needed to thwart common mitm attacks but the > section does not give any specific guidance. > > It has been two years since RFC 4930 was published. Have any secure > transports been used? If so, I think it would be a good idea to state which > one(s) and how its attributes do thwart the threats. > > Best regards, > Chris > From alexey.melnikov@isode.com Mon Jun 1 12:42:45 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 856383A6A19; Mon, 1 Jun 2009 12:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 3ZGu8IGdDjwK; Mon, 1 Jun 2009 12:42:44 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A92803A68C4; Mon, 1 Jun 2009 12:42:44 -0700 (PDT) Received: from [172.16.2.178] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 1 Jun 2009 20:42:43 +0100 Message-ID: <4A242EEF.3050508@isode.com> Date: Mon, 01 Jun 2009 20:41:35 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Chris Lonvick References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: shollenbeck@verisign.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-hollenbeck-rfc4932bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 19:42:45 -0000 Chris Lonvick wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > I found security-related problems in my review of the document. Chris, Can you be more specific? > I did see, however, that the Security Considerations, which point back > to ID 4930.bis, are very similar to the security considerations in RFC > 4930. They hint that a secure transport is needed to thwart common > mitm attacks but the section does not give any specific guidance. > It has been two years since RFC 4930 was published. Have any secure > transports been used? If so, I think it would be a good idea to state > which one(s) and how its attributes do thwart the threats. See draft-hollenbeck-rfc4934bis-01.txt From kivinen@iki.fi Tue Jun 2 03:52:37 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D253A6A09; Tue, 2 Jun 2009 03:52: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 euH38dT0OBsa; Tue, 2 Jun 2009 03:52:36 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 807793A6866; Tue, 2 Jun 2009 03:52:36 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n52AqW02020503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jun 2009 13:52:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n52AqVY2009177; Tue, 2 Jun 2009 13:52:31 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18981.1135.241220.933349@fireball.kivinen.iki.fi> Date: Tue, 2 Jun 2009 13:52:31 +0300 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 17 min Cc: webdav-chairs@tools.ietf.org, draft-ietf-webdav-bind@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-webdav-bind-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 10:52:37 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document adds binding extensions to the WebDAV. Binding extensions seem to be like hard links on unix file system i.e. providing multiple bindings for same resource (and resource is freed only when the last binding goes away). Security considerations section refers to the "HTTP/1.1 and the WebDAV Distributed Authoring Protocol specification" and says that all security considerations of them also applies to this document, but it does not give explicit references to the documents containing those security considerations. Bindings adds some new security concerns (privacy, loops, denial of service etc.), and those issues seem to be adequately covered by the security considerations section. One of the things I am not sure if it is really applicable here, but which is not covered by the security considerations section is that bindings might confuse administrator about access permissions. I.e. even when administrator revokes all change permissions from certain collection (i.e the user cannot change the data any more), if that collection has binding pointing to some other collection or resource where user still has permissions, the user might still be able to change resources in the first collection even when administrator believes he already removed permissions. I am not familiar enough with the WebDAV authorization model to know if this kind of attacks are possible or not, i.e. I do not know if the permissions are set per resource basis or for per collection or what. -- kivinen@iki.fi From julian.reschke@greenbytes.de Tue Jun 2 05:26:15 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0284B3A6CFC; Tue, 2 Jun 2009 05:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 ATnRYmX+pasQ; Tue, 2 Jun 2009 05:26:13 -0700 (PDT) Received: from donbot.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by core3.amsl.com (Postfix) with ESMTP id 13DF43A6808; Tue, 2 Jun 2009 05:26:12 -0700 (PDT) Received: from [192.168.1.106] (unknown [192.168.1.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by donbot.greenbytes.de (Postfix) with ESMTPSA id A177AC4C05A; Tue, 2 Jun 2009 14:26:12 +0200 (CEST) Message-ID: <4A251A64.9050209@greenbytes.de> Date: Tue, 02 Jun 2009 14:26:12 +0200 From: Julian Reschke Organization: greenbytes GmbH User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Tero Kivinen References: <18981.1135.241220.933349@fireball.kivinen.iki.fi> In-Reply-To: <18981.1135.241220.933349@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: webdav-chairs@tools.ietf.org, draft-ietf-webdav-bind@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-webdav-bind-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 12:26:15 -0000 Hi Tero, Tero Kivinen wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This document adds binding extensions to the WebDAV. Binding > extensions seem to be like hard links on unix file system i.e. > providing multiple bindings for same resource (and resource is freed > only when the last binding goes away). > > Security considerations section refers to the "HTTP/1.1 and the WebDAV > Distributed Authoring Protocol specification" and says that all > security considerations of them also applies to this document, but it > does not give explicit references to the documents containing those > security considerations. > ... I have fixed this in my copy of the draft; see . We can either produce a new draft after IESG review, or let this change wait until AUTH48. (My personal preference is to provide the RFC Editor with a draft that has as few pending changes as possible). > Bindings adds some new security concerns (privacy, loops, denial of > service etc.), and those issues seem to be adequately covered by the > security considerations section. > > One of the things I am not sure if it is really applicable here, but > which is not covered by the security considerations section is that > bindings might confuse administrator about access permissions. I.e. > even when administrator revokes all change permissions from certain > collection (i.e the user cannot change the data any more), if that > collection has binding pointing to some other collection or resource > where user still has permissions, the user might still be able to > change resources in the first collection even when administrator > believes he already removed permissions. > > I am not familiar enough with the WebDAV authorization model to know > if this kind of attacks are possible or not, i.e. I do not know if the > permissions are set per resource basis or for per collection or what. RFC 3744 (WebDAV ACLs) defines access privileges per resource, not per URI (see also and ). Best regards, Julian -- bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782 From kivinen@iki.fi Tue Jun 2 05:32:12 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7DD53A6DB8; Tue, 2 Jun 2009 05:32:12 -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 N6ZtukgiYcTR; Tue, 2 Jun 2009 05:32:11 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 498D33A6808; Tue, 2 Jun 2009 05:32:10 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n52CW3g6006376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jun 2009 15:32:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n52CW31h015393; Tue, 2 Jun 2009 15:32:03 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18981.7107.200837.124304@fireball.kivinen.iki.fi> Date: Tue, 2 Jun 2009 15:32:03 +0300 From: Tero Kivinen To: Julian Reschke In-Reply-To: <4A251A64.9050209@greenbytes.de> References: <18981.1135.241220.933349@fireball.kivinen.iki.fi> <4A251A64.9050209@greenbytes.de> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: webdav-chairs@tools.ietf.org, draft-ietf-webdav-bind@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-webdav-bind-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 12:32:12 -0000 Julian Reschke writes: > I have fixed this in my copy of the draft; see > . That seems to be ok. > We can either produce a new draft after IESG review, or let this change > wait until AUTH48. Either one is ok for me... > > One of the things I am not sure if it is really applicable here, but > > which is not covered by the security considerations section is that > > bindings might confuse administrator about access permissions. I.e. > > even when administrator revokes all change permissions from certain > > collection (i.e the user cannot change the data any more), if that > > collection has binding pointing to some other collection or resource > > where user still has permissions, the user might still be able to > > change resources in the first collection even when administrator > > believes he already removed permissions. > > > > I am not familiar enough with the WebDAV authorization model to know > > if this kind of attacks are possible or not, i.e. I do not know if the > > permissions are set per resource basis or for per collection or what. > > RFC 3744 (WebDAV ACLs) defines access privileges per resource, not per > URI (see also > > and ). Ok, that should make it clear as then bindings do not affect access privileges. -- kivinen@iki.fi From d3e3e3@gmail.com Tue Jun 2 12:04:36 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9927E3A6F0A; Tue, 2 Jun 2009 12:04:36 -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 fhM9ojNVF90x; Tue, 2 Jun 2009 12:04:35 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id D29183A6E56; Tue, 2 Jun 2009 12:04:28 -0700 (PDT) Received: by ewy24 with SMTP id 24so8987489ewy.37 for ; Tue, 02 Jun 2009 12:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=j3pg4SZfGXs3UiTopGtKaTr9amwN3TqUTk8O7AL4XdQ=; b=u6u37DIdEQWbgXr0FFJ63fKGPkWElW646b/VVisWDAqq0VuZMjLgcvX8669btB+xXi TFgzi4syFzooTeKEeIu71ob/LIGilbXV/6u+cr0du1xgtODsQyMv3bar6XElEipRJ63R xtFWrsYKMqvoLb+P1EiKD/KG4B0wwfNqOYyr8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=TnH/Dy4Mp85peiH5K2z7jPqlEtOYbxsGQoHoyeq19x1xClqZvkQfYUKNAEWSTS5bEg TRNHizpwVfh7WndjkvOSkxH6zZvfc+M/uJVVBcGz/A3NGMslnxoyix/dNdAdxHdekzz0 R+1Mupl1yUDuxD8S5zz5OidwYpSlJOTI1hroQ= MIME-Version: 1.0 Received: by 10.216.18.212 with SMTP id l62mr26050wel.76.1243969465836; Tue, 02 Jun 2009 12:04:25 -0700 (PDT) Date: Tue, 2 Jun 2009 15:04:25 -0400 Message-ID: <1028365c0906021204i5819935dx35477354b4b3aa36@mail.gmail.com> From: Donald Eastlake To: ietf@ietf.org, secdir@ietf.org, Matthew Zekauskas , Henk Uijterwaal , acmorton@att.com, kaynam.hedayat@exfo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] draft-ietf-ippm-more-twamp-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 19:04:36 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This draft does two things in connection with the Two-Way Active Measurement Protocol (TWAMP) a protocol which builds on the One-Way Active Measurement Protocol (OWAMP): (1) Add an extension whereby the TWAMP-Test protocol can be done in an unauthenticated mode while TWAMP-Control is authenticated and encrypted, where previously they had been required to have the same security mode. TWAMP-Control is used to initiate, start, and stop, etc. test sessions, while TWAMP-Test is used to exchange test packets. (2) The draft establishes an IANA registration called TWAMP-Modes for adding features. Establishing the IANA registry as such is not security relevant. This draft has a brief Security Considerations section. It incorporates by reference the lengthy Security Considerations in RFC 4656, which specified OWAMP, and from RFC 5357, which specifies TWAMP and adds considerations for one DoS attack which overlooked in RFC 4656. Generally, this incorporation by reference is adequate. However, the draft Security Considerations sections has one additional sentence which includes the words "thus making it possible to increase overall security when compared to the previous options". That would only be true if the additional burden, under previous options where both control and test had the same security mode, of securing both TWAMP-Control and TWAMP-Test was prohibitive, forcing less security for TWAMP-Control and where having TWAMP-Test unauthenticated is not a problem with respect to the security threats in the particular instance. I believe the Security Considerations section should be re-worded to either drop the claim of "increase overall security" or at least make it clear that the claim only applies under resource constraints that would, under previous modes, have forced less security for TWAMP-Control and where unauthenticated TWAMP-Test is not a significant security concern. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com From d3e3e3@gmail.com Tue Jun 2 12:37:02 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9243A6E32; Tue, 2 Jun 2009 12:37:02 -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 UImMnxkHx2dE; Tue, 2 Jun 2009 12:37:01 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id D0EA23A6D90; Tue, 2 Jun 2009 12:37:00 -0700 (PDT) Received: by ewy24 with SMTP id 24so9017377ewy.37 for ; Tue, 02 Jun 2009 12:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jbQLayEwwAxp3imx+dddmIxrrmNVr7qSVjiwfQCZ5uY=; b=moVhIbcLYCyF+Q3Sd6VW5WRBOqKserRsRe7/c/1XOHk34pUpYFlR7ZmZhq7iVlpAPy GmyC2xc4o9Z9hs9TKwxqt0z47ZK5be8RSqcyGRKFxt1rY+2rEz07nnG/bCksRhX5lSw5 fNfHCnAu/lA642uN6ghLLEuuOF6Lvancx9l3s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=joj10H08915zf6ByhqXtUuOAuhjWQ0gvEUXkBDi/Tvx1gMPMyY5IzEVjQPjwpVd3oF quWRgZbvIn+VRSncLgkCpkm7mtEYUawJD56hdkXcLy1l//WmlBS6I8ap95CJhb+Ys2If ZxbWhZaP4fyrDDs39iUS46ZhPXDbdbLMDWnmo= MIME-Version: 1.0 Received: by 10.216.49.209 with SMTP id x59mr25812web.195.1243971415484; Tue, 02 Jun 2009 12:36:55 -0700 (PDT) In-Reply-To: <200906021935.n52JZjC3020120@klph001.kcdc.att.com> References: <1028365c0906021204i5819935dx35477354b4b3aa36@mail.gmail.com> <200906021935.n52JZjC3020120@klph001.kcdc.att.com> Date: Tue, 2 Jun 2009 15:36:55 -0400 Message-ID: <1028365c0906021236y4dafd85aqa5fba3298972d288@mail.gmail.com> From: Donald Eastlake To: Al Morton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Matthew Zekauskas , kaynam.hedayat@exfo.com, Henk Uijterwaal , iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] draft-ietf-ippm-more-twamp-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 19:37:02 -0000 Looks OK to me. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com On Tue, Jun 2, 2009 at 3:35 PM, Al Morton wrote: > Thanks for your comments, Donald, well-sorted through. > > I think the following will do it, > Al > > 5. =A0Security Considerations > OLD > =A0 The extended mixed-mode of operation permits stronger security/ > =A0 integrity protection on the TWAMP-Control protocol while > =A0 simultaneously emphasizing accuracy or efficiency on the TWAMP-Test > =A0 protocol, thus making it possible to increase overall security when > =A0 compared to the previous options. > > NEW > =A0 The extended mixed-mode of operation permits stronger security/ > =A0 integrity protection on the TWAMP-Control protocol while > =A0 simultaneously emphasizing accuracy or efficiency on the TWAMP-Test > =A0 protocol, thus making it possible to increase overall security when > =A0 compared to the previous options (when resource constraints would > =A0 have forced less security for TWAMP-Control and where unauthenticated > =A0 TWAMP-Test is not a significant concern). > > > > At 03:04 PM 6/2/2009, Donald Eastlake wrote: >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. =A0Document editors and WG chairs should treat these comments just >> like any other last call comments. >> >> This draft does two things in connection with the Two-Way Active >> Measurement Protocol (TWAMP) a protocol which builds on the One-Way >> Active Measurement Protocol (OWAMP): >> =A0 =A0 (1) Add an extension whereby the TWAMP-Test protocol can be done >> in an unauthenticated mode while TWAMP-Control is authenticated and >> encrypted, where previously they had been required to have the same >> security mode. TWAMP-Control is used to initiate, start, and stop, >> etc. test sessions, while TWAMP-Test is used to exchange test packets. >> =A0 =A0 (2) The draft establishes an IANA registration called TWAMP-Mode= s >> for adding features. Establishing the IANA registry as such is not >> security relevant. >> >> This draft has a brief Security Considerations section. It >> incorporates by reference the lengthy Security Considerations in RFC >> 4656, which specified OWAMP, and from RFC 5357, which specifies TWAMP >> and adds considerations for one DoS attack which overlooked in RFC >> 4656. Generally, this incorporation by reference is adequate. >> >> However, the draft Security Considerations sections has one additional >> sentence which includes the words "thus making it possible to increase >> overall security when compared to the previous options". That would >> only be true if the additional burden, under previous options where >> both control and test had the same security mode, of securing both >> TWAMP-Control and TWAMP-Test was prohibitive, forcing less security >> for TWAMP-Control and where having TWAMP-Test unauthenticated is not a >> problem with respect to the security threats in the particular >> instance. I believe the Security Considerations section should be >> re-worded to either drop the claim of "increase overall security" or >> at least make it clear that the claim only applies under resource >> constraints that would, under previous modes, have forced less >> security for TWAMP-Control and where unauthenticated TWAMP-Test is not >> a significant security concern. >> >> Thanks, >> Donald >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> =A0Donald E. Eastlake 3rd =A0 +1-508-634-2066 (home) >> =A0155 Beaver Street >> =A0Milford, MA 01757 USA >> =A0d3e3e3@gmail.com > > From mayank@google.com Tue Jun 2 10:23:54 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D313A67B7; Tue, 2 Jun 2009 10:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.376 X-Spam-Level: X-Spam-Status: No, score=-101.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, 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 Urfcl0BVvzzn; Tue, 2 Jun 2009 10:23:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id D7A163A69B4; Tue, 2 Jun 2009 10:23:45 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id n52HNk2v000723; Tue, 2 Jun 2009 10:23:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1243963426; bh=QzMt0y+muOBFNuGKaYM4OPXId6g=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-System-Of-Record; b=I zChp6KVfH/E1R4em8i1xQdlwH4AAds0lMdNEek+NRvrHo3JIO3+L+BMoCZT1H75HRVC vGS63mWsRseJgGTIWQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=ALcm4BTqzLsEXeR8wTNLPxXORsSsUHW+gCZxAXiSvZyr5lp8pW4kU3kF/kYCMe2vV tkcgMFdlpvWajydxxHlmA== Received: from bwz8 (bwz8.prod.google.com [10.188.26.8]) by wpaz37.hot.corp.google.com with ESMTP id n52HNWJp015522; Tue, 2 Jun 2009 10:23:44 -0700 Received: by bwz8 with SMTP id 8so8343554bwz.46 for ; Tue, 02 Jun 2009 10:23:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.112.204 with SMTP id x12mr3874439fap.70.1243963423363; Tue, 02 Jun 2009 10:23:43 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Jun 2009 10:23:38 -0700 Message-ID: <6f7ed4930906021023t657b2570s3e76993dc2cb2084@mail.gmail.com> From: Mayank Upadhyay To: Charlie Kaufman Content-Type: multipart/alternative; boundary=001636c5b1f4f6b801046b60cdf3 X-System-Of-Record: true X-Mailman-Approved-At: Tue, 02 Jun 2009 13:01:37 -0700 Cc: "seema.malkani@sun.com" , "secdir@ietf.org" , "mayank+ietf-2853@google.com" , "iesg@ietf.org" , Seema Malkani Subject: Re: [secdir] Secdir review of draft-ietf-kitten-rfc2853bis-05.txt (GSSAPI JAVA BINDINGS) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 17:45:40 -0000 --001636c5b1f4f6b801046b60cdf3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit FYI, Seema no longer has the email address seema.malkani@sun.com. I'm CC'ing her on an alternate email address: seema.malkani@gmail.com. -Mayank On Sat, May 30, 2009 at 11:20 PM, Charlie Kaufman wrote: > I am reviewing this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. Feel free to forward to any appropriate > forum. > > > > This refresh of RFC 2853 (GSSAPI JAVA BINDINGS) is almost trivial. The only > technical changes are the renumbering of error codes and OID values because > the values in RFC 2853 were internally inconsistent, missing, or (in the > case of OIDs) obsolete. There are a handful of other minor corrections in > the document (none technical). The document was also refreshed to use the > now-current copyright notices, etc. > > > > Since all of the error codes correspond to fatal errors, it is unlikely > that even interoperation with an implementation with bad codes could cause > security problems (just confusing error messages). The security > considerations seemed reasonable in RFC 2853 and they are unchanged here. > > > > --Charlie > --001636c5b1f4f6b801046b60cdf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI, Seema no longer has the email address seema.malkani@sun.com. I'm CC'ing her on an alternate = email address: seema.malkani@gma= il.com.

-Mayank

On Sat, May 30, 2= 009 at 11:20 PM, Charlie Kaufman <charliek@microsoft.com> wrote:

I am reviewing this document as part of the security directorate's ongoing e= ffort to review all IETF documents being processed by the IESG.=A0 These comments were written primarily for the benefit of the security area directors.=A0 Document editors and WG chairs should treat these comments just like any ot= her last call comments. Feel free to forward to any appropriate forum.

=A0

This refresh of RFC 2853 (GSSAPI JAVA BINDINGS) is almost trivial. The only technical changes are the renumbering of error codes and = OID values because the values in RFC 2853 were internally inconsistent, missing= , or (in the case of OIDs) obsolete. There are a handful of other minor correcti= ons in the document (none technical). The document was also refreshed to use th= e now-current copyright notices, etc.

=A0

Since all of the error codes correspond to fatal errors, it is unlikely that even interoperation with an implementation with bad codes could cause security problems (just confusing error messages). The security considerations seemed reasonable in RFC 2853 and they are unchanged here.

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 --Charlie


--001636c5b1f4f6b801046b60cdf3-- From acmorton@att.com Tue Jun 2 12:35:54 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7B6B3A6D90; Tue, 2 Jun 2009 12:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.796 X-Spam-Level: X-Spam-Status: No, score=-105.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, RCVD_IN_DNSWL_MED=-4, 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 1d4AAefkWgOV; Tue, 2 Jun 2009 12:35:54 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id C01CD3A6BA9; Tue, 2 Jun 2009 12:35:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: acmorton@att.com X-Msg-Ref: server-2.tower-146.messagelabs.com!1243971354!14228288!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.128.141] Received: (qmail 18858 invoked from network); 2 Jun 2009 19:35:55 -0000 Received: from sbcsmtp9.sbc.com (HELO flph161.enaf.ffdc.sbc.com) (144.160.128.141) by server-2.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Jun 2009 19:35:55 -0000 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n52JZpBN029129; Tue, 2 Jun 2009 12:35:52 -0700 Received: from klph001.kcdc.att.com (klph001.kcdc.att.com [135.188.3.11]) by flph161.enaf.ffdc.sbc.com (8.14.3/8.14.3) with ESMTP id n52JZn8Z029116; Tue, 2 Jun 2009 12:35:49 -0700 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n52JZmJI020174; Tue, 2 Jun 2009 14:35:48 -0500 Received: from maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by klph001.kcdc.att.com (8.14.0/8.14.0) with ESMTP id n52JZj36020123; Tue, 2 Jun 2009 14:35:45 -0500 Message-Id: <200906021935.n52JZj36020123@klph001.kcdc.att.com> Received: from acmt.att.com (martym.mt.att.com[135.16.251.71](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20090602193544gw1000u6rre>; Tue, 2 Jun 2009 19:35:44 +0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Jun 2009 15:35:44 -0400 To: Donald Eastlake , iesg@ietf.org, secdir@ietf.org, Matthew Zekauskas , Henk Uijterwaal , kaynam.hedayat@exfo.com From: Al Morton In-Reply-To: <1028365c0906021204i5819935dx35477354b4b3aa36@mail.gmail.co m> References: <1028365c0906021204i5819935dx35477354b4b3aa36@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Mailman-Approved-At: Tue, 02 Jun 2009 13:01:37 -0700 Subject: Re: [secdir] draft-ietf-ippm-more-twamp-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 19:35:55 -0000 Thanks for your comments, Donald, well-sorted through. I think the following will do it, Al 5. Security Considerations OLD The extended mixed-mode of operation permits stronger security/ integrity protection on the TWAMP-Control protocol while simultaneously emphasizing accuracy or efficiency on the TWAMP-Test protocol, thus making it possible to increase overall security when compared to the previous options. NEW The extended mixed-mode of operation permits stronger security/ integrity protection on the TWAMP-Control protocol while simultaneously emphasizing accuracy or efficiency on the TWAMP-Test protocol, thus making it possible to increase overall security when compared to the previous options (when resource constraints would have forced less security for TWAMP-Control and where unauthenticated TWAMP-Test is not a significant concern). At 03:04 PM 6/2/2009, Donald Eastlake wrote: >I have reviewed this document as part of the security directorate's >ongoing effort to review all IETF documents being processed by the >IESG. Document editors and WG chairs should treat these comments just >like any other last call comments. > >This draft does two things in connection with the Two-Way Active >Measurement Protocol (TWAMP) a protocol which builds on the One-Way >Active Measurement Protocol (OWAMP): > (1) Add an extension whereby the TWAMP-Test protocol can be done >in an unauthenticated mode while TWAMP-Control is authenticated and >encrypted, where previously they had been required to have the same >security mode. TWAMP-Control is used to initiate, start, and stop, >etc. test sessions, while TWAMP-Test is used to exchange test packets. > (2) The draft establishes an IANA registration called TWAMP-Modes >for adding features. Establishing the IANA registry as such is not >security relevant. > >This draft has a brief Security Considerations section. It >incorporates by reference the lengthy Security Considerations in RFC >4656, which specified OWAMP, and from RFC 5357, which specifies TWAMP >and adds considerations for one DoS attack which overlooked in RFC >4656. Generally, this incorporation by reference is adequate. > >However, the draft Security Considerations sections has one additional >sentence which includes the words "thus making it possible to increase >overall security when compared to the previous options". That would >only be true if the additional burden, under previous options where >both control and test had the same security mode, of securing both >TWAMP-Control and TWAMP-Test was prohibitive, forcing less security >for TWAMP-Control and where having TWAMP-Test unauthenticated is not a >problem with respect to the security threats in the particular >instance. I believe the Security Considerations section should be >re-worded to either drop the claim of "increase overall security" or >at least make it clear that the claim only applies under resource >constraints that would, under previous modes, have forced less >security for TWAMP-Control and where unauthenticated TWAMP-Test is not >a significant security concern. > >Thanks, >Donald >============================= > Donald E. Eastlake 3rd +1-508-634-2066 (home) > 155 Beaver Street > Milford, MA 01757 USA > d3e3e3@gmail.com From secdir-bounces@mit.edu Wed Jun 3 03:18:54 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04413A67A3 for ; Wed, 3 Jun 2009 03:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 NyEWeG6z-cof for ; Wed, 3 Jun 2009 03:18:52 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id E5C373A6A55 for ; Wed, 3 Jun 2009 03:18:40 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n53AIgJt026245 for ; Wed, 3 Jun 2009 06:18:42 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n53AIdsw026219 for ; Wed, 3 Jun 2009 06:18:39 -0400 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n53AIU26027298 for ; Wed, 3 Jun 2009 06:18:31 -0400 (EDT) Received: from doar.tau.ac.il (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 92D951EA2838 for ; Wed, 3 Jun 2009 06:18:30 -0400 (EDT) Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by mit.edu with ESMTP id dVYb4CSymzcVqxR8 for ; Wed, 03 Jun 2009 06:18:30 -0400 (EDT) Received-SPF: pass (mit.edu: domain of canetti@post.tau.ac.il designates 132.66.16.26 as permitted sender) receiver=mit.edu; client_ip=132.66.16.26; envelope-from=canetti@post.tau.ac.il; Received: from [10.0.0.5] (unknown [193.37.128.224]) by doar.tau.ac.il (Postfix) with ESMTP id 58F32BEF8; Wed, 3 Jun 2009 13:18:28 +0300 (IDT) Message-ID: <4A264DE7.6080407@post.tau.ac.il> Date: Wed, 03 Jun 2009 13:18:15 +0300 From: canetti User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: secdir@mit.edu, cfrg@ietf.org, avt@ietf.org, seokung@kisa.or.kr X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] SECDIR review of draft-ietf-avt-seed-srtp-11 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 10:18:54 -0000 *** I have reviewed this document as part of the security directorate's *** ongoing effort to review all IETF documents being processed by the *** IESG. These comments were written primarily for the benefit of the *** security area directors. Document editors and WG chairs should treat *** these comments just like any other last call comments. The draft describes the use of the SEED cipher (RFC 4269) within the SRTP protocol. The document is well written and thorough. I see no problems with it. My only potential concern is regarding the use of SEED itself. SEED is a cipher that's apparently very popular in Korea and less so elsewhere. While no weaknesses have been found afaik, it did not receive the level of scrutiny that AES did. Thus, the question arises whether the IETF should standardize (and thereby implicitly endorse) the use of this cipher as an alternative to AES. I personally see no problem here, as long as a security comparison is made clear in the document. Still, others may feel differently. In fact, for this purpose I cc'ed the cfrg RG on this evaluation. Best, Ran _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From stephen.farrell@cs.tcd.ie Wed Jun 3 04:53:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F1783A6D4A for ; Wed, 3 Jun 2009 04:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 fCu-8hVf7G52 for ; Wed, 3 Jun 2009 04:53:20 -0700 (PDT) Received: from VA3EHSOBE005.bigfish.com (va3ehsobe005.messaging.microsoft.com [216.32.180.15]) by core3.amsl.com (Postfix) with ESMTP id 285293A67D8 for ; Wed, 3 Jun 2009 04:53:19 -0700 (PDT) Received: from mail20-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 8.1.340.0; Wed, 3 Jun 2009 11:53:10 +0000 Received: from mail20-va3 (localhost.localdomain [127.0.0.1]) by mail20-va3-R.bigfish.com (Postfix) with ESMTP id 01C42128500; Wed, 3 Jun 2009 11:53:10 +0000 (UTC) X-SpamScore: 9 X-BigFish: VPS9(zz936eNzz1202hzz2ba5Mz2dh6bh1a3h17ch87il64h) X-Spam-TCS-SCL: 3:0 X-FB-DOMAIN-IP-MATCH: fail Received: by mail20-va3 (MessageSwitch) id 1244029986297929_9943; Wed, 3 Jun 2009 11:53:06 +0000 (UCT) Received: from imx2.tcd.ie (imx2.tcd.ie [134.226.1.156]) by mail20-va3.bigfish.com (Postfix) with ESMTP id 146EA1910051; Wed, 3 Jun 2009 11:53:06 +0000 (UTC) Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id AD14868006; Wed, 3 Jun 2009 12:53:05 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A03088A89DF; Wed, 03 Jun 2009 12:53:05 +0100 Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by imx2.tcd.ie (Postfix) with ESMTP id 9C27C68006; Wed, 3 Jun 2009 12:53:05 +0100 (IST) Message-ID: <4A2664F4.8030504@cs.tcd.ie> Date: Wed, 3 Jun 2009 12:56:36 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: secdir@ietf.org, draft-ietf-netlmm-pmip6-ipv4-support@tools.ietf.org, netlmm-chairs@tools.ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-AntiVirus-Status: MessageID = A13088A89DF X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.60.2 VDF=10.106.8) Subject: [secdir] secdir review of draft-ietf-netlmm-pmip6-ipv4-support-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 11:53:21 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines a way to support IPv4 home addresses in mobile IPv6 and a way to tunnel mobile IPv6 messages over IPv4. Pre-amble: I know next to nothing about this set of protocols though it seems that this specification mixes so many things that its security properties must be highly complex, certainly beyond what I can analyse in the time available. #1 I guess the main concern would be that a node could hijack another node's IPv4 home address. If an MN is able to (securely) do mobile IPv6, I'm not clear on how that node is prevented from claiming someone else's IPv4 address as its IPv4 home address. If that is covered, adding a paragraph to the security considerations section that makes it clear would be useful. (At least to me.) #2 - p10, last para: this refers to the mobile node's "policy profile" but that's not defined (here) so its not possible to know what security considerations apply. Same paragraph says that "the network will ensure..." but doesn't say how. #3 - 3.1.2.2, 2nd bullet says that the mobility anchor MUST check the authorization of the node to use the address claimed but doesn't say how that authorization can be done. (I *think* this may be the same point as #1 above.) #4 - 3.1.2.4 Does this create a new way to cause another node to lose its address(es) by sending bogus lifetime extension requests? #5 - (not really security but...) 3.2.1 I couldn't follow what'd happen if a lot of nodes with static IPv4 home addresses that belong to the same subnet roamed to different mobile gateways. Nits/Typos etc. 1. The draft could do with some more work on the language, e.g. "both the protocols" in the 1st sentence should be "both of the protocols." There are many similar cases, however, none that I've seen make the document less clear to me, other than as a distraction though that might not be the same for all readers (e.g. non native English speakers). OTOH, this kind of language might be clearer for non-native English speakers:-) 2. If section 1 is intended to be a useful overview for the non-initiated, then I have to say it failed in that for me (one of the non-initiated). However, it may actually be intended more to position this for people familiar with the technology. #3 3.1.2.7 says: "when there is not a single Home Network Prefix option with NON_ZERO value present in the request..." That's very hard to interpret and possibly badly ambiguous. "Not a single" could mean zero or >1. #4 3.1.3 says that the mobility anchor MUST advertise a connected route but doesn't say how. #5 section 7: s/news/new/ From hartmans@mit.edu Wed Jun 3 12:51:48 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8027F28C19C for ; Wed, 3 Jun 2009 12:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 Oii+aHbXXHR5 for ; Wed, 3 Jun 2009 12:51:47 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 3DE973A6F57 for ; Wed, 3 Jun 2009 12:51:47 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 220E54141; Wed, 3 Jun 2009 15:51:47 -0400 (EDT) To: secdir@ietf.org From: Sam Hartman Date: Wed, 03 Jun 2009 15:51:47 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [secdir] [Sam Hartman] Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 19:51:48 -0000 --=-=-= I was assigned this as a secdir review but didn't feel like labeling what I came up with as a secdir review. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Wed, 03 Jun 2009 15:24:28 -0400 X-Sieve: CMU Sieve 2.2 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mail.suchdamage.org (Postfix) with ESMTP id 51FBE2029B for ; Wed, 3 Jun 2009 15:23:53 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9E628C187; Wed, 3 Jun 2009 12:22:39 -0700 (PDT) X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849503A7062; Wed, 3 Jun 2009 12:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 cT5KwwNl5Yxx; Wed, 3 Jun 2009 12:22:37 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 37D063A6929; Wed, 3 Jun 2009 12:22:37 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4DB484141; Wed, 3 Jun 2009 15:22:30 -0400 (EDT) To: ietf@ietf.org Subject: Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP References: <20090519133936.DC6B63A6AC0@core3.amsl.com> From: Sam Hartman Date: Wed, 03 Jun 2009 15:22:30 -0400 In-Reply-To: <20090519133936.DC6B63A6AC0@core3.amsl.com> (The IESG's message of "Tue\, 19 May 2009 06\:39\:36 -0700 \(PDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) Cc: opsawg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Jun 3 15:24:28 2009 X-DSPAM-Confidence: 0.5650 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,4a26cdec161565843716735 X-DSPAM-Factors: 27, Subject*ietf, 0.00010, From*Sam Hartman , 0.00010, List-Unsubscribe* X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201D628C1C7 for ; Wed, 3 Jun 2009 12:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.432 X-Spam-Level: X-Spam-Status: No, score=-4.432 tagged_above=-999 required=5 tests=[AWL=2.167, 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 Bdtuny7jLRvV for ; Wed, 3 Jun 2009 12:57:57 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 92BD03A6FCD for ; Wed, 3 Jun 2009 12:57:57 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n53JvxaW026959 for ; Wed, 3 Jun 2009 15:57:59 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n53Jvwa0026956 for ; Wed, 3 Jun 2009 15:57:58 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n53Jvnu3007446 for ; Wed, 3 Jun 2009 15:57:49 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 5CA4910CF817 for ; Wed, 3 Jun 2009 15:50:52 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by mit.edu with ESMTP id cjEy0bAKK0efj8oc (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 03 Jun 2009 15:50:52 -0400 (EDT) Received-SPF: softfail (mit.edu: domain of transitioning hartmans@mit.edu does not designate 69.25.196.178 as permitted sender) receiver=mit.edu; client_ip=69.25.196.178; envelope-from=hartmans@mit.edu; Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ADCEE4141; Wed, 3 Jun 2009 15:50:49 -0400 (EDT) To: secdir@mit.edu From: Sam Hartman Date: Wed, 03 Jun 2009 15:50:49 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] [Sam Hartman] Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 19:57:59 -0000 --=-=-= I was assigned this as a secdir review. I didn't really feel like calling what I came up with a secdir review. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Wed, 03 Jun 2009 15:24:28 -0400 X-Sieve: CMU Sieve 2.2 Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mail.suchdamage.org (Postfix) with ESMTP id 51FBE2029B for ; Wed, 3 Jun 2009 15:23:53 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9E628C187; Wed, 3 Jun 2009 12:22:39 -0700 (PDT) X-Original-To: ietf@core3.amsl.com Delivered-To: ietf@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849503A7062; Wed, 3 Jun 2009 12:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 cT5KwwNl5Yxx; Wed, 3 Jun 2009 12:22:37 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 37D063A6929; Wed, 3 Jun 2009 12:22:37 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4DB484141; Wed, 3 Jun 2009 15:22:30 -0400 (EDT) To: ietf@ietf.org Subject: Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP References: <20090519133936.DC6B63A6AC0@core3.amsl.com> From: Sam Hartman Date: Wed, 03 Jun 2009 15:22:30 -0400 In-Reply-To: <20090519133936.DC6B63A6AC0@core3.amsl.com> (The IESG's message of "Tue\, 19 May 2009 06\:39\:36 -0700 \(PDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) Cc: opsawg@ietf.org X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-bounces@ietf.org Errors-To: ietf-bounces@ietf.org X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Jun 3 15:24:28 2009 X-DSPAM-Confidence: 0.5650 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,4a26cdec161565843716735 X-DSPAM-Factors: 27, Subject*ietf, 0.00010, From*Sam Hartman , 0.00010, List-Unsubscribe* X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8C193A6E74; Thu, 4 Jun 2009 09:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] 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 zoLJrccqkzdr; Thu, 4 Jun 2009 09:15:36 -0700 (PDT) Received: from leela.webpack.hosteurope.de (leela.webpack.hosteurope.de [217.115.142.65]) by core3.amsl.com (Postfix) with ESMTP id D5A783A6E62; Thu, 4 Jun 2009 09:15:35 -0700 (PDT) Received: from 78-86-27-62.zone2.bethere.co.uk ([78.86.27.62] helo=[192.168.1.64]); authenticated by leela.webpack.hosteurope.de running ExIM with esmtpa id 1MCFb4-0004Ye-LN; Thu, 04 Jun 2009 18:15:18 +0200 Message-ID: <4A27F317.8020608@gondrom.org> Date: Thu, 04 Jun 2009 17:15:19 +0100 From: Tobias Gondrom User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de; tobias.gondrom@gondrom.org; 1244132138; 9fe7ee46; Cc: fluffy@cisco.com, kns10@cs.columbia.edu, eunsoo@locus.net, iesg@ietf.org, alan@sipstation.com, rjsparks@nostrum.com Subject: [secdir] SECDIR review of draft-sinnreich-sip-tools-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 16:15:36 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This informational document is mainly based on refers to RFC 3261, 4566, 3264, 3840, 3263, 3265, 3856, 3863, 3428, 4474 and 3581. The key elements are security considerations in the referred documents and the document's section about NAT traversal and its Security considerations section - which I find both sufficient. I believe this document adds no new security issues and do not see any issues with this informational draft. >From my point of view security considerations have been addressed appropriately. Best regards, Tobias From Sandra.Murphy@cobham.com Thu Jun 4 11:44:05 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E85F3A6C6C; Thu, 4 Jun 2009 11:44: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 lDZx6hVcnvaG; Thu, 4 Jun 2009 11:44:03 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 08ECF28C1CC; Thu, 4 Jun 2009 11:43:54 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n54Ihuix010081; Thu, 4 Jun 2009 13:43:56 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id n54Ihrmk018005; Thu, 4 Jun 2009 13:43:54 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.209]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 14:43:14 -0400 Date: Thu, 4 Jun 2009 14:43:12 -0400 (Eastern Daylight Time) From: Sandra Murphy To: iesg@ietf.org, secdir@ietf.org, shollenbeck@verisign.com Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 04 Jun 2009 18:43:14.0472 (UTC) FILETIME=[51811280:01C9E544] Subject: [secdir] review of draft-hollenbeck-rfc4933bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 18:44:05 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The draft updates RFC 4933, the EPP Contacts Mapping spec. The updates listed are relatively minor - updates to references and a few minor updates to text. Many of my comments below apply to language that was in RFC4933, but perhaps it is OK to suggest changes from the original at this point. First: EPP, as in RFC4930 and draft *-rfc4930bis-01*, employs a very simple authentication scheme that is cleartext password based. It therefore mandates: Specifically, EPP instances MUST be protected using a transport mechanism or application protocol that provides integrity, confidentiality, and mutual strong client-server authentication. This mandate is inherited by the rfc4933bis draft, which also says Both client and server MUST ensure that authorization information is stored and exchanged with high-grade encryption mechanisms to provide privacy services. I would expect that this would make the protocol subject to channel binding issues. I probably am not up on the whole idea, but the I reviewed RFC5060 and the description of the problem sure sounds like it applies to EPP as well. OTOH, I seem to recall several drafts recently that relied on the security of their transport layers, and no one has been talking about how they deal with channel binding. Maybe I'm way off. Also, the security considerations there and in rfc4930bis do not address the cases when completion of a pending request is communicated by an out-of-band mechanism. I don't know if there are security concerns for those notifications, but given that they are not covered by the security of the transport mechanism, advice would be good. sect 2.2, page 5 - pendingCreate, pendingDelete, pendingRenew, pendingTransfer, pendingUpdate A transform command has been processed for the object, but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action. A transform command that is processed, but whose requested action is pending, is noted with response code 1001. When the requested action has been completed, the pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status value MUST be removed. Later, sect 3.3 page 27 says (indirectly) that the status MUST be set if the action is delayed: The status of the corresponding object MUST clearly reflect processing of the pending action. If the MUST for removal is here, it would be good to be consistent and put the MUST for setting the status as well. (As a matter of fact, it would be nice to mention the pending status being set in the description of the transform commands as well.) (By the way: why is a pendingRenew status defined when section 3.2 says there is no mapping defined for the Renew command?) Same section, immediately following: All clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed. Later sections (p 17 sec 3.2 and p 28 sec 3.3) add qualifications to this MUST: "Other notification methods MAY be used" and "or by using an out-of-band mechanism." sect 2.9, page 7 A server operator MUST reject any transaction that requests disclosure practices that do not conform to the announced data collection policy with a 2308 error response code. When servers are compling with client specified exceptional disclosure handling for some data elements, does this same requirement apply, and with the same error code? sect 3.1.2, page 14 The response example contains: S: +1.7035555555 S: +1.7035555556 ... S: S: S: S: Section 2.9, page 7 says In conjunction with this disclosure requirement, this mapping includes data elements that allow a client to identify elements that require exceptional server operator handling to allow or restrict disclosure to third parties. but then also A value of "false" or "0" (zero) notes a client preference to not allow disclosure of the specified elements as an exception to the stated data collection policy. Between "require .. operator handling" and "client preference", I'm not sure of the obligation the server has to refrain from disclosing data elements that the client has requested be prohibited from disclosing But at any rate, this example seems to me to be ignoring the client's request. True? If so, and allowed, it would deserve more discussion. sect 3.2, page 17 Server operators SHOULD confirm that a client is authorized to perform a transform command on a given object. Any attempt to transform an object by an unauthorized client MUST be rejected, and the server MUST return a 2201 response code to the client to note that the client lacks privileges to execute the requested command. Is that "MUST be rejected" only in the case that the server operator decides that they will confirm authorization? sect 3.2.2, page 20 A contact object SHOULD NOT be deleted if it is associated with other known objects. An associated contact SHOULD NOT be deleted until associations with other known objects have been broken. A server SHOULD notify clients that object relationships exist by sending a 2305 error response code when a command is attempted and fails due to existing object relationships. Do these object associations and object relationships include cases where the status is "clientDeleteProhibited" or "serverDeleteProhibited"? If not, should there be this (or some other) error message in those status cases as well? The prohibition status values don't seem to show up in the discussions of server response to commands. Perhaps those prohibitions are covered under the "An EPP error response MUST be returned if the ... command cannot be processed for any reason". I believe an explicit discussion would be good, including the appropriate error code. (Same comment in the Transfer and Update commands.) sect 3.2.5, page 24 At least one , , or element MUST be provided if the command is not being extended. All of these elements MAY be omitted if an extension is present. The and elements contain the following child elements: - One or more elements that contain status values to be associated with or removed from the object. When specifying a value to be removed, only the attribute value is significant; element text is not required to match a value for removal. Who is responsible for ensuring the valid status combinations discussed in sect 2.2? I.e., if the client is adding a prohibition, does the server remove the "ok" status or must the client include that removal in the update? if the removal is in the same update, does the order in the update matter (removal first?)? Note: the example adds a prohibition without removing an "ok" status, implying that the client is not responsible. But it is not necessarily the case that the "ok" status was there, so the implication isn't certain. sect 3.3, page 27 rfc4930bis says: The server MUST also notify the client when offline processing of the action has been completed. Object mappings SHOULD describe standard formats for notices that describe completion of offline processing. Section 3.3 contains an example of the contents of the notification for a create command. But Delete, Update and Transfer may also be pending. Should there be a description of their notification service messages also? --Sandy From weiler@watson.org Thu Jun 4 19:55:42 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72A763A68EA for ; Thu, 4 Jun 2009 19:55:42 -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 EP-XORK9SBMa for ; Thu, 4 Jun 2009 19:55:41 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 7A4233A6899 for ; Thu, 4 Jun 2009 19:55:41 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n552thWG095837 for ; Thu, 4 Jun 2009 22:55:43 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n552tg7o095834 for ; Thu, 4 Jun 2009 22:55:43 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 4 Jun 2009 22:55:42 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Fri, 05 Jun 2009 03:55:43 +0100 (BST) Subject: [secdir] Assignments for June 11th X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 02:55:42 -0000 We'd had a surge in workload: we've gone through the entire rotation in the last month. Derek Atkins is next. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-06-18 Dave Cridland T draft-housley-aes-key-wrap-with-pad-02 For telechat 2009-07-16 Glen Zorn T draft-solinas-suiteb-cert-profile-03 Last calls and special requests: Ran Canetti draft-eronen-enterprise-number-documentation-01 Dave Cridland draft-ietf-behave-nat-behavior-discovery-06 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Shawn Emery draft-ietf-avt-app-rtp-keepalive-05 Steve Hanna draft-peterson-rai-rfc3427bis-01 Steve Hanna draft-ietf-avt-rtcpssm-18 Dan Harkins draft-ietf-avt-rtp-mps-02 David Harrington draft-dusseault-impl-reports-02 Paul Hoffman draft-ietf-sip-eku-05 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Scott Kelly R draft-ietf-enum-enumservices-guide-16 Scott Kelly draft-livingood-woundy-p4p-experiences-07 Stephen Kent draft-ietf-geopriv-l7-lcp-ps-09 Julien Laganier draft-ietf-sip-certs-07 Julien Laganier draft-hollenbeck-rfc4934bis-01 Barry Leiba draft-hollenbeck-rfc4931bis-01 Catherine Meadows draft-ietf-speechsc-mrcpv2-19 Catherine Meadows draft-ietf-rmt-bb-lct-revised-09 Catherine Meadows draft-hollenbeck-rfc4930bis-01 Vidya Narayanan draft-ietf-sip-saml-06 Vidya Narayanan draft-ietf-enum-3761bis-04 Chris Newman draft-ietf-sip-connect-reuse-13 Magnus Nystrom draft-ietf-sipping-cc-framework-11 Hilarie Orman draft-ietf-geopriv-lbyr-requirements-07 Radia Perlman draft-ietf-geopriv-civic-address-recommendations-02 Eric Rescorla R draft-ietf-geopriv-http-location-delivery-14 Eric Rescorla draft-ietf-enum-iax-05 Joe Salowey draft-ietf-geopriv-lis-discovery-11 Joe Salowey draft-dawkins-nomcom-dont-wait-03 Stefan Santesson draft-ietf-tsvwg-rsvp-l3vpn-02 Juergen Schoenwaelder draft-ietf-ospf-ospfv3-mib-14 Yaron Sheffer draft-iana-special-ipv4-registry-01 Hannes Tschofenig draft-ietf-pce-monitoring-04 Hannes Tschofenig draft-ietf-l2tpext-circuit-status-extensions-04 Sean Turner draft-ietf-ltans-dssc-08 Carl Wallace draft-ietf-ntp-autokey-05 Sam Weiler draft-chown-v6ops-rogue-ra-03 Sam Weiler draft-ietf-ospf-dynamic-hostname-03 Brian Weis draft-ietf-pce-p2mp-app-01 Brian Weis draft-ietf-pce-inter-layer-frwk-10 Nico Williams draft-ietf-v6ops-ra-guard-03 Nico Williams draft-ietf-pcn-marking-behaviour-03 Tom Yu draft-ietf-pwe3-ms-pw-arch-06 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 Larry Zhu draft-ietf-ecrit-location-hiding-req-01 Larry Zhu draft-ietf-tcpm-rfc2581bis-05 From Radia.Perlman@sun.com Thu Jun 4 20:54:26 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DF5D3A6AB6; Thu, 4 Jun 2009 20:54: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 a-hQ-6HFS5SM; Thu, 4 Jun 2009 20:54:25 -0700 (PDT) Received: from mail-mta.sunlabs.com (edge.sunlabs.com [204.153.12.50]) by core3.amsl.com (Postfix) with ESMTP id 4797C3A67F7; Thu, 4 Jun 2009 20:54:25 -0700 (PDT) Received: from mail.sunlabs.com ([152.70.2.186]) by mail-mta.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0KKQ00JDOYURB500@mail-mta.sfvic.sunlabs.com>; Thu, 04 Jun 2009 20:54:28 -0700 (PDT) Received: from [129.150.32.227] ([192.18.101.5]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0KKQ00F71YUPX911@mail.sunlabs.com>; Thu, 04 Jun 2009 20:54:26 -0700 (PDT) Date: Thu, 04 Jun 2009 20:54:14 -0700 From: Radia Perlman To: iesg@ietf.org, secdir@ietf.org, alexander.mayrohofer@nic.at, karlheinz.wolf@nic.at Message-id: <4A2896E6.6080508@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Subject: [secdir] secdir review of draft-ietf-geopriv-civic-address-recommendations-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 03:54:26 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how to write documents that describe how to extract address information from various sources to be translated into the format for the "Presence Information Data Format Location Object" (PIDF-LO) [RFC4119 <./rfc4119>]". I found no security issues with the document. (and only typos I noticed: a missing period at the end of point 5 in section 4.1, "receipients" in 5th bullet of section 3 should be "recipients", missing "of" in 2nd paragraph of 4.2.3 "basic specification *of* which") Radia From ietfdbh@comcast.net Fri Jun 5 10:31:43 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82E003A6CC7 for ; Fri, 5 Jun 2009 10:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.619 X-Spam-Level: X-Spam-Status: No, score=-1.619 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 yNw3BzxHTdwJ for ; Fri, 5 Jun 2009 10:31:42 -0700 (PDT) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 8A5A43A6B95 for ; Fri, 5 Jun 2009 10:31:42 -0700 (PDT) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA09.westchester.pa.mail.comcast.net with comcast id 0HFG1c00F0QuhwU59HXmqa; Fri, 05 Jun 2009 17:31:46 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA02.westchester.pa.mail.comcast.net with comcast id 0HXl1c00E0UQ6dC3NHXl3E; Fri, 05 Jun 2009 17:31:46 +0000 From: "David Harrington" To: Date: Fri, 5 Jun 2009 13:31:44 -0400 Message-ID: <02c701c9e603$7f223b50$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcnmAz+Kk4PK1FiQTeKzEEoZhSMYEQ== Cc: RjS@nostrum.com, ldusseault@commerce.net Subject: [secdir] secdir review of draft-dusseault-impl-reports-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 17:31:43 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes updates to existing processes for implementation and interoperability reports, and provides recommendations about the level of detail required. The document is about IETF standards process, is well written, and introduces no new security concerns. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com From yaronf@checkpoint.com Sat Jun 6 04:30:49 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA893A659B; Sat, 6 Jun 2009 04:30:49 -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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6AeJNb4gCCS; Sat, 6 Jun 2009 04:30:44 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7EBE23A6A8D; Sat, 6 Jun 2009 04:30:43 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2E81629C004; Sat, 6 Jun 2009 14:30:50 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B404429C001; Sat, 6 Jun 2009 14:30:49 +0300 (IDT) X-CheckPoint: {4A2A51BA-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n56BUi3d013688; Sat, 6 Jun 2009 14:30:45 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sat, 6 Jun 2009 14:30:45 +0300 From: Yaron Sheffer To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-iana-special-ipv4-registry@tools.ietf.org" Date: Sat, 6 Jun 2009 14:30:41 +0300 Thread-Topic: SecDir review of draft-iana-special-ipv4-registry-01 Thread-Index: AcnmE208cUQsiY1ASkmgEeKSVSWSUwAg/Q8Q Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898EBAA@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_018D_01C9E6B3.5E9A6140" MIME-Version: 1.0 Subject: [secdir] SecDir review of draft-iana-special-ipv4-registry-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 11:30:49 -0000 ------=_NextPart_000_018D_01C9E6B3.5E9A6140 Content-Type: multipart/alternative; boundary="----=_NextPart_001_018E_01C9E6B3.5E9A6140" ------=_NextPart_001_018E_01C9E6B3.5E9A6140 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document consists of a directive to IANA on creating and managing an IPv4 Special Purpose Address registry. It took me some time to realize this document is about all of two hundred fifty six IP addresses. It sure seems to be a lot of effort for very few addresses. General - The document is missing a reference to [rfc3330bis] (which should be Normative). Does "[date]" refer to this document's publication date? - The document is copied from RFC 4773, in places a bit too verbatim. In particular it mentions "scoped, local, or private contexts", which rarely apply to IPv4. Today even link-local IPv4 addresses are usually treated as error indications, unfortunately. Security I would have been much happier with a Security Considerations section that said there are no such considerations. The current text includes: "This registry is intended to provide an authoritative source of information regarding the currency and intended purpose of IPv4 Special Purpose address blocks that are designated from the IANA-administered IPv4 Special Purpose address pool. This is a small step towards the creation of a comprehensive registry framework that can be used as a trust point for commencing a chain of address validation." I am not aware of specified mechanisms to securely allocate, deallocate and query the ownership and status of IP addresses. Perhaps it's just my ignorance, but if any such mechanisms exist, they should be referenced from the document. In the absence of such security mechanisms, the above paragraph doesn't make sense to me, in particular when the scope current is just 256 addresses. ------=_NextPart_001_018E_01C9E6B3.5E9A6140 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the security = directorate's ongoing effort to review all IETF documents being processed by the = IESG.  These comments were written primarily for the benefit of the security area = directors.  Document editors and WG chairs should treat these comments just like any = other last call comments.

 

This document consists of a directive to IANA on creating and = managing an IPv4 Special Purpose Address registry. It took me some time to = realize this document is about all of two hundred fifty six IP addresses. It sure = seems to be a lot of effort for very few addresses.

 

General

 

-        The = document is missing a reference to [rfc3330bis] (which should be Normative). Does = "[date]" refer to this document’s publication date?

-        The = document is copied from RFC 4773, in places a bit too verbatim. In particular it = mentions "scoped, local, or private contexts", which rarely apply to = IPv4. Today even link-local IPv4 addresses are usually treated as error = indications, unfortunately.

 

Security

 

I would have been much happier with a Security Considerations = section that said there are no such considerations. The current text = includes:

 

"This registry is intended to provide an authoritative source of information regarding the currency and intended = purpose of IPv4 Special Purpose address blocks that are designated from the IANA-administered IPv4 Special Purpose address pool.  This is a = small step towards the creation of a comprehensive registry framework that can be = used as a trust point for commencing a chain of address = validation."

 

I am not aware of specified mechanisms to securely allocate, = deallocate and query the ownership and status of IP addresses. Perhaps it’s = just my ignorance, but if any such mechanisms exist, they should be referenced = from the document. In the absence of such security mechanisms, the above = paragraph doesn’t make sense to me, in particular when the scope current is just 256 = addresses.

------=_NextPart_001_018E_01C9E6B3.5E9A6140-- ------=_NextPart_000_018D_01C9E6B3.5E9A6140 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDYwNjExMzA0MVowIwYJKoZIhvcNAQkEMRYEFLOcyZ2hyUDS M8PDJCIwn8o+VD8eMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA F9Gsw3hjx88Ug7nlDOvlwnUevzWl04Yc3Nxh4285HsHBx6huM7oC86EZJqDuJIMzSUbpNQt2PC34 when1RaX83hB4U/Xok3/7ekWt7t8dV8dloE7uTDgsbxrMMuGPXJ/RYawLZMvDYS6zxzIlfX0dVTk bPqlgwaNFVijP95fWWiwEP7ZHCkimwr1oWsJIV3e8IYXAtyJjj1623hODD01Cjxji7/QtPEwGvDR GbCowuN0bu+PAPXpaRGFqlW/cUBmpJlgRs96+m7C06aLUB3Wgc8YXgy3gf7PHl31zYst+l/qgr1f PzvVFSkY3fkgJjBT+kxhiuX1Lt2BGHg7D0qiNwAAAAAAAA== ------=_NextPart_000_018D_01C9E6B3.5E9A6140-- From gih@apnic.net Sat Jun 6 16:00:03 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 687703A6969; Sat, 6 Jun 2009 16:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10PshwIG4csB; Sat, 6 Jun 2009 16:00:02 -0700 (PDT) Received: from asmtp.apnic.net (oregano.apnic.net [IPv6:2001:dc0:2001:a:4608::60]) by core3.amsl.com (Postfix) with ESMTP id CD8DD3A6817; Sat, 6 Jun 2009 16:00:01 -0700 (PDT) Received: from [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10] (unknown [IPv6:2001:dc0:2001:10:217:f2ff:fec9:1b10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id D4BF0110041; Sun, 7 Jun 2009 09:00:03 +1000 (EST) Message-Id: <4C488261-A489-4B1F-899D-161EEA05DE49@apnic.net> From: Geoff Huston To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898EBAA@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 7 Jun 2009 09:00:01 +1000 References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898EBAA@il-ex01.ad.checkpoint.com> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Sun, 07 Jun 2009 13:57:05 -0700 Cc: "iesg@ietf.org" , "draft-iana-special-ipv4-registry@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-iana-special-ipv4-registry-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 23:00:03 -0000 Hi Yaron, Thanks indeed for this review of the draft.. On 06/06/2009, at 9:30 PM, Yaron Sheffer wrote: > I have reviewed this document as part of the security directorate's =20= > ongoing effort to review all IETF documents being processed by the =20 > IESG. These comments were written primarily for the benefit of the =20= > security area directors. Document editors and WG chairs should =20 > treat these comments just like any other last call comments. > > This document consists of a directive to IANA on creating and =20 > managing an IPv4 Special Purpose Address registry. It took me some =20 > time to realize this document is about all of two hundred fifty six =20= > IP addresses. It sure seems to be a lot of effort for very few =20 > addresses. We have managed to drive ourselves into areas of confusion over =20 addresses in the past over too great a level of informality in aspects =20= of address administration and this is one more element of adding some =20= guidance for IANA and the IETF in terms of the process of making =20 address assignments through IANA for the purposes described in Section =20= 2 of this document. Without this direction IANA has no clear process =20 that it must follow to make such assignments, and the results, if =20 judged by what we've done in the past, are somewhat haphazard at best. > > General > > - The document is missing a reference to [rfc3330bis] (which =20= > should be Normative). Yes, agreed, although I'm not sure of the Normative / Informative =20 delineation in this case - but I'm sure that the rfc editor could =20 provide the appropriate advice here. > Does "[date]" refer to this document=92s publication date? yes > - The document is copied from RFC 4773, in places a bit too =20 > verbatim. In particular it mentions "scoped, local, or private =20 > contexts", which rarely apply to IPv4. Today even link-local IPv4 =20 > addresses are usually treated as error indications, unfortunately. I would not agree with such a blanket assertion for IPv4. 192.88.99.1 =20= appears to be intended to operate as a scoped context address, for =20 example. > > Security > > I would have been much happier with a Security Considerations =20 > section that said there are no such considerations. The current text =20= > includes: > > "This registry is intended to provide an authoritative source of =20 > information regarding the currency and intended purpose of IPv4 =20 > Special Purpose address blocks that are designated from the IANA-=20 > administered IPv4 Special Purpose address pool. This is a small =20 > step towards the creation of a comprehensive registry framework that =20= > can be used as a trust point for commencing a chain of address =20 > validation." > > I am not aware of specified mechanisms to securely allocate, =20 > deallocate and query the ownership and status of IP addresses. =20 > Perhaps it=92s just my ignorance, but if any such mechanisms exist, =20= > they should be referenced from the document. In the absence of such =20= > security mechanisms, the above paragraph doesn=92t make sense to me, =20= > in particular when the scope current is just 256 addresses. This is a cut and paste from RFC4773. There is a rich history of =20 ambiguity over the details of many address allocations, and this =20 document is part of an intention to clarify procedure and registry =20 outcomes, and yes, such a registry is a potential anchor point for a =20 more formal mechanism that could validate attestations relating to =20 addresses and their use. However the technology is still the subject =20 of study in the IETF in the SIDR WG in particular, and reference to =20 any stable outcomes of that WG appear to be somewhat premature, nor =20 would stalling the process of this document to await such outcomes =20 serve any useful purpose as far as I am aware. Thanks, Geoff=20= From Sandra.Murphy@cobham.com Mon Jun 8 07:01:07 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551493A6ADC; Mon, 8 Jun 2009 07:01:07 -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 0borT5feR8dx; Mon, 8 Jun 2009 07:01:06 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 6C0643A6848; Mon, 8 Jun 2009 07:01:06 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id n58E19MV012948; Mon, 8 Jun 2009 09:01:09 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id n58DxIFf026269; Mon, 8 Jun 2009 09:01:08 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([10.71.1.67]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Jun 2009 09:59:09 -0400 Date: Mon, 8 Jun 2009 09:59:04 -0400 (Eastern Daylight Time) From: Sandra Murphy To: ananth@cisco.com, mdalal@cisco.com Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 08 Jun 2009 13:59:09.0749 (UTC) FILETIME=[4BB5BE50:01C9E841] Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] draft-ietf-tcpm-tcpsecure X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 14:01:07 -0000 I've been on the road, so this is just a quick note to say that I still have questions, with a promise of more full answer when I get back to the office tomorrow. All the following done really from memory from a re-review yesterday. Just so you know I haven't forgotten you. About quoting text: The example you point to of what each mitigation says is a good case. (what is "rg"?) You posit a case 1 and case 2. This is a summary of what 793 says, not a quote. 793 spreads the discussion over 2 pages. your case 1 is represented in a parenthetical remark in an "otherwise" clause - hard to find. And you have a typo in the inequality. And the case 2 in 793 is broken out over three different groupings of states. Do you mean the new ACK to be generated in all three state groups? About the stingency. If UNA is 1000, Max.snd.wnd is 50, and the ack is 975, then in 793, the ack is < UNA and so "it is ignored", in your draft the ack is > UNA-max.snd.wnd so it is acceptable. So your draft accepts more ACKs that 793. Have I lost my ability to tell > from X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C57A3A6A88; Mon, 8 Jun 2009 16:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 5MNGQLVyu21V; Mon, 8 Jun 2009 16:22:52 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 684CD3A63CB; Mon, 8 Jun 2009 16:22:52 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E975EA888108; Mon, 8 Jun 2009 16:22:57 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 8 Jun 2009 16:22:57 -0700 (PDT) Message-ID: <8ef65cd7e977e2d73a3702a524cada0b.squirrel@www.trepanning.net> Date: Mon, 8 Jun 2009 16:22:57 -0700 (PDT) From: "Dan Harkins" To: iesg@ietf.org, secdir@ietf.org, avt-chars@tools.ietf.org, fluffy@cisco.com User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: frans.de.bont@phillips.com, "malte.schmidt@dolby.com" , stefan.doehla@iis.fraunhofer.de Subject: [secdir] SECDIR review of draft-ietf-avt-rtp-mps-02.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 23:22:58 -0000 Hi, I have reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document extends the RTP payload format to transport MPEG Surround multi-channel audio. By extending the RTP payload format, this document states that it is "subject to the security considerations of the RTP specification" itself. It also informatively cuts-and-pastes from the security considerations of RFC 3640. I see no problem with that. While it's not an issue that needs addressing in this draft, it seems to me that this draft takes advantage of a covert channel in an ISO Standard on the coding of audo-visual objects-- "skip unknown extension data" in a stream. RFC 3640 discusses the possibility of crashing a system using this bug^H^H^Hfeature but does not mention the covert channel possibilities. It would be nice to mention that in a successor to RFC 3640 if there ever is one. Minor issues: - missing reference to SDP, RFC 2327 - please spell out "Advanced Audio Coding" before using the acronym AAC (assuming that's what it meant). - the term "High Efficiency AAC" is used after the acronym HE-AAC. Please reverse that. regards, Dan. From hilarie@purplestreak.com Mon Jun 8 21:52:25 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21883A6B30; Mon, 8 Jun 2009 21:52:25 -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 1yeXloVEOAsV; Mon, 8 Jun 2009 21:52:24 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by core3.amsl.com (Postfix) with ESMTP id ED1193A6B75; Mon, 8 Jun 2009 21:52:23 -0700 (PDT) Received: from mx01.mta.xmission.com ([166.70.13.211]) by out02.mta.xmission.com with esmtp (Exim 4.62) (envelope-from ) id 1MDtK0-0001vP-GW; Mon, 08 Jun 2009 22:52:28 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=localhost.localdomain) by mx01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MDtJz-0007Kt-Pk; Mon, 08 Jun 2009 22:52:28 -0600 Received: from localhost.localdomain (tobermory [127.0.0.1]) by localhost.localdomain (8.12.10/8.12.10) with ESMTP id n594pIKV012950; Mon, 8 Jun 2009 22:51:18 -0600 Received: (from ho@localhost) by localhost.localdomain (8.12.10/8.12.10/Submit) id n594pGcD012946; Mon, 8 Jun 2009 22:51:16 -0600 Date: Mon, 8 Jun 2009 22:51:16 -0600 Message-Id: <200906090451.n594pGcD012946@localhost.localdomain> X-Authentication-Warning: localhost.localdomain: ho set sender to hilarie using -f From: "Hilarie Orman" To: secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx01.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=no signature X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Thu, 25 Oct 2007 00:26:12 +0000) X-SA-Exim-Scanned: Yes (on mx01.mta.xmission.com) Cc: fluffy@cisco.com, rmarshall@telecomsys.com, acooper@cdt.org, iesg@ietf.org, Lisa.Dusseault@messagingarchitects.com Subject: [secdir] Review of draft-ietf-geopriv-lbyr-requirements-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 04:52:26 -0000 Requirements for a Location-by-Reference Mechanism draft-ietf-geopriv-lbyr-requirements-07 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The draft is about the requirements for using an indirect reference ("location by reference") for geolocation information. The geolocation protocol can return a URI for retrieving the information that would be conveyed if "location by value" were used. Much of the document is about ensuring privacy of location information. --- In section 2, terminology, "Location-by-Value (LbyV): Using location information in the form of a location object (LO), such as a PIDF-LO." This is copied from RFC3693, but it is my understanding that PIDF-LO is an absolute requirement for geopriv-lbyr, so a note to that effect would be helpful here. --- The document would be improved by consistently using the term "target" for the thing to be located, instead of the occasional "user" or "device". If it is important to distinguish them, one could say "target's user", for example. --- "Section 4, High Level Requirements, item C8, Location URI Not guessable." This is a required default behavior. I'm not sure why the URI shouldn't be guessable, given that the PIDF-LO information can be protected through mime security. A clarifying statement should be added. --- "C6. Reuse indicator: There SHOULD be a way to allow a client to control whether a location URI can be resolved once only, or multiple times." What is the point of one-time use? Why not just send the information directly, instead of a URI? One could overload the URI format and encode the encrypted location info in the URI itself. Is the "client" the target? Must the server return an error if a one-time URI is reused? Or can it return the old information? --- The covert channel of the protocol messages is not mentioned, but should be. If user A subscribes to location information for user B, then every time A gets a location update an observer may know that B has moved. There are mitigations, such as sending the information at regular time intervals, even if the target is stationary. Hilarie From secdir-bounces@mit.edu Mon Jun 8 23:19:22 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 971583A6C36 for ; Mon, 8 Jun 2009 23:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 HHQvxTzorE69 for ; Mon, 8 Jun 2009 23:19:20 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 974593A6B81 for ; Mon, 8 Jun 2009 23:19:20 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n596JPdi015586 for ; Tue, 9 Jun 2009 02:19:25 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n596JN09015574 for ; Tue, 9 Jun 2009 02:19:23 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n596JGXr003157 for ; Tue, 9 Jun 2009 02:19:16 -0400 (EDT) Received: from doar.tau.ac.il (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 498237F16FF for ; Tue, 9 Jun 2009 02:19:13 -0400 (EDT) Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by mit.edu with ESMTP id vyEzLvNcX5i8n4B2 for ; Tue, 09 Jun 2009 02:19:13 -0400 (EDT) Received-SPF: pass (mit.edu: domain of canetti@post.tau.ac.il designates 132.66.16.26 as permitted sender) receiver=mit.edu; client_ip=132.66.16.26; envelope-from=canetti@post.tau.ac.il; Received: from [10.0.0.5] (bzq-79-182-104-115.red.bezeqint.net [79.182.104.115]) by doar.tau.ac.il (Postfix) with ESMTP id 0665FBEFB; Tue, 9 Jun 2009 09:19:13 +0300 (IDT) Message-ID: <4A2DFEDF.2030202@post.tau.ac.il> Date: Tue, 09 Jun 2009 09:19:11 +0300 From: canetti User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: secdir@mit.edu, pasi.eronen@nokia.com X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] SECDIR review of draft-eronen-enterprise-number-documentation-01.txt X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 06:19:22 -0000 *** I have reviewed this document as part of the security directorate's *** ongoing effort to review all IETF documents being processed by the *** IESG. These comments were written primarily for the benefit of the *** security area directors. Document editors and WG chairs should treat *** these comments just like any other last call comments. The draft describes a specific vendor number (32473) to be used in documentation and examples. I see no security issues here. Best, Ran _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From turners@ieca.com Tue Jun 9 07:27:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03EF73A6C39 for ; Tue, 9 Jun 2009 07:27:21 -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 R5DH-BmLYlHq for ; Tue, 9 Jun 2009 07:27:20 -0700 (PDT) Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by core3.amsl.com (Postfix) with SMTP id C0B1F3A6CCD for ; Tue, 9 Jun 2009 07:27:19 -0700 (PDT) Received: (qmail 41805 invoked from network); 9 Jun 2009 14:27:23 -0000 Received: from unknown (HELO thunderfish.local) (turners@129.6.248.49 with plain) by smtp107.biz.mail.re2.yahoo.com with SMTP; 9 Jun 2009 14:27:23 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: rsgvmv0VM1nbaI2YI8kTWwe8nD4OPtpvtZhWH37YoSNNi.nvLbwXlGQYZ2BuQ8wHPximh..bdRMVS8Z_igDPaYtgCvh9WjyzODbjwPeuQpjtg6XJhmKT63ZtgNuF3IasJHhDowv.GSB9p7qGC332e8j7mTzybLTCwDprURmy2K8zacJwBojIo0CF8fLNQMdrjPifozgTGha_PSIgxRCmxvaLqWApcta3NvQa7A8TbEpzBPotd__kO1nLCwBQAGMtGBeYFX76exIVr9trvgnIy1lIuX_xTx8hUmVObHxpIzfggrl.Fd_Qva9_Xf3sAWhPEs67 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A2E7143.40103@ieca.com> Date: Tue, 09 Jun 2009 10:27:15 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: secdir , draft-ietf-ltans-dscc@tools.ietf.org, ltans-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-ltans-dssc-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 14:27:21 -0000 I have reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Doc: Data Structure for the Security Suitability of Cryptographic Algorithms (DSSC) Track: Proposed Standard Summary: Ready except for some nits. The first paragraph in Section 4 refers to RFC 3447 and FIPS 186-1 for RSA and DSA and further it goes on to say these algorithms can be combined with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 and RIPEMD-160. I believe these are the wrong references for DSA (and the link doesn't work) and one of the RSA-SHA combos. FIPS 186-1 only specifies SHA-1 for use with DSA and only for certain key sizes. I think this is more correct: For 512-bit DSA with SHA-1 see [FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see [FIPS186-2] with Change Notice 1, for 1024-bit and above DSA with SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 see [FIPS186-3]. I don't believe 512-bit DSA with SHA-224, SHA-256, SHA-384, and SHA-512 are defined. FIPS 186-2 with Change Notice 1 required key sizes be 1024-bit and FIPS 186-3 allowed key sizes from 1024-3072. Where is DSA or RSA with RIPEMD-160 defined? RFC 3447 doesn't specify RSA with SHA-224. Maybe pointing to RFC 4055 would be better? spt From secdir-bounces@mit.edu Tue Jun 9 09:15:31 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B5A3A687A for ; Tue, 9 Jun 2009 09:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 1gljKZky+bAI for ; Tue, 9 Jun 2009 09:15:28 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 44FBB3A67D8 for ; Tue, 9 Jun 2009 09:15:23 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n59GFSVG026182 for ; Tue, 9 Jun 2009 12:15:28 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n59GFPj7026131 for ; Tue, 9 Jun 2009 12:15:25 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n59GFGFa015325 for ; Tue, 9 Jun 2009 12:15:16 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 09008827E27 for ; Tue, 9 Jun 2009 12:15:11 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id ll6wNFEXhxrQKmhY for ; Tue, 09 Jun 2009 12:15:11 -0400 (EDT) Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D58728C19A; Tue, 9 Jun 2009 09:15:04 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B476D3A68DD; Tue, 9 Jun 2009 09:15:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090609161501.B476D3A68DD@core3.amsl.com> Date: Tue, 9 Jun 2009 09:15:01 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Tue, 09 Jun 2009 09:22:47 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 16:15:31 -0000 A modified charter has been submitted for the Behavior Engineering for Hindrance Avoidance (behave) working group in the Transport Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 16, 2009. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- Last Modified: 2009-05-27 Current Status: Active Working Group Chair(s): Dan Wing Dave Thaler Transport Area Director(s): Magnus Westerlund Lars Eggert Transport Area Advisor: Magnus Westerlund Mailing Lists: General Discussion: behave@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/behave Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group: The behavior of NATs varies from one implementation to another. As a result it is very difficult for applications to predict or discover the behavior of these devices. Predicting and/or discovering the behavior of NATs is important for designing application protocols and NAT traversal techniques that work reliably in existing networks. This situation is especially problematic for end- to-end applications where one or both end-points are behind a NAT, such as multiuser games, interactive multimedia and P2P download. The working group documents best current practices to enable NATs to function in as deterministic a fashion as possible. The NAT behavior practices will be application independent. This has already completed for UDP, TCP, DCCP, Multicast and ICMP. It continues with SCTP and any additional protocol deemed necessary to handle. The WG has documented approaches for characterizing and testing NAT devices. BEHAVE will develop protocol-independent toolkits usable by application protocols for NAT traversal. The WG has already produced an update of the binding discovery protocol STUN. It will now produce a relay protocol that focuses on security that is usable with both IPv4 and IPv6, and capable of relaying between the two IP versions. The goal of this work is to encourage migration to IPv6. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. The BEHAVE WG will design solutions for the following six translation scenarios; other scenarios are out of scope: 1. An IPv6 network to IPv4 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function is intended to service a specific IPv6 network of arbitary size. Port translation is necessary on the IPv4 side for efficient IPv4 address usage. 2. IPv6 Internet to an IPv4 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translator function services is intended to service a specific IPv4 network using either private or public IPv4 addresses. Because this scenario has different constraints compared to (1), e.g. the IPv4 hosts that are to be reachable over IPv6 can be enumerated. The WG should attempt to design a simpler solution with less impact on applications. 3. An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. 4. IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. 5. An IPv6 network to an IPv4 network, i.e., perform translation between IPv6 and IPv4 for packets in uni- or bi-directional flows that are initiated from an IPv6 host towards an IPv4 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). 6. An IPv4 network to an IPv6 network, i.e., perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translation function is intended to service a specific IPv6 network of arbitrary size and a specific IPv4 network of arbitrary size (neither of which are the Internet). All translation solutions shall be capable of handling flows using TCP, UDP, DCCP, and SCTP, unless they prevent a timely completion of the work item. The fundamental parts of ICMP are also required to work. Additional protocols directly on top of IP may be supported. Translation mechanisms must handle IP fragmentation. The translators should support multicast traffic and its control traffic (IGMP and MLD) across them, both Single Source Multicast (SSM) and Any Source Multicast (ASM). However, the WG may determine that it becomes too complex or too difficult to realize with maintained functionality, for some or all cases of multicast functionality. Translation mechanisms cannot transparently support protocols that embed network addresses within their protocol messages without application level gateways (ALGs). Because ALGs have security issues (like blocking usage of TLS), are error prone and brittle, and hinder application development, the usage of ALGs in the defined translators should be avoided. Instead application developers will need to be aware and use mechanisms that handle the address family translation. ALGs may be considered only for the most crucial of legacy applications. DNS is a crucial part in making a large number of applications work across a translator. Thus the solution to the above translation cases shall include recommendations for DNS. If additional DNS functionality is needed, it may be developed. Any DNS extensions must be developed together with the DNSEXT WG, including issuing a joint WG last call for any documents. The WG needs to determine the best method for providing address space to a translator in the different deployment cases and documenting the pros and cons of the suggested approaches. The WG is to seek input from the Routing, Operations and Internet areas. Solutions may solve more than one of the cases, however timely delivery is more important than a unified solution. Goals and Milestones: Done Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Done Submit a BCP that defines TCP behavioral requirements for NATs to IESG Done Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Done Submit informational that discusses current NAT traversal techniques used by applications Done Submit BCP that defines multicast UDP Done Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG Done Submit informational document for rfc3489bis test vectors Done Submit experimental document that describes how an application can determine the type of NAT it is behind Done Submit BCP document for DCCP NAT behavior Jun 2009 Submit BCP document for SCTP NAT behavior Done Submit standards-track relay protocol Done Determine relative prioritization of the four translation cases. Sep 2009 Submit standards-track document for relaying of a TCP bytestream Jun 2009 Submit standard-track document of an IPv6 relay protocol to IESG Done Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components. Jul 2009 Submit standards-track TURN-URI document Sep 2009 Submit informational for framework for IPv6/IPv4 translation document Sep 2009 Submit standards-track stateless IPv6/IPv4 translation document Sep 2009 Submit standards-track stateful IPv6/IPv4 translation document Sep 2009 Submit standards-track DNS rewriting for IPv6/IPv4 translation document Nov 2009 Submit standards-track FTP ALG for IPv6/IPv4 translation document Nov 2009 Submit standards-track IPv6 prefix for IPv6/IPv4 translator document Mar 2010 Submit BCP large scale NAT requirements document _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Tue Jun 9 14:06:30 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B20E28C208 for ; Tue, 9 Jun 2009 14:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 OmB+F9jzgQCN for ; Tue, 9 Jun 2009 14:06:29 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 52CFF28C1DD for ; Tue, 9 Jun 2009 14:06:29 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n59L6ZTQ018397 for ; Tue, 9 Jun 2009 17:06:35 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n59L6YRx018382 for ; Tue, 9 Jun 2009 17:06:34 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n59L6UQk013295 for ; Tue, 9 Jun 2009 17:06:30 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id A120D1FE3A8E for ; Tue, 9 Jun 2009 12:00:14 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id BFHYI2tM8xap2in1 for ; Tue, 09 Jun 2009 12:00:14 -0400 (EDT) Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7793628C168; Tue, 9 Jun 2009 09:00:07 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F09F43A69DD; Tue, 9 Jun 2009 09:00:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090609160001.F09F43A69DD@core3.amsl.com> Date: Tue, 9 Jun 2009 09:00:01 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Tue, 09 Jun 2009 14:14:02 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Geographic Location/Privacy (geopriv) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 21:06:30 -0000 A modified charter has been submitted for the Geographic Location/Privacy (geopriv) working group in the Real-time Applications and Infrastructure Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 16, 2009. Geographic Location/Privacy (geopriv) -------------------------------------- Last Modified: 2009-05-29 Chair(s): - Richard Barnes - Alissa Cooper Real-time Applications and Infrastructure Area Director(s): - Robert Sparks - Cullen Jennings Real-time Applications and Infrastructure Area Advisor: - Cullen Jennings Technical Advisor(s): - Lisa Dusseault Mailing Lists: General Discussion: geopriv@ietf.org To Subscribe: geopriv-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/geopriv/index.html Description of Working Group: The IETF has recognized that many applications are emerging that require geographic and civic location information about resources and entities, and that the representation and transmission of that information has significant privacy and security implications. We have created a suite of protocols that allow such applications to represent and transmit such location objects and to allow users to express policies on how these representations are exposed and used. The IETF has also begun working on creating applications that use these capabilities, for emergency services, general real-time communication, and other usages. The GEOPRIV working group is chartered to continue to develop and refine representations of location in Internet protocols, and to analyze the authorization, integrity, and privacy requirements that must be met when these representations of location are created, stored, and used. The group will create and refine mechanisms for the transmission of these representations that address the requirements that have been identified. The working group will work with other IETF working groups and other standards development organizations that are building applications that use location information to ensure that the requirements are well understood and met, and that no additional security or privacy issues related to location are left unaddressed as these location information is incorporated into other protocols. It remains a goal of the GEOPRIV working group to deliver specifications of broad applicability that will become mandatory to implement for IETF protocols that are location aware. This working group will not develop location-determining technology. However, the IETF acknowledges that information used in the location- determination process will in some cases need to be carried over the Internet. Where necessary, this working group will develop protocols or protocol extensions to encode location-determination data structures defined elsewhere. This working group will not develop technologies to directly address any particular regulatory requirements (e.g. 9-1-1). The group will continue to coordinate with any other IETF entities that are working on those problems to ensure the technologies created here meet the needs of those entities, and that the authorization, integrity, and privacy requirements on the mechanisms provided by these technologies continue to be met. Goals and Milestones: Done Discuss initial geopriv scenarios and application requirements i-d's Done Discuss initial geographic location privacy and security requirements i-d. Done Initial i-d on geographic information protocol design, including privacy and security techniques. Done Review charter and initial i-ds with AD, and have IESG consider rechartering if necessary. Done Submit geopriv scenarios and application requirements to IESG for publication as Informational RFCs Done Submit security/privacy requirements I-D to IESG for publication As Informational RFC. Done Submit PIDF-LO basic geopriv object draft as a PS Done Initial Common Rules base object draft Done Initial Common Rules GEOPRIV object draft Done Submit DHCP Civil draft as a PS Done Resubmit Conveying Location Objects in RADIUS and Diameter to the IESG for publication as PS Done Submit Additional Civic PIDF-LO types (updating 4119) to the IESG for publication as PS Done Submit minimal HTTP based protocol satisfying baseline requirements specified in the Layer 7 Location Conveyance Protocol Problem Statement and Requirements to the IESG for publication as PS Done Submit PIDF-LO Usage Clarifications and Recommendations (updating 4119) to the IESG for publication as PS Done Submit Layer 7 Location Conveyance Protocol Problem Statement and Requirements to the IESG for publication as Informational Done Submit recommendations for representing civic addresses in PIDF-LO to the IESG for publication as BCP Done Submit Recommendations for Retransmission in SIP Location Conveyance to the IESG for publication as Informational Done Submit Requirements for Location by Reference Protocols to the IESG for publication as Informational Done Submit a LIS Discovery Mechanism to the IESG for publication as a PS Jun 2009 Resubmit Geolocation Policy to the IESG for publication as PS Sep 2009 Submit an draft for DHCP geodetic location to the IESG for publication as PS to obsolete 3825 Sep 2009 Submit an Architecture for Location and Location Privacy to the IESG for publication as Informational Dec 2009 Submit a URI scheme for directly expressing geodetic location to the IESG for publication as PS Dec 2009 Submit a DHCP Option for a Location Uniform Resource Identifier (URI) to the IESG for publication as PS Dec 2009 Submit a Document Format for Filtering and Reporting PIDF-LO Location Notifications to the IESG for publication as PS _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From frans.de.bont@philips.com Wed Jun 10 00:53:47 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 698913A692D; Wed, 10 Jun 2009 00:53:47 -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 eCdQjXuWmR3z; Wed, 10 Jun 2009 00:53:46 -0700 (PDT) Received: from smtpx.philips.com (smtpx.philips.com [168.87.56.21]) by core3.amsl.com (Postfix) with ESMTP id D27303A6838; Wed, 10 Jun 2009 00:53:44 -0700 (PDT) Received: from NLHILEXH05.connect1.local (172.16.153.71) by connect1.philips.com (172.16.156.152) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 10 Jun 2009 09:53:47 +0200 Received: from NLCLUEXM01.connect1.local ([172.16.153.10]) by NLHILEXH05.connect1.local ([172.16.153.71]) with mapi; Wed, 10 Jun 2009 09:53:46 +0200 From: "Bont, Frans de" To: Dan Harkins Date: Wed, 10 Jun 2009 09:51:53 +0200 Thread-Topic: [Fwd: [secdir] SECDIR review of draft-ietf-avt-rtp-mps-02.txt] Thread-Index: AcnokO3WPKnKpNyyQKWHFwdEFZI+gABDMk0A Message-ID: <19FE62CE8D62CF4B96C845DC556B88132FB6C98CA9@NLCLUEXM01.connect1.local> References: <7d80ec7de2f05820800f98692962ab00.squirrel@www.trepanning.net> In-Reply-To: <7d80ec7de2f05820800f98692962ab00.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 10 Jun 2009 02:01:22 -0700 Cc: Cullen Jennings , "Schmidt , Malte" , "secdir@ietf.org" , Ralph, =?iso-8859-1?Q?Stefan_D=F6hla?= , Sperschneider , "iesg@ietf.org" , "avt-chairs@ietf.org" Subject: Re: [secdir] [Fwd: SECDIR review of draft-ietf-avt-rtp-mps-02.txt] X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 07:53:47 -0000 Hi Dan, Thanks for your review, we will update the draft accordingly. With respect to your 'covert channel' comment we want to make the following remark. RFC 3640 says: > However, it is possible to inject non-compliant MPEG streams (Audio, > Video, and Systems) so that the receiver/decoder's buffers are > overloaded, which might compromise the functionality of the receiver > or even crash it. This is a general remark that hold for all audio/video formats, this is not different for the format described in this draft. The mentioned 'covert channel', in ISO/IEC 14496-3 (MPEG-4 Audio) implemented by means of the extension_payload(), is defined as a backward compatible mechanism for transport of extension data inside AAC payloads. Streams using this mechanism are fully compliant MPEG-4 Audio streams and code points, the extension identifiers in ISO/IEC 14496-3, that are not supported by a decoder are gracefully skipped. Best regards, Frans > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: 2009 Jun 09 1:29 AM > To: avt-chairs@ietf.org; Bont, Frans de > Subject: [Fwd: [secdir] SECDIR review of draft-ietf-avt-rtp-mps-02.txt] > > > Hi, > > I fat-fingered your addresses in the following-- chars and phillips. > Sorry about that. > > Dan. > > ---------------------------- Original Message ------------------------- > --- > Subject: [secdir] SECDIR review of draft-ietf-avt-rtp-mps-02.txt > From: "Dan Harkins" > Date: Mon, June 8, 2009 4:22 pm > To: iesg@ietf.org > secdir@ietf.org > avt-chars@tools.ietf.org > fluffy@cisco.com > Cc: frans.de.bont@phillips.com > "malte.schmidt@dolby.com" > > stefan.doehla@iis.fraunhofer.de > ----------------------------------------------------------------------- > --- > > > Hi, > > I have reviewed this document as part of the Security Directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > Security Area directors. Document editors and WG chairs should > treat these comments just like any other last call comments. > > This document extends the RTP payload format to transport MPEG > Surround multi-channel audio. > > By extending the RTP payload format, this document states that it > is "subject to the security considerations of the RTP specification" > itself. It also informatively cuts-and-pastes from the security > considerations of RFC 3640. I see no problem with that. > > While it's not an issue that needs addressing in this draft, it > seems to me that this draft takes advantage of a covert channel > in an ISO Standard on the coding of audo-visual objects-- "skip > unknown extension data" in a stream. RFC 3640 discusses the > possibility of crashing a system using this bug^H^H^Hfeature but > does not mention the covert channel possibilities. It would be nice > to mention that in a successor to RFC 3640 if there ever is one. > > Minor issues: > > - missing reference to SDP, RFC 2327 > - please spell out "Advanced Audio Coding" before using the > acronym AAC (assuming that's what it meant). > - the term "High Efficiency AAC" is used after the acronym HE-AAC. > Please reverse that. > > regards, > > Dan. > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From j.schoenwaelder@jacobs-university.de Wed Jun 10 06:39:58 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A98AE3A6841; Wed, 10 Jun 2009 06:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 QtfkfWiWS7vW; Wed, 10 Jun 2009 06:39:52 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 6E3163A6E83; Wed, 10 Jun 2009 06:39:52 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 79B7FC0018; Wed, 10 Jun 2009 15:39:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vxPk9UNzBn2l; Wed, 10 Jun 2009 15:39:56 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A30FC000A; Wed, 10 Jun 2009 15:39:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E0752B36E96; Wed, 10 Jun 2009 15:39:54 +0200 (CEST) Date: Wed, 10 Jun 2009 15:39:54 +0200 From: Juergen Schoenwaelder To: djoyal@nortel.com, vishwas@ipinfusion.com Message-ID: <20090610133954.GC6346@elstar.local> Mail-Followup-To: djoyal@nortel.com, vishwas@ipinfusion.com, iesg@ietf.org, secdir@ietf.org, ospf-chairs@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: ospf-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-ospf-ospfv3-mib.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 13:39:58 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines a MIB module and I have not spent time reviewing the MIB module itself. Instead, I have been focusing on the security considerations section and I believe the security considerations section needs some improvement in order to comply to RFC 4181 section 3.4 and the current MIB module security template. Let me go through the security considerations in draft-ietf-ospf-ospfv3-mib-13.txt: 6. Security Considerations There are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Up to here, this is standard boilerplate text. What is missing is next is the discussion of the sensitivity / vulnerability of the objects / tables. See RFC 4181 section 3.4 and the boilerplate text posted at . It is recommended that attention be specifically given to implementing the MAX-ACCESS clause in objects in scenarios that DO NOT use SNMPv3 strong security (i.e. authentication and encryption). Extreme caution must be used to minimize the risk of cascading security vulnerabilities when SNMPv3 strong security is not used. When SNMPv3 strong security is not used, these objects should have access of read-only, not read-create. This is new text and I dislike it because it recommends to not implement objects as writable objects. I believe this is not what we want to achieve; we want writable objects implemented since we want operators to decide via access control configuration rules which objects are accessible to whom. Having the implementors take the decision by implemting them read-only makes it impossible for operators to do what they might want to do. SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 3414 [RFC3414] and the View-based Access Control Model RFC 3415 [RFC3415] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. The text in these three paragraphs does not match the current boilerplate and I think it is also wrong since it ignores SNMPv2c and SNMPv3 in noAuth/noPriv mode. This text is also misleading since you can have access control with SNMPv1 - all you miss in that scenario is a secure binding to an authenticated principal. So I suggest to use the current boilerplate text. I am attaching a boilerplate template generated by smidump. Since the MIB module is large, you end up with a long list of objects and it likely makes sense to group them and to discuss things at the level of table rows instead of individual objects or so (smidump is currently not smart enough to do this). Take this as a starting point if you want. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From prvs=4051f18fa=acee@redback.com Wed Jun 10 08:06:27 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910F028C1CA; Wed, 10 Jun 2009 08:06:27 -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 6GJ91U+uWonk; Wed, 10 Jun 2009 08:06:26 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 96F503A6BC0; Wed, 10 Jun 2009 08:06:26 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,341,1241420400"; d="scan'208";a="2328867" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 10 Jun 2009 08:06:33 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 924571C9B43; Wed, 10 Jun 2009 08:06:33 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16969-02; Wed, 10 Jun 2009 08:06:33 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id C6FE41C9B42; Wed, 10 Jun 2009 08:06:31 -0700 (PDT) In-Reply-To: <20090610133954.GC6346@elstar.local> References: <20090610133954.GC6346@elstar.local> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72DEC793-5666-4441-BFD7-05F03956E065@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Wed, 10 Jun 2009 11:06:30 -0400 To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.753.1) Cc: ospf-chairs@tools.ietf.org, secdir@ietf.org, iesg@ietf.org, vishwas@ipinfusion.com, djoyal@nortel.com Subject: Re: [secdir] secdir review of draft-ietf-ospf-ospfv3-mib.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 15:09:00 -0000 Juergen, You refer to an an attached boiler plate for MIB security considerations but I don't see any attachments. In the future, I'd hope the secdir could register their comments earlier in the process. We have taken this document all the way through the IESG and MIB doctors reviews and are not one day away from the end of the IETF last call. Thanks, Acee - OSPF Co-Chair. On Jun 10, 2009, at 9:39 AM, Juergen Schoenwaelder wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The document defines a MIB module and I have not spent time reviewing > the MIB module itself. Instead, I have been focusing on the security > considerations section and I believe the security considerations > section needs some improvement in order to comply to RFC 4181 section > 3.4 and the current MIB module security template. Let me go through > the security considerations in draft-ietf-ospf-ospfv3-mib-13.txt: > > 6. Security Considerations > > There are a number of management objects defined in this MIB that > have a MAX-ACCESS clause of read-write and/or read-create. Such > objects may be considered sensitive or vulnerable in some network > environments. The support for SET operations in a non-secure > environment without proper protection can have a negative > effect on > network operations. > > Up to here, this is standard boilerplate text. What is missing is next > is the discussion of the sensitivity / vulnerability of the objects / > tables. See RFC 4181 section 3.4 and the boilerplate text posted at > . > > It is recommended that attention be specifically given to > implementing the MAX-ACCESS clause in objects in scenarios > that DO NOT use SNMPv3 strong security (i.e. authentication and > encryption). Extreme caution must be used to minimize the risk of > cascading security vulnerabilities when SNMPv3 strong security is > not used. When SNMPv3 strong security is not used, these objects > should have access of read-only, not read-create. > > This is new text and I dislike it because it recommends to not > implement objects as writable objects. I believe this is not what we > want to achieve; we want writable objects implemented since we want > operators to decide via access control configuration rules which > objects are accessible to whom. Having the implementors take the > decision by implemting them read-only makes it impossible for > operators to do what they might want to do. > > SNMPv1 by itself is not a secure environment. Even if the network > itself is secure (for example by using IPsec), even then, > there is > no control as to who on the secure network is allowed to > access and > GET/SET (read/change/create/delete) the objects in this MIB. > > It is recommended that the implementers consider the security > features as provided by the SNMPv3 framework. Specifically, > the use > of the User-based Security Model RFC 3414 [RFC3414] and the > View-based Access Control Model RFC 3415 [RFC3415] is > recommended. > > It is then a customer/user responsibility to ensure that the SNMP > entity giving access to an instance of this MIB, is properly > configured to give access to the objects only to those principals > (users) that have legitimate rights to indeed GET or SET > (change/create/delete) them. > > The text in these three paragraphs does not match the current > boilerplate and I think it is also wrong since it ignores SNMPv2c and > SNMPv3 in noAuth/noPriv mode. This text is also misleading since you > can have access control with SNMPv1 - all you miss in that scenario is > a secure binding to an authenticated principal. So I suggest to use > the current boilerplate text. > > I am attaching a boilerplate template generated by smidump. Since the > MIB module is large, you end up with a long list of objects and it > likely makes sense to group them and to discuss things at the level of > table rows instead of individual objects or so (smidump is currently > not smart enough to do this). Take this as a starting point if you > want. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From dharkins@lounge.org Wed Jun 10 08:19:07 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475073A6C77; Wed, 10 Jun 2009 08:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 cxlqvMdInVvx; Wed, 10 Jun 2009 08:19:06 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 3FC383A6B5B; Wed, 10 Jun 2009 08:19:06 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id AAE82A888108; Wed, 10 Jun 2009 08:19:12 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 10 Jun 2009 08:19:12 -0700 (PDT) Message-ID: In-Reply-To: <19FE62CE8D62CF4B96C845DC556B88132FB6C98CA9@NLCLUEXM01.connect1.local> References: <7d80ec7de2f05820800f98692962ab00.squirrel@www.trepanning.net> <19FE62CE8D62CF4B96C845DC556B88132FB6C98CA9@NLCLUEXM01.connect1.local> Date: Wed, 10 Jun 2009 08:19:12 -0700 (PDT) From: "Dan Harkins" To: "Bont, Frans de" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Cullen Jennings , "Schmidt , Malte" , "secdir@ietf.org" , Stefan =?iso-8859-1?Q?D=F6hla?= , Ralph Sperschneider , "iesg@ietf.org" , "avt-chairs@ietf.org" Subject: Re: [secdir] [Fwd: SECDIR review of draft-ietf-avt-rtp-mps-02.txt] X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 15:19:07 -0000 Hi Frans, RFC 3640 only considers one security issue associated with gracefully disregarding unknown content. It's correct to mention that this capability can be used to compromise or crash a receiver but there's another security consideration that I think deserve mention. Something along the lines of: An attacker can exploit the requirement that a decoder skip over unknown extensions to create a covert channel and transmit unauthorized data. So even if you properly address the issue of potentially crashing there is still another security issue to consider. Given the nature of audio/video equipment it might be remote but to this naive reader it deserved mention. It's like a hitch-hiker. One must take into account that a hitch-hiker might kill you but even if you properly address that threat you still have consider the fact that you might need to explain to law enforcement that those drugs/firearms/etc in the dufflebag in your car aren't really yours. regards, Dan. On Wed, June 10, 2009 12:51 am, Bont, Frans de wrote: > Hi Dan, > > Thanks for your review, we will update the draft accordingly. > > With respect to your 'covert channel' comment we want to make > the following remark. > > RFC 3640 says: >> However, it is possible to inject non-compliant MPEG streams (Audio, >> Video, and Systems) so that the receiver/decoder's buffers are >> overloaded, which might compromise the functionality of the receiver >> or even crash it. > > This is a general remark that hold for all audio/video formats, this > is not different for the format described in this draft. > > The mentioned 'covert channel', in ISO/IEC 14496-3 (MPEG-4 Audio) > implemented by means of the extension_payload(), is defined as a > backward compatible mechanism for transport of extension data inside AAC > payloads. Streams using this mechanism are fully compliant MPEG-4 Audio > streams and code points, the extension identifiers in ISO/IEC 14496-3, > that are not supported by a decoder are gracefully skipped. > > Best regards, > Frans > > >> -----Original Message----- >> From: Dan Harkins [mailto:dharkins@lounge.org] >> Sent: 2009 Jun 09 1:29 AM >> To: avt-chairs@ietf.org; Bont, Frans de >> Subject: [Fwd: [secdir] SECDIR review of draft-ietf-avt-rtp-mps-02.txt] >> >> >> Hi, >> >> I fat-fingered your addresses in the following-- chars and phillips. >> Sorry about that. >> >> Dan. >> >> ---------------------------- Original Message ------------------------- >> --- >> Subject: [secdir] SECDIR review of draft-ietf-avt-rtp-mps-02.txt >> From: "Dan Harkins" >> Date: Mon, June 8, 2009 4:22 pm >> To: iesg@ietf.org >> secdir@ietf.org >> avt-chars@tools.ietf.org >> fluffy@cisco.com >> Cc: frans.de.bont@phillips.com >> "malte.schmidt@dolby.com" >> >> stefan.doehla@iis.fraunhofer.de >> ----------------------------------------------------------------------- >> --- >> >> >> Hi, >> >> I have reviewed this document as part of the Security Directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> Security Area directors. Document editors and WG chairs should >> treat these comments just like any other last call comments. >> >> This document extends the RTP payload format to transport MPEG >> Surround multi-channel audio. >> >> By extending the RTP payload format, this document states that it >> is "subject to the security considerations of the RTP specification" >> itself. It also informatively cuts-and-pastes from the security >> considerations of RFC 3640. I see no problem with that. >> >> While it's not an issue that needs addressing in this draft, it >> seems to me that this draft takes advantage of a covert channel >> in an ISO Standard on the coding of audo-visual objects-- "skip >> unknown extension data" in a stream. RFC 3640 discusses the >> possibility of crashing a system using this bug^H^H^Hfeature but >> does not mention the covert channel possibilities. It would be nice >> to mention that in a successor to RFC 3640 if there ever is one. >> >> Minor issues: >> >> - missing reference to SDP, RFC 2327 >> - please spell out "Advanced Audio Coding" before using the >> acronym AAC (assuming that's what it meant). >> - the term "High Efficiency AAC" is used after the acronym HE-AAC. >> Please reverse that. >> >> regards, >> >> Dan. >> >> >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> > > > The information contained in this message may be confidential and legally > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby > notified that any use, forwarding, dissemination, or reproduction of this > message is strictly prohibited and may be unlawful. If you are not the > intended recipient, please contact the sender by return e-mail and destroy > all copies of the original message. > From j.schoenwaelder@jacobs-university.de Wed Jun 10 09:21:42 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1CA3A6E6A; Wed, 10 Jun 2009 09:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_56=0.6, J_CHICKENPOX_57=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 RJsKPe4sIwPH; Wed, 10 Jun 2009 09:21:41 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 932813A68A7; Wed, 10 Jun 2009 09:21:40 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC05BC00CD; Wed, 10 Jun 2009 18:21:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Sh4q4eJ3kSsH; Wed, 10 Jun 2009 18:21:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C69FC0018; Wed, 10 Jun 2009 18:21:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 8B131B371C2; Wed, 10 Jun 2009 18:21:41 +0200 (CEST) Date: Wed, 10 Jun 2009 18:21:41 +0200 From: Juergen Schoenwaelder To: Acee Lindem Message-ID: <20090610162141.GB7309@elstar.local> Mail-Followup-To: Acee Lindem , "djoyal@nortel.com" , "vishwas@ipinfusion.com" , "iesg@ietf.org" , "secdir@ietf.org" , "ospf-chairs@tools.ietf.org" References: <20090610133954.GC6346@elstar.local> <72DEC793-5666-4441-BFD7-05F03956E065@redback.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <72DEC793-5666-4441-BFD7-05F03956E065@redback.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "ospf-chairs@tools.ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" , "vishwas@ipinfusion.com" , "djoyal@nortel.com" Subject: Re: [secdir] secdir review of draft-ietf-ospf-ospfv3-mib.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 16:21:42 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jun 10, 2009 at 05:06:30PM +0200, Acee Lindem wrote: > Juergen, > > You refer to an an attached boiler plate for MIB security > considerations but I don't see any attachments. Sorry, I am trying again to attach the attachment. But this boilerplate is really just an extended version of the boilerplate posted on the OPS web site. Lines beginning with # are comment lines. > In the future, I'd hope the secdir could register their comments > earlier in the process. We have taken this document all the way > through the IESG and MIB doctors reviews and are not one day away > from the end of the IETF last call. I understand your feelings. But on the other hand, the requested changes do not affect in any way how the MIB module works - it is all about properly writing up the security considerations - so this is mainly some additional editing work. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="OSPFV3-MIB-boilerplate.txt" # OSPFV3-MIB security considerations boilerplate (generated by smidump 0.4.8) # if you have any read-write and/or read-create objects, please # describe their specific sensitivity or vulnerability. # RFC 2669 has a very good example. There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: ospfv3RouterId # explain sensitivity ospfv3AdminStatus # explain sensitivity ospfv3ASBdrRtrStatus # explain sensitivity ospfv3ExtAreaLsdbLimit # explain sensitivity ospfv3ExitOverflowInterval # explain sensitivity ospfv3DemandExtensions # explain sensitivity ospfv3ReferenceBandwidth # explain sensitivity ospfv3RestartSupport # explain sensitivity ospfv3RestartInterval # explain sensitivity ospfv3RestartStrictLsaChecking # explain sensitivity ospfv3NotificationEnable # explain sensitivity ospfv3StubRouterAdvertisement # explain sensitivity ospfv3AreaImportAsExtern # explain sensitivity ospfv3AreaSummary # explain sensitivity ospfv3AreaRowStatus # explain sensitivity ospfv3AreaStubMetric # explain sensitivity ospfv3AreaNssaTranslatorRole # explain sensitivity ospfv3AreaNssaTranslatorStabInterval # explain sensitivity ospfv3AreaStubMetricType # explain sensitivity ospfv3AreaTEEnabled # explain sensitivity ospfv3HostMetric # explain sensitivity ospfv3HostRowStatus # explain sensitivity ospfv3HostAreaID # explain sensitivity ospfv3IfAreaId # explain sensitivity ospfv3IfType # explain sensitivity ospfv3IfAdminStatus # explain sensitivity ospfv3IfRtrPriority # explain sensitivity ospfv3IfTransitDelay # explain sensitivity ospfv3IfRetransInterval # explain sensitivity ospfv3IfHelloInterval # explain sensitivity ospfv3IfRtrDeadInterval # explain sensitivity ospfv3IfPollInterval # explain sensitivity ospfv3IfRowStatus # explain sensitivity ospfv3IfDemand # explain sensitivity ospfv3IfMetricValue # explain sensitivity ospfv3IfDemandNbrProbe # explain sensitivity ospfv3IfDemandNbrProbeRetransLimit # explain sensitivity ospfv3IfDemandNbrProbeInterval # explain sensitivity ospfv3IfTEDisabled # explain sensitivity ospfv3IfLinkLSASuppression # explain sensitivity ospfv3VirtIfTransitDelay # explain sensitivity ospfv3VirtIfRetransInterval # explain sensitivity ospfv3VirtIfHelloInterval # explain sensitivity ospfv3VirtIfRtrDeadInterval # explain sensitivity ospfv3VirtIfRowStatus # explain sensitivity ospfv3CfgNbrPriority # explain sensitivity ospfv3CfgNbrRowStatus # explain sensitivity ospfv3AreaAggregateRowStatus # explain sensitivity ospfv3AreaAggregateEffect # explain sensitivity ospfv3AreaAggregateRouteTag # explain sensitivity # for all MIB modules you must evaluate whether any readable objects # are sensitive or vulnerable (for instance, if they might reveal # customer information or violate personal privacy laws such as # those of the European Union if exposed to unathorized parties) Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: ospfv3RouterId # explain sensitivity ospfv3AdminStatus # explain sensitivity ospfv3VersionNumber # explain sensitivity ospfv3AreaBdrRtrStatus # explain sensitivity ospfv3ASBdrRtrStatus # explain sensitivity ospfv3AsScopeLsaCount # explain sensitivity ospfv3AsScopeLsaCksumSum # explain sensitivity ospfv3OriginateNewLsas # explain sensitivity ospfv3RxNewLsas # explain sensitivity ospfv3ExtLsaCount # explain sensitivity ospfv3ExtAreaLsdbLimit # explain sensitivity ospfv3ExitOverflowInterval # explain sensitivity ospfv3DemandExtensions # explain sensitivity ospfv3ReferenceBandwidth # explain sensitivity ospfv3RestartSupport # explain sensitivity ospfv3RestartInterval # explain sensitivity ospfv3RestartStrictLsaChecking # explain sensitivity ospfv3RestartStatus # explain sensitivity ospfv3RestartAge # explain sensitivity ospfv3RestartExitReason # explain sensitivity ospfv3NotificationEnable # explain sensitivity ospfv3StubRouterSupport # explain sensitivity ospfv3StubRouterAdvertisement # explain sensitivity ospfv3DiscontinuityTime # explain sensitivity ospfv3RestartTime # explain sensitivity ospfv3AreaImportAsExtern # explain sensitivity ospfv3AreaSpfRuns # explain sensitivity ospfv3AreaBdrRtrCount # explain sensitivity ospfv3AreaAsBdrRtrCount # explain sensitivity ospfv3AreaScopeLsaCount # explain sensitivity ospfv3AreaScopeLsaCksumSum # explain sensitivity ospfv3AreaSummary # explain sensitivity ospfv3AreaRowStatus # explain sensitivity ospfv3AreaStubMetric # explain sensitivity ospfv3AreaNssaTranslatorRole # explain sensitivity ospfv3AreaNssaTranslatorState # explain sensitivity ospfv3AreaNssaTranslatorStabInterval # explain sensitivity ospfv3AreaNssaTranslatorEvents # explain sensitivity ospfv3AreaStubMetricType # explain sensitivity ospfv3AreaTEEnabled # explain sensitivity ospfv3AsLsdbSequence # explain sensitivity ospfv3AsLsdbAge # explain sensitivity ospfv3AsLsdbChecksum # explain sensitivity ospfv3AsLsdbAdvertisement # explain sensitivity ospfv3AsLsdbTypeKnown # explain sensitivity ospfv3AreaLsdbSequence # explain sensitivity ospfv3AreaLsdbAge # explain sensitivity ospfv3AreaLsdbChecksum # explain sensitivity ospfv3AreaLsdbAdvertisement # explain sensitivity ospfv3AreaLsdbTypeKnown # explain sensitivity ospfv3LinkLsdbSequence # explain sensitivity ospfv3LinkLsdbAge # explain sensitivity ospfv3LinkLsdbChecksum # explain sensitivity ospfv3LinkLsdbAdvertisement # explain sensitivity ospfv3LinkLsdbTypeKnown # explain sensitivity ospfv3HostMetric # explain sensitivity ospfv3HostRowStatus # explain sensitivity ospfv3HostAreaID # explain sensitivity ospfv3IfAreaId # explain sensitivity ospfv3IfType # explain sensitivity ospfv3IfAdminStatus # explain sensitivity ospfv3IfRtrPriority # explain sensitivity ospfv3IfTransitDelay # explain sensitivity ospfv3IfRetransInterval # explain sensitivity ospfv3IfHelloInterval # explain sensitivity ospfv3IfRtrDeadInterval # explain sensitivity ospfv3IfPollInterval # explain sensitivity ospfv3IfState # explain sensitivity ospfv3IfDesignatedRouter # explain sensitivity ospfv3IfBackupDesignatedRouter # explain sensitivity ospfv3IfEvents # explain sensitivity ospfv3IfRowStatus # explain sensitivity ospfv3IfDemand # explain sensitivity ospfv3IfMetricValue # explain sensitivity ospfv3IfLinkScopeLsaCount # explain sensitivity ospfv3IfLinkLsaCksumSum # explain sensitivity ospfv3IfDemandNbrProbe # explain sensitivity ospfv3IfDemandNbrProbeRetransLimit # explain sensitivity ospfv3IfDemandNbrProbeInterval # explain sensitivity ospfv3IfTEDisabled # explain sensitivity ospfv3IfLinkLSASuppression # explain sensitivity ospfv3VirtIfIndex # explain sensitivity ospfv3VirtIfInstId # explain sensitivity ospfv3VirtIfTransitDelay # explain sensitivity ospfv3VirtIfRetransInterval # explain sensitivity ospfv3VirtIfHelloInterval # explain sensitivity ospfv3VirtIfRtrDeadInterval # explain sensitivity ospfv3VirtIfState # explain sensitivity ospfv3VirtIfEvents # explain sensitivity ospfv3VirtIfRowStatus # explain sensitivity ospfv3VirtIfLinkScopeLsaCount # explain sensitivity ospfv3VirtIfLinkLsaCksumSum # explain sensitivity ospfv3NbrAddressType # explain sensitivity ospfv3NbrAddress # explain sensitivity ospfv3NbrOptions # explain sensitivity ospfv3NbrPriority # explain sensitivity ospfv3NbrState # explain sensitivity ospfv3NbrEvents # explain sensitivity ospfv3NbrLsRetransQLen # explain sensitivity ospfv3NbrHelloSuppressed # explain sensitivity ospfv3NbrIfId # explain sensitivity ospfv3NbrRestartHelperStatus # explain sensitivity ospfv3NbrRestartHelperAge # explain sensitivity ospfv3NbrRestartHelperExitReason # explain sensitivity ospfv3CfgNbrPriority # explain sensitivity ospfv3CfgNbrRowStatus # explain sensitivity ospfv3VirtNbrIfIndex # explain sensitivity ospfv3VirtNbrIfInstId # explain sensitivity ospfv3VirtNbrAddressType # explain sensitivity ospfv3VirtNbrAddress # explain sensitivity ospfv3VirtNbrOptions # explain sensitivity ospfv3VirtNbrState # explain sensitivity ospfv3VirtNbrEvents # explain sensitivity ospfv3VirtNbrLsRetransQLen # explain sensitivity ospfv3VirtNbrHelloSuppressed # explain sensitivity ospfv3VirtNbrIfId # explain sensitivity ospfv3VirtNbrRestartHelperStatus # explain sensitivity ospfv3VirtNbrRestartHelperAge # explain sensitivity ospfv3VirtNbrRestartHelperExitReason # explain sensitivity ospfv3AreaAggregateRowStatus # explain sensitivity ospfv3AreaAggregateEffect # explain sensitivity ospfv3AreaAggregateRouteTag # explain sensitivity ospfv3VirtLinkLsdbSequence # explain sensitivity ospfv3VirtLinkLsdbAge # explain sensitivity ospfv3VirtLinkLsdbChecksum # explain sensitivity ospfv3VirtLinkLsdbAdvertisement # explain sensitivity ospfv3VirtLinkLsdbTypeKnown # explain sensitivity ospfv3ConfigErrorType # explain sensitivity ospfv3PacketType # explain sensitivity ospfv3PacketSrc # explain sensitivity SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. 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). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. --Qxx1br4bt0+wmkIi-- From stefan.doehla9ab33xy531iis.fraunhofer.de@bounce.antispameurope.com Wed Jun 10 09:00:00 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF813A6A02 for ; Wed, 10 Jun 2009 09:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] 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 qvgG8r12SB8r for ; Wed, 10 Jun 2009 09:00:00 -0700 (PDT) Received: from relay01-haj2.antispameurope.com (relay01-haj2.antispameurope.com [83.246.65.51]) by core3.amsl.com (Postfix) with ESMTP id 7AF633A6831 for ; Wed, 10 Jun 2009 08:59:59 -0700 (PDT) Received: by relay01-haj2.antispameurope.com (ASE-Secure-MTA, from userid 1000) id A5223160037; Wed, 10 Jun 2009 17:51:31 +0200 (CEST) Received: from iis.fhg.de (iis.iis.fhg.de [153.96.172.2]) by relay01-haj2.antispameurope.com (ASE-Secure-MTA) with SMTP id 6B736940AD; Wed, 10 Jun 2009 17:51:30 +0200 (CEST) Received: from smtp02.iis.fraunhofer.de (mailserv02.iis.fraunhofer.de [153.96.171.52]) by iis.fhg.de (8.8.5/) with ESMTP id RAA12972; Wed, 10 Jun 2009 17:51:30 +0200 (MET DST) Received: from [10.54.94.198] (mn079.iis.fhg.de [10.54.94.198]) by smtp02.iis.fraunhofer.de (Postfix) with ESMTP id 7403A200A083; Wed, 10 Jun 2009 17:51:30 +0200 (CEST) Message-ID: <4A2FD682.3050808@iis.fraunhofer.de> Date: Wed, 10 Jun 2009 17:51:30 +0200 From: =?ISO-8859-1?Q?Stefan_D=F6hla?= User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dan Harkins References: <7d80ec7de2f05820800f98692962ab00.squirrel@www.trepanning.net> <19FE62CE8D62CF4B96C845DC556B88132FB6C98CA9@NLCLUEXM01.connect1.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by iis.fhg.de id RAA12972 X-Mailman-Approved-At: Wed, 10 Jun 2009 10:23:12 -0700 Cc: Cullen Jennings , "Schmidt , Malte" , "secdir@ietf.org" , Ralph Sperschneider , "Bont, Frans de" , "iesg@ietf.org" , "avt-chairs@ietf.org" Subject: Re: [secdir] [Fwd: SECDIR review of draft-ietf-avt-rtp-mps-02.txt] X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 16:00:00 -0000 Hi Dan, thanks for pointing us into the right direction. Normally, SRTP is=20 recommended in RTP payload formats so that this "hitch-hiking" is not=20 possible for the RTP-streamed phase in the end-to-end model. Would an additional sentence in the spirit of this The AAC audio codec includes an extension mechanism to transmit extra data within a stream that is gracefully skipped by decoders that do not support this extra data. This covert channel may be used to transmit unwanted data in an otherwise valid stream and it is hence recommended to use SRTP [RFC3711] for stream encryption, authentication, and integrity check. help? The overall end-to-end integrity check is probably out-of-scope=20 for IETF matters, since we probably cannot stop an encoder to add=20 proprietary data to the stream that is e.g. only understood by decoders=20 that conform to a specific application standard etc. Something like the proposed sentence above is btw. already part of the=20 document - but it just refers to the weak RTP encryption. Cheers - Stefan Dan Harkins wrote: > Hi Frans, > > RFC 3640 only considers one security issue associated with gracefull= y > disregarding unknown content. It's correct to mention that this capabil= ity > can be used to compromise or crash a receiver but there's another secur= ity > consideration that I think deserve mention. Something along the lines o= f: > > An attacker can exploit the requirement that a decoder skip over > unknown extensions to create a covert channel and transmit > unauthorized data. > > So even if you properly address the issue of potentially crashing there > is still another security issue to consider. Given the nature of > audio/video equipment it might be remote but to this naive reader it > deserved mention. > > It's like a hitch-hiker. One must take into account that a hitch-hike= r > might kill you but even if you properly address that threat you still > have consider the fact that you might need to explain to law enforcemen= t > that those drugs/firearms/etc in the dufflebag in your car aren't reall= y > yours. > > regards, > > Dan. > > On Wed, June 10, 2009 12:51 am, Bont, Frans de wrote: > =20 >> Hi Dan, >> >> Thanks for your review, we will update the draft accordingly. >> >> With respect to your 'covert channel' comment we want to make >> the following remark. >> >> RFC 3640 says: >> =20 >>> However, it is possible to inject non-compliant MPEG streams (Audio, >>> Video, and Systems) so that the receiver/decoder's buffers are >>> overloaded, which might compromise the functionality of the receiv= er >>> or even crash it. >>> =20 >> This is a general remark that hold for all audio/video formats, this >> is not different for the format described in this draft. >> >> The mentioned 'covert channel', in ISO/IEC 14496-3 (MPEG-4 Audio) >> implemented by means of the extension_payload(), is defined as a >> backward compatible mechanism for transport of extension data inside A= AC >> payloads. Streams using this mechanism are fully compliant MPEG-4 Audi= o >> streams and code points, the extension identifiers in ISO/IEC 14496-3, >> that are not supported by a decoder are gracefully skipped. >> >> Best regards, >> Frans >> >> >> =20 >>> -----Original Message----- >>> From: Dan Harkins [mailto:dharkins@lounge.org] >>> Sent: 2009 Jun 09 1:29 AM >>> To: avt-chairs@ietf.org; Bont, Frans de >>> Subject: [Fwd: [secdir] SECDIR review of draft-ietf-avt-rtp-mps-02.tx= t] >>> >>> >>> Hi, >>> >>> I fat-fingered your addresses in the following-- chars and phillips. >>> Sorry about that. >>> >>> Dan. >>> >>> ---------------------------- Original Message -----------------------= -- >>> --- >>> Subject: [secdir] SECDIR review of draft-ietf-avt-rtp-mps-02.txt >>> From: "Dan Harkins" >>> Date: Mon, June 8, 2009 4:22 pm >>> To: iesg@ietf.org >>> secdir@ietf.org >>> avt-chars@tools.ietf.org >>> fluffy@cisco.com >>> Cc: frans.de.bont@phillips.com >>> "malte.schmidt@dolby.com" >>> >>> stefan.doehla@iis.fraunhofer.de >>> ---------------------------------------------------------------------= -- >>> --- >>> >>> >>> Hi, >>> >>> I have reviewed this document as part of the Security Directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> Security Area directors. Document editors and WG chairs should >>> treat these comments just like any other last call comments. >>> >>> This document extends the RTP payload format to transport MPEG >>> Surround multi-channel audio. >>> >>> By extending the RTP payload format, this document states that it >>> is "subject to the security considerations of the RTP specification" >>> itself. It also informatively cuts-and-pastes from the security >>> considerations of RFC 3640. I see no problem with that. >>> >>> While it's not an issue that needs addressing in this draft, it >>> seems to me that this draft takes advantage of a covert channel >>> in an ISO Standard on the coding of audo-visual objects-- "skip >>> unknown extension data" in a stream. RFC 3640 discusses the >>> possibility of crashing a system using this bug^H^H^Hfeature but >>> does not mention the covert channel possibilities. It would be nice >>> to mention that in a successor to RFC 3640 if there ever is one. >>> >>> Minor issues: >>> >>> - missing reference to SDP, RFC 2327 >>> - please spell out "Advanced Audio Coding" before using the >>> acronym AAC (assuming that's what it meant). >>> - the term "High Efficiency AAC" is used after the acronym HE-AAC. >>> Please reverse that. >>> >>> regards, >>> >>> Dan. >>> >>> >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >>> >>> =20 >> The information contained in this message may be confidential and lega= lly >> protected under applicable law. The message is intended solely for the >> addressee(s). If you are not the intended recipient, you are hereby >> notified that any use, forwarding, dissemination, or reproduction of t= his >> message is strictly prohibited and may be unlawful. If you are not the >> intended recipient, please contact the sender by return e-mail and des= troy >> all copies of the original message. >> >> =20 > > > =20 --=20 Dipl.-Ing. Stefan D=F6hla | Email: stefan.doehla@iis.fraunhofer.de Multimedia Transport | Phone: +49 (0)9131 776 6042 (!NEW!) Audio Department | Fax: +49 (0)9131 776 6099 (!NEW!) Fraunhofer IIS | Am Wolfmantel 33 | 91058 Erlangen, Germany | Web: http://www.iis.fraunhofer.de/amm From shollenbeck@verisign.com Wed Jun 10 11:47:11 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7BB3A683A; Wed, 10 Jun 2009 11:47:11 -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 7hTfjJi5x1NA; Wed, 10 Jun 2009 11:47:09 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id 99DC63A681D; Wed, 10 Jun 2009 11:47:09 -0700 (PDT) Received: from dul1wnexcn02.vcorp.ad.vrsn.com (dul1wnexcn02.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id n5AIaBcS022772; Wed, 10 Jun 2009 14:36:11 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Jun 2009 14:47:15 -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: Wed, 10 Jun 2009 14:47:14 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF0702ADCEEE@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: review of draft-hollenbeck-rfc4933bis-01 Thread-Index: AcnlRG4eXjB9Niv8Q5Kthc6OR71G5wEiuoWg References: From: "Hollenbeck, Scott" To: "Sandra Murphy" , , X-OriginalArrivalTime: 10 Jun 2009 18:47:15.0606 (UTC) FILETIME=[DFB5B360:01C9E9FB] Cc: "Hollenbeck, Scott" Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 18:47:11 -0000 > -----Original Message----- > From: Sandra Murphy [mailto:sandy@sparta.com]=20 > Sent: Thursday, June 04, 2009 2:43 PM > To: iesg@ietf.org; secdir@ietf.org; Hollenbeck, Scott > Subject: review of draft-hollenbeck-rfc4933bis-01 >=20 >=20 > I have reviewed this document as part of the security=20 > directorate's ongoing effort to review all IETF documents=20 > being processed by the IESG.=20 > These comments were written primarily for the benefit of the=20 > security area directors. Document editors and WG chairs=20 > should treat these comments just like any other last call comments. >=20 > The draft updates RFC 4933, the EPP Contacts Mapping spec. =20 > The updates listed are relatively minor - updates to=20 > references and a few minor updates to text. >=20 > Many of my comments below apply to language that was in=20 > RFC4933, but perhaps it is OK to suggest changes from the=20 > original at this point. >=20 > First: EPP, as in RFC4930 and draft *-rfc4930bis-01*,=20 > employs a very simple authentication scheme that is cleartext=20 > password based.=20 > It therefore mandates: >=20 > Specifically, EPP instances MUST be=20 > protected using > a transport mechanism or application protocol that provides > integrity, confidentiality, and mutual strong client-server > authentication. >=20 > This mandate is inherited by the rfc4933bis draft, which also says >=20 > Both client and server MUST ensure that authorization > information is stored and exchanged with high-grade encryption > mechanisms to provide privacy services. >=20 > I would expect that this would make the protocol subject to=20 > channel binding issues. I probably am not up on the whole=20 > idea, but the I reviewed RFC5060 and the description of the=20 > problem sure sounds like it applies to EPP as well. >=20 > OTOH, I seem to recall several drafts recently that relied on=20 > the security of their transport layers, and no one has been=20 > talking about how they deal with channel binding. Maybe I'm way off. I would need more specific information to know if there's something to be done with this comment. Reliance on security mechanisms provided at the transport layer has been part of this specification since day one. I am not aware of any implementation issues. > Also, the security considerations there and in rfc4930bis do=20 > not address the cases when completion of a pending request is=20 > communicated by an out-of-band mechanism. I don't know if=20 > there are security concerns for those notifications, but=20 > given that they are not covered by the security of the=20 > transport mechanism, advice would be good. What about adding something like this to the Security Considerations section of 4930bis: "As described in Section 2, EPP includes features that allow for offline review of transform commands before the requested action is actually completed. The server is required to notify the client when offline processing of the action has been completed. Notifications can be sent using an out-of-band mechanism that is not protected by the mechanism used to provide EPP transport security. Notifications sent without EPP's transport security services should be protected using another mechanism that provides an appropriate level of protection for the notification." > sect 2.2, page 5 >=20 > - pendingCreate, pendingDelete, pendingRenew, pendingTransfer, > pendingUpdate >=20 > A transform command has been processed for the object, but the > action has not been completed by the server. Server=20 > operators can > delay action completion for a variety of reasons, such=20 > as to allow > for human review or third-party action. A transform=20 > command that > is processed, but whose requested action is pending,=20 > is noted with > response code 1001. >=20 > When the requested action has been completed, the pendingCreate, > pendingDelete, pendingTransfer, or pendingUpdate status=20 > value MUST be > removed. >=20 > Later, sect 3.3 page 27 says (indirectly) that the status=20 > MUST be set if the action is delayed: >=20 > The status of the corresponding object MUST=20 > clearly reflect > processing of the pending action. >=20 > If the MUST for removal is here, it would be good to be=20 > consistent and put the MUST for setting the status as well. =20 > (As a matter of fact, it would be nice to mention the=20 > pending status being set in the description of the=20 > transform commands as well.) Maybe, but this hasn't been an issue for implementers. I'd prefer to leave the text as-is, particularly given that changing it here would make it inconsistent with the other documents in the series. > (By the way: why is a pendingRenew status defined when=20 > section 3.2 says there is no mapping defined for the Renew command?) That's a good catch! pendingRenew should be removed. > Same section, immediately following: >=20 > All clients involved in the transaction MUST be notified > using a service message that the action has been=20 > completed and that > the status of the object has changed. >=20 > Later sections (p 17 sec 3.2 and p 28 sec 3.3) add=20 > qualifications to this > MUST: "Other notification methods MAY be used" and "or by=20 > using an out-of-band mechanism." The situations are different. The text in section 2.2 describes a specific requirement for notification when a status value is changed. The later sections address notification mechanisms for completion of offline processing. > sect 2.9, page 7 >=20 > A server operator MUST reject any > transaction that requests disclosure practices that do=20 > not conform to > the announced data collection policy with a 2308 error=20 > response code. >=20 > When servers are compling with client specified exceptional=20 > disclosure handling for some data elements, does this same=20 > requirement apply, and with the same error code? Yes. If the client asks the server to do something outside the stated policy, a 2308 response would be appropriate. > sect 3.1.2, page 14 >=20 >=20 > The response example contains: >=20 >=20 > S: +1.7035555555 > S: +1.7035555556 > ... > S: > S: > S: > S: >=20 >=20 > Section 2.9, page 7 says >=20 > In conjunction with this disclosure > requirement, this mapping includes data elements that=20 > allow a client > to identify elements that require exceptional server operator > handling to allow or restrict disclosure to third parties. >=20 > but then also >=20 > A value of "false" or "0" (zero) > notes a client preference to not allow disclosure of the specified > elements as an exception to the stated data collection policy. >=20 > Between "require .. operator handling" and "client=20 > preference", I'm not sure of the obligation the server has to=20 > refrain from disclosing data elements that the client has=20 > requested be prohibited from disclosing >=20 > But at any rate, this example seems to me to be ignoring the=20 > client's request. True? If so, and allowed, it would=20 > deserve more discussion. Not true, because the response is being sent to a client that is authorized ("Example response for an authorized client") to see the full data record. The response would be different if the query were performed by a client that isn't authorized to see the full record. > sect 3.2, page 17 >=20 > Server operators SHOULD confirm that a client is authorized to > perform a transform command on a given object. Any attempt to > transform an object by an unauthorized client MUST be=20 > rejected, and > the server MUST return a 2201 response code to the client to note > that the client lacks privileges to execute the requested command. >=20 > Is that "MUST be rejected" only in the case that the server=20 > operator decides that they will confirm authorization? Yes. That's why the MUST refers to an "unauthorized client". > sect 3.2.2, page 20 >=20 > A contact object SHOULD NOT be deleted if it is=20 > associated with other > known objects. An associated contact SHOULD NOT be deleted until > associations with other known objects have been broken. A server > SHOULD notify clients that object relationships exist by sending a > 2305 error response code when a command is attempted and > fails due to existing object relationships. >=20 > Do these object associations and object relationships include=20 > cases where the status is "clientDeleteProhibited" or=20 > "serverDeleteProhibited"? If not, should there be this (or=20 > some other) error message in those status cases as well? The=20 > prohibition status values don't seem to show up in the=20 > discussions of server response to commands. Perhaps those=20 > prohibitions are covered under the "An EPP error response=20 > MUST be returned if the ...=20 > command cannot be processed for any reason". I believe an=20 > explicit discussion would be good, including the appropriate=20 > error code. (Same comment in the Transfer and Update commands.) No, this text refers to relationships where a contact is associated with, for example, a domain object. The 2304 response code is used to identify a failure due to a status constraint. > sect 3.2.5, page 24 >=20 >=20 > At least one , , or=20 > element > MUST be provided if the command is not being extended. =20 > All of these > elements MAY be omitted if an extension is present. The > and elements contain the=20 > following child > elements: >=20 > - One or more elements that contain=20 > status values > to be associated with or removed from the object. =20 > When specifying > a value to be removed, only the attribute value is significant; > element text is not required to match a value for removal. >=20 > Who is responsible for ensuring the valid status combinations=20 > discussed in sect 2.2? I.e., if the client is adding a=20 > prohibition, does the server remove the "ok" status or must=20 > the client include that removal in the update? if the=20 > removal is in the same update, does the order in the update=20 > matter (removal first?)? >=20 > Note: the example adds a prohibition without removing an "ok"=20 > status, implying that the client is not responsible. But it=20 > is not necessarily the case that the "ok" status was there,=20 > so the implication isn't certain. The server implementation is responsible for validating status combinations. > sect 3.3, page 27 >=20 > rfc4930bis says: >=20 >=20 > The server MUST also notify the > client when offline processing of the action has been completed. > Object mappings SHOULD describe standard formats for notices that > describe completion of offline processing. >=20 > Section 3.3 contains an example of the contents of the=20 > notification for a create command. But Delete, Update and=20 > Transfer may also be pending.=20 > Should there be a description of their notification service=20 > messages also? I don't think so, because elsewhere in the spec it states that the format of the messages is outside the scope of the spec. > --Sandy >=20 From dharkins@lounge.org Wed Jun 10 17:24:15 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E4963A69B2; Wed, 10 Jun 2009 17:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 C9E1RnIJz0p0; Wed, 10 Jun 2009 17:24:13 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id CAA933A67DD; Wed, 10 Jun 2009 17:24:13 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 453B210224074; Wed, 10 Jun 2009 17:24:20 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 10 Jun 2009 17:24:20 -0700 (PDT) Message-ID: In-Reply-To: <4A2FD682.3050808@iis.fraunhofer.de> References: <7d80ec7de2f05820800f98692962ab00.squirrel@www.trepanning.net> <19FE62CE8D62CF4B96C845DC556B88132FB6C98CA9@NLCLUEXM01.connect1.local> <4A2FD682.3050808@iis.fraunhofer.de> Date: Wed, 10 Jun 2009 17:24:20 -0700 (PDT) From: "Dan Harkins" To: Stefan =?iso-8859-1?Q?D=F6hla?= User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Cullen Jennings , "Schmidt , Malte" , "secdir@ietf.org" , Ralph Sperschneider , "Bont, Frans de" , "iesg@ietf.org" , "avt-chairs@ietf.org" Subject: Re: [secdir] [Fwd: SECDIR review of draft-ietf-avt-rtp-mps-02.txt] X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 00:24:15 -0000 Hi Stefan, That looks great. I would only suggest s/unwanted/unauthorized/ to highlight that it's not just some proprietary cruft a manufacturer would add that could be understood by his decoders, it's something that was not placed there by the participants in the protocol. regards, Dan. On Wed, June 10, 2009 8:51 am, Stefan Döhla wrote: > Hi Dan, > > thanks for pointing us into the right direction. Normally, SRTP is > recommended in RTP payload formats so that this "hitch-hiking" is not > possible for the RTP-streamed phase in the end-to-end model. > > Would an additional sentence in the spirit of this > > The AAC audio codec includes an extension mechanism to transmit extra > data within a stream that is gracefully skipped by decoders that do > not support this extra data. This covert channel may be used to > transmit unwanted data in an otherwise valid stream and it is hence > recommended to use SRTP [RFC3711] for stream encryption, > authentication, and integrity check. > > help? The overall end-to-end integrity check is probably out-of-scope > for IETF matters, since we probably cannot stop an encoder to add > proprietary data to the stream that is e.g. only understood by decoders > that conform to a specific application standard etc. > > Something like the proposed sentence above is btw. already part of the > document - but it just refers to the weak RTP encryption. > > Cheers > - Stefan > > Dan Harkins wrote: >> Hi Frans, >> >> RFC 3640 only considers one security issue associated with gracefully >> disregarding unknown content. It's correct to mention that this >> capability >> can be used to compromise or crash a receiver but there's another >> security >> consideration that I think deserve mention. Something along the lines >> of: >> >> An attacker can exploit the requirement that a decoder skip over >> unknown extensions to create a covert channel and transmit >> unauthorized data. >> >> So even if you properly address the issue of potentially crashing there >> is still another security issue to consider. Given the nature of >> audio/video equipment it might be remote but to this naive reader it >> deserved mention. >> >> It's like a hitch-hiker. One must take into account that a hitch-hiker >> might kill you but even if you properly address that threat you still >> have consider the fact that you might need to explain to law enforcement >> that those drugs/firearms/etc in the dufflebag in your car aren't really >> yours. >> >> regards, >> >> Dan. >> >> On Wed, June 10, 2009 12:51 am, Bont, Frans de wrote: >> >>> Hi Dan, >>> >>> Thanks for your review, we will update the draft accordingly. >>> >>> With respect to your 'covert channel' comment we want to make >>> the following remark. >>> >>> RFC 3640 says: >>> >>>> However, it is possible to inject non-compliant MPEG streams (Audio, >>>> Video, and Systems) so that the receiver/decoder's buffers are >>>> overloaded, which might compromise the functionality of the >>>> receiver >>>> or even crash it. >>>> >>> This is a general remark that hold for all audio/video formats, this >>> is not different for the format described in this draft. >>> >>> The mentioned 'covert channel', in ISO/IEC 14496-3 (MPEG-4 Audio) >>> implemented by means of the extension_payload(), is defined as a >>> backward compatible mechanism for transport of extension data inside >>> AAC >>> payloads. Streams using this mechanism are fully compliant MPEG-4 Audio >>> streams and code points, the extension identifiers in ISO/IEC 14496-3, >>> that are not supported by a decoder are gracefully skipped. >>> >>> Best regards, >>> Frans >>> >>> >>> >>>> -----Original Message----- >>>> From: Dan Harkins [mailto:dharkins@lounge.org] >>>> Sent: 2009 Jun 09 1:29 AM >>>> To: avt-chairs@ietf.org; Bont, Frans de >>>> Subject: [Fwd: [secdir] SECDIR review of >>>> draft-ietf-avt-rtp-mps-02.txt] >>>> >>>> >>>> Hi, >>>> >>>> I fat-fingered your addresses in the following-- chars and phillips. >>>> Sorry about that. >>>> >>>> Dan. >>>> >>>> ---------------------------- Original Message >>>> ------------------------- >>>> --- >>>> Subject: [secdir] SECDIR review of draft-ietf-avt-rtp-mps-02.txt >>>> From: "Dan Harkins" >>>> Date: Mon, June 8, 2009 4:22 pm >>>> To: iesg@ietf.org >>>> secdir@ietf.org >>>> avt-chars@tools.ietf.org >>>> fluffy@cisco.com >>>> Cc: frans.de.bont@phillips.com >>>> "malte.schmidt@dolby.com" >>>> >>>> stefan.doehla@iis.fraunhofer.de >>>> ----------------------------------------------------------------------- >>>> --- >>>> >>>> >>>> Hi, >>>> >>>> I have reviewed this document as part of the Security Directorate's >>>> ongoing effort to review all IETF documents being processed by the >>>> IESG. These comments were written primarily for the benefit of the >>>> Security Area directors. Document editors and WG chairs should >>>> treat these comments just like any other last call comments. >>>> >>>> This document extends the RTP payload format to transport MPEG >>>> Surround multi-channel audio. >>>> >>>> By extending the RTP payload format, this document states that it >>>> is "subject to the security considerations of the RTP specification" >>>> itself. It also informatively cuts-and-pastes from the security >>>> considerations of RFC 3640. I see no problem with that. >>>> >>>> While it's not an issue that needs addressing in this draft, it >>>> seems to me that this draft takes advantage of a covert channel >>>> in an ISO Standard on the coding of audo-visual objects-- "skip >>>> unknown extension data" in a stream. RFC 3640 discusses the >>>> possibility of crashing a system using this bug^H^H^Hfeature but >>>> does not mention the covert channel possibilities. It would be nice >>>> to mention that in a successor to RFC 3640 if there ever is one. >>>> >>>> Minor issues: >>>> >>>> - missing reference to SDP, RFC 2327 >>>> - please spell out "Advanced Audio Coding" before using the >>>> acronym AAC (assuming that's what it meant). >>>> - the term "High Efficiency AAC" is used after the acronym HE-AAC. >>>> Please reverse that. >>>> >>>> regards, >>>> >>>> Dan. >>>> >>>> >>>> >>>> _______________________________________________ >>>> secdir mailing list >>>> secdir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/secdir >>>> >>>> >>> The information contained in this message may be confidential and >>> legally >>> protected under applicable law. The message is intended solely for the >>> addressee(s). If you are not the intended recipient, you are hereby >>> notified that any use, forwarding, dissemination, or reproduction of >>> this >>> message is strictly prohibited and may be unlawful. If you are not the >>> intended recipient, please contact the sender by return e-mail and >>> destroy >>> all copies of the original message. >>> >>> >> >> >> > > > -- > Dipl.-Ing. Stefan Döhla | Email: stefan.doehla@iis.fraunhofer.de > Multimedia Transport | Phone: +49 (0)9131 776 6042 (!NEW!) > Audio Department | Fax: +49 (0)9131 776 6099 (!NEW!) > Fraunhofer IIS | > Am Wolfmantel 33 | > 91058 Erlangen, Germany | Web: http://www.iis.fraunhofer.de/amm > > From barryleiba@gmail.com Wed Jun 10 23:04:36 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6D7E3A6899; Wed, 10 Jun 2009 23:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 SBC3F6jGFHDc; Wed, 10 Jun 2009 23:04:36 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 950AC3A67A7; Wed, 10 Jun 2009 23:04:35 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so16812eyf.9 for ; Wed, 10 Jun 2009 23:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=t6GpepcZA8s4qlLMol1z4OfMezBMDYrDVUOrG3/Gd+4=; b=dhMT+jVFV/K3VRon16u7GNnxRE0GHFo50ezIfB+SWnKwg62fXEKXvgoZ8iFIjZrV+F WCLh3FpaTzhvCIkdwxMRW0rhl7uRJ7StC26BXUkxzSNF4A92MQ+1ewzjQbEzzkUH73R3 Atdx/rayo4/e/leQEP2NKgYZ7/niidjcrTryQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; b=rz6/rz3rO0OKBhmAyTADSKQzaJoln7bzfkufh+Sczf6t3MNNeFt8qeyT0DQIV4CX1v Ifs/rFcDke1HWIuq56HPz5rPSFdo9LpUiRynzpv8x0vJCVRPawUB1SY9s/RcSuuTfj2F spKZ+IWCkkVIpyBESG8HoMAVnZrd37AspEea0= MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.210.38.5 with SMTP id l5mr2690253ebl.4.1244700278166; Wed, 10 Jun 2009 23:04:38 -0700 (PDT) Date: Thu, 11 Jun 2009 02:04:38 -0400 X-Google-Sender-Auth: 17f8fec344d530f7 Message-ID: <9abf48a60906102304q27f92dcbmc51553fa1ae4c39d@mail.gmail.com> From: Barry Leiba To: secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: shollenbeck@verisign.com, Chris Newman Subject: [secdir] secdir review of draft-hollenbeck-rfc4931bis-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 06:04:37 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is progressing RFC 4931 from Draft Standard to [full] Standard. That's an entirely appropriate thing to do, and I see no issues with this document. I also note, as requested in the Last Call notice, that I think the downreference to RFC 952 is appropriate. Two nits that I noticed, both in Section 1.1: OLD Name server hosts for domain delegation can be specified as either references to existing host objects or as domain attributes that describe a host machine. NEW Name server hosts for domain delegation can be specified either as references to existing host objects or as domain attributes that describe a host machine. OLD - Zero or more OPTIONAL element that contain the IP addresses to be associated with the host. Each element MAY NEW - Zero or more OPTIONAL elements that contain the IP addresses to be associated with the host. Each element MAY Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ From magnus@rsa.com Sun Jun 14 14:36:55 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1678E3A6878; Sun, 14 Jun 2009 14:36:55 -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 kqbNzNcQ9fzH; Sun, 14 Jun 2009 14:36:54 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 0C1833A689C; Sun, 14 Jun 2009 14:36:53 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id n5ELax5d021430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 14 Jun 2009 17:36:59 -0400 Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Sun, 14 Jun 2009 17:36:53 -0400 Received: from corpussmtp1.corp.emc.com (corpussmtp1.corp.emc.com [128.221.10.43]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n5ELaq6L003050; Sun, 14 Jun 2009 17:36:52 -0400 Received: from CORPUSMX50B.corp.emc.com ([128.221.62.39]) by corpussmtp1.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 14 Jun 2009 17:36:51 -0400 Received: from W-JNISBETTEST-1.tablus.com ([10.4.144.11]) by CORPUSMX50B.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 14 Jun 2009 17:36:49 -0400 Date: Sun, 14 Jun 2009 23:37:10 +0200 (W. Europe Daylight Time) From: =?iso-8859-1?Q?Magnus_Nystr=F6m?= To: iesg@ietf.org, secdir@ietf.org, rjsparks@nostrum.com, fluffy@cisco.com In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 14 Jun 2009 21:36:50.0098 (UTC) FILETIME=[39D4F920:01C9ED38] X-EMM-EM: Active Cc: rohan@ekabal.com, jdrosen@cisco.com, secdir-secretary@ietf.org, dpetrie@sipez.com, alan@sipstation.com, rjsparks@nostrum.com Subject: [secdir] SecDir review of draft-ietf-sipping-cc-framework X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2009 21:36:55 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Background ---------- This document describes a framework for call control and multi-party usage of SIP (while the abstract also talks about requirements, I did not see any strong requirements - at least there are no normative statements in the RFC 2119 sense in the document). Comments -------- Although brief, the Security Considerations section reads well (a more comprehensive trust/threat model analysis for the proposed framework would have been nice though). It could be useful to add a sentence or two on anonymity aspects in the context of the proposed framework. The body of the text mentions this aspect in passing once (2.6.4) but there is no mentioning in the Security Considerations section. In the sixth paragraph, an explicit method for replay attack prevention is recommended (lower-case "should"). I am not sure about the reason for this and could potentially see other ways to mitigate such attacks. Hence, one suggestion could be to replace the current "In the case of features initiated by a former participant, these should be protected against replay attacks by using a unique name or identifier per invocation" with: "In the case of features initiated by a former participant, these should be protected against replay attacks, e.g. by using a unique name or identifier per invocation." For clarity, I also suggest changing this section's last sentence to: "These credentials may for example need to be passed transitively or fetched in an event body." A question: The third paragraph in the Security Considerations section refers to Section 3.2 - might this be Section 2.3? General/editorial: - Abstract states "This framework also describes other goals that embody the spirit of SIP applications as used on the Internet" - it would have been useful if this sentence at least had identified a few of these goals. - Section 2.3: "peers can take advantage of end-to-end message integrity or encryption" - I would say this applies only when certain conditions are met and hence perhaps something like "peers may take advantage..." or similar would be better. - Section 2.6.7.2: Acronym "IVR" introduced without explanation. An early "Acronyms" section would be useful. - Section 3: The sentence "One means of accomplishing this is through the ability to define and obtain URIs for these actions as described in section ." seems to be missing the final section reference. -- Magnus From Shawn.Emery@Sun.COM Sun Jun 14 23:50:14 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25613A6B8C; Sun, 14 Jun 2009 23:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.745 X-Spam-Level: X-Spam-Status: No, score=-5.745 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 NX1nfA8vydEP; Sun, 14 Jun 2009 23:50:14 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id C41283A6C32; Sun, 14 Jun 2009 23:50:13 -0700 (PDT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5F6oNXx020789; Mon, 15 Jun 2009 06:50:23 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KL900A00PFK4O00@mail-amer.sun.com>; Mon, 15 Jun 2009 00:50:23 -0600 (MDT) Received: from [10.0.0.5] ([unknown] [67.190.47.79]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KL900BQOPNZRI80@mail-amer.sun.com>; Mon, 15 Jun 2009 00:50:23 -0600 (MDT) Date: Mon, 15 Jun 2009 00:50:16 -0600 From: Shawn M Emery Sender: Shawn.Emery@Sun.COM To: secdir@ietf.org, draft-ietf-avt-app-rtp-keepalive@tools.ietf.org, avt-chairs@tools.ietf.org, iesg@ietf.org Message-id: <4A35EF28.2090105@sun.com> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Subject: [secdir] Review of draft-ietf-avt-app-rtp-keepalive-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 06:50:15 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes various ways for RTP applications to keep NAT mappings alive. It goes on to detail individual keepalive methods and advantages/disadvantages of its approach. Intended status of the draft is BCP. I'm not for sure I understand the security considerations section, but I think what it's trying to say is that: old peers, which don't understand the new keepalive message, will appropriately drop the packet sent by its peer? If so then please reword accordingly. No additional security related issues beyond RTP itself discovered in this draft. General comment(s): I appreciate the use of a requirements section, this makes it easier to find out what is or is not in scope for the recommended solutions. Editorial comment(s): Expand the first occurrences of "SDP" and "RTCP". s/needs support/needs to support/ s/mux"attribute/mux" attribute/ Shawn. -- From cwallace@cygnacom.com Mon Jun 15 09:51:52 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5103A6A4D; Mon, 15 Jun 2009 09:51:52 -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 P8rCrbj7N1yw; Mon, 15 Jun 2009 09:51:51 -0700 (PDT) Received: from p03c11o142.symantecmail.net (p03c11o142.symantecmail.net [208.65.144.85]) by core3.amsl.com (Postfix) with ESMTP id 357F63A67B4; Mon, 15 Jun 2009 09:51:51 -0700 (PDT) Received: from unknown [65.242.48.5] (EHLO p03c11o142.symantecmail.net) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id 23c763a4.2024635312.119567.00-504.p03c11o142.symantecmail.net (envelope-from ); Mon, 15 Jun 2009 10:52:02 -0600 (MDT) Received: from unknown [65.242.48.5] (EHLO scygexch1.cygnacom.com) by p03c11o142.symantecmail.net (mxl_mta-5.7.0-7) with ESMTP id e2c763a4.1856797616.119556.00-028.p03c11o142.symantecmail.net (envelope-from ); Mon, 15 Jun 2009 10:51:58 -0600 (MDT) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 15 Jun 2009 12:51:51 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-ntp-autokey-05 thread-index: Acnt2ZSOUKpimDyrSku48rYUgrYMfA== From: "Carl Wallace" To: , , , X-Spam: [F=0.2000000000; S=0.200(2009052001)] X-MAIL-FROM: X-SOURCE-IP: [65.242.48.5] Subject: [secdir] secdir review of draft-ietf-ntp-autokey-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 16:51:52 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft describes a protocol for authenticating Network Time Protocol (NTPv4) servers to clients. General comments - I think the draft would benefit from the usage of 2119 language. At present, it often seemed to be describing the reference implementation instead of providing a protocol specification that would enable interoperability. For example, the following appears in section 11: "while the high order 16 bits specify the message digest/signature encryption scheme as encoded in the OpenSSL library". =20 - I don't follow why it was necessary to invent new words for this draft (i.e., proventic) and found myself simply substituting existing words for the new words. =20 - Is the Informational the correct status for this? Specific comments - Why use a self-signed certificate as a means of requesting certificates instead of P10 (or CMC or CMP)? The draft makes no mention of checking the signature on this request or checking the contents of the request in any way. =20 - In section 8 where the Sign Exchange is described, the server is to extract "the subject, issuer and extensions fields" then build a new certificate with that data along with "its own serial number and expiration time" and signed using its private key. There are several potential problems with this, including: the issuer name may be inappropriate, extraction of the public key is not mentioned, revocation is not mentioned (should the certificates have short life times to compensate), the extensions field may have inappropriate values. - The diagrams in section 5 appear to indicate that a server may be issued a certificate from multiple superiors. Section 8 doesn't indicate how a server should select which of the certificates issueed to it should be used when interacting with its dependent clients. =20 - In 11.4.1, I'm guessing PREV should be PROV. Also, ENB is not expanded anywhere in the draft (elsewhere ENAB is used but also not expanded). - Section 7 states "All cryptographic values used by the protocol are time sensitive and are regularly refreshed." The security considerations section should expand on this. - I think sections 11.7 and 11.8 should be renamed as 11.6.1 and 11.6.2. - In 11.7, a middleman is said to be unable to produce a valid signature. Why is this the case given the trusted certificate is returned by the server? There are no trusted public keys listed in the client state in section 11.3 and the CERT exchange seems to end only when the server sends a self-signed certificate. Assuming the client has a set of trusted public keys (trust anchors), the CERT exchange may work better if the name sent by the client was the name of a trust anchor and the server sent down the full path in one shot. =20 - H.2 states that the semantics of certificate fields "generally conforms with conventional usage, there are subtle variations". Some of these variations are problematic. The description of the ExtendedKeyUsage extension refers to populating it with string values. The extension is a sequence of OIDs. Similarly it refers to a string values in basic constraints and keyUsage extensions. =20 - The Name example in H.2 should have a SET as the outermost layer (containing the current SEQUENCE). Similarly, the validity example seems to require UTCTime. =20 - There are several references to RFC 2510 that should probably be changed to refer to RFC 5280. References to RFC 3280 should be changed to RFC 5280. - I focused on the "trusted certificate" scheme and have not yet reviewed the other identity schemes and was fairly quick in reading some other sections. =20 From bew@cisco.com Mon Jun 15 11:58:58 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D2F63A6923; Mon, 15 Jun 2009 11:58:58 -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 3Me4LUatocmq; Mon, 15 Jun 2009 11:58:57 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 5F91A3A6BC2; Mon, 15 Jun 2009 11:58:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,224,1243814400"; d="scan'208";a="176526641" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 15 Jun 2009 18:59:04 +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 n5FIx4Xg008360; Mon, 15 Jun 2009 11:59:04 -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 n5FIx4pm025180; Mon, 15 Jun 2009 18:59:04 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 11:59:04 -0700 Received: from dhcp-128-107-163-126.cisco.com ([128.107.163.126]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Jun 2009 11:59:04 -0700 Message-Id: From: Brian Weis To: secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 15 Jun 2009 11:59:03 -0700 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 15 Jun 2009 18:59:04.0212 (UTC) FILETIME=[5A232540:01C9EDEB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1929; t=1245092344; x=1245956344; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20Secdir=20review=20of=20draft-ietf-pce-p2mp-app- 01 |Sender:=20; bh=gTBH4zneMiIELjpcSYZcbmzuV8w8v5yIPLbW0iI2pPQ=; b=XJvWTDbAhxhQngIW+VQHo4ymabGt3icA0U3lfLrIs6y/4UricaNRadSa7R S+zX/k01RYhn7GFk1NHffpN91vEG87Nk4Xqf68Quux/jDuSx+4VrectI2XBY c1uZ8nJbEI; Authentication-Results: sj-dkim-2; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: draft-ietf-pce-p2mp-app@tools.ietf.org, pce-chairs@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-pce-p2mp-app-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 18:58:58 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This Informational document describes how the Path Computation Element (PCE)-based architecture defined in RFC 4655 can support point-to- multipoint label switched paths. A PCE is a device that computes the path of Traffic Engineered Label Switched Paths (TE LSPs) within Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A PCE-based architecture is generally used to offload path computation processing from Label Switching Routers (LSRs). This document does not substantially change the architecture described in RFC 4655. The Security Considerations section states that this document does not raise any additional security issues beyond those that generally apply to the PCE architecture, and I believe that is generally true. However, I do have one minor suggestion for the authors: The "Note" in the Security Considerations section points out that P2MP computation is CPU-intensive, and posits that an attacker injecting spurious P2MP path computation requests may be more successful than if the attacker injected P2P computation requests. Since you brought up the attack, it would be worth noting that the use of a message integrity mechanism by a PCE protocol should be used to mitigate attacks from devices that are not authorized to send requests to the PCE device. I hesitate to be more specific because the document does not describe a particular PCE protocol. Brian -- Brian Weis Router/Switch Security Group, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From prvs=41033d221=acee@redback.com Mon Jun 15 16:41:18 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1B423A6967; Mon, 15 Jun 2009 16:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_46=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 cs2EUJC09EsX; Mon, 15 Jun 2009 16:41:17 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 006EF3A69D0; Mon, 15 Jun 2009 16:41:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,224,1243839600"; d="scan'208";a="2471990" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 15 Jun 2009 16:41:10 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id A2AE882977C; Mon, 15 Jun 2009 16:41:10 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27692-05; Mon, 15 Jun 2009 16:41:10 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id CB44B829779; Mon, 15 Jun 2009 16:41:08 -0700 (PDT) In-Reply-To: <20090610162141.GB7309@elstar.local> References: <20090610133954.GC6346@elstar.local> <72DEC793-5666-4441-BFD7-05F03956E065@redback.com> <20090610162141.GB7309@elstar.local> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <471300CE-CFA8-4A9D-A155-89EBE8A47E08@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Mon, 15 Jun 2009 19:41:07 -0400 To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.753.1) Cc: "ospf-chairs@tools.ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" , "vishwas@ipinfusion.com" , "djoyal@nortel.com" Subject: Re: [secdir] secdir review of draft-ietf-ospf-ospfv3-mib.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 23:41:18 -0000 Juergen, I think what I'll ask the authors to do is talk about the risks in general terms for read=create and read-only variables. We're NOT going have a separate set of security considerations per variable. That would be the type of work that was carried out in the now- defunct RPSEC WG. Thanks, Acee On Jun 10, 2009, at 12:21 PM, Juergen Schoenwaelder wrote: > On Wed, Jun 10, 2009 at 05:06:30PM +0200, Acee Lindem wrote: >> Juergen, >> >> You refer to an an attached boiler plate for MIB security >> considerations but I don't see any attachments. > > Sorry, I am trying again to attach the attachment. But this > boilerplate is really just an extended version of the boilerplate > posted on the OPS web site. Lines beginning with # are comment > lines. > >> In the future, I'd hope the secdir could register their comments >> earlier in the process. We have taken this document all the way >> through the IESG and MIB doctors reviews and are not one day away >> from the end of the IETF last call. > > I understand your feelings. But on the other hand, the requested > changes do not affect in any way how the MIB module works - it is all > about properly writing up the security considerations - so this is > mainly some additional editing work. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > From xavier.marjou@orange-ftgroup.com Tue Jun 16 05:52:03 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6454E28C146; Tue, 16 Jun 2009 05:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 zI20tSMjIbIG; Tue, 16 Jun 2009 05:52:02 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 0748A3A6A76; Tue, 16 Jun 2009 05:52:01 -0700 (PDT) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 14:51:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 14:51:06 +0200 Message-ID: <51D96D3F30495C4BAF8D190702F9B93316E6E1@ftrdmel1> In-Reply-To: <4A35EF28.2090105@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-avt-app-rtp-keepalive-05 Thread-Index: AcnthctnXopTyER2QNC3nohaH+CJmgA+nAOg References: <4A35EF28.2090105@sun.com> From: To: X-OriginalArrivalTime: 16 Jun 2009 12:51:09.0028 (UTC) FILETIME=[1EB72240:01C9EE81] X-Mailman-Approved-At: Tue, 16 Jun 2009 06:01:48 -0700 Cc: aurelien.sollaud@orange-ftgroup.com, draft-ietf-avt-app-rtp-keepalive@tools.ietf.org, iesg@ietf.org, avt-chairs@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Review of draft-ietf-avt-app-rtp-keepalive-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 12:52:03 -0000 > old peers, which don't understand the new keepalive message, will=20 > appropriately drop the packet sent by its peer? =20 Yes exactly. An old peer "only" implements RFC3550, which mandates to = "ignore packets with payload types that it does not understand". The new = fallback keepalive message makes part of such non-understandable packets = and will thus be ignored/discarded, as mentioned in section 4.6 > Editorial comment(s): > > Expand the first occurrences of "SDP" and "RTCP". > > s/needs support/needs to support/ > > s/mux"attribute/mux" attribute/ =20 Thank you for your careful review.=20 =20 Cheers, Xavier & Aur=E9lien=20 -----Message d'origine----- De : Shawn.Emery@Sun.COM [mailto:Shawn.Emery@Sun.COM]=20 Envoy=E9 : lundi 15 juin 2009 08:50 =C0 : secdir@ietf.org; draft-ietf-avt-app-rtp-keepalive@tools.ietf.org; = avt-chairs@tools.ietf.org; iesg@ietf.org Objet : Review of draft-ietf-avt-app-rtp-keepalive-05 I have reviewed this document as part of the security directorate's = ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security = area directors. Document editors and WG chairs should treat these = comments just like any other last call comments. This draft describes various ways for RTP applications to keep NAT = mappings alive. It goes on to detail individual keepalive methods and = advantages/disadvantages of its approach. Intended status of the draft is BCP. I'm not for sure I understand the security considerations section, but I = think what it's trying to say is that: old peers, which don't understand = the new keepalive message, will appropriately drop the packet sent by = its peer? If so then please reword accordingly. No additional security related issues beyond RTP itself discovered in = this draft. General comment(s): I appreciate the use of a requirements section, this makes it easier to = find out what is or is not in scope for the recommended solutions. Editorial comment(s): Expand the first occurrences of "SDP" and "RTCP". s/needs support/needs to support/ s/mux"attribute/mux" attribute/ Shawn. -- From turners@ieca.com Tue Jun 16 08:45:13 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FB5928C197 for ; Tue, 16 Jun 2009 08:45:13 -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 cYXlId1Y-+JU for ; Tue, 16 Jun 2009 08:45:12 -0700 (PDT) Received: from smtp108.biz.mail.mud.yahoo.com (smtp108.biz.mail.mud.yahoo.com [68.142.201.177]) by core3.amsl.com (Postfix) with SMTP id 6060328C19A for ; Tue, 16 Jun 2009 08:45:12 -0700 (PDT) Received: (qmail 25351 invoked from network); 16 Jun 2009 15:43:39 -0000 Received: from unknown (HELO thunderfish.local) (turners@98.240.94.168 with plain) by smtp108.biz.mail.mud.yahoo.com with SMTP; 16 Jun 2009 15:43:38 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: LczwrxQVM1nAV.q3uoqP7BcU9MEn9kjdoXRFeNzzTPrSFRowpJ9cn1Wx2v8Tts5trmzo7btkwA8i.OkMaZ5oWCozHgCc8OoEhTBZDMkv5UdshlHYXqt6Em4P.laf.QVPq3kwlSWrCJTXLgUojSa8oji0MkpxsHGYuVkRE5VkhmiKGSI33sEHN9REo970V0C3GyPUp75A_hAOwmhbLZS9CCzbSiYrXOAVpqh5aBvmAEMi9.Jkb3I8FwZedTqY7TsGKBacR9TJ7MPOC5AFF8BBrNOpjjFTOQG0u5sMhXb_psRI_RIznHCsEdI1pUhvYEngBQt1hCnDG5mh7CaaJd_.n3daBMHNuU4SJGeIomDHgYx2EQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A37BDAA.50306@ieca.com> Date: Tue, 16 Jun 2009 11:43:38 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: secdir , draft-ietf-dime-diameter-api@tools.ietf.org, iesg@ietf.org, dime-chairs@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Hannes Tschofenig Subject: [secdir] Review of draft-ietf-dime-diameter-api-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 15:45:13 -0000 I have reviewed this document (twice now) as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This version does not address the comments I made against the -07 version, notably: The document needs to discuss the security considerations surrounding the API in your document, as opposed to just pointing to RFC5388. Nits: - Sec 3.1.1: add "." to end of last sentence - Sec 3.4.3.1 and 3.4.3.2: r/- The NAI of the user./The NAI of the user. - Sec 3.4.5.7: Move description before C code. spt From weiler+secdir@watson.org Tue Jun 16 09:17:34 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28463A6B58 for ; Tue, 16 Jun 2009 09:17:34 -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 AI8O3n-SvQ8F for ; Tue, 16 Jun 2009 09:17:34 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id DB8F83A6BD5 for ; Tue, 16 Jun 2009 09:17:33 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n5GGHAhu069321 for ; Tue, 16 Jun 2009 12:17:10 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n5GGH9rl069316 for ; Tue, 16 Jun 2009 12:17:10 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Tue, 16 Jun 2009 12:17:09 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Tue, 16 Jun 2009 17:17:10 +0100 (BST) Subject: [secdir] assignments for June 23rd X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 16:17:35 -0000 The last big assignment message was on June 4th; some of you may also have gotten notes since then about documents on the telechat this week. There are about twenty new assignments below; it would be wise to check for your name. Love Hornquist-Astrand is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-06-18 Dave Cridland T draft-housley-aes-key-wrap-with-pad-03 For telechat 2009-07-02 Rob Austein T draft-ietf-opsec-blackhole-urpf-04 Stephen Farrell T draft-ietf-mipshop-mos-dns-discovery-06 David Harrington T draft-ietf-pkix-tac-04 Paul Hoffman T draft-ietf-smime-new-asn1-05 For telechat 2009-07-16 Julien Laganier T draft-hollenbeck-rfc4934bis-01 Catherine Meadows T draft-hollenbeck-rfc4930bis-02 Glen Zorn T draft-solinas-suiteb-cert-profile-03 Last calls and special requests: Reviewer Draft Derek Atkins draft-green-secsh-ecc-08 Richard Barnes draft-ietf-adslmib-vdsl2-07 Pat Cain draft-ietf-ancp-framework-10 Ran Canetti draft-ietf-ancp-security-threats-07 Dave Cridland draft-ietf-behave-nat-behavior-discovery-06 Dave Cridland draft-ietf-dccp-ccid4-04 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Alan DeKok draft-ietf-dccp-quickstart-05 Donald Eastlake draft-ietf-dime-qos-attributes-12 Shawn Emery draft-ietf-ipfix-export-per-sctp-stream-02 Tobias Gondrom draft-ietf-nea-pa-tnc-04 Phillip Hallam-Baker draft-ietf-nea-pb-tnc-04 Steve Hanna draft-peterson-rai-rfc3427bis-01 Steve Hanna draft-ietf-avt-rtcpssm-18 Steve Hanna draft-ietf-netconf-partial-lock-08 Dan Harkins draft-ietf-pwe3-vccv-bfd-05 Sam Hartman draft-ietf-sipcore-subnot-etags-02 Paul Hoffman draft-ietf-sip-eku-05 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Scott Kelly draft-livingood-woundy-p4p-experiences-10 Stephen Kent draft-ietf-geopriv-l7-lcp-ps-09 Julien Laganier draft-ietf-sip-certs-07 Catherine Meadows draft-ietf-speechsc-mrcpv2-19 Catherine Meadows draft-ietf-rmt-bb-lct-revised-09 Vidya Narayanan draft-ietf-sip-saml-06 Vidya Narayanan draft-ietf-enum-3761bis-04 Chris Newman draft-ietf-sip-connect-reuse-13 Eric Rescorla R draft-ietf-geopriv-http-location-delivery-14 Eric Rescorla draft-ietf-enum-iax-05 Joe Salowey draft-ietf-geopriv-lis-discovery-11 Joe Salowey draft-dawkins-nomcom-dont-wait-03 Stefan Santesson draft-ietf-tsvwg-rsvp-l3vpn-02 Hannes Tschofenig draft-ietf-pce-monitoring-05 Hannes Tschofenig draft-ietf-l2tpext-circuit-status-extensions-04 Sam Weiler draft-chown-v6ops-rogue-ra-03 Sam Weiler draft-ietf-ospf-dynamic-hostname-03 Brian Weis draft-ietf-pce-inter-layer-frwk-10 Nico Williams draft-ietf-v6ops-ra-guard-03 Nico Williams draft-ietf-pcn-marking-behaviour-03 Tom Yu draft-ietf-pwe3-ms-pw-arch-06 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 Larry Zhu draft-ietf-ecrit-location-hiding-req-01 Larry Zhu draft-ietf-tcpm-rfc2581bis-05 From dave.cridland@isode.com Tue Jun 16 09:44:06 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E678F3A6BC3; Tue, 16 Jun 2009 09:44:06 -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 l7FtOsIkWNeq; Tue, 16 Jun 2009 09:44:06 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 04EDE3A6A9C; Tue, 16 Jun 2009 09:44:03 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 16 Jun 2009 17:26:09 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <27893.1245169561.109739@puncture> Date: Tue, 16 Jun 2009 17:26:01 +0100 From: Dave Cridland To: The IESG , , Tim Polk , , Security Area Directorate MIME-Version: 1.0 Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: [secdir] secdir review of draft-housley-aes-key-wrap-with-pad-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 16:44:07 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is not within my expertise, but I felt it was mostly adequately clear for someone not fully familiar with the underlying cryptography. The Security Considerations in particular cover everything I was expecting to see, and some information I'd not previously been aware of. However, the 7th paragraph is somewhat surprising to me, beginning: The key wrapping technique specified in this document requires the length of the key data to be at least nine octets because a single application of the AES codebook is sufficient to protect up to eight octets of key data. In particular, if the key data consists of eight or fewer octets, then a 64-bit integrity check value could be prepended to the key data to form a single 128-bit block. For Was this intended to be: [...] application of the AES codebook is INsufficient to protect up to eight [...] Otherwise, the paragraph doesn't fully make sense to me. Aside from this, the document is clear and, in my opionion, suitable for publication. Dave. From dromasca@avaya.com Tue Jun 16 09:52:17 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6633A6BB8; Tue, 16 Jun 2009 09:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 V7cKppWA2lr7; Tue, 16 Jun 2009 09:52:16 -0700 (PDT) Received: from nj300815-nj-outbound.net.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 42E953A695F; Tue, 16 Jun 2009 09:52:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,229,1243828800"; d="scan'208";a="164452672" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.net.avaya.com with ESMTP; 16 Jun 2009 12:30:08 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 16 Jun 2009 12:30:07 -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, 16 Jun 2009 18:30:04 +0200 Message-ID: In-Reply-To: <4A37BDAA.50306@ieca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-dime-diameter-api-08 Thread-Index: AcnumX+1jgtXkBqHSRe3ViZPe/SmzQABYVJg References: <4A37BDAA.50306@ieca.com> From: "Romascanu, Dan (Dan)" To: "Sean Turner" , "secdir" , , , Cc: pacalhou@cisco.com, Hannes Tschofenig , Victor Fajardo , dave@frascone.com Subject: Re: [secdir] Review of draft-ietf-dime-diameter-api-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 16:52:17 -0000 Sean, Was your review sent to the editors of the document?=20 Can you please clarify why you believe that the API introduces supplementary security concerns, which would make the reference to the security considerations of RFC 5366 insufficient?=20 Thanks and Regards, Dan > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On=20 > Behalf Of Sean Turner > Sent: Tuesday, June 16, 2009 6:44 PM > To: secdir; draft-ietf-dime-diameter-api@tools.ietf.org;=20 > iesg@ietf.org; dime-chairs@ietf.org > Cc: Hannes Tschofenig > Subject: Review of draft-ietf-dime-diameter-api-08 >=20 > I have reviewed this document (twice now) as part of the=20 > security directorate's ongoing effort to review all IETF=20 > documents being processed by the IESG. These comments were=20 > written primarily for the benefit of the security area=20 > directors. Document editors and WG chairs should treat these=20 > comments just like any other last call comments. >=20 > This version does not address the comments I made against the=20 > -07 version, notably: >=20 > The document needs to discuss the security considerations=20 > surrounding the API in your document, as opposed to just=20 > pointing to RFC5388. >=20 > Nits: > - Sec 3.1.1: add "." to end of last sentence > - Sec 3.4.3.1 and 3.4.3.2: r/- The NAI of the user./The NAI=20 > of the user. > - Sec 3.4.5.7: Move description before C code. >=20 > spt >=20 From turners@ieca.com Tue Jun 16 11:07:47 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 835293A6A7D for ; Tue, 16 Jun 2009 11:07:47 -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 Rk0U5XLtlXNp for ; Tue, 16 Jun 2009 11:07:47 -0700 (PDT) Received: from smtp103.biz.mail.mud.yahoo.com (smtp103.biz.mail.mud.yahoo.com [68.142.200.238]) by core3.amsl.com (Postfix) with SMTP id 431153A6ACA for ; Tue, 16 Jun 2009 11:07:47 -0700 (PDT) Received: (qmail 67330 invoked from network); 16 Jun 2009 18:01:17 -0000 Received: from unknown (HELO thunderfish.local) (turners@98.240.94.168 with plain) by smtp103.biz.mail.mud.yahoo.com with SMTP; 16 Jun 2009 18:01:16 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: pISTYoAVM1mSvc2lbBF.Vnhiz7ucautZFiW1WxUivwOdl8aBIHLuMShcBCD1OrmmKhnjvx7ugL_NzHxzqZxPcp04lFeW7t6VtH2wD7ey6cDrNwQ0gT9F5mWFOL.549SESblIc8W724xdRWk1aEoX83Os9iJ2yN.YNNaM15_X0_U.wP3qeK0bv5bY0PxTw9ipDxJam0lsMhoV.wdeqhKFivlIIGFUxoHDPE_yCR6PuU_pPLtyEy.TIAxerTWrkf.LjvwPEPVwKp42mEp8n1WyLkr8nuxXhNZxQdqFLGgOQmYZqwvHQFqorCVZLymYT0xGFXFzRIJuyitMjWboCy8D9gVQR_tkFpzza18E X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A37DDEB.7070402@ieca.com> Date: Tue, 16 Jun 2009 13:01:15 -0500 From: Sean Turner User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4A37BDAA.50306@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pacalhou@cisco.com, secdir , dave@frascone.com, dime-chairs@ietf.org, draft-ietf-dime-diameter-api@tools.ietf.org, iesg@ietf.org, Hannes Tschofenig , Victor Fajardo Subject: Re: [secdir] Review of draft-ietf-dime-diameter-api-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:07:47 -0000 Dan, I sent the review to Pat and to Dave (and the iesg and secdir). I see that Victor was also added during the last go around so if he made the changes I'm not sure he would have seen them. My concern is that the document is for the Diameter API but the security considerations points to the Diameter Protocol. So, we don't have any security considerations at all if we just point to the protocol definition, which is what the document does now. spt Romascanu, Dan (Dan) wrote: > Sean, > > Was your review sent to the editors of the document? > > Can you please clarify why you believe that the API introduces > supplementary security concerns, which would make the reference to the > security considerations of RFC 5366 insufficient? > > Thanks and Regards, > > Dan > > >> -----Original Message----- >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On >> Behalf Of Sean Turner >> Sent: Tuesday, June 16, 2009 6:44 PM >> To: secdir; draft-ietf-dime-diameter-api@tools.ietf.org; >> iesg@ietf.org; dime-chairs@ietf.org >> Cc: Hannes Tschofenig >> Subject: Review of draft-ietf-dime-diameter-api-08 >> >> I have reviewed this document (twice now) as part of the >> security directorate's ongoing effort to review all IETF >> documents being processed by the IESG. These comments were >> written primarily for the benefit of the security area >> directors. Document editors and WG chairs should treat these >> comments just like any other last call comments. >> >> This version does not address the comments I made against the >> -07 version, notably: >> >> The document needs to discuss the security considerations >> surrounding the API in your document, as opposed to just >> pointing to RFC5388. >> >> Nits: >> - Sec 3.1.1: add "." to end of last sentence >> - Sec 3.4.3.1 and 3.4.3.2: r/- The NAI of the user./The NAI >> of the user. >> - Sec 3.4.5.7: Move description before C code. >> >> spt >> > From stefan@aaa-sec.com Tue Jun 16 19:26:45 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFFAB3A687A for ; Tue, 16 Jun 2009 19:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 kidyqYsOZ3V4 for ; Tue, 16 Jun 2009 19:26:40 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 74FA53A67B2 for ; Tue, 16 Jun 2009 19:26:38 -0700 (PDT) Received: (qmail 32221 invoked from network); 17 Jun 2009 02:26:47 -0000 Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 17 Jun 2009 02:26:47 -0000 Received: (qmail 8146 invoked from network); 17 Jun 2009 02:26:46 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 17 Jun 2009 02:26:46 -0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 17 Jun 2009 04:26:45 +0200 From: Stefan Santesson To: secdir Message-ID: Thread-Topic: Nroff editor Thread-Index: Acnu8w7ThM4q35QWhEe/5JLkHxNNQw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3328057606_3681875" Subject: [secdir] Nroff editor X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 02:26:46 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3328057606_3681875 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, I hope this is appropriate communication on this mailing list. I finally got some spare time to write the tool I always wanted to have whe= n editing and compiling .nroff formatted I-Ds. I have always hated the endles= s cut and paste, compile, check result iterations when finalizing a new draft= . With this simple app you can edit and see the result instantly in one singl= e app.=20 Some basic information and screenshots are available on my website: http://aaa-sec.com/nroffedit/index.html Download is available from: http://aaa-sec.com/nroffedit/nroffedit/download.html This is basically a Java Swing app distributed in .jar format, which can be opened in any computer with Java VM installed. The Mac version uses Java VM 1.6 and the Windows version Java VM 1.6. It would be fun to know if anyone else would find this useful, and also if you could test this with other .nroff files and find bugs I didn=B9t catch. If you find any, or have any suggestions, I would be happy to know them. Cheers /Stefan --B_3328057606_3681875 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Nroff editor Hi,

I hope this is appropriate communication on this mailing list.

I finally got some spare time to write the tool I always wanted to have whe= n editing and compiling .nroff formatted I-Ds. I have always hated the endle= ss cut and paste, compile, check result iterations when finalizing a new dra= ft.

With this simple app you can edit and see the result instantly in one singl= e app.
Some basic information and screenshots are available on my website: http://aaa-sec.com/nroffedit/inde= x.html
Download is available from: http://aaa-sec.com/nroffedit/nroffedit/download.html

This is basically a Java Swing app distributed in .jar format, which can be= opened in any computer with Java VM installed.
The Mac version uses Java VM 1.6 and the Windows version Java VM 1.6.

It would be fun to know if anyone else would find this useful, and also if = you could test this with other .nroff files  and find bugs I didn’= ;t catch. If you find any, or have any suggestions, I would be happy to know= them.

Cheers

/Stefan --B_3328057606_3681875-- From tlyu@MIT.EDU Tue Jun 16 20:52:55 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5465C3A6822; Tue, 16 Jun 2009 20:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, 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 yI1D5Z6BNGm0; Tue, 16 Jun 2009 20:52:48 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 7233F3A67FE; Tue, 16 Jun 2009 20:52:48 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n5H3qlVs012843; Tue, 16 Jun 2009 23:52:47 -0400 (EDT) Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n5H3qjGW006264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Jun 2009 23:52:46 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id n5H3qjQx027074; Tue, 16 Jun 2009 23:52:45 -0400 (EDT) To: secdir@ietf.org, iesg@ietf.org, pwe3-chairs@tools.ietf.org, matthew.bocci@alcatel-lucent.com, stbryant@cisco.com From: Tom Yu Date: Tue, 16 Jun 2009 23:52:45 -0400 Message-ID: Lines: 44 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.42 Subject: [secdir] secdir review of draft-ietf-pwe3-ms-pw-arch-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 03:52:55 -0000 Security-related comments: My observations on the security-related content of this document focus on the ambiguity of the text in a few places. I suspect that details resolving those ambiguities are available elsewhere, which would make the ambiguity only a minor problem, but I believe that this document should contain at least a summary of those details or a citation to where the reader can find those details. In the Section 13, "Security Considerations", the sentence "However, S-PEs represent a point in the network where the PW label is exposed to additional processing." needs clear elaboration. The PW label is not mentioned again in that section. What are the risks associated with this additional processing? Is a breach of the integrity or confidentiality of the pseudowire (PW) label a threat? Or is the issue that a PW Switching Provider Edge (S-PE) may misdirect or otherwise tamper with a PW segment due to malice, malfunction, or misconfiguration? As in RFC 5254 (referenced in this document), the word "trust" appears in multiple places in the Security Considerations sections without adequate specification, in my opinion. There may be additional disambiguating context for the uses of the word "trust" in RFC 5254 and this document that I am not familiar with. The most reasonable interpretation that I can attach to words such as "trust" and "eligible" in the Security Considerations of these documents is that they refer to the policy of the operator of some network participating in the pseudowire. Ambiguity remains concerning the specific entity whose policy applies in any given instance of those words, but I expect that I would find it more clear once I had more context. Editorial comments: The references section does not distinguish between normative and informative references. By the context of their citations, I infer that all of the cited references are normative. If this is true, the subsection (or section) heading should reflect this fact. Section 11, "Congestion Considerations", includes an editor's note to reference draft-ietf-pwe3-congestion-frmwk-01.txt, which has expired. Trailing whitespace occurs on many lines of this document. While cosmetic in nature, it did complicate copying and pasting from this document. From dromasca@avaya.com Wed Jun 17 05:12:24 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4E983A6868; Wed, 17 Jun 2009 05:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 JMdRZZWk856J; Wed, 17 Jun 2009 05:12:23 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id AFA593A6B73; Wed, 17 Jun 2009 05:12:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,235,1243828800"; d="scan'208";a="174200628" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Jun 2009 08:12:34 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 17 Jun 2009 08:12:33 -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: Wed, 17 Jun 2009 14:12:18 +0200 Message-ID: In-Reply-To: <4A37DDEB.7070402@ieca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-dime-diameter-api-08 Thread-Index: AcnurHNnc/K0ebLgTh6TOEJHqBneKQAl68Bw References: <4A37BDAA.50306@ieca.com> <4A37DDEB.7070402@ieca.com> From: "Romascanu, Dan (Dan)" To: "Sean Turner" Cc: pacalhou@cisco.com, secdir , dave@frascone.com, dime-chairs@ietf.org, draft-ietf-dime-diameter-api@tools.ietf.org, iesg@ietf.org, Hannes Tschofenig , Victor Fajardo Subject: Re: [secdir] Review of draft-ietf-dime-diameter-api-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 12:12:24 -0000 Sean, I will let the authors infirm or confirm what I am saying, but my understanding is that they take the position that the document describes an internal API for applications to access the Diameter protocol, and that there is no additional security threat involved in the definition or implementation of such an API.=20 Dan > -----Original Message----- > From: Sean Turner [mailto:turners@ieca.com]=20 > Sent: Tuesday, June 16, 2009 9:01 PM > To: Romascanu, Dan (Dan) > Cc: secdir; draft-ietf-dime-diameter-api@tools.ietf.org;=20 > iesg@ietf.org; dime-chairs@ietf.org; Hannes Tschofenig;=20 > Victor Fajardo; pacalhou@cisco.com; dave@frascone.com > Subject: Re: Review of draft-ietf-dime-diameter-api-08 >=20 > Dan, >=20 > I sent the review to Pat and to Dave (and the iesg and=20 > secdir). I see that Victor was also added during the last go=20 > around so if he made the changes I'm not sure he would have seen them. >=20 > My concern is that the document is for the Diameter API but=20 > the security considerations points to the Diameter Protocol. =20 > So, we don't have any security considerations at all if we=20 > just point to the protocol definition, which is what the=20 > document does now. >=20 > spt >=20 > Romascanu, Dan (Dan) wrote: > > Sean, > >=20 > > Was your review sent to the editors of the document?=20 > >=20 > > Can you please clarify why you believe that the API introduces=20 > > supplementary security concerns, which would make the=20 > reference to the=20 > > security considerations of RFC 5366 insufficient? > >=20 > > Thanks and Regards, > >=20 > > Dan > >=20 > >=20 > >> -----Original Message----- > >> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org]=20 > On Behalf=20 > >> Of Sean Turner > >> Sent: Tuesday, June 16, 2009 6:44 PM > >> To: secdir; draft-ietf-dime-diameter-api@tools.ietf.org; > >> iesg@ietf.org; dime-chairs@ietf.org > >> Cc: Hannes Tschofenig > >> Subject: Review of draft-ietf-dime-diameter-api-08 > >> > >> I have reviewed this document (twice now) as part of the security=20 > >> directorate's ongoing effort to review all IETF documents being=20 > >> processed by the IESG. These comments were written=20 > primarily for the=20 > >> benefit of the security area directors. Document editors and WG=20 > >> chairs should treat these comments just like any other last call=20 > >> comments. > >> > >> This version does not address the comments I made against the > >> -07 version, notably: > >> > >> The document needs to discuss the security considerations=20 > surrounding=20 > >> the API in your document, as opposed to just pointing to RFC5388. > >> > >> Nits: > >> - Sec 3.1.1: add "." to end of last sentence > >> - Sec 3.4.3.1 and 3.4.3.2: r/- The NAI of the user./The NAI of the=20 > >> user. > >> - Sec 3.4.5.7: Move description before C code. > >> > >> spt > >> > >=20 >=20 From vfajardo@tari.toshiba.com Wed Jun 17 05:28:56 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B128128C245; Wed, 17 Jun 2009 05:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.593 X-Spam-Level: X-Spam-Status: No, score=-3.593 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK+jzjHAoneH; Wed, 17 Jun 2009 05:28:55 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id C00BC28C242; Wed, 17 Jun 2009 05:28:54 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id n5HCShMQ025941; Wed, 17 Jun 2009 21:28:43 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id n5HCShML018407; Wed, 17 Jun 2009 21:28:43 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id XAA18406; Wed, 17 Jun 2009 21:28:43 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id n5HCSgQM026708; Wed, 17 Jun 2009 21:28:42 +0900 (JST) Received: from ivp1.toshiba.co.jp by toshiba.co.jp id n5HCSgvf003246; Wed, 17 Jun 2009 21:28:42 +0900 (JST) Received: from ext-gw.toshiba.co.jp by ivp1.toshiba.co.jp with ESMTP id n5HCSf2o019561; Wed, 17 Jun 2009 21:28:41 +0900 (JST) Received: from toshi17.tari.toshiba.com (tari-gw [172.30.24.10]) by ext-gw.toshiba.co.jp with ESMTP id n5HCSeaa003050; Wed, 17 Jun 2009 21:28:41 +0900 (JST) Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n5HCZDB5007870; Wed, 17 Jun 2009 08:35:13 -0400 (EDT) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <4A3811A7.2050708@tari.toshiba.com> Date: Tue, 16 Jun 2009 17:41:59 -0400 From: Victor Fajardo User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4A37BDAA.50306@ieca.com> <4A37DDEB.7070402@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 17 Jun 2009 05:41:13 -0700 Cc: pacalhou@cisco.com, secdir , dave@frascone.com, dime-chairs@ietf.org, draft-ietf-dime-diameter-api@tools.ietf.org, iesg@ietf.org, Hannes Tschofenig Subject: Re: [secdir] Review of draft-ietf-dime-diameter-api-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 12:28:56 -0000 Hi Dan, > I will let the authors infirm or confirm what I am saying, but my > understanding is that they take the position that the document describes > an internal API for applications to access the Diameter protocol, and > that there is no additional security threat involved in the definition > or implementation of such an API. > Yes. This is our understanding as well. Defining functions and structures does not seem to introduce any security concerns to us. It is possible that implementors introduced security vulnerabilities when implementing internals of the API's (etc. bug in code, weak algorithms, data structures that will not scale etc.). However, these are outside the scope of the document. If this is something to be clarified then we can add text stating this. regards, victor > Dan > > > >> -----Original Message----- >> From: Sean Turner [mailto:turners@ieca.com] >> Sent: Tuesday, June 16, 2009 9:01 PM >> To: Romascanu, Dan (Dan) >> Cc: secdir; draft-ietf-dime-diameter-api@tools.ietf.org; >> iesg@ietf.org; dime-chairs@ietf.org; Hannes Tschofenig; >> Victor Fajardo; pacalhou@cisco.com; dave@frascone.com >> Subject: Re: Review of draft-ietf-dime-diameter-api-08 >> >> Dan, >> >> I sent the review to Pat and to Dave (and the iesg and >> secdir). I see that Victor was also added during the last go >> around so if he made the changes I'm not sure he would have seen them. >> >> My concern is that the document is for the Diameter API but >> the security considerations points to the Diameter Protocol. >> So, we don't have any security considerations at all if we >> just point to the protocol definition, which is what the >> document does now. >> >> spt >> >> Romascanu, Dan (Dan) wrote: >> >>> Sean, >>> >>> Was your review sent to the editors of the document? >>> >>> Can you please clarify why you believe that the API introduces >>> supplementary security concerns, which would make the >>> >> reference to the >> >>> security considerations of RFC 5366 insufficient? >>> >>> Thanks and Regards, >>> >>> Dan >>> >>> >>> >>>> -----Original Message----- >>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] >>>> >> On Behalf >> >>>> Of Sean Turner >>>> Sent: Tuesday, June 16, 2009 6:44 PM >>>> To: secdir; draft-ietf-dime-diameter-api@tools.ietf.org; >>>> iesg@ietf.org; dime-chairs@ietf.org >>>> Cc: Hannes Tschofenig >>>> Subject: Review of draft-ietf-dime-diameter-api-08 >>>> >>>> I have reviewed this document (twice now) as part of the security >>>> directorate's ongoing effort to review all IETF documents being >>>> processed by the IESG. These comments were written >>>> >> primarily for the >> >>>> benefit of the security area directors. Document editors and WG >>>> chairs should treat these comments just like any other last call >>>> comments. >>>> >>>> This version does not address the comments I made against the >>>> -07 version, notably: >>>> >>>> The document needs to discuss the security considerations >>>> >> surrounding >> >>>> the API in your document, as opposed to just pointing to RFC5388. >>>> >>>> Nits: >>>> - Sec 3.1.1: add "." to end of last sentence >>>> - Sec 3.4.3.1 and 3.4.3.2: r/- The NAI of the user./The NAI of the >>>> user. >>>> - Sec 3.4.5.7: Move description before C code. >>>> >>>> spt >>>> >>>> > > > > From Matthew.Bocci@alcatel-lucent.com Wed Jun 17 06:10:43 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43B3E3A6C44; Wed, 17 Jun 2009 06:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=2.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 1M1MMvECI+Fp; Wed, 17 Jun 2009 06:10:41 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id C9E313A6982; Wed, 17 Jun 2009 06:10:40 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n5HDAE9S009216; Wed, 17 Jun 2009 15:10:25 +0200 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 15:10:24 +0200 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: Wed, 17 Jun 2009 15:10:22 +0200 Message-ID: <0458D2EE0C36744BABB36BE37805C29A03FB78C7@FRVELSMBS11.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-ietf-pwe3-ms-pw-arch-06 Thread-Index: Acnu/xfQq5DAl9vxTYCNwxPpIbMncwASEXKQ References: From: "BOCCI Matthew" To: "Tom Yu" , , , , X-OriginalArrivalTime: 17 Jun 2009 13:10:24.0128 (UTC) FILETIME=[F99F2800:01C9EF4C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 X-Mailman-Approved-At: Wed, 17 Jun 2009 08:07:17 -0700 Subject: Re: [secdir] secdir review of draft-ietf-pwe3-ms-pw-arch-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 13:10:43 -0000 Tom, Many thanks for your review. > -----Original Message----- > From: Tom Yu [mailto:tlyu@MIT.EDU] > Sent: 17 June 2009 04:53 > To: secdir@ietf.org; iesg@ietf.org; pwe3-chairs@tools.ietf.org; BOCCI > Matthew; stbryant@cisco.com > Subject: secdir review of draft-ietf-pwe3-ms-pw-arch-06 >=20 > Security-related comments: >=20 > My observations on the security-related content of this document focus > on the ambiguity of the text in a few places. I suspect that details > resolving those ambiguities are available elsewhere, which would make > the ambiguity only a minor problem, but I believe that this document > should contain at least a summary of those details or a citation to > where the reader can find those details. >=20 > In the Section 13, "Security Considerations", the sentence "However, > S-PEs represent a point in the network where the PW label is exposed > to additional processing." needs clear elaboration. The PW label is > not mentioned again in that section. What are the risks associated > with this additional processing? Is a breach of the integrity or > confidentiality of the pseudowire (PW) label a threat? Or is the > issue that a PW Switching Provider Edge (S-PE) may misdirect or > otherwise tamper with a PW segment due to malice, malfunction, or > misconfiguration? It is exposed to the forwarding functionality in the S-PE, so it is at least swapped by an S-PE and therefore associated with the context of the downstream PW segment. The PW label is itself not confidential because it is allocated by a downstream S-PE that does the label swap, however an upstream S-PE must 'trust' that the downstream S-PE will maintain that context correctly. I suggest adding the following to address this: "An S-PE or T-PE must trust that the context of the MS-PW is maintained by a downstream S-PE. OAM tools must be able to verify the identity of the far end T-PE to the satisfaction of the network operator." >=20 > As in RFC 5254 (referenced in this document), the word "trust" appears > in multiple places in the Security Considerations sections without > adequate specification, in my opinion. There may be additional > disambiguating context for the uses of the word "trust" in RFC 5254 > and this document that I am not familiar with. The most reasonable > interpretation that I can attach to words such as "trust" and > "eligible" in the Security Considerations of these documents is that > they refer to the policy of the operator of some network participating > in the pseudowire. Ambiguity remains concerning the specific entity > whose policy applies in any given instance of those words, but I > expect that I would find it more clear once I had more context. I propose adding the following clarifications of the terms 'trust' and 'eligible': An eligible S-PE or T-PE is one that meets the security and privacy requirements of the MS-PW, according to the network operator's policy.=20 A trusted S-PE or T-PE is therefore one that is understood to be eligible by its next hop S-PE or T-PE, while a trust relationship exists between two S-PEs or T-PEs if they mutually consider each other to be eligible. =20 >=20 > Editorial comments: >=20 > The references section does not distinguish between normative and > informative references. By the context of their citations, I infer > that all of the cited references are normative. If this is true, the > subsection (or section) heading should reflect this fact. We have split this into normative and informative references as per the GenART review. >=20 > Section 11, "Congestion Considerations", includes an editor's note to > reference draft-ietf-pwe3-congestion-frmwk-01.txt, which has expired. I propose removing this editor's note and adding an informative reference to the latest congestion framework draft, which has just been uploaded. >=20 > Trailing whitespace occurs on many lines of this document. While > cosmetic in nature, it did complicate copying and pasting from this > document. I think this is a result of the draft being produced with the MS Word template. I think Word pads the end of each line with white space when we print to text file, which post-processing with the draft.pl script does not remove. Best regards Matthew From jelte@NLnetLabs.nl Thu Jun 18 02:44:06 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05DAB3A698D for ; Thu, 18 Jun 2009 02:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU7dcQFxM+KA for ; Thu, 18 Jun 2009 02:44:05 -0700 (PDT) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by core3.amsl.com (Postfix) with ESMTP id A8B143A6CA3 for ; Thu, 18 Jun 2009 02:43:50 -0700 (PDT) Received: from mirre.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:fecd:6a66] (may be forged)) (authenticated bits=0) by open.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id n5I9hx6i028443 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jun 2009 11:43:59 +0200 (CEST) (envelope-from jelte@NLnetLabs.nl) Message-ID: <4A3A0BEA.6090108@NLnetLabs.nl> Date: Thu, 18 Jun 2009 11:42:02 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.21 (X11/20090423) MIME-Version: 1.0 To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::53]); Thu, 18 Jun 2009 11:43:59 +0200 (CEST) X-Mailman-Approved-At: Thu, 18 Jun 2009 02:45:11 -0700 Cc: Andrew Sullivan Subject: [secdir] SHA512 in draft-dnsext-dnssec-rsa-sha2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 09:44:06 -0000 Hi, I am the editor of http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-rsasha256-14 which has seen its share of trouble, but is finally nearing WGLC. This draft defines the use of RSA/SHA256 and RSA/SHA512 with DNSSEC. We were about to call it, when Alfred Hoenes mentioned to me that the IESG will probably raise an issue about the use of SHA512 in this draft. For practical reasons, it does not specify keys larger than 4096 bits to use with RSA/SHA-512, while normally, much larger keysizes are chosen for use with the bigger digest values. So he suspects that this definition should be removed or reduced to SHA/384. So my question is, do you as the security directorate think the same, and should I change this before going into last call? Thanks, Jelte Jansen From ekr@networkresonance.com Thu Jun 18 07:05:33 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D632128C14F for ; Thu, 18 Jun 2009 07:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.227 X-Spam-Level: X-Spam-Status: No, score=-0.227 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] 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 dyOrVZvnNCGy for ; Thu, 18 Jun 2009 07:05:33 -0700 (PDT) Received: from kilo.networkresonance.com (74-95-2-169-SFBA.hfc.comcastbusiness.net [74.95.2.169]) by core3.amsl.com (Postfix) with ESMTP id 0860E28C319 for ; Thu, 18 Jun 2009 07:05:33 -0700 (PDT) Received: from kilo.local (localhost [127.0.0.1]) by kilo.networkresonance.com (Postfix) with ESMTP id 45F101BE038; Thu, 18 Jun 2009 07:06:14 -0700 (PDT) Date: Thu, 18 Jun 2009 07:06:14 -0700 From: Eric Rescorla To: Jelte Jansen In-Reply-To: <4A3A0BEA.6090108@NLnetLabs.nl> References: <4A3A0BEA.6090108@NLnetLabs.nl> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090618140614.45F101BE038@kilo.networkresonance.com> Cc: Andrew Sullivan , secdir@ietf.org Subject: Re: [secdir] SHA512 in draft-dnsext-dnssec-rsa-sha2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 14:05:34 -0000 At Thu, 18 Jun 2009 11:42:02 +0200, Jelte Jansen wrote: > I am the editor of http://tools.ietf.org/html/draft-ietf-dnsext-dnssec-rsasha256-14 > > which has seen its share of trouble, but is finally nearing WGLC. > > This draft defines the use of RSA/SHA256 and RSA/SHA512 with DNSSEC. > > We were about to call it, when Alfred Hoenes mentioned to me that the IESG will > probably raise an issue about the use of SHA512 in this draft. > > For practical reasons, it does not specify keys larger than 4096 bits to use > with RSA/SHA-512, while normally, much larger keysizes are chosen for use with > the bigger digest values. So he suspects that this definition should be removed > or reduced to SHA/384. > > So my question is, do you as the security directorate think the same, and should > I change this before going into last call? Well, I would ask why you're specifying either 384 or 512. SHA-256 would have to be weakened *very* badly before it would be necessary to move up, at which point what makes you think that SHA-384/512 will be strong? -Ekr From ajs@shinkuro.com Thu Jun 18 08:14:52 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0B0A3A6814 for ; Thu, 18 Jun 2009 08:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.478, 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 pnZNaEI8+Hkm for ; Thu, 18 Jun 2009 08:14:52 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 1EC113A686A for ; Thu, 18 Jun 2009 08:14:52 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7B1B72FE9573; Thu, 18 Jun 2009 15:14:56 +0000 (UTC) Date: Thu, 18 Jun 2009 11:14:54 -0400 From: Andrew Sullivan To: Eric Rescorla Message-ID: <20090618151454.GH3542@shinkuro.com> References: <4A3A0BEA.6090108@NLnetLabs.nl> <20090618140614.45F101BE038@kilo.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090618140614.45F101BE038@kilo.networkresonance.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Thu, 18 Jun 2009 08:26:36 -0700 Cc: secdir@ietf.org, Jelte Jansen Subject: Re: [secdir] SHA512 in draft-dnsext-dnssec-rsa-sha2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 15:14:52 -0000 On Thu, Jun 18, 2009 at 07:06:14AM -0700, Eric Rescorla wrote: > > Well, I would ask why you're specifying either 384 or 512. > > SHA-256 would have to be weakened *very* badly before it would > be necessary to move up, at which point what makes you think > that SHA-384/512 will be strong? The point of this is just to get things done. It has taken a remarkably long time to get this SHA-2 draft through the WG -- the current revision is -14, and when we started everyone (including the incredibly patient Jelte) thought this was a quick housekeeping problem. The draft specifies 256, but while we were at it we thought 512 might be a good idea too, so that it'd be done in case we needed it later. Does that change your response? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From phoffman@imc.org Thu Jun 18 09:35:39 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981D63A685E for ; Thu, 18 Jun 2009 09:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, 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 4OggkZH-1X6T for ; Thu, 18 Jun 2009 09:35:38 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5B0433A6842 for ; Thu, 18 Jun 2009 09:35:38 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5IGZk0I017055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jun 2009 09:35:47 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090618151454.GH3542@shinkuro.com> References: <4A3A0BEA.6090108@NLnetLabs.nl> <20090618140614.45F101BE038@kilo.networkresonance.com> <20090618151454.GH3542@shinkuro.com> Date: Thu, 18 Jun 2009 09:35:44 -0700 To: Andrew Sullivan , Eric Rescorla From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: Jelte Jansen , secdir@ietf.org Subject: Re: [secdir] SHA512 in draft-dnsext-dnssec-rsa-sha2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 16:35:39 -0000 At 11:14 AM -0400 6/18/09, Andrew Sullivan wrote: >On Thu, Jun 18, 2009 at 07:06:14AM -0700, Eric Rescorla wrote: >> >> Well, I would ask why you're specifying either 384 or 512. >> >> SHA-256 would have to be weakened *very* badly before it would >> be necessary to move up, at which point what makes you think >> that SHA-384/512 will be strong? > >The point of this is just to get things done. It has taken a >remarkably long time to get this SHA-2 draft through the WG -- the >current revision is -14, and when we started everyone (including the >incredibly patient Jelte) thought this was a quick housekeeping >problem. The draft specifies 256, but while we were at it we thought >512 might be a good idea too, so that it'd be done in case we needed >it later. > >Does that change your response? In the security area, we have discovered that if something security-related is defined, people will use it even if it is stupid. "That's a bigger number, so it will be safer" is a common theme, but so is "they would not have specified that algorithm unless they wanted everyone to implement it". Thus, I think Eric's question still stands. Your response in the document could be "we define this because of the IETF overhead of doing so, not because we want you to use it now", but I suspect that will only reduce the number of people who use the signature algorithm for absolutely no good reason by less than 50%. From ajs@shinkuro.com Thu Jun 18 10:02:41 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45FC03A6D02 for ; Thu, 18 Jun 2009 10:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.025 X-Spam-Level: X-Spam-Status: No, score=-2.025 tagged_above=-999 required=5 tests=[AWL=0.574, 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 4N9NfSFXEjsT for ; Thu, 18 Jun 2009 10:02:40 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 791093A69D9 for ; Thu, 18 Jun 2009 10:02:40 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CE5B12FE9573; Thu, 18 Jun 2009 17:02:50 +0000 (UTC) Date: Thu, 18 Jun 2009 13:02:49 -0400 From: Andrew Sullivan To: Paul Hoffman Message-ID: <20090618170248.GA4118@shinkuro.com> References: <4A3A0BEA.6090108@NLnetLabs.nl> <20090618140614.45F101BE038@kilo.networkresonance.com> <20090618151454.GH3542@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Jelte Jansen , secdir@ietf.org Subject: Re: [secdir] SHA512 in draft-dnsext-dnssec-rsa-sha2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 17:02:41 -0000 On Thu, Jun 18, 2009 at 09:35:44AM -0700, Paul Hoffman wrote: > In the security area, we have discovered that if something > security-related is defined, people will use it even if it is > stupid. "That's a bigger number, so it will be safer" is a common > theme, but so is "they would not have specified that algorithm > unless they wanted everyone to implement it". This is not a property confined to the security area, but I bet you know that ;-) > Thus, I think Eric's question still stands. Your response in the > document could be "we define this because of the IETF overhead of > doing so, not because we want you to use it now", but I suspect that > will only reduce the number of people who use the signature > algorithm for absolutely no good reason by less than 50%. Let me ask the question a different way. We have now a definition for 512 but with a key size that MUST NOT be larger than 4096 bits. Is that something you would oppose? Is it something against which you advise? If the answer to the 1st of those questions is "yes", then it would be very helpful if we could get a short statement from secdir that we could take to the WG to say, "We're removing 512 from this document on the advice of the secdir, and here's their statement." (We might want to define 512 later with a larger max key size, but given that we have at least one working implementation for 256 it'd be nice to get the existing draft out the door.) If the answer to the 2d of those questions is "yes" but the answer to the 1st is "no", then we can put a note in the implementation considerations to the effect that, while we've defined this for completeness, implementors might want to think twice about implementing for the following reasons [insert secdir reasons here]. I appreciate your feedback on this topic -- it's way better to hash this out now (no pun intended) than later. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From phoffman@imc.org Thu Jun 18 11:00:35 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D9228C43C for ; Thu, 18 Jun 2009 11:00:35 -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 Om4nBAxxJ3uo for ; Thu, 18 Jun 2009 11:00:35 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B0CD43A688A for ; Thu, 18 Jun 2009 11:00:34 -0700 (PDT) Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5II0iH0022580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Jun 2009 11:00:45 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090618170248.GA4118@shinkuro.com> References: <4A3A0BEA.6090108@NLnetLabs.nl> <20090618140614.45F101BE038@kilo.networkresonance.com> <20090618151454.GH3542@shinkuro.com> <20090618170248.GA4118@shinkuro.com> Date: Thu, 18 Jun 2009 11:00:42 -0700 To: Andrew Sullivan From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: Jelte Jansen , secdir@ietf.org Subject: Re: [secdir] SHA512 in draft-dnsext-dnssec-rsa-sha2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 18:00:35 -0000 At 1:02 PM -0400 6/18/09, Andrew Sullivan wrote: >Let me ask the question a different way. We have now a definition for >512 but with a key size that MUST NOT be larger than 4096 bits. Is >that something you would oppose? No. >Is it something against which you >advise? Yes. Eric's question is still germane. What attack do you see on SHA256 that makes the cost of SHA512 worth it? >If the answer to the 2d of those questions is "yes" but the answer to >the 1st is "no", then we can put a note in the implementation >considerations to the effect that, while we've defined this for >completeness, implementors might want to think twice about >implementing for the following reasons [insert secdir reasons here]. "We're defining RSA/SHA-512 but we really don't think that there is any good use for it at this time. If we feel that there is a good reason for it, we will publish another RFC that explains why." Again, by the mere act of defining the code point, you will cause a huge waste of resources. Developers will code it prematurely. Naive sysadmins will sign their zones with it. The signatures will traverse the Internet. From jelte@NLnetLabs.nl Thu Jun 18 11:44:41 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0FCF28C37F for ; Thu, 18 Jun 2009 11:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] 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 VMhiTyLJmRnm for ; Thu, 18 Jun 2009 11:44:34 -0700 (PDT) Received: from sol.nlnetlabs.nl (sol.nlnetlabs.nl [213.154.224.43]) by core3.amsl.com (Postfix) with ESMTP id 0214E3A69AE for ; Thu, 18 Jun 2009 11:44:34 -0700 (PDT) Received: from jelte (vhe-520087.sshn.net [195.169.221.157]) by sol.nlnetlabs.nl (Postfix) with ESMTP id 70AC513002C; Thu, 18 Jun 2009 20:44:45 +0200 (CEST) Received: from [192.168.8.11] (dragon [192.168.8.11]) by jelte (Postfix) with ESMTP id DD34BD0172; Thu, 18 Jun 2009 20:44:44 +0200 (CEST) Message-ID: <4A3A8B1C.1090706@NLnetLabs.nl> Date: Thu, 18 Jun 2009 20:44:44 +0200 From: Jelte Jansen User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Paul Hoffman References: <4A3A0BEA.6090108@NLnetLabs.nl> <20090618140614.45F101BE038@kilo.networkresonance.com> <20090618151454.GH3542@shinkuro.com> <20090618170248.GA4118@shinkuro.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Andrew Sullivan , secdir@ietf.org Subject: Re: [secdir] SHA512 in draft-dnsext-dnssec-rsa-sha2 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 18:44:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Hoffman wrote: > At 1:02 PM -0400 6/18/09, Andrew Sullivan wrote: > > "We're defining RSA/SHA-512 but we really don't think that there is any good use for it at this time. If we feel that there is a good reason for it, we will publish another RFC that explains why." > > Again, by the mere act of defining the code point, you will cause a huge waste of resources. Developers will code it prematurely. Naive sysadmins will sign their zones with it. The signatures will traverse the Internet. Just for a bit of recent history; originally the draft only defined 256. There were some people who wanted to do all SHA2 algorithms 'while we're at it' (the reasoning being, even if there is no known attack on 256 right now, it wouldn't hurt to have stronger algorithms in there to be ready for the future, not so much for the IETF overhead, but for deployment times). Because we didn't want to waste code points, we decided on selecting two. Conforming key sizes weren't taken into account here. Since most implementations use crypto libraries that either don't support SHA2 at all or support both 256 and 512, it doesn't seem like a waste of resources from an implementation point of view (of course I could be wrong here). I don't want to define something and essentially tell people not to use it until another RFC comes along; the definition could also go in there then. If it's defined I expect people to use it (in fact, partly due to some overeager developers and some misconceptions about the time this all would take, there happens to be one implementation in the wild that actually uses them right now, which isn't a problem, but will be if the code point that was chosen gets assigned to another algorithm). So, if it's up to me, SHA512 is going to be either in there 'fully' (albeit with keys that are way to small) or not at all. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAko6ixwACgkQ4nZCKsdOncUEMQCeL+Q0TTxaKodXctBbCk4kAGTY O1AAn0QTG7lOIl1+iwT6nGqhAIOcfS6l =S4Sd -----END PGP SIGNATURE----- From Pasi.Eronen@nokia.com Thu Jun 18 12:59:24 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED0CA3A6877; Thu, 18 Jun 2009 12:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 jxt4Gb7wD7sY; Thu, 18 Jun 2009 12:59:23 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 9D7EB3A67A1; Thu, 18 Jun 2009 12:59:23 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5IJxYKx029218; Thu, 18 Jun 2009 14:59:37 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 22:58:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 22:58:27 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 18 Jun 2009 21:58:26 +0200 From: To: , Date: Thu, 18 Jun 2009 21:58:25 +0200 Thread-Topic: Pasi's AD Notes for June 2009 Thread-Index: AcnwTyQo1RQ4yBBZRf6CoJBKhn9BZA== Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6B1379D8@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jun 2009 19:58:27.0196 (UTC) FILETIME=[25149BC0:01C9F04F] X-Nokia-AV: Clean Subject: [secdir] Pasi's AD Notes for June 2009 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 19:59:25 -0000 Here's again a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. Best regards, Pasi MISC NOTES =20 - I will be on parental leave/vacation (not reading email) starting from today; I'll be back on July 20, and the next AD notes will be posted in August. - We received a liaison statement from ITU-T regarding identity management. Tim and I need to organize a reply. - EAPFIX BOF proposal was discussed on the IESG BOF call (Jari=20 handled most of this) - Looking into appointing security advisor for ROLL WG with Tim (currently Adrian has the ball) - Preparing SAAG agenda for IETF75 with Tim - (not wearing AD hat): Errata #1628 (for RFC 4742): waiting for NETCONF WG chairs/Dan to confirm this [since 2009-02-26] (some=20 emails in May, but not done yet) WORKING GROUPS DKIM - draft-ietf-dkim-overview: was approved by IESG, now in RFC Editor queue - draft-ietf-dkim-ssp: waiting for Magnus to get back from his leave and clear his DISCUSS [since 2009-06-08] - I still need to review what to do about errata 1385, 1532, and 1596 - draft-ietf-dkim-rfc4871-errata: waiting for Adrian to clear his DISCUSS [since 2009-06-11], and Dave/Cullen/Barry/Stephen to tell=20 me when we have acceptable text for the introduction. EMU - Quiet month so far... IPSECME - draft-ietf-ipsecme-ikev2-redirect (not wearing AD hat; Tim=20 is handling this one): in IETF Last Call until 2009-06-30 - draft-ietf-ipsecme-ikev2-ipv6-config (not wearing AD hat):=20 I submitted an updated version; waiting for chairs to decide the next steps. - Working on fixing the IANA registrations of RFC 4543; currently waiting for IANA [since 2009-06-11] - Verified errata 1654 for RFC 4303 ISMS - draft-ietf-isms-secshell, draft-ietf-isms-tmsm, and draft-ietf-isms-transport-security-model: in RFC Editor queue/AUTH48; should be published as RFCs in couple of days. - draft-ietf-isms-radius-usage: was approved by IESG, now in=20 RFC Editor queue - Recharter text sent for IETF review, might be approved on 2009-07-02 IESG telechat - Looking for new co-chair... KEYPROV - WGLC for PSKC PKIX - draft-ietf-pkix-rfc4055-update: in RFC Editor queue, waiting for smime-3851bis draft (not a normative reference, but authors preferred it this way), which is waiting for several other drafts (including pkix-3281update and pkix-sha2-dsa-ecdsa). SASL - Change control for TLS channel bindings has been transferred to IETF (big thanks to Larry and Sam!), and Nico has revived=20 draft-altman-tls-channel-bindings to publish them as RFC. When=20 I'm back I need to talk with Nico to see what (if anything)=20 needs to happen before moving this draft forward. SYSLOG - draft-ietf-syslog-sign: waiting for authors to confirm what changes are still needed for version -26 [since 2009-06-17] - Some discussions about rechartering TLS - draft-ietf-tls-extractor: in AD evaluation, waiting for Eric to=20 submit a revised draft [since 2009-05-27] - draft-ietf-tls-rfc4366-bis: went through WGLC; waiting for authors to submit a revised draft, and WG chairs to send=20 a publication request soon... - Looking into errata #117 (for RFC 4346) - (not WG item yet) I need to talk with the chairs and Michael about what to do with Mobi-D OTHER DOCUMENTS - draft-lebovitz-kmart-roadmap: I need to read this and=20 comment/contribute. - "Applicability guidance for security protocols": Tim and I have promised to write something that would help in determining which security mechanism (e.g. TLS, IPsec, SASL, GSS-API, ..) to use for a new higher-layer protocol. DISCUSSES (active -- something happened within last month) - draft-housley-aes-key-wrap-with-pad: waiting for Russ to talk with his coauthor to see how to support 1..8 octet plaintexts [since 2009-06-18] - draft-ietf-dime-diameter-api: waiting for Dan to get WG's opinion=20 on whether this will be useful and if yes, why [since 2009-06-18] - draft-ietf-ltans-dssc: waiting for authors to reply to my=20 comments [since 2009-06-18] - draft-ietf-netlmm-pmip6-ipv4-support: waiting for authors to propose text or submit a revised ID [since 2009-06-11] - draft-ietf-ntp-autokey: waiting for Ralph to get more information from WG [since 2009-06-18] - draft-igoe-secsh-aes-gcm: text agreed, waiting for authors to submit a revised ID. I've cleared my DISCUSS so that my leave doesn't block this for additional month -- Tim will check that the text is as we agreed before approving this. DISCUSSES (stalled -- I haven't heard anything from the authors or document shepherd for over one month) - draft-atlas-icmp-unnumbered: waiting for authors to reply to my comments [since 2009-04-21] - draft-ietf-ipfix-file: waiting for authors to reply to my comments [since 2009-04-23] - draft-ietf-ntp-ntpv4-proto: waiting for authors to reply to my email or submit a revised ID [since 2009-04-16] DISCUSSES (presumed dead -- I haven't heard anything from the authors or document shepherd for over three months) - draft-cain-post-inch-phishingextns: authors have promised a new version some time in February [since 2009-01-29] - draft-cheshire-dnsext-nbp: waiting for authors to reply to my comments [since 2008-12-03] (pinged again on 2009-04-30 and 2009-06-09) - draft-ietf-bfd-base: text agreed, waiting for authors to submit=20 a revised ID [since 2009-03-19] (pinged again on 2009-04-30 and 2009-06-09) - draft-ietf-vrrp-unified-spec: waiting for authors to propose text [since 2008-11-07] (but talked briefly with Radia at IETF74) - draft-ietf-sipping-policy-package: waiting for draft-ietf-sipping- media-policy-dataset to progress (or more information from Robert) [since 2008-10-28] --end-- From turners@ieca.com Sun Jun 21 10:21:20 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DDE73A6CFD for ; Sun, 21 Jun 2009 10:21:20 -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 A1CLwwBprPZU for ; Sun, 21 Jun 2009 10:21:19 -0700 (PDT) Received: from smtp110.biz.mail.re2.yahoo.com (smtp110.biz.mail.re2.yahoo.com [206.190.53.9]) by core3.amsl.com (Postfix) with SMTP id 554C33A6CF6 for ; Sun, 21 Jun 2009 10:21:19 -0700 (PDT) Received: (qmail 33740 invoked from network); 21 Jun 2009 17:21:32 -0000 Received: from unknown (HELO thunderfish.local) (turners@71.191.10.138 with plain) by smtp110.biz.mail.re2.yahoo.com with SMTP; 21 Jun 2009 17:21:31 -0000 X-Yahoo-SMTP: qPTWNAeswBAtDTSn9GKlmmL3C90ke7grn_5n9To- X-YMail-OSG: EfOZW3gVM1l.ei7SSrglkVO9T7we24cgzh5QXk9mWCQKLe2hqaFn9qGZ3uJg.ju8t21Uc45_tIZq3cIbrK4pkCDn2B9goDRF21uBGszy4dGYEpl8jLXBuv9gjwopSyO4SuV2JgjqnLtE5iD_gKFT0.ExLsyJadRiP_z2YNaZJSLfH79qRiTVAakGwTIzTRTZfK6QDFfdsGBdQMzSTo_bFP9DiytzP2F2fCeAJqD24v9daJETijjVCWY1IzPKdr8qOvGjrNhP2P0RYXZUWcT6D6P6AXjDhchtBTBFFbdBOssCNmvWMCnOdby63Xl8HYFBEcOgjkyvR2zg.W0Dzy36yFMOe5lfX_0tUy8eCL7rGA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A3E6C1B.2090907@ieca.com> Date: Sun, 21 Jun 2009 13:21:31 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: <4A37BDAA.50306@ieca.com> <4A37DDEB.7070402@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pacalhou@cisco.com, secdir , dave@frascone.com, dime-chairs@ietf.org, draft-ietf-dime-diameter-api@tools.ietf.org, iesg@ietf.org, Hannes Tschofenig , Victor Fajardo Subject: Re: [secdir] Review of draft-ietf-dime-diameter-api-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 17:21:20 -0000 Dan, If this is the case, then I'd suggest adding something to make it explicit that the API adds no additional security concerns. spt Romascanu, Dan (Dan) wrote: > Sean, > > I will let the authors infirm or confirm what I am saying, but my > understanding is that they take the position that the document describes > an internal API for applications to access the Diameter protocol, and > that there is no additional security threat involved in the definition > or implementation of such an API. > > Dan > > >> -----Original Message----- >> From: Sean Turner [mailto:turners@ieca.com] >> Sent: Tuesday, June 16, 2009 9:01 PM >> To: Romascanu, Dan (Dan) >> Cc: secdir; draft-ietf-dime-diameter-api@tools.ietf.org; >> iesg@ietf.org; dime-chairs@ietf.org; Hannes Tschofenig; >> Victor Fajardo; pacalhou@cisco.com; dave@frascone.com >> Subject: Re: Review of draft-ietf-dime-diameter-api-08 >> >> Dan, >> >> I sent the review to Pat and to Dave (and the iesg and >> secdir). I see that Victor was also added during the last go >> around so if he made the changes I'm not sure he would have seen them. >> >> My concern is that the document is for the Diameter API but >> the security considerations points to the Diameter Protocol. >> So, we don't have any security considerations at all if we >> just point to the protocol definition, which is what the >> document does now. >> >> spt >> >> Romascanu, Dan (Dan) wrote: >>> Sean, >>> >>> Was your review sent to the editors of the document? >>> >>> Can you please clarify why you believe that the API introduces >>> supplementary security concerns, which would make the >> reference to the >>> security considerations of RFC 5366 insufficient? >>> >>> Thanks and Regards, >>> >>> Dan >>> >>> >>>> -----Original Message----- >>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] >> On Behalf >>>> Of Sean Turner >>>> Sent: Tuesday, June 16, 2009 6:44 PM >>>> To: secdir; draft-ietf-dime-diameter-api@tools.ietf.org; >>>> iesg@ietf.org; dime-chairs@ietf.org >>>> Cc: Hannes Tschofenig >>>> Subject: Review of draft-ietf-dime-diameter-api-08 >>>> >>>> I have reviewed this document (twice now) as part of the security >>>> directorate's ongoing effort to review all IETF documents being >>>> processed by the IESG. These comments were written >> primarily for the >>>> benefit of the security area directors. Document editors and WG >>>> chairs should treat these comments just like any other last call >>>> comments. >>>> >>>> This version does not address the comments I made against the >>>> -07 version, notably: >>>> >>>> The document needs to discuss the security considerations >> surrounding >>>> the API in your document, as opposed to just pointing to RFC5388. >>>> >>>> Nits: >>>> - Sec 3.1.1: add "." to end of last sentence >>>> - Sec 3.4.3.1 and 3.4.3.2: r/- The NAI of the user./The NAI of the >>>> user. >>>> - Sec 3.4.5.7: Move description before C code. >>>> >>>> spt >>>> > From phoffman@imc.org Sun Jun 21 12:02:47 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C8A23A680E for ; Sun, 21 Jun 2009 12:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 cpgZqxSGiGwU for ; Sun, 21 Jun 2009 12:02:46 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 337AF28C0F9 for ; Sun, 21 Jun 2009 12:02:45 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5LJ2vQT044707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Jun 2009 12:02:58 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 21 Jun 2009 12:02:56 -0700 To: secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: secdir-secretary@mit.edu Subject: Re: [secdir] assignments for June 23rd X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2009 19:02:47 -0000 At 12:17 PM -0400 6/16/09, Samuel Weiler wrote: >For telechat 2009-07-02 > >Rob Austein T draft-ietf-opsec-blackhole-urpf-04 >Stephen Farrell T draft-ietf-mipshop-mos-dns-discovery-06 >David Harrington T draft-ietf-pkix-tac-04 >Paul Hoffman T draft-ietf-smime-new-asn1-05 I am the author of draft-ietf-smime-new-asn1-05, thus an inappropriate reviewer. Anyone want to trade with me? From ietfdbh@comcast.net Sun Jun 21 19:19:40 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37D543A67DA for ; Sun, 21 Jun 2009 19:19: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.806, BAYES_20=-0.74] 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 Gu0rDIy-sHff for ; Sun, 21 Jun 2009 19:19:39 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 2023128C184 for ; Sun, 21 Jun 2009 19:19:39 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA07.westchester.pa.mail.comcast.net with comcast id 6iLA1c0020vyq2s57qKuAc; Mon, 22 Jun 2009 02:19:54 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA05.westchester.pa.mail.comcast.net with comcast id 6qKu1c00A0UQ6dC3RqKu1k; Mon, 22 Jun 2009 02:19:54 +0000 From: "David Harrington" To: "'Paul Hoffman'" , References: Date: Sun, 21 Jun 2009 22:19:53 -0400 Message-ID: <01e701c9f2df$eddad460$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcnyoueKUWK3np7rSHiyZ07IWT/D9wAPOeCg Cc: secdir-secretary@mit.edu Subject: Re: [secdir] assignments for June 23rd X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 02:19:40 -0000 Hi Paul, I can swap with you. I am equally ignorant of both drafts ;-) dbh > -----Original Message----- > From: secdir-bounces@ietf.org > [mailto:secdir-bounces@ietf.org] On Behalf Of Paul Hoffman > Sent: Sunday, June 21, 2009 3:03 PM > To: secdir@ietf.org > Cc: secdir-secretary@mit.edu > Subject: Re: [secdir] assignments for June 23rd > > At 12:17 PM -0400 6/16/09, Samuel Weiler wrote: > >For telechat 2009-07-02 > > > >Rob Austein T draft-ietf-opsec-blackhole-urpf-04 > >Stephen Farrell T > draft-ietf-mipshop-mos-dns-discovery-06 > >David Harrington T draft-ietf-pkix-tac-04 > >Paul Hoffman T draft-ietf-smime-new-asn1-05 > > I am the author of draft-ietf-smime-new-asn1-05, thus an > inappropriate reviewer. Anyone want to trade with me? > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From weiler+secdir@watson.org Mon Jun 22 06:53:00 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40FF428C1A4 for ; Mon, 22 Jun 2009 06:53:00 -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 JBvnF4Yq3kfZ for ; Mon, 22 Jun 2009 06:52:59 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 4E6A23A6DB9 for ; Mon, 22 Jun 2009 06:52:59 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n5MDrDjo014694 for ; Mon, 22 Jun 2009 09:53:13 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n5MDrDcj014691 for ; Mon, 22 Jun 2009 09:53:13 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Mon, 22 Jun 2009 09:53:13 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Mon, 22 Jun 2009 14:53:14 +0100 (BST) Subject: [secdir] Assignments for June 29th X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 13:53:00 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-07-02 Reviewer Draft Rob Austein T draft-ietf-opsec-blackhole-urpf-04 Stephen Farrell T draft-ietf-mipshop-mos-dns-discovery-06 David Harrington T draft-ietf-smime-new-asn1-05 Sam Hartman T draft-ietf-sipcore-subnot-etags-02 Paul Hoffman T draft-ietf-pkix-tac-04 Scott Kelly T draft-livingood-woundy-p4p-experiences-10 Hannes Tschofenig T draft-ietf-l2tpext-circuit-status-extensions-04 For telechat 2009-07-16 Reviewer Draft Scott Kelly T draft-ietf-softwire-lb-03 Julien Laganier T draft-hollenbeck-rfc4934bis-01 Catherine Meadows T draft-hollenbeck-rfc4930bis-02 Glen Zorn T draft-solinas-suiteb-cert-profile-03 Last calls and special requests: Reviewer Draft Derek Atkins draft-green-secsh-ecc-08 Richard Barnes draft-ietf-adslmib-vdsl2-07 Pat Cain draft-ietf-ancp-framework-10 Ran Canetti draft-ietf-ancp-security-threats-07 Dave Cridland draft-ietf-behave-nat-behavior-discovery-06 Dave Cridland draft-ietf-dccp-ccid4-04 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Alan DeKok draft-ietf-dccp-quickstart-05 Donald Eastlake draft-ietf-dime-qos-attributes-12 Shawn Emery draft-ietf-ipfix-export-per-sctp-stream-02 Tobias Gondrom draft-ietf-nea-pa-tnc-04 Phillip Hallam-Baker draft-ietf-nea-pb-tnc-04 Steve Hanna draft-peterson-rai-rfc3427bis-01 Steve Hanna draft-ietf-avt-rtcpssm-18 Steve Hanna draft-ietf-netconf-partial-lock-08 Dan Harkins draft-ietf-pwe3-vccv-bfd-05 Paul Hoffman draft-ietf-sip-eku-05 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Love Hornquist-Astrand draft-ietf-opsawg-smi-datatypes-in-xsd-05 Jeffrey Hutzelman draft-ietf-sip-body-handling-06 Charlie Kaufman draft-ietf-ipsecme-ikev2-redirect-11 Stephen Kent draft-ietf-geopriv-l7-lcp-ps-09 Julien Laganier draft-ietf-sip-certs-07 Catherine Meadows draft-ietf-speechsc-mrcpv2-19 Catherine Meadows draft-ietf-rmt-bb-lct-revised-09 Vidya Narayanan draft-ietf-sip-saml-06 Vidya Narayanan draft-ietf-enum-3761bis-04 Chris Newman draft-ietf-sip-connect-reuse-13 Eric Rescorla R draft-ietf-geopriv-http-location-delivery-14 Eric Rescorla draft-ietf-enum-iax-05 Joe Salowey draft-ietf-geopriv-lis-discovery-11 Joe Salowey draft-dawkins-nomcom-dont-wait-03 Stefan Santesson draft-ietf-tsvwg-rsvp-l3vpn-02 Hannes Tschofenig draft-ietf-pce-monitoring-05 Sam Weiler draft-chown-v6ops-rogue-ra-03 Sam Weiler draft-ietf-ospf-dynamic-hostname-04 Brian Weis draft-ietf-pce-inter-layer-frwk-10 Nico Williams draft-ietf-v6ops-ra-guard-03 Nico Williams draft-ietf-pcn-marking-behaviour-03 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 Larry Zhu draft-ietf-ecrit-location-hiding-req-01 Larry Zhu draft-ietf-tcpm-rfc2581bis-05 From phoffman@imc.org Mon Jun 22 15:41:02 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651AA3A6AA1 for ; Mon, 22 Jun 2009 15:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 rmEEIWknipDr for ; Mon, 22 Jun 2009 15:41:01 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 601A33A699F for ; Mon, 22 Jun 2009 15:41:01 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5MMfDBf037750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jun 2009 15:41:14 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <27893.1245169561.109739@puncture> References: <27893.1245169561.109739@puncture> Date: Mon, 22 Jun 2009 15:41:11 -0700 To: , Security Area Directorate From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [secdir] Secdir review of draft-ietf-pkix-tac X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 22:41:02 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is an experimental protocol for creating "traceable anonymous certificates". These certs split the authority into two entities, one who issues an end-entity cert with a pseudonym, and another who verifies that the end entity has the private key. There are many pretty deep security issues with the proposal, mostly that there are many ways where the anonymity of the user can be exposed. In many ways, this represents leap-of-faith anonymity. The security consideration section swings around wildly on recommendations for how a user can maintain their anonymity, but at least mentions a few times that this is all pretty much conditioned on factors over which the end entity has no control. On a personal note, I doubt that this will be at all useful in practice. The end entity is trading off trusting one CA to not reveal personal information against two CAs with not colluding plus having to get multiple certs over time from different CAs. Having said that, there are probably no security/privacy considerations that are not already covered in the document. From phoffman@imc.org Mon Jun 22 15:44:06 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0FA3A6A59 for ; Mon, 22 Jun 2009 15:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 dJx65yJrgdXo for ; Mon, 22 Jun 2009 15:44:06 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 0BE4B3A6825 for ; Mon, 22 Jun 2009 15:44:03 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5MMiGZN037898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Jun 2009 15:44:17 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 22 Jun 2009 15:44:15 -0700 To: , Security Area Directorate From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [secdir] Secdir review of draft-ietf-sip-eku X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 22:44:06 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is a simple definition of a PKIX key usage for SIP proxies. It is, in essence, no different than a PKIX key usage for any other server, and thus doesn't introduce any interesting security issues. From hartmans@mit.edu Tue Jun 23 09:12:24 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF51B28C3C0; Tue, 23 Jun 2009 09:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 YydsAvNr6Lvn; Tue, 23 Jun 2009 09:12:24 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) by core3.amsl.com (Postfix) with ESMTP id 2421928C3B2; Tue, 23 Jun 2009 09:12:24 -0700 (PDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 476ED4143; Tue, 23 Jun 2009 12:12:35 -0400 (EDT) To: secdir@ietf.org,iesg@ietf.org From: Sam Hartman Date: Tue, 23 Jun 2009 12:12:35 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-sipcore-subnot-etags@tools.ietf.org, sipcore-chairs@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-sipcore-subnot-etags-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 16:12:25 -0000 I've reviewed this draft for the security directorate. My review was reasonably light although I believe was sufficient. This draft defines a mechanism so that subscribers can avoid a notification message being generated when they already know the contents of that notification. The security considerations section claims that this mechanism does not change the security properties of the protocol: it is just an optimization. I'm fine with the document as it stands. It's not inherently true that an optimization of this type doesn't change the security properties. For example, if an attacker could modify a subscribe request and suppress a notification, that might change the security properties. However, as far as I can tell, this particular mechanism does not make any significant changes to the security properties. From stefan@aaa-sec.com Tue Jun 23 09:51:20 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 852373A6B8B for ; Tue, 23 Jun 2009 09:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 bgQKs1zOQkBZ for ; Tue, 23 Jun 2009 09:51:19 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id C311328C39E for ; Tue, 23 Jun 2009 09:51:18 -0700 (PDT) Received: (qmail 27760 invoked from network); 23 Jun 2009 16:51:37 -0000 Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 23 Jun 2009 16:51:37 -0000 Received: (qmail 67118 invoked from network); 23 Jun 2009 16:51:30 -0000 Received: from 213-64-142-21-no153.business.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[213.64.142.21]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 23 Jun 2009 16:51:30 -0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 23 Jun 2009 18:51:29 +0200 From: Stefan Santesson To: , , Bruce Davie , Francois le Faucheur , Ashok Narayanan , James Polk , Gorry Fairhurst , Magnus Westerlund Message-ID: Thread-Topic: SecDir review of draft-ietf-tsvwg-rsvp-l3vpn-02 Thread-Index: Acn0ItqU/YAdZG9qeEuzK09aj5lQSw== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3328627890_1981279" Subject: [secdir] SecDir review of draft-ietf-tsvwg-rsvp-l3vpn-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 16:51:20 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3328627890_1981279 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This specification define a set of procedures to overcome challenges with deployment of Resource Reservation Protocols over BGP/MPLS VPNs. The BGP/MPLS VPN (RFC 4364) is a VPN technique that doesn't rely encryption to ensure secrecy or message integrity. The security properties are instead dependent on the security of the network infrastructure. It appears that this draft makes a serious effort to describe and analyze relevant security considerations. With my limited expertise in this particular area I can't find any thing that is obviously missing. However, one question that comes to my mind, which might be worth looking at from a security perspective, is whether the procedures introduced by this document requires the communication to be unencrypted and if so, whether deployment of this protocol blocks or prevents legitimate use of e.g. IPsec based VPN as discussed in RFC 4364 and RFC 4023. If this is the case, should it be discussed in the security considerations section? Stefan Santesson AAA-sec.com --B_3328627890_1981279 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable SecDir review of draft-ietf-tsvwg-rsvp-l3vpn-02 I have reviewed this document as part of the security directorate's ongoin= g effort to review all IETF documents being processed by the IESG.  The= se comments were written primarily for the benefit of the security area dire= ctors.  Document editors and WG chairs should treat these comments just= like any other last call comments.

This specification define a set of procedures to overcome challenges with d= eployment of Resource Reservation Protocols over BGP/MPLS VPNs.

The BGP/MPLS VPN (RFC 4364) is a VPN technique that doesn't rely encryption= to ensure secrecy or message integrity. The security properties are instead= dependent on the security of the network infrastructure.

It appears that this draft makes a serious effort to describe and analyze r= elevant security considerations. With my limited expertise in this particula= r area I can't find any thing that is obviously missing.

However, one question that comes to my mind, which might be worth looking a= t from a security perspective, is whether the procedures introduced by this = document requires the communication to be unencrypted and if so, whether dep= loyment of this protocol blocks or prevents legitimate use of e.g. IPsec bas= ed VPN as discussed in RFC 4364 and RFC 4023. If this is the case, should it= be discussed in the security considerations section?


Stefan Santesson
AAA-sec.com





 --B_3328627890_1981279-- From stephen.farrell@cs.tcd.ie Tue Jun 23 10:52:48 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3F4428C3D5; Tue, 23 Jun 2009 10:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.293 X-Spam-Level: X-Spam-Status: No, score=-0.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, RDNS_DYNAMIC=0.1] 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 pJZ95KEOY6OR; Tue, 23 Jun 2009 10:52:48 -0700 (PDT) Received: from mail.newbay.com (87-198-172-198.ptr.magnet.ie [87.198.172.198]) by core3.amsl.com (Postfix) with ESMTP id B443028C306; Tue, 23 Jun 2009 10:52:41 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.newbay.com (Postfix) with ESMTP id B18F81003F504; Tue, 23 Jun 2009 18:52:56 +0100 (IST) X-Virus-Scanned: amavisd-new at newbay.com Received: from mail.newbay.com ([127.0.0.1]) by localhost (mail.newbay.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWsYdNHXGaNm; Tue, 23 Jun 2009 18:52:56 +0100 (IST) Received: from [192.168.3.171] (unknown [192.168.3.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.newbay.com (Postfix) with ESMTP id 5AEA91003F51A; Tue, 23 Jun 2009 18:52:54 +0100 (IST) Message-ID: <4A411679.4020009@cs.tcd.ie> Date: Tue, 23 Jun 2009 18:52:57 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.21 (X11/20090302) MIME-Version: 1.0 To: sec-ads@ietf.org, secdir@ietf.org, draft-ietf-mipshop-mos-dns-discovery@tools.ietf.org, mipshop-chairs@tools.ietf.org, IESG X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] Secdir review of draft-ietf-mipshop-mos-dns-discovery-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 17:52:48 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document defines a way to find IEEE 802.21 servers using NAPTR resource records. Since I'm not familiar with IEEE 802.21 I've no idea how security sensitive one ought be about getting told which server to use. Perhaps there's a general 802.21 security considerations reference that should be pointed to from the security considerations here? I guess the concern would be if this way of finding servers introduced some new way to e.g. eavesdrop on calls/sessions but since I don't know 802.21 I can't tell if that's the case or not (as it happens I suspect there'd be easier ways to cheat if that were the case). Other than that, the security considerations seem fine. This is of course yet another spec that needs DNSSEC to get data origin authentication. Hopefully that'll be possible soon. A couple of non-security things that I noticed: - There's a MUST about what the MN does when in its home domain but I'm not sure how a MN would know that. Perhaps that's covered in some other mipshop document? - I didn't see where allowed values for the NAPTR flags field were defined but the examples show "s" - are other values allowed? Does "s" mean the replacement indicates an SRV lookup? - Are the order and pref values in the example NAPTR records correct? - The document discourages the use of the regexp field but if there's no need for it, why not say that the regexp MUST be empty? Stephen. From frascone@gmail.com Mon Jun 22 14:36:22 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022223A697B; Mon, 22 Jun 2009 14:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 S+mx8B7KYX5T; Mon, 22 Jun 2009 14:36:21 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 617C43A6971; Mon, 22 Jun 2009 14:36:20 -0700 (PDT) Received: by bwz9 with SMTP id 9so3515758bwz.37 for ; Mon, 22 Jun 2009 14:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=gPhbNKSkXFkvWgyZPY9qgTaRCNHX7qPJC7otAVVlNHg=; b=hWyiX+QVXrpNmCJF9PilbHqJw+fAB9gQ4jTZIGyk2op1iAaGkHdra9lKg30JCXvZNg sFuE+cn9iI3LAQMI3w1vmG36U53pMIu78JD8Cc848Q3ZBjUKiiLGKysCpFy+JnktPn5D oYNXEyjr5Ta8pI6ixD47UeQklhd6FF+wtYZGg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=NWnm1uphGixaqOREcM1KSv27gQSNazs80x1XpC6ptEup8XfRkwfBn/sAiOiKcVJN9L VkksBb7hVO8BGpjbJ6xrBdyv1nEAQ9DXTurBAPJg6s1aO2fPhyrGOCmopRf1QdKsjfyj hFlWuyAjBPg8Xe2+EpJ2dMk91K6+T866mHNM0= MIME-Version: 1.0 Sender: frascone@gmail.com Received: by 10.216.11.210 with SMTP id 60mr2266944wex.188.1245706592291; Mon, 22 Jun 2009 14:36:32 -0700 (PDT) In-Reply-To: <4A3E6C1B.2090907@ieca.com> References: <4A37BDAA.50306@ieca.com> <4A37DDEB.7070402@ieca.com> <4A3E6C1B.2090907@ieca.com> Date: Mon, 22 Jun 2009 17:36:32 -0400 X-Google-Sender-Auth: 8e5836544e5e3739 Message-ID: <9cf5ced20906221436q4ad148c8kf4cc260c52275a03@mail.gmail.com> From: David Frascone To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 24 Jun 2009 08:03:21 -0700 Cc: pacalhou@cisco.com, secdir , "Romascanu, Dan \(Dan\)" , dime-chairs@ietf.org, draft-ietf-dime-diameter-api@tools.ietf.org, iesg@ietf.org, Hannes Tschofenig , Victor Fajardo Subject: Re: [secdir] Review of draft-ietf-dime-diameter-api-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 21:36:22 -0000 Ok. Will do. -Dave On Sun, Jun 21, 2009 at 1:21 PM, Sean Turner wrote: > Dan, > > If this is the case, then I'd suggest adding something to make it explici= t > that the API adds no additional security concerns. > > spt > > Romascanu, Dan (Dan) wrote: >> >> Sean, >> >> I will let the authors infirm or confirm what I am saying, but my >> understanding is that they take the position that the document describes >> an internal API =A0for applications to access the Diameter protocol, and >> that there is no additional security threat involved in the definition >> or implementation of such an API. >> Dan >> >> >>> -----Original Message----- >>> From: Sean Turner [mailto:turners@ieca.com] Sent: Tuesday, June 16, 200= 9 >>> 9:01 PM >>> To: Romascanu, Dan (Dan) >>> Cc: secdir; draft-ietf-dime-diameter-api@tools.ietf.org; iesg@ietf.org; >>> dime-chairs@ietf.org; Hannes Tschofenig; Victor Fajardo; pacalhou@cisco= .com; >>> dave@frascone.com >>> Subject: Re: Review of draft-ietf-dime-diameter-api-08 >>> >>> Dan, >>> >>> I sent the review to Pat and to Dave (and the iesg and secdir). =A0I se= e >>> that Victor was also added during the last go around so if he made the >>> changes I'm not sure he would have seen them. >>> >>> My concern is that the document is for the Diameter API but the securit= y >>> considerations points to the Diameter Protocol. =A0So, we don't have an= y >>> security considerations at all if we just point to the protocol definit= ion, >>> which is what the document does now. >>> >>> spt >>> >>> Romascanu, Dan (Dan) wrote: >>>> >>>> Sean, >>>> >>>> Was your review sent to the editors of the document? >>>> Can you please clarify why you believe that the API introduces >>>> supplementary security concerns, which would make the >>> >>> reference to the >>>> >>>> security considerations of RFC 5366 insufficient? >>>> >>>> Thanks and Regards, >>>> >>>> Dan >>>> >>>> >>>>> -----Original Message----- >>>>> From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] >>> >>> On Behalf >>>>> >>>>> Of Sean Turner >>>>> Sent: Tuesday, June 16, 2009 6:44 PM >>>>> To: secdir; draft-ietf-dime-diameter-api@tools.ietf.org; >>>>> iesg@ietf.org; dime-chairs@ietf.org >>>>> Cc: Hannes Tschofenig >>>>> Subject: Review of draft-ietf-dime-diameter-api-08 >>>>> >>>>> I have reviewed this document (twice now) as part of the security >>>>> directorate's ongoing effort to review all IETF documents being proce= ssed by >>>>> the IESG. These comments were written >>> >>> primarily for the >>>>> >>>>> benefit of the security area directors. Document editors and WG chair= s >>>>> should treat these comments just like any other last call comments. >>>>> >>>>> This version does not address the comments I made against the >>>>> -07 version, notably: >>>>> >>>>> The document needs to discuss the security considerations >>> >>> surrounding >>>>> >>>>> the API in your document, as opposed to just pointing to RFC5388. >>>>> >>>>> Nits: >>>>> - Sec 3.1.1: add "." to end of last sentence >>>>> - Sec 3.4.3.1 and 3.4.3.2: r/- The NAI of the user./The NAI of the >>>>> user. >>>>> - Sec 3.4.5.7: Move description before C code. >>>>> >>>>> spt >>>>> >> > From rbarnes@bbn.com Wed Jun 24 21:06:15 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D88D3A69DE; Wed, 24 Jun 2009 21:06:15 -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 bAIwgRXS3Yo9; Wed, 24 Jun 2009 21:06:14 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1C7733A68E7; Wed, 24 Jun 2009 21:06:14 -0700 (PDT) Received: from [128.89.252.139] (helo=Richard-Barnes-Laptop.local) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1MJgEH-0006qC-AV; Thu, 25 Jun 2009 00:06:29 -0400 Message-ID: <4A42F7C4.3050401@bbn.com> Date: Thu, 25 Jun 2009 00:06:28 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: SECDIR , IESG , IETF Discussion , draft-ietf-adslmib-vdsl2@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [secdir] SECDIR review of draft-ietf-adslmib-vdsl2-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 04:06:15 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes an SNMP MIB for managing VDSL interfaces, extending existing MIBs for managing other classes of DSL interfaces. As such, the primary security issues are related to the risks associated with read, create, or write access to various tables and objects. Overall, the Security Considerations does a good job of describing the risks associated with use of this MIB and the security mechanisms that should be used to mitigate them. My only concerns are that: 1. There is no mandatory security mechanism, either for implementation or deployment, and that 2. Risks related to read-only fields may require a slightly more thorough treatment Beyond these two minor issues, the comments below are focused on the clarity of the security discussion, rather than its content. --Richard ----- The current security considerations section has three main parts: 1. A list of fields with write/create access and associated risks 2. A list of fields with read access that pose especial risks 3. Recommendations as to how to mitigate these risks Comments below are organized accordingly. 1. Objects with write/create access 1.1. The current list seems to be comprehensive, but it can be difficult for the reader to get a general idea of what the high-level risks are and how these relate to the individual Objects. It could be helpful to group these tables and objects under classes of general risks (maybe in subsections), or alternatively, to tag each table or object with an indicator of which classes of risk it introduces. The list I came up with as I was reading was as follows: 1.1.1. Disruption of service 1.1.2. Degradation of service 1.1.3. Information loss or overload 1.1.4. Privilege escalation / unauthorized access to lines/channels 1.1.5. Multiple lines/channels/profiles/templates affected 1.2. The phrase "adverse operational effect" is too vague. Suggest trying to find something more specific to say (maybe from the above list?) 2. Objects with read access 2.1. It's a good first step to list the fields you do here. I'm wondering though, whether there is some interaction between other readable fields and the writable objects discussed previously. Are there situations where reading objects could allow an adversary to gain information that would allow him to better exploit a write permission he has? E.g., an attacker that can read objects related to monitoring (e.g., counter) might be able to determine what attacks would be detectable by the current monitoring configuration and which would not. It's not necessary (or even necessarily possible) to list all the possible interactions here, but it would be helpful to have a general note that they exist, and possibly a recommendation that any given user be given access only to the objects he needs (e.g. only to objects within a given set of tables), not all readable objects. 3. Recommendations for mitigations 3.1. The reference to Section 8 of RFC 3410 ("Standardization Status") seems incorrect. Suggest changing to refer to section 6.4, 7.8, or 7.9, or simply to refer to RFC 3414 and 3415. 3.2. The phrase "using IPsec" is unclear here. I assume this means "using IPsec to connect sites that are remote from each other". 3.3. "IPSec" should be "IPsec" 3.4. What is the reason for not requiring implementations to provide support for SNMPv3 security mechanisms? The SHOULD=MUST+exceptions (i.e., RECOMMENDED=REQUIRED+exceptions) pattern could be useful here -- when is it acceptable for an implementation to omit security support? From weiler+secdir@watson.org Thu Jun 25 03:47:36 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8970F28C11D for ; Thu, 25 Jun 2009 03:47:36 -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 FJqDIL9m-rhD for ; Thu, 25 Jun 2009 03:47:35 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id D34A53A67E4 for ; Thu, 25 Jun 2009 03:47:34 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id n5PAjslx061208 for ; Thu, 25 Jun 2009 06:45:54 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id n5PAjsJ4061204 for ; Thu, 25 Jun 2009 06:45:54 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 25 Jun 2009 06:45:54 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (fledge.watson.org [127.0.0.1]); Thu, 25 Jun 2009 11:45:54 +0100 (BST) Subject: [secdir] Assignments for June 30th and July 2nd X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 10:47:36 -0000 There was an assignment message on Monday; I'm sending another this week because many things have been added to the telechat agenda for next week. It's possible that some of the items listed have been deferred -- if you're really pressed for time, feel free to check the draft tracker to see. Six new assignments. Vidya Narayanan is next in the queue. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview -- Sam For telechat 2009-07-02 Reviewer Draft Rob Austein T draft-ietf-opsec-blackhole-urpf-04 Ran Canetti T draft-ietf-ancp-security-threats-07 Dave Cridland T draft-ietf-dccp-ccid4-04 Alan DeKok T draft-ietf-dccp-quickstart-05 Donald Eastlake T draft-ietf-dime-qos-attributes-12 Steve Hanna T draft-ietf-avt-rtcpssm-18 Dan Harkins T draft-ietf-pwe3-vccv-bfd-05 David Harrington T draft-ietf-smime-new-asn1-05 Jeffrey Hutzelman T draft-ietf-sip-body-handling-06 Scott Kelly T draft-livingood-woundy-p4p-experiences-10 Stephen Kent T draft-ietf-geopriv-l7-lcp-ps-09 Joe Salowey T draft-dawkins-nomcom-dont-wait-03 Hannes Tschofenig T draft-ietf-l2tpext-circuit-status-extensions-04 Sam Weiler T draft-ietf-ospf-dynamic-hostname-04 Brian Weis T draft-ietf-pce-inter-layer-frwk-10 Larry Zhu T draft-ietf-tcpm-rfc2581bis-05 For telechat 2009-07-16 Reviewer Draft Pat Cain T draft-ietf-ancp-framework-10 Scott Kelly T draft-ietf-softwire-lb-03 Julien Laganier T draft-hollenbeck-rfc4934bis-01 Catherine Meadows T draft-hollenbeck-rfc4930bis-02 Chris Newman T draft-ietf-sip-connect-reuse-13 Eric Rescorla TR draft-ietf-geopriv-http-location-delivery-15 Juergen Schoenwaelder TR draft-ietf-ospf-ospfv3-mib-15 Glen Zorn T draft-solinas-suiteb-cert-profile-03 Last calls and special requests: Reviewer Draft Derek Atkins draft-green-secsh-ecc-08 Dave Cridland draft-ietf-behave-nat-behavior-discovery-06 Alan DeKok draft-ietf-mpls-ldp-end-of-lib-03 Shawn Emery draft-ietf-ipfix-export-per-sctp-stream-02 Tobias Gondrom draft-ietf-nea-pa-tnc-04 Phillip Hallam-Baker draft-ietf-nea-pb-tnc-04 Steve Hanna draft-peterson-rai-rfc3427bis-01 Steve Hanna draft-ietf-netconf-partial-lock-08 Love Hornquist-Astrand draft-ietf-ipfix-mib-06 Love Hornquist-Astrand draft-ietf-opsawg-smi-datatypes-in-xsd-05 Charlie Kaufman draft-ietf-ipsecme-ikev2-redirect-11 Stephen Kent draft-ietf-l3vpn-as4octet-ext-community-03 Julien Laganier draft-ietf-sip-certs-07 Julien Laganier draft-ietf-l3vpn-v6-ext-communities-02 Barry Leiba draft-ietf-simple-interdomain-scaling-analysis-06 Chris Lonvick draft-ietf-sip-record-route-fix-06 Catherine Meadows draft-ietf-speechsc-mrcpv2-19 Catherine Meadows draft-ietf-rmt-bb-lct-revised-09 Catherine Meadows draft-ietf-speermint-requirements-07 Sandy Murphy draft-ietf-speermint-voip-consolidated-usecases-12 Vidya Narayanan draft-ietf-sip-saml-06 Vidya Narayanan draft-ietf-enum-3761bis-04 Eric Rescorla draft-ietf-enum-iax-05 Joe Salowey draft-ietf-geopriv-lis-discovery-11 Hannes Tschofenig draft-ietf-pce-monitoring-05 Sam Weiler draft-chown-v6ops-rogue-ra-03 Nico Williams draft-ietf-v6ops-ra-guard-03 Nico Williams draft-ietf-pcn-marking-behaviour-03 Larry Zhu draft-thaler-v6ops-teredo-extensions-03 Larry Zhu draft-ietf-ecrit-location-hiding-req-01 From j.schoenwaelder@jacobs-university.de Thu Jun 25 05:34:15 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF50E3A6D9F; Thu, 25 Jun 2009 05:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 T+tyusgVamhJ; Thu, 25 Jun 2009 05:34:14 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B1DB23A6961; Thu, 25 Jun 2009 05:34:14 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23B67C00FA; Thu, 25 Jun 2009 14:30:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qSTn+j8BcE6j; Thu, 25 Jun 2009 14:30:50 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E2A3BC00F1; Thu, 25 Jun 2009 14:30:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EA5E7B506B6; Thu, 25 Jun 2009 14:30:48 +0200 (CEST) Date: Thu, 25 Jun 2009 14:30:48 +0200 From: Juergen Schoenwaelder To: djoyal@nortel.com, vishwas@ipinfusion.com Message-ID: <20090625123048.GC22794@elstar.local> Mail-Followup-To: djoyal@nortel.com, vishwas@ipinfusion.com, iesg@ietf.org, secdir@ietf.org, ospf-chairs@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: ospf-chairs@tools.ietf.org, iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-ietf-ospf-ospfv3-mib-15.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 12:34:15 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I have reviewed the -14 version of this document and suggested some changes to the security considerations. This has been addressed and I am fine with the content of the text now. Two minor editorial nits in the new text: Replace "MIB" with "MIB module" in the following two text fragments: by this MIB may result -> by this MIB module may result MIB allows the discovery -> MIB module allows the discovery /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From secdir-bounces@mit.edu Tue Jun 23 13:00:23 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1485F3A67FB for ; Tue, 23 Jun 2009 13:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 pdLTUDBMnvKi for ; Tue, 23 Jun 2009 13:00:21 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id F1D7E3A6EF4 for ; Tue, 23 Jun 2009 13:00:19 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n5NK0arU031124 for ; Tue, 23 Jun 2009 16:00:36 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n5NK0YHX031115 for ; Tue, 23 Jun 2009 16:00:34 -0400 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n5NK0PG3019590 for ; Tue, 23 Jun 2009 16:00:25 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 7DCC3143989E for ; Tue, 23 Jun 2009 16:00:24 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id 9AmACVmLAFun0etI for ; Tue, 23 Jun 2009 16:00:24 -0400 (EDT) Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6527E3A6EDD; Tue, 23 Jun 2009 13:00:06 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 79E123A67FB; Tue, 23 Jun 2009 13:00:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090623200001.79E123A67FB@core3.amsl.com> Date: Tue, 23 Jun 2009 13:00:01 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Thu, 25 Jun 2009 11:25:59 -0700 Subject: [secdir] [New-work] WG Review: STORage Maintenance (storm) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 20:00:23 -0000 A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 30, 2009. STORage Maintenance (storm) ---------------------------------- Last Modified: 2009-06-18 Current Status: Proposed Working Group Chairs: - TBD Transport Area Director(s): - Magnus Westerlund - Lars Eggert Transport Area Advisor: - Lars Eggert Mailing Lists: General Discussion: storm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/storm Archive: http://www.ietf.org/mail-archive/web/storm/index.html Description of Working Group: The IETF ips (IP Storage) and rddp (Remote Direct Data Placement) working groups have produced a significant number of storage protocols (e.g., iSCSI, iSER and FCIP) for which there is significant usage. The time has come to reflect feedback from implementation and usage into updated RFCs; this work may include: - Implementation-driven revisions and updates to existing protocols (i.e., updated RFCs that match the "running code"). - Interoperability reports as needed for the resulting revised protocols that are appropriate for Draft Standard RFC status. - Minor protocol changes or additions. Backwards compatibility is required. Significant changes to the existing protocol standards are out of scope, including any work on version 2 of any of these protocols. Security for these protocols is based on the functionality specified in RFC 3723 (Securing Block Storage Protocols over IP); the working group does not intend to make major changes or updates to that RFC. Stability is critical to the usage of these protocols, making backwards compatibility with existing implementations a requirement for all protocol changes and additions. This is a requirement for implementation compatibility - if all implementations of a protocol have done something different than what the RFC specified, then it is appropriate for a new RFC to document what the "running code" actually does and deprecate the unimplemented original behavior. Initial list of work items: (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node architecture key) and 5048 (corrections/clarifications) into one draft (3720bis), removing features that are not implemented in practice. This draft should be prepared so that it could become a Draft Standard RFC, but it is up to the WG to decide whether to advance it to Draft Standard. (2) iSCSI: Add features to support at least SAM-4 (4th version of the SCSI architecture) in a backwards-compatible fashion, as iSCSI is currently based on SAM-2. This will be a separate draft from the iSCSI update in the previous item. The Working group may add additional minor useful iSCSI features to this draft, including features from draft versions of SAM-5. The iSCSI MIB (RFC 4544) should be updated to provide SNMP support for new features as appropriate. (3) FCIP: IP Protocol number 133 was allocated to a precursor of the FCIP protocol in 2000, but that allocated number is not used by FCIP. The working group will consider whether that allocated number should be returned to IANA for future reallocation. (4) iFCP: The Address Translation mode of iFCP needs to be deprecated (SHOULD NOT implement or use), as there are significant technical problems with it as specified in RFC 4172, and moreover, only the Address Transparent mode of iFCP is in use. This change is to be done via a short draft that updates RFC 4172, as opposed to a complete rewrite of RFC 4172. A combined draft is expected that encompasses items (3) and (4); this draft should also update the iFCP MIB (RFC 4369) to deprecate support for iFCP Address Translation mode. (5) RDDP Connection Setup: Good support for MPI applications requires a small update to MPA startup functionality to allow either end of the connection to initiate. In addition, a couple of minor changes to RDDP connection setup are needed based on implementation experience. (6) iSER: Experience with Infiniband implementations suggests a few minor updates to reflect what has been done in practice. The working group is expected to maintain good working relationships with INCITS Technical Committee T10 (SCSI standards) and INCITS Technical Committee T11 (Fibre Channel standards) via overlaps in membership as opposed to appointment of formal liaisons. The liaison process (including IAB appointment of a liaison or liaisons) remains available for use if needed. Recent changes in INCITS rules have removed public access to some T10 and T11 standards documents that are expected to be needed for the WG's program of work. Arrangements have been made with T10 and T11 for IETF participants to obtain copies of specific standards their personal use in IETF work as needed; contact the WG chair(s) for details. Goals and Milestones: July 2009 First version of FCIP protocol number and iFCP Address Translation mode draft. Aug 2009 First version of iSCSI SAM-4 (and other) new features draft. Aug 2009 First version of RDDP MPA startup change draft Sep 2009 Working Group Last Call on FCIP protocol number and iFCP address change draft Sep 2009 First version of combined iSCSI draft (3720bis) Oct 2009 First version of iSER update draft Oct 2009 Working Group Last Call on RDDP MPA startup change draft. Dec 2009 Functionally complete iSCSI SAM-4 (and other) new features draft, plus iSCSI MIB update draft. Feb 2010 Working Group Last Call on iSER update draft Mar 2010 Working Group Last Call on iSCSI SAM-4 (and other) new features draft. Apr 2010 Working Group decision on whether to seek Draft Standard RFC status for the combined iSCSI draft (3720bis). [Note: decision may be made significantly before this date.] Sep 2010 Working Group Last Call on combined iSCSI draft (3720bis) and iSCSI MIB update draft. _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Tue Jun 23 13:30:21 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4124628C405 for ; Tue, 23 Jun 2009 13:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 o46AzWgZkd-T for ; Tue, 23 Jun 2009 13:30:18 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 921DB28C2D8 for ; Tue, 23 Jun 2009 13:30:16 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n5NKUWbu004986 for ; Tue, 23 Jun 2009 16:30:32 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n5NKUVXl004982 for ; Tue, 23 Jun 2009 16:30:31 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n5NKUPEn019437 for ; Tue, 23 Jun 2009 16:30:26 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 154761145033 for ; Tue, 23 Jun 2009 16:30:24 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id Zfe9pi7QRafoimVl for ; Tue, 23 Jun 2009 16:30:24 -0400 (EDT) X-Barracuda-Envelope-From: new-work-bounces@ietf.org Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E7213A6EFB; Tue, 23 Jun 2009 13:30:06 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 943293A6C45; Tue, 23 Jun 2009 13:30:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090623203001.943293A6C45@core3.amsl.com> Date: Tue, 23 Jun 2009 13:30:01 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Thu, 25 Jun 2009 11:25:59 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Site Multihoming by IPv6 Intermediation (shim6) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 20:30:21 -0000 A modified charter has been submitted for the Site Multihoming by IPv6 Intermediation (shim6) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 30, 2009. Site Multihoming by IPv6 Intermediation (shim6) =============================================== Last Modified: 2009-06-17 Current Status: Active Working Group Additional information is available at tools.ietf.org/wg/shim6 Chair(s): Kurt Lindqvist Geoff Huston Internet Area Director(s): Ralph Droms Jari Arkko Internet Area Advisor: Jari Arkko Technical Advisor(s): Thomas Narten Mailing Lists: General Discussion: shim6@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/shim6 Archive: http://www.ietf.org/mail-archive/web/shim6/current/maillist.html Description of Working Group: Earlier efforts in this working group completed the Shim6 protocol specification, documented in RFCs 5533 through 5535. This protocol is a layer 3 shim for providing locator agility with failover capabilities for IPv6 nodes. Hosts that employ Shim6 use multiple IPv6 address prefixes and setup state with peer hosts. This state can later be used to failover to a different set of locators, should the original locators stop working. The Shim6 approach has a number of advantages, such as enabling small sites to be multihomed without requiring a provider independent IPv6 address prefix for the site. But the approach has also been criticized, e.g., for the operational impacts that the use of multiple prefixes causes. At this time there is no clear view on how well Shim6 works in practice. Implementation and deployment in select networks is needed to determine its true characteristics. The Shim6 working group is chartered to track the implementation and testing or deployment efforts. The group is also expected to shepherd to completion a few remaining informational documents that complement the existing protocol specifications. The specific work items of the group are: o Write an implementation and/or deployment experience report. o Specify socket API extensions. This API enables interactions between applications and the Shim6 layer for advanced locator management, and access to information about failure detection and path exploration. It also enables some applications to turn Shim6 off. o Complete the work on the applicability draft. This draft explains in detail in which types of networks Shim6 is applicable, and what its advantages and disadvantages are. The draft will also explain how firewalls are impacted by the use of Shim6. Finally, the draft will also explain how Shim6 can be used in situations where native IPv6 connectivity is not available, such as using Shim6 over 6to4. The group will also work in co-operation with the 6MAN working group as they continue their efforts in improving IPv6 address selection mechanisms. The group shall not work on extensions to the Shim6 protocol itself at this time. However, new work items can be added through rechartering as others get completed. Goals and Milestones: Sep 2009 Next revision of the API document Nov 2009 First WG draft on an implementation report Jan 2010 Submit API document to IESG for publication as Informational RFC Jan 2010 Next revision of the applicability document Dec 2010 Submit implementation report to IESG for publication as Informational RFC Dec 2010 Submit applicability document to IESG for publication as Informational RFC Dec 2010 Close or re-charter _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Tue Jun 23 13:30:27 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060D828C42F for ; Tue, 23 Jun 2009 13:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 IjxPD+1uhd7h for ; Tue, 23 Jun 2009 13:30:25 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id BDB9C28C2D8 for ; Tue, 23 Jun 2009 13:30:22 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n5NKUdJC005036 for ; Tue, 23 Jun 2009 16:30:39 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n5NKUcFq005022 for ; Tue, 23 Jun 2009 16:30:38 -0400 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n5NKUSHH027152 for ; Tue, 23 Jun 2009 16:30:28 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id AA02E14F65BB for ; Tue, 23 Jun 2009 16:30:27 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id UpiXTU5HvCkFOGBj for ; Tue, 23 Jun 2009 16:30:27 -0400 (EDT) Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E02F28C3D0; Tue, 23 Jun 2009 13:30:08 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 08C183A6D3E; Tue, 23 Jun 2009 13:30:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090623203002.08C183A6D3E@core3.amsl.com> Date: Tue, 23 Jun 2009 13:30:01 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Thu, 25 Jun 2009 11:25:59 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Diameter Maintenance and Extensions (dime) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 20:30:27 -0000 A modified charter has been submitted for the Diameter Maintenance and Extensions (dime) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, June 30, 2009. Diameter Maintenance and Extensions (dime) =========================================== Last Modified: 2009-06-10 Current Status: Working Group Chair(s): Hannes Tschofenig Victor Fajardo Operations and Management Area Director(s): Dan Romascanu Ronald Bonica Operations and Management Area Advisor: Dan Romascanu Mailing Lists: General Discussion: dime@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting and provisioning in network access as well as for other applications environments (e.g., IP telephony, mobility). The IETF has completed work on the Diameter Base protocol and is working on revising the base protocol specification. There is on-going work on defining RADIUS extensions and the DIME WG will ensure that work done in RADEXT is also available for Diameter. The DIME working group plains to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes, such NAI routing or capability update extensions. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Diameter QoS extensions. This work focuses on extensions to Diameter to support QoS information to be authorized and provisioned in AAA deployments. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Diameter extensions for mobility protocols, such as Mobile IPv6 and Proxy Mobile IPv6. Diameter extensions to support handover keying developed in the HOKEY WG are part of this effort. - New Diameter applications, such as the Diameter NAT control application. This group will also conduct work on new Diameter applications with a Diameter application for configuring NATs as the first item. Additionally, AAA systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed. Coordination with other IETF working groups and other SDOs will used to ensure this. Goals and Milestones: Done Submit 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Nov 2009 Submit 'Revision of Diameter Base Protocol' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Aug 2009 Submit 'Diameter Application Design Guidelines' to the IESG for consideration as a BCP document Done Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Jan 2010 Submit 'Diameter Support for EAP Re-authentication Protocol' to the IESG for consideration as a Proposed Standard Jun 2009 Submit new DIME charter to the IESG Jun 2009 Submit 'Updated IANA Considerations for Diameter Command Code Allocations' as DIME working group item Jul 2009 Submit 'Updated IANA Considerations for Diameter Command Code Allocations' to the IESG for consideration as a Proposed Standard Jul 2009 Submit 'Diameter NAT Control Application' as DIME working group item Jul 2009 Submit 'Diameter Capabilities Update' as DIME working group item Nov 2009 Submit ' Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Nov 2009 Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Nov 2009 Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Jan 2010 Submit 'Diameter NAT Control Application' to the IESG for consideration as a Proposed Standard _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From alan@sipstation.com Wed Jun 24 10:09:08 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D62963A6CC8; Wed, 24 Jun 2009 10:09:08 -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 wx4popB8qpVm; Wed, 24 Jun 2009 10:09:08 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 9510B3A6BCE; Wed, 24 Jun 2009 10:08:39 -0700 (PDT) Received: from [208.71.39.153] (helo=alan-johnstons-powerbook-g4-17.local) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MJVUU-000Aqg-QA; Wed, 24 Jun 2009 16:38:30 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 208.71.39.153 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX194tLRSuvPMndylLnXVIBnZeCm0xr+27Pg= Message-ID: <4A42567E.3060106@sipstation.com> Date: Wed, 24 Jun 2009 11:38:22 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Magnus_Nystr=F6m?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 25 Jun 2009 11:25:59 -0700 Cc: fluffy@cisco.com, rohan@ekabal.com, jdrosen@cisco.com, secdir@ietf.org, secdir-secretary@ietf.org, dpetrie@sipez.com, iesg@ietf.org, rjsparks@nostrum.com Subject: Re: [secdir] SecDir review of draft-ietf-sipping-cc-framework X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 17:09:09 -0000 Magnus, Thanks for your review of the document. See my comments below. Thanks, Alan Magnus Nyström wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Background > ---------- > This document describes a framework for call control and multi-party > usage of SIP (while the abstract also talks about requirements, I did > not see any strong requirements - at least there are no normative > statements in the RFC 2119 sense in the document). > > Comments > -------- > > Although brief, the Security Considerations section reads well (a more > comprehensive trust/threat model analysis for the proposed framework > would have been nice though). It could be useful to add a sentence or > two on anonymity aspects in the context of the proposed framework. The > body of the text mentions this aspect in passing once (2.6.4) but > there is no mentioning in the Security Considerations section. We could add a statement like: "Standard SIP privacy and anonymity mechanisms such as [RFC3323] and [RFC3325] used during SIP session establishment apply equally well to SIP call control operations. SIP call control mechanisms should address privacy and anonymity issues associated with that operation. For example, privacy during a transfer operation using REFER is discussed in Section 7.2 of [draft-ietf-sipping-cc-transfer]." > > > In the sixth paragraph, an explicit method for replay attack > prevention is recommended (lower-case "should"). I am not sure about > the reason for this and could potentially see other ways to mitigate > such attacks. Hence, one suggestion could be to replace the current > "In the case of features initiated by a former participant, these > should be protected against replay attacks by using a unique name or > identifier per invocation" with: > "In the case of features initiated by a former participant, these > should be protected against replay attacks, e.g. by using a unique > name or identifier per invocation." This is a good suggestion - I'm fine with this text. > > For clarity, I also suggest changing this section's last sentence to: > "These credentials may for example need to be passed transitively or > fetched in an event body." I'm fine with this change as well. > > A question: The third paragraph in the Security Considerations section > refers to Section 3.2 - might this be Section 2.3? Yes - we will fix this. > > General/editorial: > > - Abstract states "This framework also describes other goals that > embody the spirit of SIP applications as used on the Internet" - it > would have been useful if this sentence at least had identified a few > of these goals. We can list some like this: "This framework also describes other goals that embody the spirit of SIP applications as used on the Internet such as: definition of primitives, not services; invoker and participant oriented; signaling and mixing model independence, and others." > > > - Section 2.3: "peers can take advantage of end-to-end message > integrity or encryption" - I would say this applies only when certain > conditions are met and hence perhaps something like "peers may take > advantage..." or similar would be better. I'm fine with changing it to: "peers may take advantage of end-to-end message integrity or encryption" > > - Section 2.6.7.2: Acronym "IVR" introduced without explanation. An > early "Acronyms" section would be useful. We will expand IVR, and also 3PCC, URI, JTAPI, CSTA, B2BUA, UA, GSM, HTTP, RTSP, PSTN, W3C, and SDP when they are first mentioned in the text. I'd prefer not to introduce an Acronyms section as most of these acronyms are only used once or twice in the text, but I can if others feel strongly about it. > > - Section 3: The sentence "One means of accomplishing this is through > the ability to define and obtain URIs for these actions as described > in section ." seems to be missing the final section reference. > We will change it to: "One means of accomplishing this is through the ability to define and obtain URIs for these actions as described in Section 2.7.2." > -- Magnus > From prvs=42086607d=acee@redback.com Thu Jun 25 12:59:11 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEAC63A6A72; Thu, 25 Jun 2009 12:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 wX1EGwUv1W0K; Thu, 25 Jun 2009 12:59:11 -0700 (PDT) Received: from mgate.redback.com (mgate.redback.com [155.53.3.41]) by core3.amsl.com (Postfix) with ESMTP id 488083A67A3; Thu, 25 Jun 2009 12:59:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,292,1243839600"; d="scan'208";a="2789552" Received: from prattle.redback.com ([155.53.12.9]) by mgate.redback.com with ESMTP; 25 Jun 2009 12:57:45 -0700 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 9F487F5E95; Thu, 25 Jun 2009 12:57:45 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29083-10; Thu, 25 Jun 2009 12:57:45 -0700 (PDT) Received: from [IPv6???1] (svilogin-1.sj.us.am.ericsson.se [155.53.154.39]) by prattle.redback.com (Postfix) with ESMTP id BF70EF5E8F; Thu, 25 Jun 2009 12:57:43 -0700 (PDT) In-Reply-To: <20090625123048.GC22794@elstar.local> References: <20090625123048.GC22794@elstar.local> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3A1C5198-1BA1-4995-ABCC-2E979F1DB320@redback.com> Content-Transfer-Encoding: 7bit From: Acee Lindem Date: Thu, 25 Jun 2009 15:57:41 -0400 To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.753.1) Cc: ospf-chairs@tools.ietf.org, secdir@ietf.org, iesg@ietf.org, vishwas@ipinfusion.com, djoyal@nortel.com Subject: Re: [secdir] secdir review of draft-ietf-ospf-ospfv3-mib-15.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 20:09:17 -0000 Hi Juergen, Thanks for the help with the MIB security considerations template. I think we can go forward with the IESG telechat on this draft and update these two instances with any IESG comments. Thanks, Acee On Jun 25, 2009, at 8:30 AM, Juergen Schoenwaelder wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > I have reviewed the -14 version of this document and suggested some > changes to the security considerations. This has been addressed and I > am fine with the content of the text now. > > Two minor editorial nits in the new text: > > Replace "MIB" with "MIB module" in the following two text fragments: > > by this MIB may result -> by this MIB module may result > MIB allows the discovery -> MIB module allows the discovery > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 From derek@ihtfp.com Thu Jun 25 19:04:45 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538CE3A6A59; Thu, 25 Jun 2009 19:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] 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 lcu7U9FGfCpU; Thu, 25 Jun 2009 19:04:44 -0700 (PDT) Received: from mail.ihtfp.org (MAIL.IHTFP.ORG [204.107.200.6]) by core3.amsl.com (Postfix) with ESMTP id 88B033A687C; Thu, 25 Jun 2009 19:04:44 -0700 (PDT) Received: from pgpdev.ihtfp.org (PGPDEV.IHTFP.ORG [204.107.200.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail.ihtfp.org (Postfix) with ESMTP id A8AFABD8585; Thu, 25 Jun 2009 22:04:47 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.3/8.14.2/Submit) id n5Q24j0o031586; Thu, 25 Jun 2009 22:04:45 -0400 To: iesg@ietf.org, secdir@ietf.org From: Derek Atkins Date: Thu, 25 Jun 2009 22:04:44 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: douglas@stebila.ca, jon.green@ece.queensu.ca Subject: [secdir] sec-dir review of draft-green-secsh-ecc-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 02:04:45 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies: Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol. I see no security issues with this document. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From sra@hactrn.net Sat Jun 27 14:43:29 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFADC3A6D0F; Sat, 27 Jun 2009 14:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799] 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 wt5YVvcLwL7D; Sat, 27 Jun 2009 14:43:29 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id D2B7D3A687B; Sat, 27 Jun 2009 14:43:28 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 38B8428433; Sat, 27 Jun 2009 21:43:47 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id BD9462286E; Sat, 27 Jun 2009 17:43:46 -0400 (EDT) Date: Sat, 27 Jun 2009 17:43:46 -0400 From: Rob Austein To: iesg@ietf.org, secdir@ietf.org MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20090627214346.BD9462286E@thrintun.hactrn.net> Cc: Danny McPherson , Warren Kumari Subject: [secdir] secdir review of draft-ietf-opsec-blackhole-urpf-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2009 21:43:30 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a BGP-based mitigation technique for denial-of-service attacks, combining two previously known techniques (BGP-triggered black holes and unicast reverse path forwarding -- see RFCs 3704 & 3882) in a clever way to allow configuration of relatively precise rules to discard offending packets with minimal collateral damage (at least by comparision to other known techniques). This is not a protocol draft; it is an explanation of how to use existing tools to handle a real problem. The techniques described require careful attention to detail, there are some tricky router configuration issues setting this stuff up, and the BGP announcements involved really need to be prevented from leaking out of their intended scope. The draft spells out a number of precautions, including use of the BGP NO_EXPORT community and several "belt and suspenders" checks in case all the other precautions fail. Nothing in this space is risk-free, but I am satisfied that the authors have done a reasonable job of identifying the risks and explaining how to manage them. The authors have also included a brief discussion of a variation of uRPF which, if implemented by router vendors, would allow operators to turn on just the part of uRPF that is needed for this mitigation technique, thus reducing one of the associated risks. I do not have any security concerns per se with this draft. Most of the issues above are operational; the only security issue per se is in step 2.3 of section 3.2 ("Customer Triggered" RTBH filtering), and the authors have already specified the obvious restriction. Caveats: - While I am reasonably familiar with how BGP works, I am not a BGP protocol wizard. - I am not a router operator. - I am not competent to debug the configuration examples in the appendices of this draft. From secdir-bounces@mit.edu Thu Jun 25 15:34:20 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8A183A68A4 for ; Thu, 25 Jun 2009 15:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.562 X-Spam-Level: X-Spam-Status: No, score=-106.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 h19h0-hYtRmw for ; Thu, 25 Jun 2009 15:34:19 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 345A73A688B for ; Thu, 25 Jun 2009 15:33:46 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n5PMUeeO026930 for ; Thu, 25 Jun 2009 18:30:40 -0400 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n5PMUd5f026919 for ; Thu, 25 Jun 2009 18:30:39 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n5PMUTDX014249 for ; Thu, 25 Jun 2009 18:30:30 -0400 (EDT) Received: from mail.ietf.org (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 9927715D93D3 for ; Thu, 25 Jun 2009 18:30:25 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mit.edu with ESMTP id pq8Vlb56IO8dv3To for ; Thu, 25 Jun 2009 18:30:24 -0400 (EDT) Received-SPF: pass (mit.edu: domain of new-work-bounces@ietf.org designates 64.170.98.32 as permitted sender) receiver=mit.edu; client_ip=64.170.98.32; envelope-from=new-work-bounces@ietf.org; Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC46128C12C; Thu, 25 Jun 2009 15:30:05 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D8FB33A67D8; Thu, 25 Jun 2009 15:30:02 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20090625223002.D8FB33A67D8@core3.amsl.com> Date: Thu, 25 Jun 2009 15:30:02 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu X-Mailman-Approved-At: Mon, 29 Jun 2009 05:14:05 -0700 Subject: [secdir] [New-work] WG Review: Recharter of Integrated Security Model for SNMP (isms) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 22:34:20 -0000 A modified charter has been submitted for the Integrated Security Model for SNMP (isms) working group in the Security Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Thursday, July 2, 2009. Integrated Security Model for SNMP (isms) ========================================= Last Modified: 2009-06-18 Current Status: Active Working Group Chair(s): Juergen Schoenwaelder Security Area Director(s): Tim Polk Pasi Eronen Security Area Advisor: Pasi Eronen Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem definition, a new Transport Security Model, and a Secure Shell Transport Model and a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). The initial body of work to be tackled by the working group involved only these pieces. Additional work on other transport models and other security extensions were to wait until the initial transport architecture and defining documents were completed. It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the newly defined SSH transport. However, it still remains impossible to centrally authorize a given SNMP transaction as on-device pre-existing authorization configuration is still required. In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be an extension to obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing named access control policies, defining session timeouts, and similar session parameters. This mechanism will not provision the detailed access control rules. Additionally, new work will be undertaken to define TLS and DTLS-based transports that can offer support for environments that prefer certificate authentication. Certificate based authentication is desirable for many environments with a centralized authentication service. DTLS also provides datagram-based transmissions which may be desired for environments where TCP performance suffers because of network anomalies (e.g. high packet loss rates). A combination of TLS and DTLS-based transports offers solutions that addresses both the need for certificate-based authentication and for datagram-based delivery. Operators will be able to chose the transport solution that best meets their needs. The current goal of the ISMS working group is two-fold: to develop a method for allowing for access control decisions to be based on information provide by an AAA provisioning service and to develop TLS-based and DTLS-based Transport Models. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions by means of a RADIUS-provisioned policy name bound to a username, which the VACM extension will use to dynamically populate the securityToGroupname table. Additionally, specify a time limit for access decisions, and such a time limit should be used to garbage collect expired dynamic securityToGroup mappings. - Specify TLS and DTLS transport models for SNMP. Goals and Milestones: Jul 2009 Publish initial documentation on the (D)TLS transports for SNMP Jul 2009 Publish initial documentation for the centralized access control Jan 2010 Submit documentation on the (D)TLS transports for SNMP to IESG Jan 2010 Submit documentation for the centralized access control to IESG _______________________________________________ New-work mailing list New-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From pcain2@mail2.coopercain.com Mon Jun 29 07:12:38 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61B1A28C268; Mon, 29 Jun 2009 07:12:38 -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 ehueFuWzo-xv; Mon, 29 Jun 2009 07:12:37 -0700 (PDT) Received: from server1.acmehacking.com (server1.acmehacking.com [72.51.39.79]) by core3.amsl.com (Postfix) with ESMTP id B198728C255; Mon, 29 Jun 2009 07:12:37 -0700 (PDT) Received: from familyroom (familyroom8.bc.edu [136.167.27.78]) (authenticated bits=0) by server1.acmehacking.com (8.14.3/8.13.8) with ESMTP id n5TECJnb020836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Jun 2009 09:12:49 -0500 Received: from familyroom by familyroom (PGP Universal service); Mon, 29 Jun 2009 10:12:53 -0500 X-PGP-Universal: processed; by familyroom on Mon, 29 Jun 2009 10:12:53 -0500 From: "pat cain" To: , Date: Mon, 29 Jun 2009 10:12:22 -0400 Message-ID: <039b01c9f8c3$a108a7e0$e319f7a0$@coopercain.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn4w5iFLrA4q3muRTSpPrluE93lVA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us Cc: iesg@ietf.org Subject: [secdir] secdir review of draft-ietf-ancp-framework-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 14:12:38 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a framework for an Access Node Control Mechanism between a Network Access Server and a DSLAM. It is informational. I have a mostly small comment on this document: The security considerations section points to "draft-ietf-ancp-security-threats that lists the security-related security threats". I read that document, too. It has more than threats in it; there a whole section on security requirements. I would add a small phrase to the security considerations of the framework to make sure the reader is aware that there are more requirements than just what is in the framework document. Maybe just add a few words to the first sentence of the security considerations section in the framework: "I develops a threat model [ and identifies requirements] for ANCP security...." Otherwise it looked okay to me. Pat Cain From dharkins@lounge.org Mon Jun 29 17:48:37 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E1013A6927; Mon, 29 Jun 2009 17:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 LQY1IllSGMWs; Mon, 29 Jun 2009 17:48:36 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 6A7F93A67D4; Mon, 29 Jun 2009 17:48:36 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 35CA010224074; Mon, 29 Jun 2009 17:48:57 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 29 Jun 2009 17:48:57 -0700 (PDT) Message-ID: Date: Mon, 29 Jun 2009 17:48:57 -0700 (PDT) From: "Dan Harkins" To: secdir@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tom.nadeau@bt.com, matthew.bocci@alcatel-lucent.com, cpignata@cisco.com, iesg@ietf.org, pwe3-chairs@tools.ietf.org Subject: [secdir] secdir review of draft-ietf-pwe3-vccv-bfd-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 00:48:37 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft adds some new types verify connectivity and signal fault detection or fault status over a Pseudowire. It states that it introduces no new security issues beyond those defined in RFC 5085 and a couple of I-Ds on Bidirectional Forwarding Detection (BFD) and that seems to be correct. I see no security issues with this draft. On a non-security issue though, it appears that when doing IP encapsulation of BFD it sends to a randomly selected IP address from the loopback. I always thought that a loopback address MUST NOT appear outside a router or host. Has that changed or am I misunderstanding something about this draft? regards, Dan. From cpignata@cisco.com Mon Jun 29 18:56:52 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2C323A6ADE; Mon, 29 Jun 2009 18:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.531 X-Spam-Level: X-Spam-Status: No, score=-4.531 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 INOypRrjrTjg; Mon, 29 Jun 2009 18:56:50 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7A5DB3A6A49; Mon, 29 Jun 2009 18:56:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,312,1243814400"; d="scan'208,217";a="48939610" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Jun 2009 01:57:10 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5U1vAtn025022; Mon, 29 Jun 2009 21:57:10 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5U1vAM1015956; Tue, 30 Jun 2009 01:57:10 GMT Received: from xmb-rtp-204.amer.cisco.com ([64.102.31.25]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 21:57:10 -0400 Received: from 171.70.151.174 ([171.70.151.174]) by xmb-rtp-204.amer.cisco.com ([64.102.31.25]) with Microsoft Exchange Server HTTP-DAV ; Tue, 30 Jun 2009 01:57:10 +0000 Message-ID: <71584B08-4026-4DBE-9694-FBF3302C3336@cisco.com> From: "Carlos Pignataro (cpignata)" To: "Dan Harkins" Content-Type: multipart/alternative; boundary="Apple-Mail-2--415631695"; charset="iso-8859-1" Thread-Topic: secdir review of draft-ietf-pwe3-vccv-bfd-05 Thread-Index: Acn5JhQmBHz+aiwuQry+YJ3Yx+6B+g== Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (iPhone Mail 7A341) Date: Mon, 29 Jun 2009 21:57:02 -0400 X-OriginalArrivalTime: 30 Jun 2009 01:57:10.0322 (UTC) FILETIME=[14684120:01C9F926] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5689; t=1246327030; x=1247191030; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=cpignata@cisco.com; z=From:=20=22Carlos=20Pignataro=20(cpignata)=22=20 |Subject:=20Re=3A=20secdir=20review=20of=20draft-ietf-pwe3- vccv-bfd-05 |Sender:=20 |To:=20=22Dan=20Harkins=22=20; bh=ICmN9wJKAGNtcX3NLmM37pplgZ/VmhyiHe76TJpusa8=; b=YmfwVvKc5hsY/UVZrl0znubPtgSAgAhjIiLVprDbL0F4Tw3LVPdF/mMTHm NIHUlK9Zfgepr4p5nPbG2IhhhgZU2Tan4eHkv99fJGtujUpur2fSC60f3Mjr 48oM1uL+y4; Authentication-Results: rtp-dkim-1; header.From=cpignata@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: tom.nadeau@bt.com, pwe3-chairs@tools.ietf.org, matthew.bocci@alcatel-lucent.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-pwe3-vccv-bfd-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 01:56:52 -0000 --Apple-Mail-2--415631695 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello Dan, Thank you for your review and the security-focus validation of the document. Regarding the non-security issue, your understanding of the draft is correct; however this is already addressed in S3.2 of the draft: "The destination IP address is a (randomly chosen) IPv4 address from the range 127/8 or IPv6 address from the range 0:0:0:0:0:FFFF:127.0.0.0/104. The rationale is explained in Section 2.1 of [RFC4379]." Hope this clarifies and thanks again for your review. -- Thumb typed by Carlos Pignataro. On Jun 29, 2009, at 8:49 PM, "Dan Harkins" wrote: > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > This draft adds some new types verify connectivity and signal fault > detection or fault status over a Pseudowire. It states that it > introduces > no new security issues beyond those defined in RFC 5085 and a couple > of > I-Ds on Bidirectional Forwarding Detection (BFD) and that seems to be > correct. I see no security issues with this draft. > > On a non-security issue though, it appears that when doing IP > encapsulation of BFD it sends to a randomly selected IP address from > the > loopback. I always thought that a loopback address MUST NOT appear > outside > a router or host. Has that changed or am I misunderstanding something > about this draft? > > regards, > > Dan. > > > --Apple-Mail-2--415631695 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj48ZGl2PjxkaXY+SGVsbG8gRGFuLDxi cj48YnI+PC9kaXY+PGRpdj5UaGFuayB5b3UgZm9yIHlvdXIgcmV2aWV3IGFuZCB0aGUgc2VjdXJp dHktZm9jdXMgdmFsaWRhdGlvbiBvZiB0aGUgZG9jdW1lbnQuPC9kaXY+PGRpdj5SZWdhcmRpbmcg dGhlIG5vbi1zZWN1cml0eSBpc3N1ZSwgeW91ciB1bmRlcnN0YW5kaW5nIG9mIHRoZSBkcmFmdCBp cyBjb3JyZWN0OyBob3dldmVyIHRoaXMgaXMgYWxyZWFkeSBhZGRyZXNzZWQgaW4gUzMuMiBvZiB0 aGUgZHJhZnQ6ICZuYnNwOzwvZGl2PjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHls ZT0iZm9udC1mYW1pbHk6IFRpbWVzOyBmb250LXNpemU6IDE2cHg7IC13ZWJraXQtdGFwLWhpZ2hs aWdodC1jb2xvcjogcmdiYSgyNiwgMjYsIDI2LCAwLjI5Njg3NSk7IC13ZWJraXQtY29tcG9zaXRp b24tZmlsbC1jb2xvcjogcmdiYSgxNzUsIDE5MiwgMjI3LCAwLjIzMDQ2OSk7IC13ZWJraXQtY29t cG9zaXRpb24tZnJhbWUtY29sb3I6IHJnYmEoNzcsIDEyOCwgMTgwLCAwLjIzMDQ2OSk7ICI+PHBy ZSBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7ICI+ ICAgICAiVGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3MNCiAgICAgIGlzIGEgKHJhbmRvbWx5IGNo b3NlbikgSVB2NCBhZGRyZXNzIGZyb20gdGhlIHJhbmdlIDEyNy84IG9yIElQdjYNCiAgICAgIGFk ZHJlc3MgZnJvbSB0aGUgcmFuZ2UgMDowOjA6MDowOkZGRkY6MTI3LjAuMC4wLzEwNC4gIFRoZQ0K ICAgICAgcmF0aW9uYWxlIGlzIGV4cGxhaW5lZCBpbiBTZWN0aW9uIDIuMSBvZiBbUkZDNDM3OV0u Ijxicj48L3ByZT48L3NwYW4+PGRpdj5Ib3BlIHRoaXMgY2xhcmlmaWVzIGFuZCB0aGFua3MgYWdh aW4gZm9yIHlvdXIgcmV2aWV3LiZuYnNwOzwvZGl2PjxkaXY+PGJyPi0tPGRpdj5UaHVtYiB0eXBl ZCBieSBDYXJsb3MgUGlnbmF0YXJvLjwvZGl2PjwvZGl2PjxkaXY+PGJyPk9uIEp1biAyOSwgMjAw OSwgYXQgODo0OSBQTSwgIkRhbiBIYXJraW5zIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRoYXJraW5z QGxvdW5nZS5vcmciPjxhIGhyZWY9Im1haWx0bzpkaGFya2luc0Bsb3VuZ2Uub3JnIj5kaGFya2lu c0Bsb3VuZ2Uub3JnPC9hPjwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGRpdj48L2Rpdj48 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2PjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+ICZuYnNw O0kgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRp cmVjdG9yYXRlJ3M8L3NwYW4+PGJyPjxzcGFuPm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwg SUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZTwvc3Bhbj48YnI+PHNwYW4+SUVT Ry4gJm5ic3A7VGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJl bmVmaXQgb2YgdGhlPC9zcGFuPjxicj48c3Bhbj5zZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gJm5i c3A7RG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdDwvc3Bhbj48YnI+ PHNwYW4+dGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVu dHMuPC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjxzcGFuPiAmbmJzcDtUaGlzIGRyYWZ0IGFk ZHMgc29tZSBuZXcgdHlwZXMgdmVyaWZ5IGNvbm5lY3Rpdml0eSBhbmQgc2lnbmFsIGZhdWx0PC9z cGFuPjxicj48c3Bhbj5kZXRlY3Rpb24gb3IgZmF1bHQgc3RhdHVzIG92ZXIgYSBQc2V1ZG93aXJl LiBJdCBzdGF0ZXMgdGhhdCBpdCBpbnRyb2R1Y2VzPC9zcGFuPjxicj48c3Bhbj5ubyBuZXcgc2Vj dXJpdHkgaXNzdWVzIGJleW9uZCB0aG9zZSBkZWZpbmVkIGluIFJGQyA1MDg1IGFuZCBhIGNvdXBs ZSBvZjwvc3Bhbj48YnI+PHNwYW4+SS1EcyBvbiBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0 ZWN0aW9uIChCRkQpIGFuZCB0aGF0IHNlZW1zIHRvIGJlPC9zcGFuPjxicj48c3Bhbj5jb3JyZWN0 LiBJIHNlZSBubyBzZWN1cml0eSBpc3N1ZXMgd2l0aCB0aGlzIGRyYWZ0Ljwvc3Bhbj48YnI+PHNw YW4+PC9zcGFuPjxicj48c3Bhbj4gJm5ic3A7T24gYSBub24tc2VjdXJpdHkgaXNzdWUgdGhvdWdo LCBpdCBhcHBlYXJzIHRoYXQgd2hlbiBkb2luZyBJUDwvc3Bhbj48YnI+PHNwYW4+ZW5jYXBzdWxh dGlvbiBvZiBCRkQgaXQgc2VuZHMgdG8gYSByYW5kb21seSBzZWxlY3RlZCBJUCBhZGRyZXNzIGZy b20gdGhlPC9zcGFuPjxicj48c3Bhbj5sb29wYmFjay4gSSBhbHdheXMgdGhvdWdodCB0aGF0IGEg bG9vcGJhY2sgYWRkcmVzcyBNVVNUIE5PVCBhcHBlYXIgb3V0c2lkZTwvc3Bhbj48YnI+PHNwYW4+ YSByb3V0ZXIgb3IgaG9zdC4gSGFzIHRoYXQgY2hhbmdlZCBvciBhbSBJIG1pc3VuZGVyc3RhbmRp bmcgc29tZXRoaW5nPC9zcGFuPjxicj48c3Bhbj5hYm91dCB0aGlzIGRyYWZ0Pzwvc3Bhbj48YnI+ PHNwYW4+PC9zcGFuPjxicj48c3Bhbj4gJm5ic3A7cmVnYXJkcyw8L3NwYW4+PGJyPjxzcGFuPjwv c3Bhbj48YnI+PHNwYW4+ICZuYnNwO0Rhbi48L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PHNw YW4+PC9zcGFuPjxicj48c3Bhbj48L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48 ZGl2PjwvZGl2PjwvZGl2PjxkaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-2--415631695-- From d3e3e3@gmail.com Mon Jun 29 20:11:43 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62C7D3A6C79; Mon, 29 Jun 2009 20:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, 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 JgdALlDaIqQ3; Mon, 29 Jun 2009 20:11:42 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 322F03A6C70; Mon, 29 Jun 2009 20:11:42 -0700 (PDT) Received: by bwz9 with SMTP id 9so3634424bwz.37 for ; Mon, 29 Jun 2009 20:11:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=BPjpe/nFhbTLBGPHr2gGq7yHms68hKXs6Ie4zUZjw5U=; b=jL1yCQmx+Wj1l2lZIT+UZApSm3TQp2x423Gog+KAdzZrl+3aORYj6Om8Fw4Z/G/I2F 51R5kLBHZMwqqFt9/ek6QKHB5VBScaQ7NdUCsW5NwauLcLBqQTP5/bGjr1fiWdSe1qVU Z/fEDLO7cnh7iaHrv3fTc4WpeT7dlaKtwFR1E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=jKwRrYbQJ+7p8HU2H/5GPUyWjS9n59jb/4RIok7jIU495DjP7zKE00OzZLLgUiX7w1 7nDBzyS2ePJEtzMgqVuseW//N2u3jVNq/MoERJMpXtnmx/5M7jWpjoYkJObcbrTzbLDX Oe6/ta81BdRKjwhkCgYM1PKCyLfQhSCPB9r+Q= MIME-Version: 1.0 Received: by 10.204.118.132 with SMTP id v4mr5621049bkq.3.1246331519544; Mon, 29 Jun 2009 20:11:59 -0700 (PDT) Date: Mon, 29 Jun 2009 23:11:59 -0400 Message-ID: <1028365c0906292011j5200fcfbj86069f873f955921@mail.gmail.com> From: Donald Eastlake To: iesg@ietf.org, secdir@ietf.org, jouni.korhonen@nsn.com, Hannes.Tschofenig@gmx.net, mayutan.arumaithurai@gmail.com, mark.jones@bridgewatersystems.com, avi@bridgewatersystems.com, Victor Fajardo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] draft-ietf-dime-qos-attributes-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 03:11:43 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft extends Diameter capabilities specified in RFC 3588 and RFC 4005 related to packet filter and QoS rules. The document defers its security considerations in their entirety to the Diameter base protocol specification, RFC 3588. These documents all seem reasonably consistent and there do not appear to be significant new security considerations here. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-634-2066 (home) 155 Beaver Street Milford, MA 01757 USA d3e3e3@gmail.com From secdir-bounces@mit.edu Mon Jun 29 21:57:51 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9739A3A6A93 for ; Mon, 29 Jun 2009 21:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 Lw42TU7Rg87q for ; Mon, 29 Jun 2009 21:57:50 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 9D4873A6D95 for ; Mon, 29 Jun 2009 21:57:50 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n5U4wBnM025817 for ; Tue, 30 Jun 2009 00:58:11 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n5U4w8iJ025802 for ; Tue, 30 Jun 2009 00:58:08 -0400 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n5U4w1uM014451 for ; Tue, 30 Jun 2009 00:58:01 -0400 (EDT) Received: from sj-iport-2.cisco.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 2B9F5123157B for ; Tue, 30 Jun 2009 00:58:00 -0400 (EDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by mit.edu with ESMTP id tFcHRBsWnU6gBV50 (version=TLSv1 cipher=RC4-SHA bits=128 verify=NO) for ; Tue, 30 Jun 2009 00:58:00 -0400 (EDT) X-Barracuda-Envelope-From: jsalowey@cisco.com Received-SPF: pass (mit.edu: domain of jsalowey@cisco.com designates 171.71.176.71 as permitted sender) receiver=mit.edu; client_ip=171.71.176.71; envelope-from=jsalowey@cisco.com; X-IronPort-AV: E=Sophos;i="4.42,314,1243814400"; d="scan'208";a="181545782" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 30 Jun 2009 04:57:59 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5U4vx3F026547; Mon, 29 Jun 2009 21:57:59 -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.14.3) with ESMTP id n5U4vxHs009204; Tue, 30 Jun 2009 04:57:59 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 21:57:58 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 29 Jun 2009 21:57:57 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Secdir review of draft-dawkins-nomcom-dont-wait-03 Thread-Index: Acn5P1XeXCWr2lcsR4uFYJqSfMRG8w== From: "Joseph Salowey (jsalowey)" To: , , X-OriginalArrivalTime: 30 Jun 2009 04:57:59.0204 (UTC) FILETIME=[56D84640:01C9F93F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=134; t=1246337879; x=1247201879; 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:=20Secdir=20review=20of=20draft-dawkins-nomcom-don t-wait-03 |Sender:=20; bh=mlj1MtLdCcx8dC1KRpjHN5fYOCU7jaT3+yzn3Amm9N8=; b=VzOL6UNk0sgI+5KRr7vgjXh8WpQcxEBNSAa13e6TA894Ne38fi9U57dToR 37lMCXQY+xP9zGY5UOl3fAVq8Gp6BaY8yo4t8cBVTIjFnl1IB2NGIYuDsHdE k8ks5Oye+5; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Scanned-By: MIMEDefang 2.42 X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id n5U4w8iJ025802 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Subject: [secdir] Secdir review of draft-dawkins-nomcom-dont-wait-03 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 04:57:51 -0000 I have reviewed the draft draft-dawkins-nomcom-dont-wait-03 and have found no security issues with the draft. Cheers, Joe _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From secdir-bounces@mit.edu Tue Jun 30 05:35:49 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116113A6E55 for ; Tue, 30 Jun 2009 05:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 OOCgbNU61nzt for ; Tue, 30 Jun 2009 05:35:48 -0700 (PDT) Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id 24F3E3A6C8E for ; Tue, 30 Jun 2009 05:35:47 -0700 (PDT) Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n5UCZrRe011207 for ; Tue, 30 Jun 2009 08:35:53 -0400 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n5UCZoHH011173 for ; Tue, 30 Jun 2009 08:35:50 -0400 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n5UCZf7c014712 for ; Tue, 30 Jun 2009 08:35:41 -0400 (EDT) Received: from smtp152.iad.emailsrvr.com (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id A0C4016575BC for ; Tue, 30 Jun 2009 08:35:36 -0400 (EDT) Received: from smtp152.iad.emailsrvr.com (smtp152.iad.emailsrvr.com [207.97.245.152]) by mit.edu with ESMTP id MzC2vmUECGmtXBrz (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 30 Jun 2009 08:35:36 -0400 (EDT) Received: from relay15.relay.iad.mlsrvr.com (localhost [127.0.0.1]) by relay15.relay.iad.mlsrvr.com (SMTP Server) with ESMTP id 0E4D71B4092; Tue, 30 Jun 2009 08:35:36 -0400 (EDT) Received: by relay15.relay.iad.mlsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id F16C41B4114; Tue, 30 Jun 2009 08:35:34 -0400 (EDT) Message-ID: <4A4A0695.4000105@hyperthought.com> Date: Tue, 30 Jun 2009 05:35:33 -0700 From: "Scott G. Kelly" User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: secdir@mit.edu, iesg@ietf.org X-Enigmail-Version: 0.95.7 X-Scanned-By: MIMEDefang 2.42 X-BeenThere: secdir@mit.edu X-Mailman-Version: 2.1.6 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: secdir-bounces@mit.edu Errors-To: secdir-bounces@mit.edu Cc: chris_griffiths@cable.comcast.com, richard_woundy@cable.comcast.com, yry@cs.yale.edu, alto-chairs@tools.ietf.org, laird@pando.com, jason_livingood@cable.comcast.com Subject: [secdir] draft-livingood-woundy-p4p-experiences-10 X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 12:35:49 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This is in informational document describing a technical trial of a proposed approach to peer-to-peer traffic flow improvement. Here's the security considerations section: "7. Security Considerations There are no security considerations in this document. NOTE TO RFC EDITOR: PLEASE REMOVE THIS NULL SECTION PRIOR TO PUBLICATION." The current instructions to RFC authors are at http://www.rfc-editor.org/rfc-editor/instructions2authors.txt This document says "All RFCs must contain a section that discusses the security considerations relevant to the specification in the RFC; see [Secur03] for more information.", so the RFC editor is probably not going to remove this section. RFC 3552 (referenced as Secur03 above) gives further guidance. I believe that the mechanism proposed/described by the document certainly has security considerations, and any developers/deployers of such a protocol should do a thorough analysis as a fundamental element of the effort. However, since this document is an informational presentation of a study that was undertaken, it is probably most appropriate to simply state how security considerations were addressed. If security was entirely ignored (the network was assumed to be benign, messages between clients and trackers were sent in the clear with no authentication), it is probably important to explicitly say so. If security mechanisms were employed, then I think that a discussion of what threats were perceived and addressed might be helpful in interpreting the data. --Scott _______________________________________________ secdir mailing list secdir@mit.edu https://mailman.mit.edu/mailman/listinfo/secdir From flefauch@cisco.com Tue Jun 30 09:59:36 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DD7E3A6CF1; Tue, 30 Jun 2009 09:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.312 X-Spam-Level: X-Spam-Status: No, score=-10.312 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 cBsydgrfQneP; Tue, 30 Jun 2009 09:59:35 -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 474633A68E5; Tue, 30 Jun 2009 09:59:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,317,1243814400"; d="scan'208,217";a="44025404" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 30 Jun 2009 16:58:38 +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 n5UGwZDl032720; Tue, 30 Jun 2009 18:58:35 +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.14.3) with ESMTP id n5UGwZV6017238; Tue, 30 Jun 2009 16:58:35 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 18:58:35 +0200 Received: from [144.254.53.207] ([144.254.53.207]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jun 2009 18:58:31 +0200 Message-Id: From: Francois Le Faucheur IMAP To: Stefan Santesson In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-25--361547119 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 30 Jun 2009 18:58:28 +0200 References: X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 30 Jun 2009 16:58:31.0656 (UTC) FILETIME=[FF64EE80:01C9F9A3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8269; t=1246381115; x=1247245115; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20SecDir=20review=20of=20draft-ietf-tsvwg -rsvp-l3vpn-02 |Sender:=20; bh=fkOM+me4q4It9a4Y2JfmkhYUwYkI9/aeO2HsGc4M3a4=; b=t4bUyA6IKgZbqY1hWohi+lFWu+idiwuoJLoI8lNWZ45Yj213tSYH/SCv01 Ik25CaG8P6jTmyH7Ybsn0/vBIc6fBmxHZLnMFOvHgH4OacOF7ju1Jk9AVXD3 cK6BG/WPln; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: Gorry Fairhurst , Magnus Westerlund , Francois Le Faucheur IMAP , Bruce Davie , secdir@ietf.org, iesg@ietf.org, Ashok Narayanan , James Polk Subject: Re: [secdir] SecDir review of draft-ietf-tsvwg-rsvp-l3vpn-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 16:59:36 -0000 --Apple-Mail-25--361547119 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello Stefan, Thanks for your review. Please find a response to your question embedded below: On 23 Jun 2009, at 18:51, Stefan Santesson wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should > treat these comments just like any other last call comments. > > This specification define a set of procedures to overcome challenges > with deployment of Resource Reservation Protocols over BGP/MPLS VPNs. > > The BGP/MPLS VPN (RFC 4364) is a VPN technique that doesn't rely > encryption to ensure secrecy or message integrity. The security > properties are instead dependent on the security of the network > infrastructure. > > It appears that this draft makes a serious effort to describe and > analyze relevant security considerations. With my limited expertise > in this particular area I can't find any thing that is obviously > missing. > > However, one question that comes to my mind, which might be worth > looking at from a security perspective, is whether the procedures > introduced by this document requires the communication to be > unencrypted and if so, whether deployment of this protocol blocks or > prevents legitimate use of e.g. IPsec based VPN as discussed in RFC > 4364 and RFC 4023. If this is the case, should it be discussed in > the security considerations section? The short answer is that this document does not require that communication be un-encrypted. The longer answer would be: RFC4364 mentions use of IPsec both CE-CE and PE-PE: Specifically, I noticed: "Cryptographic privacy is not provided by this architecture, nor by Frame Relay or ATM VPNs. These architectures are all compatible with the use of cryptography on a CE-CE basis, if that is desired. The use of cryptography on a PE-PE basis is for further study." Regarding PE-PE IPsec: * RSVP over VPN would work just fine (as currently specified) for PE- CE links * RSVP over VPN would not allow CAC over MPLS Core as we need TE tunnels to do that which I believe could not be used with MPLS over IP/ IPsec in the core. Regarding CE-CE IPsec (or if IPsec starts deeper inside the VPN site): RFC 4923 "Quality of Service (QoS) Signaling in a Nested Virtual Private Network" describes a model for RSVP operation through IPsec Gateways (in a nutshell, the idea is that there is effectively a form of hierarchical RSVP where an RSVP reservation is made for the IPsec tunnel and then individual RSVP reservations are admitted/aggregated over the tunnel reservation). This would apply in case to the case of CE-CE IPsec (or if IPsec starts deeper inside the VPN site) and the procedures defined in the document would simply apply "as is" to the reservation for the tunnel(s) (and not to the individual end to end RSVP reservation). If this answers your question appropriately, we could add text capturing this in the Security Considerations (whenever we issue the next rev). Please let us if this works for you. Thanks Francois > > > Stefan Santesson > AAA-sec.com > > > > > --Apple-Mail-25--361547119 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello = Stefan,

Thanks for your review. Please find a = response to your question embedded below:

On 23 = Jun 2009, at 18:51, Stefan Santesson wrote:

= I have reviewed this document as part of the = security directorate's ongoing effort to review all IETF documents being = processed by the IESG.  These comments were written primarily for = the benefit of the security area directors.  Document editors and = WG chairs should treat these comments just like any other last call = comments.

This specification define a set of procedures to = overcome challenges with deployment of Resource Reservation Protocols = over BGP/MPLS VPNs.

The BGP/MPLS VPN (RFC 4364) is a VPN = technique that doesn't rely encryption to ensure secrecy or message = integrity. The security properties are instead dependent on the security = of the network infrastructure.

It appears that this draft = makes a serious effort to describe and analyze relevant security = considerations. With my limited expertise in this particular area I = can't find any thing that is obviously missing.

However, one = question that comes to my mind, which might be worth looking at from a = security perspective, is whether the procedures introduced by this = document requires the communication to be unencrypted and if so, whether = deployment of this protocol blocks or prevents legitimate use of e.g. = IPsec based VPN as discussed in RFC 4364 and RFC 4023. If this is the = case, should it be discussed in the security considerations = section?

The = short answer is that this document does not require that communication = be un-encrypted.

The longer answer would = be:

RFC4364 mentions use of IPsec both CE-CE = and PE-PE:
Specifically, I noticed: "Cryptographic privacy is not = provided by this architecture, nor by Frame Relay or ATM VPNs. These = architectures are all compatible with the use of cryptography on a CE-CE = basis, if that is desired. The use of cryptography on a PE-PE basis is = for further study."

Regarding PE-PE IPsec:
* RSVP = over VPN would work just fine (as currently specified) for PE-CE = links
= * RSVP over VPN would not allow CAC over MPLS Core as we need TE = tunnels to do that which I believe could not be used with MPLS over = IP/IPsec in the core.

Regarding CE-CE IPsec (or if IPsec starts = deeper inside the VPN site):
RFC 4923 "Quality of Service = (QoS) Signaling in a Nested Virtual Private Network" describes a model = for RSVP operation through IPsec Gateways (in a nutshell, the idea is = that there is effectively a form of hierarchical RSVP where an RSVP = reservation is made for the IPsec tunnel and then individual RSVP = reservations are admitted/aggregated over the tunnel reservation). This = would apply in case to the case of CE-CE IPsec (or if IPsec starts = deeper inside the VPN site) and the procedures defined in the document = would simply apply "as is" to the reservation for the tunnel(s) (and not = to the individual end to end RSVP = reservation).

If this answers your question = appropriately, we could add text capturing this in the Security = Considerations (whenever we issue the next rev). Please let us if this = works for = you.

Thanks

Francois

=
Stefan Santesson
AAA-sec.com



=

=

= --Apple-Mail-25--361547119-- From clonvick@cisco.com Tue Jun 30 12:24:16 2009 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7C63A6EB1; Tue, 30 Jun 2009 12:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 se4yRMiJZRHn; Tue, 30 Jun 2009 12:24:16 -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 28BBB3A6EB5; Tue, 30 Jun 2009 12:24:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,318,1243814400"; d="scan'208";a="334915986" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 30 Jun 2009 19:23:53 +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 n5UJNrJq002538; Tue, 30 Jun 2009 12:23:53 -0700 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5UJNriR021727; Tue, 30 Jun 2009 19:23:53 GMT Date: Tue, 30 Jun 2009 12:23:53 -0700 (PDT) From: Chris Lonvick To: iesg@ietf.org, secdir@ietf.org, Thomas.Froment@alcatel-lucent.fr, Christophe.Lebel@alcatel-lucent.fr, ben.bonnaerens@alcatel-lucent.be, Dean Willis , Keith Drage , Dan Romascanu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1147; t=1246389833; x=1247253833; 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:=20secdir=20review=20of=20draft-ietf-sip-record-ro ute-fix-06 |Sender:=20; bh=a+6GwDdgBGdOOjTLXpMbSMVSE5CO1qVOpWDL1quvFx8=; b=UEOFvr3t3Lfj1YO7QxS8lm2OxItLBxZ73VjbYKMNspDnKEEG8Jowd5cVWm 1PDFlXa/U0GDIr4Af9bol5tVtR4e/KyhPNCH8YhaV8RrQ3sKOcFQ4ieR3VUD ZylhUuw5SUOF2cQvoI7OdtFV6bxyjlPZix16xclUNnl+MiwdhcozQ=; Authentication-Results: sj-dkim-1; header.From=clonvick@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [secdir] secdir review of draft-ietf-sip-record-route-fix-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 19:24:16 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document explans the problems with SIP record route recommendations from prior documents and proposes a solution that should result in consistent behaviour. While I am not intimately familiar with SIP and SIP proxying, I think that this is a good thing. The Security Considerations section is appropriate for this document. I did come across two nits in my review. The first is that the Abstract contains "sip" and "sips" but those are all uppercase throughout the rest of the document. The rest of that paragraph could use some scrutiny as well to make some parts of it more clear. Also, the third paragraph in section 5 talks about a "spiral". That concept is not defined in this document so I couldn't tell if it is a good thing, or a bad thing. Regards, Chris